Como escrever um product requirements document quando você não é PM

Uma fundadora com quem trabalhamos nos mandou um PRD de quatorze páginas no verão passado. Capa, glossário, OKRs, três personas, fatiamento de sprint, métricas de sucesso, um protótipo no Figma que o time ainda não tinha construído, e uma seção chamada “non-functional requirements” que parecia copiada de um template enterprise na noite anterior. O time que ela ia briefar tinha três engenheiros e um designer meio período em um estúdio com quem ela nunca tinha trabalhado. A primeira call sobre escopo durou duas horas e não resolveu nada.

Aquele documento não era um product requirements document. Era um artefato de PM escrito no vácuo, por uma fundadora que tinha lido guias da Atlassian e da Notion suficientes para saber quais headers colocar, e tinha pensado pouco demais sobre as próprias restrições para saber de quais seções ela realmente precisava.

Se você está procurando como escrever um product requirements document, está quase certamente em uma de duas situações. Você é product manager numa empresa que já tem time de engenharia, e nesse caso os guias que existem na internet foram escritos para você. Ou você é fundador não-técnico briefando um desenvolvedor, um pequeno estúdio, ou seu primeiro hire de engenharia, e os guias que existem assumem um contexto que você não tem. Este texto é para o segundo grupo.

A definição honesta de um PRD

Um product requirements document é um acordo escrito entre a pessoa que decide o que vai ser construído e as pessoas que vão construir. Esse é o trabalho inteiro. Tudo o mais, as personas e as user stories e os dashboards de analytics, é evidência de apoio. A maior parte dos guias de PRD na internet infla a evidência de apoio até virar o documento, porque a maior parte dos guias é escrita para um contexto onde alinhar uma organização de produto de quinze pessoas é o problema real.

Seu problema é outro. Você não está alinhando quinze stakeholders. Você está entregando a um pequeno time de build uma imagem clara o bastante do que construir e por quê, para que eles possam tomar as dezenas de decisões pequenas que vão tomar na sua ausência sem te mandar uma mensagem no Slack a cada vinte minutos. O documento precisa fazer duas coisas bem: dizer o que o cliente deve conseguir fazer, e dizer quais trade-offs você já decidiu para que eles não te surpreendam depois.

Esse é um documento muito menor do que os templates sugerem. A maioria dos fundadores não-técnicos com quem trabalhamos termina em quatro a sete páginas, não vinte. O documento encolhe quando você entende quais seções merecem espaço.

Seis seções que merecem espaço

Todo PRD de fundador que vimos funcionar nos últimos três anos tem essas seis peças, mais ou menos nessa ordem. Você pode renomear os títulos. A substância tem que estar lá.

1. O cliente e o momento

Um parágrafo, no máximo. Quem é o usuário, e o que ele está fazendo nos trinta segundos antes de encontrar o seu produto. Não é deck de personas. É uma cena.

Uma contadora autônoma de um pequeno escritório acabou de receber quatorze notas fiscais de clientes no mês, cada uma em um formato diferente. Ela precisa lançar todas no QuickBooks antes da conciliação de fim de semana. Hoje isso leva três horas. Ela está na mesa dela com as notas abertas em quatorze abas do navegador.

Esse parágrafo trabalha mais do que três páginas de personas. O time que vai construir o produto agora sabe que tipo de fricção importa e qual não. Velocidade de upload importa. Animações bonitas, não. A contadora não vai encaminhar o produto para um amigo em uma planilha de comparação de features, então polish na superfície de marketing não é prioridade do v1.

2. A decisão que você já tomou

Fundadores pulam essa seção porque ela parece óbvia para eles. Não é óbvia para o time de build. Diga claramente: o que está dentro do build, o que está fora, e quais são as premissas que vão quebrar se alguém mudar.

Se você está pagando um vendor, toda premissa que você não escreve vira uma pergunta que ele te faz depois, que vira um atraso, que vira um re-escopo. Escrever as premissas é mais barato do que reabrir todas elas no meio do projeto.

Uma versão limpa lê assim: vamos construir um web app, não um app mobile, porque nossos usuários ficam em mesas. Vamos integrar com QuickBooks Online, não com Xero, não com Sage, porque oitenta por cento do nosso pipeline é QBO. Não vamos construir sistema de billing no v1; vamos cobrar fatura no manual nos primeiros seis meses. O alvo é Chrome e Safari no desktop. Mobile e Edge não são v1.

Esse parágrafo economiza quatro horas de reunião.

3. A menor versão que ganha dinheiro ou aprendizado

Isso é o que pessoas reais de produto chamam de MVP, e é a parte que a maioria dos fundadores erra. Um v1 não é “tudo da visão de longo prazo, mas menor.” Um v1 é a menor superfície que permite cobrar de um cliente real ou matar a ideia. A maioria das coisas que você quer pôr no v1 não está no v1.

Escreva essa seção como uma lista de jobs visíveis ao usuário que o v1 precisa completar de ponta a ponta. Não features. Jobs. “Subir uma nota fiscal e vê-la no QuickBooks em cinco minutos” é um job. “Drag-and-drop para upload” é uma feature. O time de build pode escolher a feature certa para entregar o job. O time não pode escolher o job certo para entregar, porque não sabe quais jobs seus clientes vão pagar para ter.

Um v1 de pre-seed normalmente tem entre três e seis jobs. Se a sua lista tem doze, você não está escrevendo um v1; está escrevendo uma wishlist. Corte.

4. Os trade-offs que você não vai brigar depois

Engenheiros tomam centenas de decisões pequenas durante um build. A maioria é invisível para você. Algumas não são, e essas viram briga se você não escrever antes.

Três trade-offs aparecem em quase todo build:

O primeiro é escopo versus polish. Você pode ter uma fatia fina que faz dez coisas mais ou menos, ou duas coisas com excelência. Escolha. O time vai escolher por você se você não escolher, e não vai escolher o que você escolheria.

O segundo é velocidade versus durabilidade. Você pode entregar algo amarrado com fita adesiva em quatro semanas, ou algo manutenível em oito. Escolha. Já vimos fundadores insistirem na versão de quatro semanas, sprintarem para a demo de fundraise, e passarem os doze meses seguintes pedindo desculpas para engenheiros pela fita adesiva. Decida que erro você prefere cometer.

O terceiro é custom versus off-the-shelf. Todo build tem partes que devem ser compradas, não construídas. Auth é a óbvia; ninguém deveria estar construindo telas de login do zero em 2026. Exemplos menos óbvios: armazenamento de arquivos, e-mail transacional, pagamentos, busca. Diga ao time de build onde você quer que eles desenhem essas fronteiras, ou eles vão desenhar em lugares que vão te surpreender.

5. Como é o sucesso na semana oito

Escolha um resultado observável que signifique que o v1 funcionou. Não um dashboard de KPIs. Uma frase.

Um caso real de uma fintech com quem trabalhamos no ano passado: “Até a semana oito, três clientes pagantes terão feito pelo menos um fechamento mensal completo no produto, de ponta a ponta, sem que nosso time de suporte intervenha.” Essa frase é um contrato. Todo mundo no time de build consegue manter ela na cabeça e usar para resolver discussões de escopo. “Essa feature ajuda a bater a métrica de fechar sem suporte?” Se sim, constrói. Se não, adia.

A maioria dos PRDs de fundadores que lemos não tem essa seção. Eles têm um dashboard de doze KPIs e uma aspiração vaga. Isso não é meta; é contabilidade emocional.

6. O que está fora do escopo, e por quê

As coisas que você não vai construir merecem uma seção própria, porque senão elas voltam de fininho durante o build. Escreva. Escreva com o motivo. “App mobile: não, porque os usuários ficam em mesas.” “Multi-moeda: não, porque os clientes do v1 são só dos EUA.” “SSO: não, porque os clientes do v1 são empresários individuais.”

Você-do-futuro vai agradecer você-do-presente por essa seção na semana seis, quando um investidor perguntar por que você não tem app mobile e você responder em uma frase em vez de ter que voltar ao documento.

Seis seções que não deveriam estar no PRD do fundador

Essas pertencem a PRDs escritos para orgs de produto estabelecidas. Não pertencem ao brief de um fundador não-técnico. Colocar elas é a maneira mais confiável de gastar três semanas escrevendo um documento e ainda assim não ter um plano construível.

Glossário. Se você precisa de glossário, não podou o documento o suficiente. O time de build não deveria precisar consultar termos. Use as palavras que os engenheiros e os clientes deles realmente usam.

Personas. Personas são uma ferramenta para priorizar entre muitos tipos de usuário. Em pre-seed, você tem um tipo de usuário, e deveria conhecê-lo pelo nome. Escreva o parágrafo do cliente-e-momento.

OKRs. OKRs são ferramenta de alinhamento organizacional. Um fundador briefando um time de quatro pessoas não precisa deles. A frase “como é o sucesso na semana oito” faz o mesmo trabalho.

Roadmap além do v1. Roadmap depois do v1 é especulação. Qualquer vendor ou hire que trate seu roadmap pós-v1 como um plano real não está prestando atenção. Mantenha o roadmap fora do PRD; o que está no v1 é o plano, o que vem depois é hipótese.

User stories detalhadas com critério de aceite. Critério de aceite é como PMs traduzem roadmap em tracker. Um time de build pequeno não precisa deles antes; eles vão escrever o critério de aceite por conta própria, contra suas seis seções, e te perguntar quando algo for ambíguo. É mais rápido.

Wireframes que o time não desenhou. Se você esboçou as telas no Figma sozinho, não bote no PRD. O time de build vai redesenhar, e deve. Mostrar seu esboço tende a ancorar todo mundo em um layout que talvez não sobreviva ao contato com a implementação. Descreva o job do usuário; deixe o time desenhar a tela.

Um exemplo trabalhado: como um PRD de fundador ficou

O exemplo da contadora acima é de uma fundadora real. O PRD do v1 dela, depois que cortamos, tinha cinco páginas. A estrutura era exatamente as seis seções acima. Três jobs na lista do v1: subir notas, vê-las no QuickBooks em cinco minutos, mandar uma mensagem no Slack para a contadora quando algo falhasse. Dois trade-offs decididos antes: entregar em seis semanas em vez de três, segurar a única integração com QBO. Uma métrica de sucesso: dez escritórios pagantes fechando o mês sem suporte até a semana dez.

O build levou oito semanas em vez de seis. Um job escorregou para um v1.5 (notificação de falha). Dez escritórios pagantes bateram a métrica na semana doze. O PRD aguentou. A versão de quatorze páginas que substituímos não teria aguentado, porque seções demais eram brigas esperando para acontecer.

Esse é o teste de um bom PRD de fundador: ele sobreviveu ao contato com o build, e alguém precisou reabrir as premissas no meio da semana quatro. Se sim, o documento estava longo demais, vago demais, ou os dois.

Quando escrever mais, e quando escrever menos

A estrutura de seis seções não é regra dura. Duas situações pedem documento mais longo.

A primeira é setores regulados. Se você está construindo em healthtech, fintech, ou em qualquer lugar onde um time de compliance vai olhar o sistema, você vai precisar de um documento separado para esse time e uma seção no PRD que diga “review de compliance está em escopo, ver anexo.” Não pule isso; o custo de descobrir um buraco de compliance na semana seis é muito maior do que o custo de escrever na semana zero.

A segunda é quando você está pagando um vendor de preço fechado. Contratos de preço fechado empurram toda ambiguidade para a negociação contratual, porque o vendor vai cobrar por qualquer coisa não especificada. Nesse caso, o PRD vira documento de contrato, e você escreve mais longo porque cada linha não escrita é um change order futuro. Geralmente recomendamos que fundadores evitem contratos de preço fechado nessa fase exatamente por isso; construa com um partner que trabalhe em time-and-materials, e o PRD pode ficar curto.

Duas situações pedem documento mais curto. Se você está com um engenheiro em quem confia e com quem já entregou antes, um brief de uma página com três jobs e uma métrica de sucesso é suficiente. A confiança faz o trabalho que o documento faria. E se o seu v1 é genuinamente um protótipo, não um produto, escreva um parágrafo e um esboço e entregue em duas semanas. Chamar isso de PRD é teatro.

A versão que você escreve na semana um não é a versão que entra no ar

A coisa mais difícil sobre escrever um PRD como fundador não-técnico é aceitar que o documento vai mudar. Os PMs que escrevem os guias na Atlassian e na Notion sabem disso; os times deles mexem em PRDs em pleno voo todo dia. Fundadores escrevendo o primeiro PRD muitas vezes tratam como entregável de tiro único, passam adiante, e se sentem traídos quando a realidade força uma edição.

Escreva o documento com uma premissa: ele vai estar errado em algum lugar até o fim da semana dois. O time de build vai descobrir algo que quebra uma premissa. O trabalho do PRD não é estar certo; é ser específico o bastante para que estar errado apareça claro, rápido. Documento vago erra calado. Documento específico erra alto, e é esse tipo de erro que dá para consertar.

Se você nunca escreveu um, a primeira versão vai parecer desconfortavelmente opinionada. Ótimo. O oposto de opinionado é “cada um tem uma leitura diferente do que estamos construindo,” que é o modo de falha que o documento existe para evitar.

FAQ

Qual a diferença entre um PRD e um product brief?

Na maioria dos contextos de fundador não-técnico, não tem diferença útil. PMs às vezes usam “product brief” para um documento de uma página em estágio inicial e “PRD” para a versão mais longa. Escolha um termo e fique com ele; o documento faz o mesmo trabalho.

Quantas páginas deve ter um PRD de fundador?

Quatro a sete páginas para um v1, na nossa experiência. Se o seu tem vinte, o time de build não vai ler; vai dar uma passada nas três primeiras e te perguntar o resto em call.

Devo usar um template de PRD?

Templates são estrutura inicial, não documento pronto. O perigo é que o template te leva a preencher toda seção, inclusive as que você não precisa. Use as seis seções acima como checklist; trate qualquer seção que um template manda preencher e que não está nessa lista como opcional.

IA serve para escrever um PRD?

Para redigir o texto, sim. Para decidir o que entra no v1, não. As decisões das seções dois a seis são suas e só suas; um LLM pode te ajudar a escrever mais rápido, mas não consegue escolher quais trade-offs são certos para o seu negócio. Use IA na digitação, não no pensamento.

E se meu engenheiro pedir mais detalhe do que o PRD dá?

Responda a pergunta, e decida se ela merece entrar no documento. Se for uma pergunta recorrente que outro engenheiro vai fazer depois, escreva. Se for um esclarecimento pontual, responda no Slack e siga. O PRD é documento de trabalho, não contrato.