O PRD é a fonte da verdade sobre o quê está sendo construído (não como). Em times maduros, é onde product/design/eng convergem antes do código. Marty Cagan (Inspired) defende PRDs minimalistas focados em outcomes, não outputs; Lenny Rachitsky e John Cutler têm templates publicados que viraram referência. PRD pesado vira teatro burocrático; PRD ausente vira retrabalho. O ponto certo varia por contexto, mas as seções centrais são previsíveis.
Template
# PRD — [Nome da feature/projeto]
**Author:** [PM responsável]
**Engineering Lead:** [tech lead]
**Design Lead:** [design lead]
**Status:** Draft / Review / Approved / Shipped
**Última atualização:** [YYYY-MM-DD]
---
## TL;DR
[3-4 frases. O que estamos construindo, para quem, e que problema
isso resolve. Imagine que alguém só vai ler isso.]
## Contexto
[Por que este problema, por que agora. Ligação com objetivos
estratégicos. Evidências quantitativas e qualitativas.]
### User research / sinais
- [Pesquisa, entrevista, reclamação que motivou]
- [Dados de uso atual mostrando o problema]
- [Benchmark de competidores]
## Personas / Usuários-alvo
| Persona | Descrição | Pain point principal |
|---------|-----------|----------------------|
| [Nome] | [Cargo, contexto] | [O que dói hoje] |
## Goals & Non-goals
### Goals (o que faz)
- [Objetivo 1, com métrica associada se possível]
- [Objetivo 2]
### Non-goals (o que NÃO faz)
- [Explicitamente fora do escopo desta versão]
- [Vai ser endereçado em V2 ou em outro projeto]
## Requirements funcionais
### Must have (bloqueante para lançamento)
- [REQ-001] [Descrição clara, testável]
- [REQ-002] [Descrição]
### Should have (importante mas não bloqueante)
- [REQ-010] [Descrição]
### Nice to have (futuro)
- [REQ-020] [Descrição]
## Requirements não-funcionais
[Ver template separado de NFR Checklist para detalhe.]
- **Performance:** [P99 target, throughput target]
- **Disponibilidade:** [SLA — ex: 99.9%]
- **Segurança:** [níveis de proteção, compliance]
- **Acessibilidade:** [WCAG nível]
- **Internacionalização:** [idiomas, locales]
## User journeys / Wireframes
[Link para Figma, ou imagens inline. Mostre os fluxos principais.]
### Fluxo 1: [Nome]
1. Usuário em [contexto]
2. Faz [ação]
3. Sistema responde com [resposta]
4. Resultado esperado: [outcome]
## Métricas de sucesso
### North star
[A métrica que define se o projeto foi um sucesso]
### Métricas de saúde (guardrails)
- [Métrica 1 que NÃO pode piorar — ex: tempo de checkout]
- [Métrica 2 — ex: taxa de erro]
### Métricas de adoção
- [DAU/MAU/conversão] — target em [horizonte temporal]
## Cronograma estimado
- **Discovery completion:** [data]
- **Tech design done:** [data]
- **Alpha (interno):** [data]
- **Beta (limited rollout):** [data]
- **GA:** [data]
## Riscos & mitigações
| Risco | Probabilidade | Impacto | Mitigação |
|-------|---------------|---------|-----------|
| [...] | Alta/Média/Baixa | Alto/Médio/Baixo | [Plano] |
## Open questions
- [Pergunta em aberto que precisa de decisão antes de seguir]
- [...]
## Apêndice
- Links para tech design, ADRs, threat model, runbook, etc.
PRD bom responde "se um engenheiro novo lê isso, ele consegue começar?". Se a resposta exige conversa adicional, o PRD está incompleto. Se a resposta exige menos do que está escrito, o PRD está inflado.
Referências
- Lenny Rachitsky — Ultimate Guide to PRDs
- Marty Cagan, Inspired: How to Create Tech Products Customers Love (2017)
- John Cutler — templates e patterns de produto
- Melissa Perri, Escaping the Build Trap (2018)