Todo AI Product Manager já perdeu uma tarde inteira travado na primeira frase de um PRD. A página em branco não é falta de ideia, é excesso. Contexto de negócio, dor do usuário, restrição técnica, métrica de sucesso, edge case: tudo na sua cabeça ao mesmo tempo, e nada organizado no papel.

O resultado é um documento que sai atrasado, incompleto, ou tão genérico que o time de engenharia volta com trinta perguntas na primeira daily.

Escrever um PRD com Claude muda esse jogo, mas não do jeito que a maioria imagina. Não se trata de pedir "escreva um PRD pra mim" e colar a resposta. Quem faz isso entrega documento raso e perde a autoria do produto. A forma que funciona é usar o modelo como par de raciocínio dentro de um método.

Neste artigo você vai ver o framework CRIA (Contexto, Requisitos, Iteração e Aceite), aplicado passo a passo, com os prompts reais de cada fase e o que esperar de saída.

O que é um PRD (e por que o modelo de IA não substitui o PM)

PRD é a sigla de Product Requirements Document: o documento que traduz um problema de produto em requisitos claros o suficiente para o time construir a coisa certa. Ele responde três perguntas: qual problema, para quem, e como saberemos que resolvemos.

Claude entra como acelerador de clareza, não como autor do produto. A decisão continua sua. O modelo estrutura, questiona, encontra o edge case que você não viu e transforma bullet solto em requisito testável. A proficiência aplicada aqui está em conduzir a conversa, não em delegá-la.

O framework CRIA na prática para construir seu PRD

CRIA é um ciclo de quatro fases. O nome não é acaso: um bom PRD cria alinhamento antes de qualquer linha de código.

C — Contexto: alimente antes de pedir

A qualidade do PRD é limitada pela qualidade do contexto. Comece assim:

> "Você é meu par na escrita de um PRD. Vou te dar o contexto bruto de uma feature. Não escreva o PRD ainda. Primeiro, organize o que eu te der e me diga quais lacunas de contexto impedem um bom documento. Contexto: [cole aqui problema, usuário, dado de uso, restrição de negócio, prazo]."

Pedir as lacunas primeiro é o pulo do gato. O modelo aponta o que você não trouxe, a métrica que falta, o segmento de usuário que ficou de fora, antes de gerar qualquer texto.

R — Requisitos: do problema ao testável

Com o contexto fechado, peça a estrutura:

> "Com base no contexto acima, liste requisitos funcionais e não-funcionais. Separe 'must have' de 'nice to have', e para cada requisito adicione a restrição técnica ou de negócio associada."

Aqui o time de engenharia começa a ganhar tempo: requisito com restrição explícita corta metade das perguntas da daily.

I — Iteração: onde o PRD fica bom

Um PRD de primeira versão é um rascunho. A iteração é o momento de subir a régua:

> "Aja como um engenheiro sênior cético. Quais edge cases esse PRD ignora? Onde o escopo está inflado? O que você cortaria para uma v1 enxuta?"

Rode isso duas ou três vezes, trocando o papel, ora engenheiro, ora designer, ora suporte. Cada lente revela um buraco diferente.

A — Aceite: fechando com critérios testáveis

Nenhum PRD está pronto sem definição de pronto:

> "Escreva os critérios de aceite em formato Dado/Quando/Então para cada requisito 'must have'."

Critério de aceite testável é o que separa um documento que gera retrabalho de um que gera entrega.

Por que isso funciona (o porquê, não só o como)

O ganho não é velocidade de digitação — é redução do gap de confiança entre o que está na sua cabeça e o que está escrito.

O modelo força você a explicitar suposições. E ao pedir para ele criticar em vez de produzir, você mantém o julgamento de produto onde ele deve estar: em você. Documentação oficial da Anthropic reforça esse padrão de uso, modelos rendem mais como colaboradores de raciocínio do que como geradores de texto final.

Erros comuns ao escrever um PRD com Claude

• Delegar a decisão. O modelo não sabe a estratégia da sua empresa. Você sabe.

• Pular o Contexto. Contexto pobre gera PRD genérico, sempre.

• Aceitar a primeira versão. A fase de Iteração é onde o documento vira profissional.

• Confiar em dado gerado. Se o modelo cita um número de mercado, valide na fonte. PRD com dado inventado é dívida técnica de produto.

Escrever um PRD com excelência é só a ponta de um trabalho de produto que está sendo redesenhado pela IA. Um PM que constrói com IA no dia a dia entrega mais rápido, com mais clareza e mais autonomia.

É exatamente isso que a Formação AI Product Manager da Tera desenvolve: proficiência aplicada para liderar produto na era dos builders. Construa essa habilidade na prática.

FAQ

Escrever um PRD com Claude substitui o Product Manager?

Não. O modelo acelera a estruturação e o questionamento, mas a decisão de produto, a priorização e a leitura de contexto estratégico continuam com o PM.

Quanto tempo o framework CRIA economiza?

Pode varias, mas o maior ganho não é o tempo de escrita, é a redução de retrabalho. Um PRD com critérios de aceite testáveis chega ao time com menos ambiguidade e menos idas e vindas.

Preciso de um prompt gigante para funcionar?

Não. O framework CRIA funciona em ciclos curtos. Cada fase é uma conversa objetiva. O segredo está na sequência, não no tamanho do prompt.

Dá para usar o framework CRIA com outros modelos?

O framework é agnóstico. Ele organiza como você conversa com o modelo. A prática mostra que funciona melhor quando você aproveita janelas de contexto grandes para manter todo o histórico da feature na conversa.