PRD (documento de requisitos de produto) é o texto que explica o que será construído, para quem e por quê. Ele reúne contexto, problema com evidências, objetivos com métricas de sucesso, público, requisitos priorizados, o que fica fora de escopo, riscos e perguntas em aberto. Serve para alinhar produto, engenharia, design e negócio antes da entrega e para registrar as decisões tomadas no caminho.
Como usar
- Dê um título à iniciativa e descreva o contexto e o problema, com as evidências que você tem.
- Escreva os objetivos com a métrica e a meta de cada um, e diga quem é o público.
- Liste os requisitos com prioridade must, should ou could, e declare o que fica fora de escopo.
- Registre riscos, dependências e perguntas em aberto, e leia os alertas do documento.
- Exporte em Markdown para colar no Notion ou no Confluence, ou em PDF e DOCX, e gere as user stories dos requisitos.
O que cada campo pede
| Campo | O que preencher |
|---|---|
| Título da iniciativa | Nome curto do que será construído. |
| Contexto | Por que isto importa agora e como se liga à estratégia. |
| Problema | O problema do cliente, sem falar ainda da solução. |
| Evidências | Dados, entrevistas ou chamados que mostram o problema. |
| Objetivo | Ex.: reduzir faturas vencidas |
| Métrica | Como saber se o objetivo foi atingido. |
| Meta | Ex.: de 62% para 75% no trimestre |
| Personas ou públicos | Quem usa e quem é afetado. Um por linha. |
| Situação de uso | Onde, quando e como a pessoa usa a solução. |
| Requisito | Ex.: enviar lembrete 3 dias antes do vencimento |
| Prioridade | Must é essencial para lançar; could pode esperar. |
| Detalhe | Regra, limite ou observação (opcional). |
| Fora de escopo | O que esta entrega não faz, de propósito. |
| Riscos | O que pode dar errado ou impedir o resultado. |
| Dependências | Times, serviços ou aprovações de que a entrega precisa. |
| Perguntas em aberto | Decisões que ainda faltam tomar. |
Exemplo
O time de um aplicativo financeiro fictício para autônomos escreve o PRD do lembrete automático de cobrança. O problema: autônomos esquecem de cobrar clientes atrasados, e 38% das faturas vencem sem pagamento. O objetivo principal é subir as faturas pagas até 7 dias após o vencimento de 62% para 75% no trimestre. São 5 requisitos: 2 must (enviar o lembrete e pausar por cliente), 2 should e 1 could. Juros, multa e pagamento dentro do app ficam fora de escopo, e duas perguntas seguem abertas.
Quando usar
- Antes de começar uma funcionalidade que envolve mais de um time ou mais de uma iteração.
- Quando a discussão sobre o que entra na entrega está girando em círculos e falta um texto de referência.
- Para levar uma proposta à revisão com engenharia, design e liderança, com objetivos e escopo explícitos.
- Para registrar o que foi decidido e por quê, e poder retomar o assunto meses depois.
Perguntas frequentes
O que é um PRD?
É o documento de requisitos de produto: descreve o problema, o objetivo, o público e o que a solução precisa fazer. Não é uma especificação técnica; o "como" fica com o time que vai construir.
Qual a diferença entre PRD e épico?
O épico é um item grande do backlog, normalmente quebrado em user stories. O PRD é o documento que explica por que esse épico existe, como medir o sucesso e o que fica de fora. Um PRD pode originar um ou vários épicos.
Qual o tamanho ideal de um PRD?
O suficiente para alguém de fora entender o problema e a decisão sem uma reunião. Para uma funcionalidade, de uma a três páginas costuma bastar. Se passar disso, talvez a iniciativa precise ser dividida.
Quem escreve o PRD?
Normalmente o gerente de produto, mas em conjunto com engenharia e design. O bom PRD é revisado por quem vai construir antes de a entrega começar.
PRD faz sentido em times ágeis?
Sim, se for curto e vivo. Ele não substitui a conversa nem o refinamento do backlog; ele dá o contexto e os limites para que as user stories sejam escritas e priorizadas com o mesmo objetivo em mente.
Como manter o PRD atualizado?
Trate as perguntas em aberto como uma lista de pendências e registre cada decisão quando ela acontecer. Revise o documento a cada mudança de escopo e deixe claro, no topo, o status e a data da última revisão.