O que é um product brief?

Um documento curto que diz o que é um produto, que problema resolve, para quem e o que deixa deliberadamente de fora. Dá a todos os que trabalham no produto, pessoas e agentes, o mesmo ponto de partida.

Em que é que um product brief difere de um PRD?

O brief cobre o produto inteiro numa página. Um documento de requisitos de produto (PRD) aprofunda uma funcionalidade ou versão e descreve exatamente como se deve comportar. Começa pelo brief e escreve PRD quando uma funcionalidade precisar desse detalhe.

Um agente de programação com IA pode usar este brief?

Sim. Guarda o ficheiro Markdown no teu repositório e faz referência a ele no AGENTS.md ou importa-o no CLAUDE.md. O AGENTS.md é Markdown simples, e o Claude Code lê o CLAUDE.md no início de cada sessão.

Porquê Markdown e JSON?

O Markdown é fácil de ler para pessoas e agentes e é apresentado em qualquer plataforma de código. O JSON tem o mesmo conteúdo com chaves fixas em inglês, para que scripts e formulários o leiam sem terem de interpretar texto corrido.

O meu brief é guardado ou enviado para algum lado?

Fica guardado apenas no armazenamento local do teu navegador para que um recarregamento não o apague. Nada é carregado nem enviado para análises, e Limpar apaga o rascunho.

Modelo de product brief: gratuito, em Markdown e JSON

Por Aleksandar Vuk JovanovicAtualizado 30 de setembro de 2026Como pesquisamos e atualizamos

Preenche o brief

Escreve diretamente nos campos. O Markdown e o JSON abaixo atualizam-se enquanto escreves e ficam prontos a copiar ou transferir.

O teu rascunho fica guardado no armazenamento local deste navegador para sobreviver a um recarregamento. Nunca é carregado. Limpar remove-o.

Pré-visualização em Markdown

# [Nome do produto]

> [O que faz e para quem, numa linha]

Última atualização: [data]

## Problema

[Quem tem hoje que dificuldade]

## Para quem é

[Principais utilizadores e compradores]

## O que faz

[Como o produto resolve o problema]

## Capacidades principais

- [Até três coisas que já faz hoje]

## Em vez de

[O que as pessoas usam hoje e porque é que isto é melhor]

## Fora do âmbito

[O que deliberadamente não faz]

## Como sabemos que funciona

[Um sinal que possas verificar]

## Ligação

[URL do site ou do repositório]

Pré-visualização em JSON

{
  "format": "product-brief",
  "version": 1,
  "language": "pt",
  "updated": "",
  "name": "",
  "oneLiner": "",
  "problem": "",
  "audience": "",
  "solution": "",
  "features": [
    "",
    "",
    ""
  ],
  "alternative": "",
  "nonGoals": "",
  "success": "",
  "url": ""
}

Ficheiros em branco

Preferes o teu próprio editor? Leva o modelo vazio num dos dois formatos.

Para que serve cada campo

Dez campos chegam para alinhar pessoas e agentes sobre o que estás a construir. Cada um responde a uma pergunta que alguém te faria de outra forma.

Nome do produto: Todos, incluindo um agente, devem escrever o nome da mesma forma. Escreve-o aqui uma vez.
Frase de apresentação: A frase que vais reutilizar em fichas, biografias e na tua página inicial. Se não a consegues escrever, o produto ainda não está claro.
Problema: O trabalho parte do problema, não da funcionalidade. Um problema claro permite que outros proponham soluções melhores do que a tua.
Para quem é: Um público restrito facilita todas as decisões seguintes: as palavras, as funcionalidades, onde lançar.
O que faz: Como o produto resolve o problema, em palavras simples. É do que alguém novo precisa primeiro.
Capacidades principais: Três capacidades que existem hoje. Um agente que escreve textos nunca deve inventar uma quarta.
Em vez de: As pessoas comparam com o que fazem agora. Nomear a solução improvisada explica o teu valor melhor do que uma tabela de funcionalidades.
Fora do âmbito: O campo que a maioria dos briefs salta. Trava o alargamento descontrolado do âmbito e impede que um agente acrescente funcionalidades que não pediste.
Como sabemos que funciona: Um sinal observável diz-te se o produto funciona e dá a um agente um objetivo com que se comparar.
Ligação: Uma ligação permite a um leitor ou a um agente confirmar os detalhes em vez de os adivinhar.

Confirma se a tua tagline cabe no limite de cada plataforma →

Entrega o brief ao teu agente

Os agentes de programação leem ficheiros Markdown do teu repositório. Um brief curto junto ao teu código dá-lhes o contexto de produto que o código sozinho não contém.

Transfere o ficheiro Markdown e guarda-o no teu repositório, por exemplo como docs/product-brief.md.
Aponta o teu agente para ele: acrescenta uma linha ao AGENTS.md ou importa-o no CLAUDE.md com @docs/product-brief.md.
Para o GitHub Copilot, cria uma ligação ou copia o essencial para .github/copilot-instructions.md.
Guarda o JSON ao lado quando um script ou outra ferramenta tiver de ler os mesmos factos.
Altera a linha da data sempre que algo mude e apaga as frases que já não sejam verdade.

Tema	Redação oficial	O que significa para o teu brief
Formato	AGENTS.md is just standard Markdown.	Um brief em Markdown simples funciona como contexto para o agente sem qualquer sintaxe especial.
Títulos	Use any headings you like; the agent simply parses the text you provide.	Os nomes das secções deste modelo são uma sugestão. Muda-os se a tua equipa usar outras palavras.
Quando é lido	You write these files in plain text; Claude reads them at the start of every session.	O Claude Code carrega o CLAUDE.md no início de cada sessão, por isso um brief importado está sempre em contexto.
Importação	CLAUDE.md files can import additional files using @path/to/import syntax.	Uma linha como @docs/product-brief.md no CLAUDE.md chega para incluir o brief.
Comprimento	target under 200 lines per CLAUDE.md file. Longer files consume more context and reduce adherence.	Um contexto curto é seguido melhor. Um brief de uma página fica muito abaixo deste tamanho.
Copilot	Add natural language instructions to the file, in Markdown format.	As instruções do Copilot também são Markdown, por isso o mesmo texto serve ali.
Codificação JSON	JSON text exchanged between systems that are not part of a closed ecosystem MUST be encoded using UTF-8	A transferência em JSON é UTF-8, por isso acentos, caracteres CJK e emoji sobrevivem a qualquer ferramenta.

Brief, PRD ou ficheiro de contexto

Três documentos que se confundem muitas vezes. Respondem a perguntas diferentes, e muitos produtos precisam de mais do que um.

Documento	Responde a	Extensão	Escrito por
Product brief (este modelo)	O que construímos, para quem e onde termina	Uma página, dez campos	Fundador ou responsável de produto
Documento de requisitos de produto (PRD)	Como deve comportar-se exatamente uma funcionalidade ou versão	Várias páginas por funcionalidade	Product manager com a engenharia
Ficheiro de contexto de produto	Que factos e textos aprovados um agente pode publicar	Cresce com cada canal	Quem gere o lançamento

Modelo de plano de lançamento →

O que este modelo deixa de fora

É um ponto de partida, não uma especificação completa. Requisitos detalhados, designs e pesquisa ficam nos seus próprios documentos.
Preços, datas de lançamento e variantes de textos de marketing ficam deliberadamente de fora.
A página não verifica se as tuas afirmações são verdadeiras. Escreve apenas o que o produto faz hoje.
Nada é enviado para lado nenhum: o rascunho fica neste navegador até carregares em Limpar.

Fontes

Lemos estas páginas a 30 de setembro de 2026 e citamo-las acima palavra por palavra.

Página	Data na página	Verificado por nós
AGENTS.md	sem data indicada	30 de set. de 2026
Claude Code Docs: How Claude remembers your project	sem data indicada	30 de set. de 2026
GitHub Docs: Adding repository custom instructions for GitHub Copilot	sem data indicada	30 de set. de 2026
RFC 8259: The JavaScript Object Notation (JSON) Data Interchange Format (December 2017)	sem data indicada	30 de set. de 2026
CommonMark Spec, version 0.31.2	sem data indicada	30 de set. de 2026

Perguntas frequentes

O que é um product brief?: Um documento curto que diz o que é um produto, que problema resolve, para quem e o que deixa deliberadamente de fora. Dá a todos os que trabalham no produto, pessoas e agentes, o mesmo ponto de partida.
Em que é que um product brief difere de um PRD?: O brief cobre o produto inteiro numa página. Um documento de requisitos de produto (PRD) aprofunda uma funcionalidade ou versão e descreve exatamente como se deve comportar. Começa pelo brief e escreve PRD quando uma funcionalidade precisar desse detalhe.
Um agente de programação com IA pode usar este brief?: Sim. Guarda o ficheiro Markdown no teu repositório e faz referência a ele no AGENTS.md ou importa-o no CLAUDE.md. O AGENTS.md é Markdown simples, e o Claude Code lê o CLAUDE.md no início de cada sessão.
Porquê Markdown e JSON?: O Markdown é fácil de ler para pessoas e agentes e é apresentado em qualquer plataforma de código. O JSON tem o mesmo conteúdo com chaves fixas em inglês, para que scripts e formulários o leiam sem terem de interpretar texto corrido.
O meu brief é guardado ou enviado para algum lado?: Fica guardado apenas no armazenamento local do teu navegador para que um recarregamento não o apague. Nada é carregado nem enviado para análises, e Limpar apaga o rascunho.

Brief pronto? Leva o produto até às pessoas.

O LaunchRepo dá ao teu agente de programação um playbook para cada plataforma de lançamento e cada diretório, para que o produto que acabaste de descrever apareça onde o teu público procura, e acompanha que fichas já estão publicadas.

Ver preços