O que entra no seu PRD, e o que você deixa de fora de propósito?

Entra: o problema, a evidência de que ele é real, o usuário e a gambiarra atual dele, métricas de sucesso com um limiar de fracasso, não objetivos explícitos, e perguntas em aberto. Sai: o design da solução e a implementação. Se o seu documento especifica a UI ou o schema, você tirou as decisões interessantes de quem está mais bem posicionado para tomá las, e vai receber obediência em vez de ideias.

Meu PRD é curto e é majoritariamente evidência. Problema, quem tem ele e com que frequência, o que essas pessoas fazem hoje no lugar, por que agora, a métrica com um limiar explícito de fracasso, e uma lista de não objetivos. A seção de não objetivos justifica o espaço dela toda vez, porque é onde você corta o scope creep que chegaria na semana três. O que eu deixo de fora de propósito é a solução. Eu não coloco wireframes nem schema ali, porque no momento em que faço isso os engenheiros e a designer param de resolver e começam a implementar a minha ideia meio formada. Eu aprendi isso do jeito difícil depois de escrever uma especificação muito detalhada uma vez e receber exatamente o que pedi, que era pior do que o time teria construído por conta própria. Eu também mantenho uma seção de perguntas em aberto no topo e atualizo conforme a gente avança, para o doc mostrar o que ainda não sabemos em vez de fingir que está pronto.