Você abriu uma página no Notion hoje de manhã com o título "PRD: [nome da feature]." Três horas depois, ela ainda diz "PRD: [nome da feature]."
Você conhece o problema. Conhece a solução. Explicou a história para o seu tech lead duas vezes ontem. Mas no momento em que senta para colocar tudo no papel, você trava.
Isso não é um problema de raciocínio. É um problema de digitação.
PMs não são pagos para digitar. Você é pago para tomar decisões sobre o que construir e por quê. O PRD é só o artefato que registra a decisão para que engenharia, design e liderança consigam agir. Em algum lugar entre saber o que escrever e terminar o doc, horas evaporam.
Existe um caminho mais rápido. O PRD é um dos documentos com formato mais adequado para voz que um PM escreve. Ele é basicamente o que você diria em pé na frente de um quadro branco explicando a feature. Quando você para de digitar PRDs e começa a ditá-los, o tempo de draft despenca.
O imposto de escrita do PM que ninguém comenta
Cada PRD que você escreve está competindo com uma reunião, uma revisão de roadmap, uma thread no Slack com stakeholders. A escrita de verdade acontece em janelinhas de meia hora roubadas ou depois do jantar.
A matemática é cruel. A pessoa média digita a cerca de 40 palavras por minuto. A pessoa média fala a cerca de 150. Isso é mais ou menos uma diferença de 3,5x antes mesmo de contar as fricções que tornam a escrita mais difícil: apagar, reformular, questionar uma frase três vezes antes de seguir em frente.
Um PRD de 1.500 palavras que leva 90 minutos para ser digitado leva cerca de 25 minutos para ser falado. O raciocínio é o mesmo. O resultado é o mesmo. Só o mecanismo muda.
Por que PRDs têm formato perfeito para voz
A maioria dos documentos pune a ditado porque exige precisão: código, tabelas, modelos financeiros. PRDs são o oposto. São documentos narrativos.
Pense no último PRD que você escreveu. A seção "Problema" é uma explicação de dois parágrafos sobre por que algo importa. A "Solução" é uma descrição de como a coisa funciona. As "User Stories" são frases no formato "Como X, quero Y, para que Z." A seção "Edge Cases" é uma lista de cenários do tipo "o que acontece quando...".
Nada disso exige precisão de teclado. Tudo isso é o tipo de coisa que você falaria em uma reunião. O formato já combina com a forma como um PM realmente comunica o trabalho.
O fluxo de draft de PRD em 30 minutos
Esta é a estrutura que funciona: 1. Abra um doc em branco com os títulos das seções já no lugar: problema, solução, user stories, critérios de aceitação, edge cases, fora do escopo, perguntas em aberto. 2. Avance seção por seção. Dite cada uma como se estivesse explicando para uma pessoa nova de engenharia que acabou de entrar no time. 3. Não edite enquanto fala. A troca mental entre "locutor" e "editor" é o que mais te atrasa. 4. Depois de ditar todas as seções, leia o draft completo uma vez, de cima a baixo. Ajuste a linguagem. Corrija o que estiver genuinamente errado. 5. Mande para revisão.
A disciplina está no passo três. Se você fica parando para arrumar frases, não está ganhando o benefício de velocidade. Você voltou à velocidade de digitação só que vestido com outra fantasia.
Seção por seção: como ditar cada parte de um PRD
Algumas seções são mais fáceis de ditar do que outras. Veja como abordar cada uma.
Declaração do problema
Esta é a seção mais fácil de ditar. Puro texto narrativo. Você está explicando o que está quebrado, para quem está quebrado e por que importa agora.
Fale como se estivesse fazendo um briefing rápido para um novo colega no stand-up. Mencione o segmento de usuário, a fricção que ele encontra, a métrica que isso afeta. Não se preocupe com elegância da prosa. Esse é trabalho da edição.
Visão geral da solução
Descreva a solução proposta como se estivesse rabiscando num quadro branco. "O usuário clica aqui, vê isto, e então..." A voz lida bem com isso porque combina com a forma como você já explicaria em voz alta.
User stories
User stories soam mecânicas por causa do padrão "Como X, quero Y, para que Z", mas funcionam bem ditadas se você se comprometer com o formato. Diga cada story como uma frase única, depois passa para a próxima.
Se você tem dez stories, dite as dez em uma única passada. Não numere conforme avança. Deixe o editor do doc ou seu passe de limpeza com IA cuidar da formatação.
Critérios de aceitação
Listas são a parte mais complicada do ditado por voz, mas viáveis. Duas abordagens:
A primeira é ditar os critérios como frases completas e deixar a IA polir e converter em lista. Diga algo como: "O usuário deve conseguir filtrar resultados por data, por usuário e por status. O estado do filtro deve persistir entre sessões. O estado vazio deve mostrar uma dica."
A segunda é falar explicitamente a estrutura de bullets: "Bullet um, filtrar por data. Bullet dois, filtrar por usuário. Bullet três, persistir entre sessões." Escolha o que ficar menos esquisito na sua boca.
Edge cases
É aqui que a voz realmente brilha. Edge cases são esse tipo de conteúdo de pensar em voz alta que sai limpinho quando você fala e desajeitado quando você digita. Perguntas como "e se o usuário estiver offline" ou "e quando os dados estiverem desatualizados" fluem mais naturalmente na fala do que na escrita.
Dite todo edge case que vier à cabeça, mesmo os que parecem óbvios. Você pode podar na edição.
Fora do escopo
Três frases. Talvez quatro. A voz resolve isso em menos de um minuto.
Perguntas em aberto
Esta seção é subestimada. A maioria dos PMs pula porque não quer parecer incerto. Não pule. A seção de perguntas em aberto é onde engenharia, design e seu skip-level pegam as coisas que você ainda não pensou direito.
A voz é a ferramenta certa para isso. Perguntas em aberto são exatamente os pensamentos meio formados que saem bem quando você fala e ficam estranhamente pesados quando você tenta digitar. Dite toda incerteza em voz alta, mesmo as que você suspeita que tenham resposta óbvia. Metade vai se resolver no próximo standup. A outra metade vai salvar o seu lançamento.
Ajustando o tom à seção
Um PRD não é escrito em uma só voz. O resumo executivo no topo precisa ser enxuto e estratégico. As specs técnicas precisam ser precisas. A seção de "perguntas em aberto" pode ser mais informal.
Quando você dita, naturalmente muda de registro. Sua voz fica mais formal quando fala de estratégia e mais solta quando passa pelos edge cases. O problema é que a maioria das ferramentas de ditado entrega a mesma transcrição chapada independente do contexto.
É exatamente aí que entram as Smart Rules do Voicr. Você pode definir um estilo "prosa profissional limpa" para seu editor de docs, um estilo "brainstorm casual" para suas threads no Slack e um estilo "clareza técnica" para a wiki de engenharia. O Voicr detecta o app ativo e aplica o estilo certo automaticamente, então o mesmo pensamento falado aterrissa de forma diferente dependendo de onde ele acaba.
Para PRDs especificamente, configure uma regra que peça prosa profissional limpa, remova palavras de preenchimento e estruture listas com bullets onde você sinalizar. Você fala uma vez. O doc fica como se você tivesse escrito com calma.
Onde a voz não ajuda
Sendo honesto: nem toda parte de um PRD se beneficia da voz.
Tabelas e matrizes ainda são mais rápidas no teclado. Se o seu PRD inclui uma grade de comparação de features, uma matriz de permissões ou uma tabela de estimativa de esforço, digite.
Strings técnicas exatas também são mais rápidas digitadas. Nomes de endpoints de API, nomes de colunas de banco, números de versão — dá para ditar contornando ("o endpoint é, barra, users, barra, ID"), mas fica desajeitado. Digite isso.
Diagramas obviamente não podem ser ditados. Desenhe na ferramenta que preferir e incorpore.
Para todo o resto — narrativa, user stories, edge cases, decisões, justificativas — a voz ganha na velocidade e no fato de que você não fica travado no meio de uma frase tentando formular tudo perfeitamente.
A mudança de mentalidade: pense em voz alta, edite depois
O maior ganho de ditar PRDs não é a matemática de WPM. É que você para de polir enquanto escreve.
Quando você digita, você apaga. Reescreve a mesma frase duas vezes. Fica olhando para um parágrafo que está "quase certo" por dez minutos. É aí que os PRDs vão morrer: no vão entre rascunho e edição, onde nenhum dos dois acontece de verdade.
Quando você dita, você se compromete. Você fala uma frase, ela cai na página, e você segue em frente. A primeira versão é mais bagunçada do que o que você digitaria. Mas você termina o draft. E um draft bagunçado, porém pronto, é dramaticamente mais útil do que um polido pela metade.
Quando o draft existe, editar é uma atividade diferente e bem mais rápida. Muitas vezes você vai gastar mais tempo refinando do que ditando, e tudo bem. Refinar um doc completo é um trabalho conhecido. Encarar um doc em branco não é.
Experimente no seu próximo PRD
Escolha um PRD que você vem empurrando com a barriga. Abra o doc, coloque os títulos das seções no lugar e dite de cima a baixo sem editar. Coloque um timer de 25 minutos. Veja o que sai.
Na primeira vez vai parecer estranho. Você vai achar que o resultado não está bom o suficiente. Resista à vontade de arrumar coisas no meio do fluxo. Só termine.
Se você quer que o ditado saia limpo a ponto de quase não precisar editar, o Voicr cuida do polimento automaticamente. Segure FN de qualquer lugar no seu Mac, fale sobre uma seção, solte e cole o texto limpo no seu doc. Ele remove palavras de preenchimento, conserta a gramática e estrutura suas ideias antes de chegarem ao clipboard. O draft de PRD que costumava ocupar uma tarde inteira passa a caber em uma sentada.
Seus PRDs não vão se escrever sozinhos. Mas também não precisam ser digitados.