O PRD que vira produto, não que vira gaveta
Um PRD solto vira interpretação. Um PRD com critério de aceite testável vira produto, porque um agente de IA consegue executar em cima dele e você consegue conferir o resultado. A diferença mora no critério, e o critério continua seu.
Você escreve um PRD de três páginas descrevendo a feature nova, entrega pro time e parte pra próxima coisa. Duas semanas depois o dev entrega algo que tecnicamente cumpre o que está escrito, e não resolve o problema que você tinha em mente. O PRD não estava errado no português. Estava errado no critério: nunca dizia, de um jeito que dá pra testar, o que "pronto" significa.
O relatório recorrente que você refaz do zero toda semana não precisa ser refeito do zero. Esta aula mostra a escada que transforma essa tarefa repetível num sistema que quase se dispara sozinho.
Para uma due diligence, a IA calculou o passivo trabalhista consolidado de uma empresa-alvo e escreveu um parágrafo seguro sobre o risco. Quase entrou no parecer assim, sem checagem.
Você pede um briefing de campanha pra IA e ela devolve um documento bonito, cheio de objetivo vago como "aumentar o engajamento". Ninguém sabe, no fim da campanha, se ela funcionou ou não, porque nada ali era mensurável.
Você escreve a descrição de um programa de onboarding com objetivos genéricos como "integrar bem o novo colaborador". Três meses depois ninguém sabe medir se funcionou, porque "integrar bem" nunca virou um critério que dá pra checar.
Você escreve um PRD de três páginas descrevendo a feature nova, entrega pro time e parte pra próxima coisa. Duas semanas depois o dev, ou o agente de IA que você conectou ao repositório, entrega algo que tecnicamente cumpre o que está escrito, e não resolve o problema que você tinha em mente. O PRD não estava errado no português. Estava errado no critério: nunca dizia, de um jeito que dá pra testar de verdade, o que "pronto" significa. Um PRD bonito sem critério de aceite verificável não é spec, é redação. E redação não vira produto.
Você escreve o playbook de uma nova abordagem de vendas com instruções vagas como "personalizar mais o discurso". O time interpreta cada um do seu jeito, e não dá pra saber se o playbook funcionou, porque não havia critério nenhum pra medir.
Você escreve o procedimento novo do centro de distribuição com uma meta genérica de "reduzir o tempo de separação". Sem número e sem critério de teste, cada turno interpreta diferente, e ninguém sabe se o procedimento realmente resolveu o gargalo.
Você escreve a política nova de tratamento de dado com linguagem genérica sobre "boas práticas de segurança". Na auditoria, ninguém consegue provar que a política foi cumprida, porque nunca existiu um critério verificável.
Você escreve a issue técnica dizendo "melhorar a performance da busca". O dev entrega uma otimização real, só que não é a que resolvia o problema que o usuário sentia, porque a issue nunca definiu o que "melhorar" significava, com número.
Você escreve o brief de redesign com a meta de "deixar o fluxo mais intuitivo". Sem critério de teste, o time de design interpreta do seu jeito e você só descobre, no teste de usabilidade final, que não era aquilo que estava travando o usuário.
Você escreve a recomendação estratégica pro board com uma frase de efeito e nenhum critério de sucesso mensurável. Seis meses depois ninguém sabe dizer se a aposta deu certo, porque nunca ficou claro o que "certo" significava.
Deixa eu te falar uma coisa sobre PRD. Todo mundo já escreveu um PRD que parecia completo: contexto, objetivo, escopo, uma lista de "requisitos". E ainda assim virou retrabalho, porque duas semanas depois ninguém concordava se o que foi entregue estava certo ou não. Pensa comigo: o problema quase nunca é a redação. É que o documento nunca disse, de um jeito que dá pra testar, o que "pronto" quer dizer.
A ideia central desta aula. Um PRD vira produto quando carrega critério de aceite testável: uma frase que qualquer pessoa, ou qualquer agente de IA, consegue verificar como verdadeira ou falsa depois de implementado. A IA rascunha a estrutura do PRD e sugere critérios candidatos rápido. O que continua seu, e é o que decide se o PRD funciona, é garantir que o critério capture a intenção real, não só uma versão fácil de testar que não resolve o problema de verdade.
01Por que o PRD solto vira gaveta ou retrabalho
Um PRD sem critério verificável tem uma característica traiçoeira: ele PARECE completo. Tem contexto, tem objetivo, tem uma lista de "o que fazer". O que falta é a régua que diz quando parar de mexer e chamar de pronto. Sem essa régua, cada pessoa que lê o documento, um dev, um designer, um agente de IA, preenche a lacuna com a própria interpretação.
O resultado clássico: a feature "tecnicamente" cumpre o PRD e não resolve o problema. Ninguém mentiu, ninguém foi preguiçoso. O documento simplesmente nunca definiu o que "certo" significava de um jeito que desse pra checar.
02A anatomia do PRD executável: problema, critério, fora de escopo
Um PRD que vira produto tem três partes que fazem o trabalho pesado:
- O problema, com a evidência que sustenta. Não "o usuário quer mais velocidade", mas "vinte e três tickets e três contas enterprise citam lentidão no checkout", puxado direto da coreografia de feedback da aula anterior.
- O critério de aceite, testável. Uma frase no formato "dado isso, quando isso acontece, então isso deve ser verdade". Não "o checkout deve ficar mais rápido", mas "o tempo entre clicar em finalizar e ver a confirmação deve cair abaixo de dois segundos em noventa por cento das compras".
- O que fica fora de escopo, explícito. O que você decidiu NÃO fazer agora, escrito com a mesma clareza do que vai fazer. Isso corta a maior fonte de retrabalho: gente adicionando coisa que ninguém pediu.
03A IA rascunha rápido, o critério certo continua seu
Aqui a IA ajuda muito, e vale usar sem culpa. Você entrega o insight da coreografia de feedback (a evidência do problema), e pede o rascunho do PRD inteiro: contexto, objetivo, uma primeira lista de critérios de aceite candidatos. Ela monta isso em minutos, no formato certo, com boa redação.
O que ela não faz sozinha é garantir que o critério capture a intenção de verdade. É fácil a IA sugerir um critério fácil de testar e fácil de programar que não é o que resolve o problema do usuário. Exemplo clássico: o critério "o botão de exportar deve aparecer na tela" é testável e não resolve nada se o problema real era "o usuário não sabe que a exportação existe". Você lê cada critério candidato e pergunta: se isso for verdade, o problema do passo um está resolvido de verdade? Se a resposta for não, o critério está errado, mesmo sendo perfeitamente testável.
Saiba mais: critério testável não é sinônimo de critério certo
Existe uma armadilha sutil aqui. "Testável" é uma qualidade de forma: dá pra verificar se é verdadeiro ou falso. "Certo" é uma qualidade de conteúdo: o critério realmente captura o que resolve o problema do usuário. A IA é ótima garantindo a forma, porque forma é estrutura, e estrutura ela redige bem. Garantir o conteúdo, que aquele critério específico é a coisa certa a medir, exige que você tenha lido o insight de origem e saiba, de verdade, o que o usuário estava tentando fazer. Um PRD cheio de critérios testáveis e errados é pior que um PRD vago, porque ele passa a falsa sensação de rigor.
04Do critério ao agente: ler, fazer, mostrar pra você conferir
Um critério de aceite bem escrito é o que permite que um agente de IA execute a implementação com segurança, do jeito que você viu na aula 1.1: ele lê o PRD e o critério, faz a mudança no seu código ou no seu sistema, e mostra pra você conferir se o critério agora é verdadeiro. Sem critério claro, o agente não tem como saber quando parar, e você não tem como aprovar com confiança, só com a sensação de "parece que ficou bom".
Um critério bem escrito vira, quase de graça, o roteiro de teste que confirma a entrega. É o mesmo princípio de qualquer coreografia deste curso: quanto mais claro o critério na entrada, mais fácil e mais segura fica a conferência na saída.
05O que nunca se automatiza: a intenção por trás do critério
A regra final desta aula, e ela é curta. A IA pode escrever o PRD inteiro, sugerir todos os critérios, até simular se a implementação parece atender cada um. O que ela não pode fazer sozinha é decidir se aquele conjunto de critérios, tomado como um todo, resolve o problema que o usuário de verdade tem. Essa leitura de intenção é sua, vem da evidência que você reuniu, e é o motivo de você ainda ser necessário quando a redação virou barata.
Faça agora
Pegue uma feature ou correção real que você precisa especificar, a sua tarefa real ou outra. Escreva o PRD em três partes:
- Problema com evidência. Uma frase com o dado real por trás (número de tickets, citação de usuário, métrica que caiu).
- Critério de aceite testável. Escreva no formato "dado isso, quando isso acontece, então isso deve ser verdade". Se não conseguir escrever no formato testável, o critério ainda está vago.
- Fora de escopo. Liste duas ou três coisas que alguém poderia assumir que estão incluídas, e que você está deixando de fora nesta rodada, por escrito.
Agora releia o critério de aceite e pergunte: se isso for verdade, o problema do passo um está mesmo resolvido? Se a resposta for não, reescreva o critério antes de mandar pro time ou pro agente.
Pratique
1. Por que um PRD pode parecer completo e ainda assim virar retrabalho?
2. A IA sugeriu, para o problema 'o usuário não sabe que a exportação existe', o critério 'o botão de exportar deve aparecer na tela'. Esse critério é testável. Ele é certo?
Para o quadro
Sobre o que falta no PRDo problema quase nunca é a redação. É nunca ter dito, de um jeito testável, o que pronto quer dizer.
Sobre a lacunasem critério verificável, cada pessoa e cada agente preenche com a própria interpretação.
Sobre o limitea IA rascunha rápido. Conferir se o critério captura a intenção real continua sendo humano.
Valeu pelo feedback. Isso ajuda a afiar a próxima aula.