Ideia principal

Uma especificação descreve uma intenção. Um PRD descreve um objetivo, regras esperadas, cenários. Um protótipo descreve uma interface desejada. Nenhum desses documentos descreve o que o cliente vai encontrar: entre eles e a entrada em produção, acordos são feitos, detalhes são ajustados, casos-limite aparecem, restrições técnicas obrigam a mudar um pouco o comportamento, e decisões são tomadas ao longo de uma pull request sem voltar para o documento inicial.

Essas arbitragens não são acidentes a eliminar: um produto vivo não é fabricado como um documento congelado. Mas elas têm uma consequência sobre o que é preciso olhar para conhecer um produto. A especificação continua sendo uma aproximação útil num dado momento; a versão em produção é a única descrição completa do que foi entregue.

O efeito também aparece nas ferramentas de acompanhamento: os tickets se dessincronizam do mesmo jeito que as especificações, porque as arbitragens tomadas durante a construção não voltam para nenhum dos dois.

Camada trazida por "O backlog não é um depósito de lixo: é uma ferramenta de ação" (2026-06-03).

Camada trazida por "PM, desenvolvedores e IA: os papéis se confundem, as responsabilidades ficam" (2026-08-01). Essas arbitragens têm um nome e um autor: são decisões de produto, e quem as toma são os desenvolvedores. Uma especificação completa é uma ficção — mesmo boa, ela deixa zonas mudas: casos-limite, mensagens de erro, comportamentos implícitos, regras de segurança, tempos de expiração, prioridades invisíveis, micro-interações, decisões de fallback. A constatação não descreve, portanto, apenas uma diferença entre o documento e a produção; ela aponta quem, na prática, decide o que o cliente vai encontrar.

Por que isso importa

Isso desloca o lugar onde vamos buscar a verdade de uma funcionalidade: no comportamento entregue, não no ticket que o pediu. As diferenças não são erros de conformidade, elas são a matéria mesma da decisão de produto.

Isso também diz o que se perde ao ficar só na ponta de cima: a parte das escolhas que determina a experiência do cliente foi jogada depois do documento, em trocas que esse documento não registra.

Nuances e limites

Em alguns escopos, a diferença é pequena e a intenção se sustenta: uma mudança de rótulo, um parâmetro, uma regra de negócio simples chegam à produção exatamente como foram escritos.

E um produto sujeito a uma restrição regulatória inverte em parte a regra: nele, a conformidade é demonstrada tanto no documento quanto no comportamento entregue, e a diferença vira um defeito em si.

Questões em aberto

• Por qual mecanismo uma arbitragem tomada numa pull request poderia voltar a quem concebeu a funcionalidade, sem reconstituir a carga documental que queremos evitar?