Como usar o Claude para escrever um PRD que o time realmente entende

Todo product manager já viu um PRD que não serviu pra nada: cheio de páginas, pobre em decisões. A engenharia leu, ficou com dúvida, e o alinhamento aconteceu mesmo foi no chat, três semanas depois. Um bom PRD (Product Requirements Document) faz o contrário: ele antecipa as perguntas e deixa claro o que está dentro e fora do escopo.

IA ajuda muito aqui — desde que você não peça "escreva um PRD sobre X". Se pedir isso, recebe um texto genérico que parece um PRD mas não decide nada. O valor está em usar a IA como parceira de raciocínio, não como geradora de texto.

Por que o PRD gerado por IA costuma ser ruim

Vale entender o mecanismo antes da receita. Um modelo de linguagem produz o texto mais provável dado o seu pedido. Se o pedido é "PRD de uma feature de notificações", o mais provável é a média de todos os PRDs de notificação que já existiram: seções bem formatadas, frases equilibradas, zero compromisso.

O problema é que a utilidade de um PRD está exatamente no que é específico do seu contexto — a restrição do seu banco, a dívida técnica daquele módulo, o acordo que você fez com o time de suporte. Nada disso é "provável"; é particular. Por isso o texto genérico soa bem e não serve: ele otimiza a média, e você precisa da exceção.

A saída é inverter o uso. Em vez de pedir texto, peça pressão: crítica, perguntas, contraexemplos. Nisso o modelo é excelente, porque a média de "o que dá errado em projetos de software" é justamente o repertório que você quer emprestado.

Comece pelo problema, não pela solução

Antes de qualquer documento, escreva em duas frases: qual problema, de quem, e como você saberá que resolveu. Peça ao Claude para criticar essas frases: "que suposições estou fazendo aqui? que dado eu deveria ter antes de escrever isso?". A IA é excelente em achar o pressuposto que você não viu porque está perto demais.

Um exemplo real de como isso muda o enunciado. Comecei com: "Usuários não encontram o histórico de pedidos, então vamos criar um menu novo." A crítica que voltou apontou três suposições que eu não tinha percebido que estava fazendo: que o problema é de navegação (e não de as pessoas nem saberem que o histórico existe), que "não encontram" veio de dado e não de duas reclamações no suporte, e que menu novo é a solução — quando ela já pressupõe a resposta dentro do enunciado do problema.

Reescrito: "Uma parcela dos usuários que abre um chamado sobre 'onde está meu pedido' já tinha a informação disponível no app. Precisamos descobrir se é problema de descoberta, de navegação ou de confiança." Esse enunciado ainda não decide nada — e é exatamente por isso que ele é melhor. Ele não fecha a porta antes de olhar.

Use a IA para gerar as perguntas difíceis

Este é o uso mais subestimado. Descreva a feature e peça: "aja como um engenheiro sênior cético e liste as 15 perguntas que você faria antes de começar a implementar isso." As respostas expõem exatamente os buracos que causariam retrabalho: estados de erro, casos-limite, o que acontece offline, permissões, migração de dados.

Um PRD bom não é o que responde tudo — é o que faz as perguntas certas antes de custar caro.

Você não precisa responder todas ali. Mas cada pergunta vira uma seção decidida ou um "fora de escopo" explícito. Isso já vale o documento.

Vale rodar a mesma dinâmica com outros papéis, porque cada um enxerga um risco diferente: o time de suporte pergunta o que fazer quando o usuário reclama; o de dados pergunta como isso vai ser medido e se o evento já existe; o de segurança pergunta quem pode ver o quê. São perguntas que normalmente aparecem tarde demais, na véspera do lançamento.

Estruture com um template fixo

Peça à IA para preencher um esqueleto que você controla — não um formato que ela inventa toda vez. O que uso:

1. Problema e contexto — por que agora.
2. Objetivo e métrica de sucesso — número, não adjetivo.
3. Usuário e cenário — quem, fazendo o quê, quando.
4. Escopo: o que entra.
5. Fora de escopo: o que não entra (a seção mais importante e mais ignorada).
6. Requisitos funcionais — em linguagem de comportamento observável.
7. Casos-limite e erros.
8. Perguntas em aberto.

Com o esqueleto fixo, a IA vira uma ferramenta de preenchimento consistente. Sem ele, cada PRD sai com uma cara e o time perde tempo se localizando.

Insisto na seção de fora de escopo porque ela é a que mais evita briga. Ela não existe pra limitar o produto — existe pra registrar que a possibilidade foi considerada e adiada de propósito. A diferença entre "não pensamos nisso" e "pensamos e ficou pra depois" é enorme na hora em que alguém pergunta na review.

Traduza "requisito" em comportamento observável

"O sistema deve ser rápido" não é requisito, é desejo. Peça à IA para reescrever cada requisito no formato "quando [situação], o sistema deve [comportamento], e o usuário vê [resultado]". Isso força clareza e, de quebra, já vira caso de teste.

Na prática, a tradução fica assim:

• ❌ "A busca precisa ser performática." → ✅ "Quando o usuário digita na busca, a lista de resultados atualiza em até 300 ms para consultas com menos de 3 caracteres; acima disso, mostramos o indicador de carregamento."
• ❌ "Tratar erro de pagamento." → ✅ "Quando o gateway retorna recusa, o usuário permanece na tela de pagamento com os dados preenchidos, vê o motivo da recusa em texto simples e um botão 'tentar outro cartão'."

Se a IA não conseguir reescrever um requisito nesse formato, o requisito ainda está vago — e isso é um sinal útil, não um defeito da ferramenta. Requisito que não vira comportamento observável é requisito que ainda não foi pensado até o fim.

Deixe a IA revisar contra o leitor real

Antes de mandar, cole o PRD e peça: "você é a pessoa de engenharia que vai implementar isso. O que ainda está ambíguo? Onde você começaria a discutir em vez de codar?" e depois "você é design. O que falta pra você desenhar as telas?". Cada persona expõe uma lacuna diferente. Corrigir isso antes da reunião transforma uma hora de dúvidas em quinze minutos de alinhamento.

Uma variação cruel e muito eficaz: "leia este PRD como alguém que quer que o projeto falhe e precisa de uma desculpa. Onde você se apoiaria?" Isso revela as frases que parecem decididas mas não são — os "vamos avaliar", os "conforme necessário", os "de forma otimizada". Cada uma dessas é uma discussão adiada que vai voltar no pior momento possível.

O que a IA não deve fazer

Ela não decide prioridade por você — isso é trabalho de PM, com contexto de negócio que ela não tem. Ela não inventa dados de usuário; se você não tem a pesquisa, o certo é escrever "suposição a validar", não deixar a IA preencher com algo plausível. E ela não substitui a conversa: o PRD alinha, mas as pessoas ainda precisam falar.

Há um risco específico que merece atenção: o PRD gerado por IA soa mais confiante do que a sua confiança real. O texto sai bem escrito, assertivo, sem hesitação — e isso esconde de você e do time o quanto ainda é chute. Se uma decisão foi tomada com pouca informação, escreva isso com todas as letras. "Escolhemos A com base em duas conversas com clientes, sem dado quantitativo" é infinitamente mais útil do que uma justificativa polida que finge certeza.

Resumo prático

Use o Claude para (1) criticar seu enunciado do problema, (2) gerar as perguntas difíceis de engenharia, design, dados e suporte, (3) preencher um template fixo que você controla, (4) transformar requisitos vagos em comportamento testável e (5) revisar o texto no lugar de cada leitor, inclusive o cético. Faça isso e o PRD deixa de ser burocracia e vira o que ele sempre deveria ter sido: o documento que evita retrabalho.