Como escrever um PRD a partir de um pedido de funcionalidade de uma linha
6 min de leitura
A maioria dos PRDs começa da mesma forma: um documento em branco e uma ideia de uma linha como "deixar os usuários exportarem os dados deles." A partir daí é fácil escrever livremente o que vier primeiro à cabeça, geralmente os requisitos, e perceber três parágrafos depois que não há declaração de problema nem métrica de sucesso em nenhum lugar do documento. Um PM entusiasmado com uma ideia de funcionalidade tende a começar escrevendo a mecânica de como ela deveria funcionar, os campos exatos, a posição exata do botão, bem antes de parar para anotar que problema ela de fato resolve.
Atenção
Um documento em branco não te lembra quais seções um PRD precisa ter. Ele só reflete de volta a ordem em que você pensou nas coisas, que raramente é a ordem em que um revisor espera lê-las.
Uma ideia de funcionalidade é uma frase. Um PRD é uma estrutura. Escrever livremente te dá a frase, só que expandida.
Por que escrever livremente pula seções sem você notar
Escrever a partir de uma página em branco significa inventar a estrutura à medida que avança, e é fácil escrever as partes que parecem óbvias, geralmente os requisitos, pulando as partes que exigem mais reflexão, como nomear o problema real ou escolher uma métrica que comprove que a funcionalidade funcionou. A seção de requisitos é concreta e satisfatória de escrever, já que é uma lista de coisas específicas e verificáveis. A declaração de problema exige dar um passo atrás e articular por que qualquer coisa disso importa, o que é um tipo de pensamento diferente e mais difícil, e é a parte que é pulada primeiro sob pressão de tempo.
Pense numa ideia de uma linha como "deixar os usuários exportarem os dados em CSV." Um PM entusiasmado com a ideia pode passar vinte minutos detalhando exatamente quais campos devem entrar na exportação e o que o botão deve dizer, e só perceber ao enviar o documento para revisão que não há uma única frase explicando por que isso importa, que o suporte vem recebendo pedidos manuais de exportação há meses. Um revisor abrindo esse documento não tem como julgar se os requisitos propostos de fato resolvem o problema real, porque o problema real nunca foi escrito.
Antes: abrir um documento em branco, começar a escrever os requisitos da ideia de funcionalidade, perceber depois que a declaração de problema e as métricas de sucesso estão faltando.
Depois: dar ao Claude a ideia de uma linha e o problema que ela resolve, e receber de volta um primeiro rascunho estruturado, problema, objetivos, requisitos e métricas, com cada seção já no lugar para refinar.
Um processo para um primeiro rascunho estruturado
- 1
Declare a ideia de funcionalidade e o problema que ela resolve
Uma frase para cada uma já é suficiente para começar. "Deixar os usuários exportarem os dados em CSV, porque o suporte não para de receber pedidos manuais" dá ao Claude tanto o quê quanto o porquê.
- 2
Peça uma estrutura fixa, não um rascunho aberto
Peça especificamente uma declaração de problema, um número pequeno de objetivos, requisitos funcionais e métricas de sucesso, nessa ordem. Uma estrutura fixa é o que torna o rascunho revisável em vez de um ensaio.
- 3
Dê um número real para objetivos e métricas
Peça uma quantidade específica, três objetivos, duas métricas, em vez de "alguns objetivos." Um número força a priorização em vez de uma lista aberta que não para de crescer.
- 4
Trate o rascunho como uma estrutura de partida, não um documento final
Releia e reescreva cada seção com sua própria voz. O valor do primeiro rascunho é que nada está faltando, não que a redação seja final.
Queremos deixar os usuários exportarem os dados em CSV. Redija um PRD de uma página com uma declaração de problema, três objetivos, requisitos funcionais e duas métricas de sucesso que poderíamos acompanhar nos primeiros 30 dias.
”Se a ideia de funcionalidade veio de uma fonte específica e conhecida, um conjunto de tickets de suporte, um pedido de cliente, uma lacuna competitiva, vale a pena dizer isso explicitamente ao Claude, já que uma declaração de problema fundamentada numa fonte real e nomeada soa muito mais credível para um revisor do que uma genérica, ainda que plausível.
Essa ideia veio diretamente de 15 tickets de suporte no último mês, todos pedindo uma forma de extrair os dados sem contatar o suporte. Reescreva a declaração de problema para referenciar especificamente essa fonte real, não uma descrição genérica da necessidade.
”
Dentro do Claude Tutorial
Começar de uma estrutura fixa em vez de uma página em branco é transferível.
Trabalhar a partir de um conjunto conhecido de seções, em vez de inventar a estrutura enquanto escreve, se aplica muito além de PRDs. O app tem uma aula completa sobre isso, com prática que vale para qualquer documento com um formato que os revisores esperam.
Quando os objetivos não combinam com as métricas
Uma lacuna comum num primeiro rascunho é um objetivo sem nenhuma métrica associada, ou uma métrica que não comprova de fato que o objetivo declarado aconteceu. Esse descompasso vale a pena ser identificado antes de o documento ser enviado, não depois que alguém perguntar como você vai saber que a funcionalidade funcionou. Um objetivo como "reduzir a carga do suporte" combinado com uma métrica como "número de exportações realizadas" parece relacionado, mas não comprova de fato o objetivo, já que os usuários poderiam exportar dados constantemente sem que um único ticket de suporte fosse evitado.
Dica
Peça ao Claude para verificar cada objetivo diretamente contra sua métrica: alcançar esse número de fato comprova o objetivo, ou só algo correlacionado a ele? Uma métrica fácil de medir não é automaticamente a certa.
Aqui estão os três objetivos e as duas métricas desse rascunho de PRD. Para cada objetivo, me diga honestamente se as métricas de fato comprovam que ele aconteceu, ou só medem algo adjacente a ele.
”Se uma métrica se revelar genuinamente difícil de acompanhar com as ferramentas existentes, vale a pena trazer essa restrição à tona desde já, em vez de lançar um PRD com uma métrica de sucesso que ninguém conseguirá de fato medir quando a funcionalidade estiver no ar.
Uma dessas métricas exigiria um rastreamento que não temos hoje em vigor. Sugira uma métrica que comprove o mesmo objetivo, mas seja realista de medir com nossa configuração atual de analytics.
”Continue lendo
- Afiando um PRD antes de enviá-lo para revisão: testando o rascunho estruturado que este artigo produz antes de ele chegar a um revisor.
- Escrevendo um documento de roadmap que explica as contrapartidas: o que acontece quando essa ideia de funcionalidade precisa competir com outras por um lugar no roadmap.
- Transformando tickets de suporte em temas priorizados: uma fonte de ideias reais de funcionalidades para escrever PRDs em primeiro lugar.