Algumas decisões de produto aparecem em todo lugar.

Elas aparecem no comitê de roadmap. Aparecem com o time de sales. Aparecem no suporte. Aparecem nas specs. Aparecem nos tickets. Aparecem a cada novo grande cliente, a cada nova oportunidade, a cada caso limite um pouco visível.

Deve-se privilegiar o cliente ou o fornecedor num marketplace?

Vale traduzir o produto para todos os idiomas pedidos pelos prospects?

Vale abrir uma exceção para um segmento que poderia render muito?

Vale abrir um perímetro se o produto ainda não conseguir dar conta dele direito?

Essas perguntas não são features. Não são tickets. Não são detalhes de execução. São decisões estruturantes.

E quando não estão documentadas com clareza, a empresa as redecide sem parar.

Às vezes com as mesmas pessoas. Às vezes com outras. Às vezes com menos contexto. Às vezes sob pressão comercial. Às vezes na correria. Às vezes com uma memória parcial do que já tinha sido decidido.

O problema não é só a perda de tempo. O problema é a perda de coerência.

Uma decisão de produto importante não pode depender da memória oral de quem estava na reunião.

É exatamente esse o papel de um Product Decision Record.

A inspiração: os ADR do lado técnico

Os times técnicos já conhecem uma prática parecida: os ADR, de Architecture Decision Records.

Um ADR é um documento curto que registra uma decisão de arquitetura. Ele explica o contexto, as opções consideradas, a decisão tomada e suas consequências.

A vantagem é simples: vários meses ou vários anos depois, uma pessoa consegue entender por que uma escolha técnica foi feita.

Vamos a um exemplo.

Uma aplicação enfrenta um aumento de carga. Os clientes ficam mais numerosos. As consultas aumentam. As lentidões ficam frequentes. O time decide então implementar uma tecnologia de fila para processar certas mensagens de forma assíncrona.

Essa escolha não é uma feature.

Durante um mês, os desenvolvedores talvez trabalhem num projeto puramente técnico. Vão precisar se capacitar. Vão precisar mudar uma parte da arquitetura. Não vão entregar de imediato um valor de negócio visível para o usuário final.

Mas essa decisão pode eliminar um gargalo enorme. Ela pode permitir absorver dez, vinte ou trinta vezes a carga atual só adicionando servidores. Ela também pode liberar o comercial, que vai poder vender novos acessos de clientes sem receio de que a aplicação trave.

Um ADR permite documentar essa decisão.

Por que ela foi tomada? Quais opções foram descartadas? Quais consequências a gente aceita? O que isso permite? O que isso restringe?

O Product Decision Record retoma essa lógica, mas no lado do produto.

Um PDR não é uma decisão de feature

Um Product Decision Record documenta uma decisão de produto estruturante.

Não uma oportunidade.

Não um card do Jira.

Não uma spec.

Não uma feature.

Um PDR registra uma regra de decisão que a empresa assume e que vai orientar vários produtos, times ou situações futuras.

Ele não diz: "aqui está a funcionalidade a construir".

Ele diz, na verdade: "nesse tipo de situação, aqui está a regra que a gente aplica".

É uma diferença importante.

Se você usa os PDR para documentar cada decisão pontual, a ferramenta vira burocracia. Ela perde a força. Um bom PDR precisa tratar de uma decisão estruturante o suficiente para evitar dezenas de rediscussões.

Seu valor vem da raridade.

Uma empresa não deveria produzir cinquenta PDR por trimestre. Alguns por ano já bastam. Cinco, dez, quinze, vinte no máximo, dependendo do tamanho e da complexidade da organização.

Um PDR precisa ser importante o bastante para ficar na cabeça, ou para ser encontrado rápido quando uma pergunta volta.

Exemplo: marketplace, cliente ou fornecedor?

Num marketplace, existe uma tensão estrutural.

Quando surge um conflito, deve-se privilegiar o cliente ou o fornecedor?

Você pode tentar fazer os dois. Pode buscar um meio-termo toda vez. Pode tratar cada caso como uma exceção. Mas em muitas situações, é preciso mesmo escolher.

Se a empresa não documenta essa decisão, cada time corre o risco de interpretá-la do seu jeito.

O suporte pode querer preservar a relação com o cliente.

O time de parcerias pode querer proteger os fornecedores.

O produto pode querer evitar complicar as regras.

O time de sales pode empurrar a opção que ajuda a conta mais estratégica do momento.

E a cada conflito, a mesma pergunta vai voltar.

Um PDR permite estabelecer uma diretriz:

Em caso de conflito, a gente privilegia o cliente.

Essa decisão não descreve uma feature. Ela nem descreve um workflow específico. Mas vai influenciar dezenas de decisões: regras de reembolso, políticas de disputa, mensagens do suporte, prioridades de produto, decisões operacionais, comunicação com o cliente.

É exatamente o nível certo para um PDR.

Ele documenta uma decisão transversal.

Ele deixa a escolha explícita.

Ele permite que os times avancem sem reabrir o debate a cada caso limite.

Exemplo: os idiomas num SaaS

Vamos a outro caso, bem frequente nas empresas SaaS.

Os times comerciais querem vender em vários países. Um prospect alemão pede uma interface em alemão. Um prospect espanhol pede o espanhol. Uma grande conta italiana pede o italiano. Cada oportunidade parece interessante.

Mas no lado do produto, traduzir uma aplicação não é só trocar o texto.

É preciso traduzir a interface. Manter as traduções. Testar as telas. Adaptar a documentação. Capacitar o suporte. Cuidar dos emails. Verificar as mensagens automáticas. Acompanhar as mudanças. Evitar que certos idiomas virem versões piores do produto.

Sem uma decisão clara, cada novo prospect pode reabrir o assunto.

Um PDR pode fixar a regra.

# PDR 004 — Idiomas suportados por padrão

## Status
Validado

## Decisão
O produto é suportado por padrão em francês e inglês. Qualquer outro idioma exige um patamar mínimo de faturamento anual assinado.

## Contexto
Os times comerciais encontram oportunidades em vários países. Cada idioma acrescenta um custo de tradução, de manutenção, de suporte, de documentação e de qualidade do produto.

## Alternativas consideradas
- Traduzir todos os idiomas pedidos: caro demais e difícil de manter.
- Suportar só o francês: limitante demais para o crescimento comercial.
- Suportar francês e inglês por padrão, e depois abrir os outros idiomas sob condição.

## Decisão tomada
Francês e inglês são suportados por padrão. Os outros idiomas só são abertos se contratos assinados ultrapassarem um patamar definido.

## Consequências
- Melhor controle da qualidade.
- Menos promessas comerciais difíceis de cumprir.
- Algumas oportunidades comerciais serão recusadas ou adiadas.

## Condições de reavaliação
A decisão será reavaliada se a IA reduzir muito o custo de tradução mantendo um nível de qualidade aceitável, ou se um novo segmento estratégico exigir um idioma.

Esse PDR não fecha o assunto de vez.

Ele dá uma regra atual.

Ele permite que o time de sales saiba o que pode vender. Permite que o produto recuse pedidos sem refazer toda a argumentação. Permite que a direção entenda o custo real de abrir um novo idioma.

E ele contém uma condição de reavaliação.

Se a IA tornar possíveis traduções confiáveis a baixo custo, a decisão pode mudar. Se um novo segmento estratégico exigir um idioma, a decisão pode mudar. Se vários contratos assinados justificarem o investimento, a decisão pode mudar.

Mas se ela muda, a gente não reescreve o PDR antigo.

A gente cria um novo.

O que merece um PDR

Nem toda decisão de produto merece um PDR.

Esse é, aliás, o ponto mais importante.

Um PDR precisa continuar raro. Senão, ele vira mais uma forma de documentação que ninguém lê.

Uma decisão provavelmente merece um PDR se ela for transversal, estruturante, duradoura, cara de reverter, sujeita a ser rediscutida, útil para vários times e importante o bastante para influenciar várias decisões futuras.

Ao contrário, uma decisão provavelmente não merece um PDR se ela for local, pontual, ligada a uma única feature, já coberta por uma regra existente, sem consequência duradoura, ou óbvia demais para ser rediscutida.

O teste é simples:

Se a decisão não vai evitar nenhuma rediscussão futura, ela provavelmente não precisa de um PDR.

Um PDR não existe para documentar tudo o que o Product Manager decide.

Ele existe para documentar as escolhas que estruturam o quadro dentro do qual os Product Managers, o time de sales, o suporte, as operações e às vezes a direção vão depois tomar decisões locais.

Um formato curto, estruturado, suficiente

Um PDR precisa continuar curto.

O formato serve para evitar esquecimentos, não para produzir um dossiê burocrático.

Um template útil pode ficar assim:

# PDR <número> — <título>

## Status
Proposto | Validado | Substituído pelo PDR <número> | Abandonado

## Data
YYYY-MM-DD

## Decisão
Uma frase clara.

## Contexto
Por que essa decisão é necessária agora.

## Alternativas consideradas
- Opção A: ...
- Opção B: ...
- Opção C: ...

## Decisão tomada
O que a empresa escolhe.

## Razões da escolha
- ...
- ...

## Consequências
### Positivas
- ...

### Negativas
- ...

### Riscos
- ...

## Condições de reavaliação
O que poderia justificar um novo PDR.

## Decisores e pessoas consultadas
- Decisor:
- Consultados:

## Referências
- ...

O conteúdo exato pode variar.

Mas o essencial precisa sempre estar presente: o contexto, a decisão, as alternativas, as razões da escolha, as consequências, os decisores, e o que poderia fazer a decisão evoluir.

O PDR não pode virar um PRD.

Ele não deve descrever toda a execução.

Ele deve documentar o porquê.

A gente não reescreve a história

Um PDR validado não some.

Ele não é reescrito para esconder uma mudança de posição.

Se for preciso mudar a decisão, a gente cria um novo PDR que substitui o antigo.

Isso é essencial.

O PDR não existe para provar que a empresa sempre teve razão. Ele existe para entender por que ela decidiu o que decidiu num dado momento.

No exemplo dos idiomas, o primeiro PDR pode dizer: francês e inglês só por padrão, outros idiomas sob condição de faturamento assinado.

Dois anos depois, a IA pode mudar o custo de tradução. A qualidade pode ficar suficiente. O suporte pode se equipar. O produto pode decidir que os idiomas secundários passarão a ser traduzidos automaticamente, com revisão humana nos fluxos críticos.

Isso não é uma contradição.

É uma nova decisão num novo contexto.

O PDR antigo continua útil, porque ele explica por que a empresa inicialmente recusou traduzir tudo. O novo PDR explica por que essa recusa não faz mais sentido.

Essa rastreabilidade evita a amnésia de produto.

Ela também evita os julgamentos internos absurdos: "Por que a gente não fez isso antes?" Talvez porque antes o custo, a qualidade, os recursos e o contexto comercial não permitiam fazer direito.

PDR, PRD, roadmap, backlog: não misturar

Um PDR não é um PRD.

Um PRD descreve o que a gente quer construir.

Um PDR explica por que a empresa escolheu uma regra de decisão.

Um roadmap mostra o que a empresa faz, prepara, considera ou recusa dentro de um horizonte definido.

Um backlog organiza o trabalho executável, ou logo executável.

Um ticket recorta uma ação operacional.

O PDR está mais a montante.

Ele pode influenciar um roadmap. Pode restringir um PRD. Pode explicar por que certos tickets existem ou não existem. Mas ele não substitui nenhum deles.

É justamente por ficar nesse nível que ele é útil.

Se um PDR desce baixo demais, ele vira uma spec disfarçada.

Se um roadmap tenta fazer o papel de um PDR, ele mistura comunicação e regra de decisão.

Se um ticket carrega uma decisão estruturante, ele a torna invisível para o resto da empresa.

Cada ferramenta precisa ficar no seu nível.

O PDR não é burocracia

É fácil usar mal os PDR.

Dá para criar demais. Deixar longos demais. Transformá-los em atas. Usá-los para se proteger. Fazê-los ser validados por gente demais. Escrevê-los depois do fato para justificar uma decisão já imposta.

Nesse caso, sim, o PDR vira burocracia.

Mas não é esse o uso normal.

Um bom PDR tira burocracia.

Ele evita refazer cinquenta vezes a mesma explicação.

Ele evita reabrir a mesma decisão a cada grande prospect.

Ele evita depender da memória de uma pessoa.

Ele evita que os times fiquem navegando entre regras implícitas, exceções não ditas e decisões contraditórias.

A documentação não é o problema.

A documentação ruim é o problema.

Um PDR curto, raro, claro e imutável não pesa na organização. Ele dá a ela uma coluna vertebral de decisão.

Conclusão

Uma empresa de produto não sofre só com falta de prioridades.

Ela sofre, muitas vezes, com falta de memória sobre suas decisões.

Ela sabe o que fez, mas nem sempre lembra por que fez. Lembra de uma conclusão, mas não do contexto. Aplica uma regra localmente e depois a esquece em outro lugar. Reabre uma discussão porque ninguém acha a decisão inicial.

O Product Decision Record serve para evitar isso.

Ele transforma uma decisão implícita em regra explícita.

Ele documenta as escolhas de produto que estruturam a empresa.

Ele permite dizer: "A gente já resolveu esse assunto. Aqui está o porquê. Aqui estão as consequências que a gente aceita. Aqui estão as condições que poderiam nos fazer mudar."

Um bom PDR não acrescenta mais uma camada de documentação.

Ele elimina dezenas de discussões inúteis.

Para saber mais

Por que as organizações preferem decisões frouxas O PM como arquiteto do Contexto As ferramentas de coerência organizacional A pergunta de produto deve partir do código-fonte