Modelo de Documento de Requisitos de Produto (+ um Exemplo Prático Completo para Copiar)

Modelo de Documento de Requisitos de Produto (+ um Exemplo Prático Completo para Copiar)

Última atualização: 28 de julho de 2026.

A maioria das páginas de modelo de documento de requisitos de produto entrega um formulário vazio. O da Atlassian tem quatro seções de instruções em torno de uma tabela de métricas de sucesso em branco. O da Product School traz "(with Example)" no título e não contém exemplo nenhum. O bloco markdown de 12 seções abaixo é o modelo completo, sem barreiras, pronto para copiar e colar. A Seção 4 preenche cada uma dessas 12 seções em um exemplo prático completo: um portal de faturas para um cliente que lê PDFs com um LLM e encaminha os casos duvidosos para revisão humana. Copie o modelo em branco. Leia o preenchido. Escreva o seu.

Principais Conclusões

• Um PRD responde o quê construir e por quê; o documento técnico de design responde o como.
• As 12 seções servem para qualquer tamanho de projeto. Um documento de uma página é o mesmo modelo com menos linhas.
• Os não-objetivos precisam estar escritos. Um agente de codificação de IA não consegue inferir escopo a partir de uma omissão.
• Os critérios de aceitação precisam ser verificáveis por máquina: "p95 abaixo de 400ms", nunca "rápido".

Qual Formato de PRD Você Deve Usar?

Escolha o formato pelo público que vai ler o documento, não pelo tamanho que o produto parece ter. Uma única funcionalidade destinada aos seus próprios engenheiros precisa de um documento de uma página. Uma construção entregue a uma equipe externa precisa do PRD completo de 12 seções, porque os critérios de aceitação também funcionam como portões de aprovação. Uma especificação destinada a um agente de codificação de IA precisa das mesmas doze seções, fatiadas em fases.

O modelo de documento de requisitos de produto de uma página que todo mundo pede não é um artefato separado. O modelo de uma página amplamente copiado de Lenny Rachitsky, publicado com exemplos reais em sua newsletter, é o mesmo esqueleto com a burocracia removida. Um documento de uma página não é um documento diferente. É as mesmas doze seções com as linhas vazias apagadas.

Equipes ágeis também fazem essa pergunta com frequência, geralmente formulada como se um PRD sobrevive ao contato com um backlog. E sobrevive, como um documento de uma página: o PRD guarda o porquê e os limites, os tickets guardam o trabalho.

O Modelo de PRD (Markdown para Copiar e Colar)

Aqui está tudo em markdown, sem barreiras, sem parede de e-mail. Cole no Notion, Confluence, Google Docs, Linear, Word, ou faça commit no GitHub como PRD.md e deixe-o versionar junto com o código. As pessoas pedem esse modelo em nove formatos diferentes; markdown é o único que sobrevive a uma colagem em todos eles, e é o único que um agente de codificação de IA lê de forma limpa.

# PRD: [Nome do produto ou funcionalidade]

## 1. Cabeçalho
- Responsável (produto):
- Líder de engenharia:
- Líder de design:
- Status: Rascunho | Em revisão | Aprovado | Lançado
- Última atualização:
- Histórico de alterações: data / autor / o que mudou

## 2. Declaração do problema
Um parágrafo. Quem sofre, com que frequência, quanto custa hoje. Sem linguagem de solução.

## 3. Objetivos e métricas de sucesso
| Objetivo | Métrica | Linha de base | Meta | Medido por | Data |
|---|---|---|---|---|---|

## 4. Não-objetivos
Declarados de forma positiva: "Esta fase não inclui X."

## 5. Usuários e personas
Quem usa, o que já sabem, qual dispositivo, com que frequência.

## 6. Histórias de usuário e critérios de aceitação
Como [persona], eu quero [ação], para que [resultado].
- Dado [contexto], quando [evento], então [resultado observável].

## 7. Requisitos funcionais
Numerados. Um requisito por linha. Testável. Nenhuma frase contendo "e".

## 8. Requisitos não funcionais
Desempenho / segurança e multi-tenancy / residência e retenção de dados / acessibilidade / disponibilidade.

## 9. Dependências e integrações
Sistemas externos, APIs, credenciais, quem é responsável pelo acesso, prazo de espera.

## 10. Marcos e faseamento
| Fase | Escopo | Critérios de saída | Data alvo |
|---|---|---|---|

## 11. Questões em aberto e riscos
| Questão ou risco | Responsável | Necessário até | Impacto se não respondido |
|---|---|---|---|

## 12. Apêndice e links
Designs, pesquisa, notas sobre concorrentes, tickets anteriores, contratos.

As doze seções, em ordem: cabeçalho, declaração do problema, objetivos e métricas de sucesso, não-objetivos, usuários e personas, histórias de usuário com critérios de aceitação, requisitos funcionais, requisitos não funcionais, dependências e integrações, marcos e faseamento, questões em aberto e riscos, apêndice.

O Que um PRD Deve Incluir? As 12 Seções, e a Versão Fraca de Cada Uma

Um documento de requisitos de produto deve incluir uma declaração do problema, objetivos mensuráveis, não-objetivos explícitos, personas, histórias de usuário com critérios de aceitação, requisitos funcionais e não funcionais, dependências, marcos, questões em aberto com responsáveis, e um histórico de alterações. Tudo o mais é apêndice. O teste para cada linha é o mesmo que a norma ISO/IEC/IEEE 29148:2018 aplica a requisitos em geral: verificável, inequívoco, singular.

A maioria dos PRDs falha nesse teste nos mesmos três pontos.

Duas seções merecem mais atenção do que costumam receber.

Requisitos não funcionais são onde o escopo silenciosamente dobra. Desempenho, multi-tenancy, residência de dados, retenção, acessibilidade, disponibilidade: cada um desses pontos é uma decisão de engenharia com um custo, e nenhum deles aparece em uma história de usuário. Coloque a linha de segurança aqui em vez de deixá-la vaga, e escreva-a da forma como você gostaria que fosse verificada, usando algo como nossa checklist de segurança pré-lançamento como lista de referência. Se a construção tiver um componente de IA, os requisitos de prontidão para produção também pertencem aqui, não em uma fase posterior de "endurecimento" que nunca chega a ser agendada: nossa checklist de PoC para produção é a versão que usamos.

Questões em aberto precisam de três colunas, não uma. Pergunta, responsável, data necessária. Uma pergunta sem responsável é uma decisão que ninguém está tomando, e ela vai aparecer como uma solicitação de mudança na sexta semana. Vale dizer: um PRD é o que você escreve depois de decidir construir em vez de comprar. Se a declaração do problema ainda parece uma lista de compras de funcionalidades, a decisão comprar-versus-construir ainda não aconteceu de verdade.

O Exemplo Prático: Um PRD de Portal de Faturas, Preenchido

Aqui está um exemplo prático completo, com todas as 12 seções preenchidas. A construção: um portal de faturas para um cliente, uma operadora logística de médio porte. Os clientes enviam faturas em PDF, um LLM extrai os itens de linha, o sistema sinaliza divergências em relação ao registro do pedido, e tudo o que gera dúvida vai para uma fila de revisão humana. Stack: Next.js, Supabase/Postgres, uma etapa de extração com LLM. Copie, imprima, exporte para PDF, o que você precisar.

# PRD: Portal de Faturas do Cliente, Fase 1

## 1. Cabeçalho
- Responsável (produto): Diretor de operações, lado do cliente
- Líder de engenharia: Líder de entrega, Techsy
- Líder de design: Designer de produto, Techsy
- Status: Aprovado para construção
- Última atualização: 2026-07-28
- Histórico de alterações:
  - 2026-07-14 / produto / primeiro rascunho
  - 2026-07-21 / engenharia / adicionada regra de limiar de confiança à seção 6.2
  - 2026-07-28 / produto / retorno ao ERP movido para não-objetivos

## 2. Declaração do problema
A equipe de operações recebe faturas de clientes como PDFs por e-mail e as
redigita manualmente no sistema de pedidos. O volume passa de 300 faturas por
semana, o tempo médio de tratamento é de cerca de 6 minutos cada, e
aproximadamente 4% apresentam um erro de digitação detectado apenas na
reconciliação de fim de mês. Cada correção custa uma segunda passagem e uma ligação.

## 3. Objetivos e métricas de sucesso
| Objetivo | Métrica | Linha de base | Meta | Medido por | Data |
|---|---|---|---|---|---|
| Reduzir o tratamento manual | Tempo médio de tratamento | 6 min | menos de 90 seg | Painel de operações, mediana semanal | 2026-11-01 |
| Reduzir erros de digitação | Faturas corrigidas na reconciliação | 4% | menos de 1% | Relatório de fim de mês do financeiro | 2026-12-01 |
| Conter a carga de revisão | Parcela encaminhada para revisão humana | n/a | menos de 25% | Métricas da fila do portal | 2026-11-01 |

## 4. Não-objetivos
Esta fase não oferece suporte a faturas multimoeda, retorno ao ERP, notas de
crédito de autoatendimento do cliente, nem aplicativo móvel. A extração cobre
apenas PDF. Fotografias de faturas em papel e digitalizações abaixo de 200 DPI
são rejeitadas no envio com uma mensagem explicando o motivo.

## 5. Usuários e personas
- Atendente de operações (principal, 6 pessoas): trabalha na fila de exceções
  o dia todo, profundo conhecimento do domínio, apenas desktop.
- Contato de contas a pagar do cliente (externo, ~140 contas): envia faturas,
  baixa tolerância a fricção na configuração da conta.
- Gerente financeiro (secundário): extrai o relatório de fim de mês, precisa
  de uma trilha de auditoria por fatura.

## 6. Histórias de usuário e critérios de aceitação
6.1 Como contato de contas a pagar do cliente, eu quero enviar um PDF de
fatura, para não precisar enviá-lo por e-mail e esperar.
- Dado um PDF de até 20 MB a 200 DPI ou mais, quando eu o envio, então o portal
  retorna um número de referência em até 5 segundos e mostra "Processando".

6.2 Como atendente de operações, eu quero que extrações de baixa confiança
sejam retidas, para que nada errado seja aprovado automaticamente.
- Dada uma fatura processada, quando a confiança de extração de qualquer item
  de linha estiver abaixo de 0,85, então a fatura é encaminhada para a fila de
  revisão e nunca é aprovada automaticamente.

6.3 Como atendente de operações, eu quero ver a divergência em um só lugar,
para poder resolvê-la sem abrir o sistema de pedidos.
- Dada uma fatura associada a um pedido, quando qualquer quantidade de linha
  ou preço unitário divergir do registro do pedido, então o portal mostra os
  dois valores lado a lado e sinaliza a diferença.

6.4 Como gerente financeiro, eu quero filtrar faturas, para poder fechar o
mês.
- Dada a lista de faturas, quando eu filtrar por fornecedor, período e status,
  então os resultados retornam em menos de 400ms em p95 e o estado vazio
  oferece "Limpar filtros".

## 7. Requisitos funcionais
1. O envio aceita apenas PDF, máximo de 20 MB, um arquivo por envio.
2. A extração retorna fornecedor, número da fatura, data, moeda, e itens de
   linha com quantidade, preço unitário e total.
3. Cada item de linha carrega uma pontuação de confiança entre 0 e 1.
4. A correspondência compara a fatura extraída com o pedido em aberto pelo
   número do pedido de compra.
5. As exceções entram em uma fila ordenada da mais antiga para a mais
   recente, atribuível a um único atendente.
6. Toda mudança de estado registra uma entrada de auditoria com ator,
   carimbo de data/hora, valor anterior.
7. Faturas aprovadas são exportadas como um lote CSV para o sistema
   financeiro.

## 8. Requisitos não funcionais
- Desempenho: lista de faturas com p95 abaixo de 400ms. A extração é
  concluída em até 90 segundos após o envio, em p95.
- Segurança e multi-tenancy: isolamento por tenant aplicado no nível de linha
  do banco de dados. Um cliente nunca pode ler a fatura de outro cliente.
  Verificado por um teste automatizado a cada versão.
- Residência e retenção de dados: documentos armazenados na UE. Originais
  retidos por 7 anos, payloads de extração por 90 dias.
- Acessibilidade: fila totalmente operável pelo teclado, contraste WCAG 2.2 AA.
- Disponibilidade: 99,5% mensal, suporte durante horário comercial.

## 9. Dependências e integrações
- Registros de pedidos: réplica Postgres somente leitura. Acesso de
  propriedade da TI do cliente, credenciais necessárias até 2026-08-15.
- Provedor de extração com LLM: contrato e acordo de processamento de dados
  assinados antes do início da construção.
- Notificações por e-mail: provedor transacional existente, domínio do
  remetente verificado pelo cliente.

## 10. Marcos e faseamento
| Fase | Escopo | Critérios de saída | Data alvo |
|---|---|---|---|
| F1 | Envio, extração, roteamento por confiança | 50 faturas reais de ponta a ponta, menos de 25% em fila | 2026-09-19 |
| F2 | Correspondência de pedidos e visão de divergências | Divergência sinalizada corretamente em 20 casos semeados | 2026-10-10 |
| F3 | Trilha de auditoria, exportação CSV, relatórios | Financeiro fecha um mês no portal | 2026-11-01 |

## 11. Questões em aberto e riscos
| Questão ou risco | Responsável | Necessário até | Impacto se não respondido |
|---|---|---|---|
| Qual número de pedido de compra é o oficial quando uma fatura mostra dois? | Diretor de operações do cliente | 2026-08-08 | Lógica de correspondência bloqueada |
| Os 12 maiores clientes enviam PDFs digitalizados ou nativos? | Líder de entrega | 2026-08-08 | Limiar de confiança pode estar errado |
| A retenção de 7 anos está confirmada com a assessoria jurídica do cliente? | Gerente financeiro do cliente | 2026-08-22 | Design de armazenamento e custo mudam |
| Custo de extração por fatura a 300/semana | Líder de entrega | 2026-09-05 | Economia unitária desconhecida |

## 12. Apêndice e links
Conjunto de amostra de faturas anonimizadas (40 arquivos), esquema da tabela
de pedidos, estudo atual de tempo de tratamento, fluxos do Figma para envio e
fila, declaração de trabalho assinada.

Quatro escolhas ali merecem destaque, porque a versão preguiçosa de cada uma custa dinheiro de verdade.

Seção 3, a linha de base. "6 minutos" não é decoração. Sem uma linha de base você não consegue saber se a coisa funcionou, e seis meses depois alguém discute isso em uma reunião sem dados. A versão preguiçosa, "melhorar a eficiência", torna o projeto infalseável.

Seção 4, o não-objetivo. O retorno ao ERP foi movido para os não-objetivos em 2026-07-28, depois de ter sido assumido como certo durante uma chamada de revisão. Escrevê-lo como não-objetivo custou uma linha e evitou uma discussão de escopo.

Seção 6.2, o limiar de confiança. Essa é a regra que nossos próprios primeiros rascunhos mais frequentemente deixam passar. Deixe-a de fora e o sistema aprova automaticamente faturas que um humano deveria ter visto, que é exatamente a falha que apaga a economia de tempo prometida na seção 3.

Seção 11, os responsáveis. Toda questão em aberto tem um nome e uma data. Essa coluna é a diferença entre um documento e uma lista de tarefas que ninguém possui.

O PRD te diz o quê. Ele não diz quanto tempo nem quanto custa, o que é um exercício separado: veja como dimensionar a construção para essa outra metade. E um não-objetivo que você não escreveu é uma funcionalidade que alguém vai construir.

Como Escrever um PRD que um Agente de Codificação de IA Consegue Realmente Usar?

Um PRD escrito para um agente de codificação de IA troca brevidade por explicitude. O agente não tem contexto informal, nenhum histórico compartilhado, e nenhum instinto sobre o que você obviamente não quis dizer. Quatro regras cobrem a maior parte da diferença, e elas vêm de observar especificações terem sucesso ou falhar em nossas próprias construções assistidas por agentes.

1. Declare os não-objetivos de forma positiva. Humanos inferem escopo a partir da omissão. Agentes não. "Não adicione autenticação nesta fase" precisa ser uma frase no documento, ou a autenticação será construída, testada e entregue de volta para você.

2. Dimensione o trabalho em fases. Um único monólito de 40 páginas produz um pull request confiante, extenso e meio-certo. Divida o PRD em passagens que um agente consegue concluir em uma execução limitada, cada uma com seus próprios critérios de saída.

3. Torne os critérios de aceitação verificáveis por máquina. "Rápido" não é um requisito, é um estado de espírito. "p95 abaixo de 400ms no endpoint da lista de faturas" é um teste que o agente pode escrever antes de escrever a funcionalidade.

4. Coloque caminhos de arquivos e restrições de stack no documento, não no chat. O contexto do chat evapora entre sessões. A especificação não. É também por isso que o modo de planejamento do Claude Code importa: ele lê seus arquivos e propõe um plano sem editar nada até você aprovar, e essa etapa de aprovação é muito mais útil quando o plano está sendo verificado contra uma especificação escrita, em vez da sua memória do que você pediu.

Aqui está o portal de faturas, fatiado em uma fase que um agente consegue executar em uma única passagem.

# Tarefa de construção: Envio e extração de faturas (Fase 1 de 3)

## Restrições de stack (não substituir)
Next.js 15 App Router, TypeScript, Supabase Postgres com row-level security,
deploy no Vercel. Nenhuma nova dependência sem perguntar primeiro.

## Arquivos que você pode criar ou editar
- app/(portal)/invoices/upload/page.tsx
- app/api/invoices/route.ts
- lib/extraction/parse-invoice.ts
- supabase/migrations/0007_invoices.sql

## Não mexer
- lib/auth/*  (autenticação é lançada na Fase 2; não adicione fluxos de login agora)
- Qualquer coisa em app/(marketing)/
- O esquema de pedidos existente. Leia-o. Nunca migre.

## Critérios de aceitação (escreva-os como testes primeiro)
1. POST /api/invoices rejeita não-PDF com 415 e arquivos acima de 20 MB com 413.
2. Um item de linha com confiança < 0.85 define invoice.status = 'review',
   nunca 'approved'.
3. Toda inserção grava uma linha de auditoria com actor_id, action, created_at.
4. GET /api/invoices?vendor=&from=&to=&status= retorna em menos de 400ms em um
   10,000-row seed.

## Fora do escopo desta passagem
Correspondência de pedidos, UI de divergências, exportação CSV, notificações por e-mail.

Três coisas mudaram em relação à versão humana: caminhos de arquivos apareceram, uma lista de "não mexer" apareceu, e os critérios de aceitação se tornaram asserções em vez de frases. Qual agente você entrega isso importa menos do que as pessoas pensam, embora a comparação de agentes de codificação valha a pena ler antes de se comprometer. Mantenha requisitos e regras do projeto em arquivos separados: Cursor rules e CLAUDE.md guardam convenções e ferramentas, o PRD guarda o que construir. Se você quiser ajuda de IA para produzir o escopo, em vez de apenas consumi-lo, isso é um fluxo de trabalho diferente. E para a própria etapa de extração, a escolha do modelo e o ciclo de avaliação são um trabalho de integração de IA à parte.

O Que Muda Quando o PRD Vai para uma Equipe Externa

Quando o PRD vai para uma agência ou contratada, ele deixa de ser um documento de alinhamento e passa a ser linguagem contratual. Uma ambiguidade que uma equipe interna resolve com uma conversa de dois minutos vira uma solicitação de mudança com um preço. O Pulse of the Profession do PMI constatou que 47% dos projetos malsucedidos não atingem seus objetivos por causa de uma gestão de requisitos imprecisa. É essa a razão de existir deste documento.

Três seções carregam um peso desproporcional nesse cenário. Os critérios de aceitação se tornam portões de aprovação, então precisam ser observáveis por alguém que não é engenheiro. As questões em aberto precisam de um responsável nomeado do lado do cliente, porque o fornecedor não consegue respondê-las e vai construir contornando a lacuna. E o histórico de alterações deixa de ser burocrático: é o registro do que foi acordado e quando, que é a primeira coisa que qualquer um busca durante um desacordo.

A linha que vimos dar errado mais de uma vez é alguma versão de "os usuários podem exportar seus dados". Ninguém escreve em qual formato. A versão cara disso, para nós, foi entregue como uma exportação CSV quando o cliente queria um pacote de faturas em PDF formatado com a marca dele, e refazer isso consumiu cerca de uma semana de engenharia que ninguém tinha dimensionado. A leitura honesta é que a falha estava no documento, não na entrega. Um critério de aceitação teria pego isso em cinco minutos: dado um pedido de exportação, quando o arquivo é gerado, então ele é um PDF que corresponde ao layout fornecido. Uma linha de não-objetivos também teria pego isso, pelo outro lado. Então agora é uma regra na nossa descoberta: qualquer requisito que dependa de um substantivo como "exportação", "relatório" ou "notificação" recebe um formato, um gatilho e um exemplo prático anexado antes de uma declaração de trabalho ser assinada.

É basicamente isso que é como conduzimos construções de aplicações web: transformar a metade vaga da especificação de um cliente em linhas testáveis antes que alguém escreva código.

O Que o r/ProductManagement Realmente Diz Sobre Modelos de PRD

Pesquise product requirements document template reddit e você vai encontrar a mesma reclamação repetida no r/ProductManagement: excesso de modelo. PRDs que ninguém lê. Seções preenchidas porque o modelo tinha um título, não porque alguém precisava do conteúdo. Documentos que ficam obsoletos no dia seguinte ao kickoff e são silenciosamente substituídos por uma thread no Slack. É uma crítica justa à maioria dos modelos, incluindo vários entre os dez primeiros resultados para essa busca.

Nossa resposta: apague seções em vez de preenchê-las com nada. Personas vêm primeiro quando os usuários são óbvios. Apêndice vem em segundo. Marcos podem viver no rastreador em vez do documento. A única que nunca apagamos é não-objetivos, porque é a única seção que fica mais curta quanto mais trabalho você faz e a única que confiavelmente evita a discussão que você teria de outra forma na sexta semana.

Sobre o Autor

Mert Batur Gurbuz, Cofundador, Techsy.io. Credenciais: Cofundador, Techsy.io, University of Birmingham. LinkedIn

Mert Batur Gurbuz é Cofundador da Techsy.io, onde a equipe entrega agentes de IA, sistemas de automação e pipelines de voz/SDR para clientes B2B. Ele estuda na University of Birmingham e escreve sobre o stack de ferramentas de LLM que a equipe da Techsy realmente usa em produção.

Perguntas Frequentes

O que é um documento de requisitos de produto?

Um documento de requisitos de produto (PRD) declara o que uma equipe está construindo e por quê: o problema, os objetivos e suas métricas, os não-objetivos, para quem é, e os requisitos que definem o "pronto". Ele deliberadamente exclui detalhes de implementação, que pertencem a um documento técnico de design escrito depois pela engenharia.

Como se escreve um documento de requisitos de produto?

Comece com a declaração do problema e evite usar linguagem de solução nela. Adicione objetivos mensuráveis com uma linha de base e uma data alvo, depois escreva os não-objetivos. Preencha personas, histórias de usuário com critérios de aceitação no formato Given/When/Then, requisitos funcionais e não funcionais, dependências, marcos e questões em aberto com responsáveis.

O que um PRD deve incluir?

Doze seções: cabeçalho com histórico de alterações, declaração do problema, objetivos e métricas de sucesso, não-objetivos, usuários e personas, histórias de usuário com critérios de aceitação, requisitos funcionais, requisitos não funcionais, dependências e integrações, marcos e faseamento, questões em aberto e riscos, e um apêndice. Qualquer coisa que não se encaixe em um desses provavelmente não é um requisito.

Quanto tempo um PRD deve ter?

De uma a duas páginas para uma única funcionalidade, de três a cinco para uma fase de produto, de cinco a oito quando uma equipe externa está construindo e os critérios de aceitação funcionam como portões de aprovação. A extensão segue o número de decisões sendo registradas, não o tamanho do produto. Seções vazias devem ser apagadas, não preenchidas com enchimento.

Um PRD é o mesmo que um BRD?

Não. Um documento de requisitos de negócio (BRD) declara o resultado comercial que a organização quer e as restrições em torno dele, geralmente antes de uma solução ser escolhida. Um PRD descreve o produto que entrega isso: usuários, comportamento, critérios de aceitação, não-objetivos. Em empresas menores, o BRD costuma ser apenas a seção de declaração do problema.

Equipes ágeis ainda escrevem PRDs?

Sim, geralmente como um documento de uma página. O backlog guarda o trabalho, mas os tickets são péssimos para guardar o porquê, os não-objetivos e a métrica de sucesso. Equipes que pulam o PRD por completo tendem a redescobri-lo como uma página do Confluence chamada "contexto" três sprints depois de o projeto começar.

É possível escrever um PRD em markdown?

Markdown é o melhor formato para isso. Cola de forma limpa no Notion, Confluence, Google Docs e Linear, versiona no Git junto com o código como PRD.md, mostra diffs corretamente em um pull request, e é o único formato que um agente de codificação de IA lê sem perder a estrutura. O modelo acima está em markdown exatamente por esses motivos.

Como se escreve um PRD para um agente de codificação de IA?

Seja explícito onde normalmente você seria breve. Declare os não-objetivos de forma positiva, porque um agente não consegue inferir escopo a partir da omissão. Divida o documento em fases que podem ser concluídas em uma única passagem. Escreva os critérios de aceitação como asserções com números. Nomeie os arquivos que o agente pode editar e os que não pode tocar.

Qual é a diferença entre um PRD e um documento técnico de design?

O PRD responde o quê e o porquê: problema, usuários, comportamento, critérios de aceitação, não-objetivos. O documento técnico de design responde o como: arquitetura, modelo de dados, contratos de API, trade-offs considerados. Produto costuma ser dono do primeiro, engenharia do segundo, e o documento de design deve poder ser lido como uma resposta ao PRD.

Quem é dono do PRD: produto, engenharia ou o cliente?

O produto é dono do documento e das decisões nele. A engenharia é dona do retorno sobre viabilidade e dos requisitos não funcionais. Em construções para agências, o cliente é dono da declaração do problema, dos objetivos e de toda questão em aberto sobre o próprio negócio dele. Propriedade compartilhada de todo o documento geralmente significa que ninguém o mantém.

Para Fechar

Três coisas para levar. O modelo só é útil depois de preenchido, então copie o formato do exemplo prático, não o do modelo em branco. Não-objetivos são a seção de maior valor por palavra no documento e a primeira que as pessoas pulam. E critérios de aceitação escritos como asserções testáveis atendem bem a dois públicos ao mesmo tempo: um engenheiro aprovando uma entrega, e um agente escrevendo o teste.

Se você está escrevendo um PRD para entregar a uma equipe externa e quer um segundo olhar sobre ele antes que vire linguagem contratual, temos prazer em lê-lo e marcar as linhas ambíguas. É a mesma revisão que fazemos nas nossas próprias construções de aplicações web.