DISCOVERY & DEFINIÇÃO · TEMPLATE 02

PRD — Product Requirements Document

Documento canônico de produto. Fonte da verdade sobre o quê está sendo construído (não como). Onde product/design/eng convergem antes do código.

Quando usar Após one-pager aprovado, antes de tech design
Quem lê PM, design, eng, QA, stakeholders
Tamanho 5–15 páginas conforme escopo
Origem Marty Cagan, Lenny Rachitsky

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.
heurística

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