← Todos os artigos
Construir a coisa certa
Como escrever um brief de produto de uma página que seja mesmo usado
Pela equipa FabricLoop · maio de 2026 · 4 min de leitura
A maioria dos briefs de produto tem o mesmo destino: são escritos com cuidado antes de um projeto arrancar, revistos uma vez numa reunião de arranque e nunca mais abertos. Quando a equipa está a meio da construção, o brief é um artefacto histórico — citado de vez em quando em discussões sobre âmbito, mas raramente usado como guia vivo para a tomada de decisões.
Isto é uma falha de processo, não uma falha de formato. O brief não é usado porque não foi escrito para ser usado. Foi escrito para cumprir um processo — para assinalar a caixa "definimos os requisitos" — e não para ajudar realmente a equipa a tomar melhores decisões em contexto de incerteza.
Um brief que é usado é curto, assertivo e estruturado em torno das perguntas que a equipa vai realmente fazer a meio da construção: o que estamos a resolver, para quem e como saberemos se resultou?
"Um brief não é um documento de requisitos. É uma referência para a tomada de decisões — uma única página que a equipa pode consultar sempre que não tiver a certeza de que uma escolha de design ou uma decisão de âmbito está correta."
As cinco secções que importam
Tudo o que consta de um brief de produto deve responder a uma de cinco perguntas. Se uma secção não responder a nenhuma delas, provavelmente não deveria estar num brief de uma página — deveria estar numa especificação separada e mais detalhada.
Problema
Os utilizadores estão a perder atualizações importantes porque não conseguem distinguir entre notificações de sinal elevado (alguém lhes atribuiu uma tarefa) e de sinal baixo (um comentário num tópico que estão a seguir). O resultado: ou ignoram todas as notificações ou desligam-nas por completo. Os pedidos de apoio do tipo "Eu não sabia" representam 18% de todas as reclamações sobre o produto neste trimestre.
Utilizadores
Primários: líderes de equipa e responsáveis de projeto que são mencionados com frequência e não conseguem acompanhar o volume. Secundários: colaboradores individuais que querem silêncio por defeito, mas precisam de ver as atribuições críticas. Não estamos a visar os utilizadores administradores — as necessidades de notificação deles são tratadas pelo painel de administração.
Métrica de sucesso
Primária Os pedidos de apoio relacionados com notificações descem 40% nos 60 dias seguintes ao lançamento.
Secundária Os utilizadores ativos semanais que personalizaram as preferências sobem de 12% para 35%.
Indicador avançado A taxa de desativação (utilizadores que desativam todas as notificações) desce de 23% para menos de 15%.
Fora do âmbito
- Preferências de notificações por e-mail (item de trabalho separado — infraestrutura diferente)
- Definições de notificações por espaço de trabalho (futuro; esta versão é apenas por utilizador)
- Agendamento de notificações / horário de não incomodar (necessidade validada, roadmap do 3.º trimestre)
- Granularidade das notificações push no telemóvel (primeiro web; o telemóvel segue-se se for validado)
Questões em aberto
Bloqueante Devemos agrupar as notificações em 2 níveis (crítico / tudo o resto) ou permitir um controlo granular por tipo? As entrevistas a utilizadores sugerem 2 níveis, mas a engenharia prefere granular, pela flexibilidade. É preciso decidir antes de o design começar.
Não bloqueante As alterações às preferências devem aplicar-se retroativamente às notificações existentes? Pode decidir-se durante a construção, com base no custo técnico.
Porque é que "fora do âmbito" é a secção mais importante
As equipas gastam muito tempo a escrever o que vão construir. Gastam muito pouco a escrever o que não vão construir — e essa assimetria causa a maior parte do scope creep. Quando o designer acrescenta um botão de "horário silencioso" porque parece óbvio, ou o engenheiro acrescenta definições por espaço de trabalho porque já está nessa área, é geralmente porque ninguém decidiu explicitamente que isso estava fora do âmbito.
Escrever os itens fora do âmbito força uma conversa sobre limites que, de outro modo, só aconteceria a meio da construção, quando o custo de mudar de direção é muito maior. Dá também ao PM uma base clara e documentada para dizer não a acrescentos: "Decidimos no brief que isto estava fora do âmbito — eis o porquê."
Como escrever bons itens fora do âmbito
Não se limite a listar o que não vai construir — registe brevemente porquê. "Preferências de e-mail (infraestrutura separada)" diz ao leitor que a decisão foi deliberada e fundamentada, e não um esquecimento. Isto evita que a mesma questão de âmbito volte a surgir três vezes durante o sprint.
Questões em aberto: a secção que a maioria dos briefs omite
Todo o projeto começa com questões por resolver. A maioria dos briefs finge que não — são escritos como se todas as decisões estivessem tomadas, mesmo quando o autor sabe que não estão. O resultado é que as equipas descobrem as questões em aberto a meio da construção, quando são mais prejudiciais.
Listar explicitamente as questões em aberto tem dois efeitos. Primeiro, faz emergir as perguntas que têm de ser resolvidas antes de o trabalho começar (bloqueantes) por oposição às que podem ser decididas durante a construção (não bloqueantes). Segundo, sinaliza à equipa que o brief é um documento vivo, e não uma especificação fechada — o que torna mais provável que volte a ele e o atualize à medida que as decisões são tomadas.
A armadilha da extensão
Um brief que ultrapassa uma página deixa de ser um brief — é um documento de especificação. As especificações têm o seu lugar, mas servem um propósito diferente. Se sentir que precisa de mais de uma página, passe o detalhe para um anexo associado e mantenha o brief nas cinco secções essenciais.
Como a FabricLoop mantém o brief vivo
Um brief só se mantém útil se a equipa conseguir encontrá-lo e atualizá-lo. A FabricLoop fixa o brief no tópico do projeto para estar sempre à distância de um clique — e a conversa sobre ele (decisões tomadas, questões em aberto resolvidas, alterações de âmbito) fica ali mesmo, em contexto, em vez de dispersa por e-mail e Slack.
10 ideias a reter deste artigo
- A maioria dos briefs de produto é escrita para cumprir um processo, e não para ajudar as equipas a tomar melhores decisões. É por isso que nunca mais são usados.
- Um brief é uma referência para a tomada de decisões, não um documento de requisitos. Deve responder às perguntas que surgem a meio da construção.
- As cinco secções que importam: Problema, Utilizadores, Métrica de sucesso, Fora do âmbito, Questões em aberto. Tudo o resto é especificação.
- A secção do problema deve descrever a dor do utilizador de forma concreta — com dados, sempre que possível — e não limitar-se a nomear a área em causa.
- Indicar para quem não vai construir é tão importante como indicar para quem vai. A ambiguidade quanto aos utilizadores causa scope creep no design.
- As métricas de sucesso devem ser mensuráveis, limitadas no tempo e acordadas antes de a construção começar — e não inferidas a posteriori a partir dos dados de utilização.
- A secção fora do âmbito é a mais importante. Os limites de âmbito não escritos expandem-se invariavelmente durante a construção.
- Indique brevemente o motivo de cada item fora do âmbito, para evitar que as mesmas perguntas voltem a surgir durante o sprint.
- As questões em aberto devem ser marcadas explicitamente como bloqueantes (decidir antes da construção) ou não bloqueantes (decidir durante a construção).
- Um brief que excede uma página tornou-se uma especificação. Passe o detalhe para um anexo e mantenha o brief conciso.
