Template PRD (Product Requirements)

PRD: anatomia de um Product Requirements Document

Um PRD — Product Requirements Document — responde três perguntas antes da primeira linha de código: o que vamos construir, por que isso importa e para quem. É o contrato entre produto, engenharia, design, marketing e jurídico, e funciona como fonte única de verdade que todo mundo consegue linkar. O formato se consolidou na cultura de engenharia da Microsoft nos anos 1980 e foi refinado na prática moderna de produto por Marty Cagan em Inspired e por autores como John Cutler na Amplitude e na Reforge.

Um PRD sólido costuma conter: problem statement (a dor do usuário que você está resolvendo), goals e non-goals (escopo e o que está explicitamente fora), personas, casos de uso / user stories, requisitos funcionais separados em must-have e nice-to-have, métricas de sucesso / KPIs, timeline, dependências de outros times ou sistemas e uma lista de open questions. Variantes modernas enxugam o formato: o one-pager PRD popularizado pela Reforge, o lean PRD, o six-pager da Amazon (sem slides — prosa narrativa lida em silêncio no início da reunião) e o estilo RFC de engenharia do Facebook.

Frameworks de priorização que andam junto com o PRD

Três frameworks aparecem com frequência ao lado de um PRD. Jobs-to-be-Done (Clayton Christensen) reformula features como o "trabalho" para o qual o usuário está contratando o produto — útil para preencher a seção de problema. RICE (Reach, Impact, Confidence, Effort) dá uma pontuação numérica para cada requisito, evitando que a lista de must-have inche. KANO classifica features em must-have (expectativas básicas), performance (valor linear) e delighters (ganho assimétrico) — informa diretamente a divisão entre must-have e nice-to-have.

Anti-padrões para evitar

PRDs falham quando são longos demais (engenheiros pulam tudo depois da quinta página), prescritivos demais (especificam como implementar em vez de o que alcançar, tirando autonomia de design da engenharia) ou quando faltam um problem statement claro (vão direto para a solução). A outra falha clássica é entregar sem métrica de sucesso — sem KPI você não sabe se a feature funcionou, só que foi entregue.

Onde o PRD entra no fluxo

Um loop típico: PRD → engineering review → design specs → tickets no Jira/Linear → implementação → A/B test → análise de métricas → iteração. O PRD é um documento vivo — atualize conforme aprende durante o desenvolvimento. Ferramentas comuns: Notion (templates ricos e views de banco), Confluence, Productboard, Aha! e ProductPlan para roadmap, e Linear para specs que vivem perto do trabalho de engenharia.

Perguntas frequentes

Qual o tamanho ideal? Uma a cinco páginas. PRDs em escala FAANG às vezes passam disso; startups Y Combinator mantêm curto de propósito. Se o doc parece longo, divida em one-pager + apêndice.

Que ferramenta usar? Notion e Confluence dominam. Productboard e Aha! agregam roadmap. Escolha a ferramenta que sua engenharia já lê — um PRD lindo que ninguém abre tem valor zero.

PRD é obrigatório em startup? A versão pesada não, mas até uma página se paga: força você a articular problema, público e métrica de sucesso antes de queimar tempo de engenharia. Pule a formalidade, não a disciplina.

Quem aprova um PRD? O PM é dono; engenharia e design revisam; em features grandes um executivo patrocina. Trate o sign-off como alinhamento, não burocracia — o objetivo é entendimento compartilhado, não trilha de papel.