Ideia principal

Algumas recusas merecem ser escritas, porque produzem um conhecimento datado: recusamos aquele tema por causa de um custo, de uma estratégia, de uma viabilidade, de uma competência que faltava, de uma demanda fraca demais, de um momento ruim. Um ano depois, o negócio mudou, a posição do produto mudou, a IA tornou viável o que era caro demais, o time contratou um data analyst — e conhecer o motivo de origem permite saber se a decisão deve mudar.

Mesmo assim, o registro só tem valor se continuar sendo uma decisão passada. No momento em que ele guarda um estatuto de espera, reconstitui com outro nome a fila que queríamos eliminar. A diferença não está no lugar onde escrevemos, mas no que escrevemos: um motivo e um contexto, não uma intenção.

Nem toda recusa merece esse trabalho. Muitas ideias fracas desaparecem sem registro. Uma recusa estruturante, recorrente ou transversal justifica uma decisão documentada — motivo, contexto, alternativas descartadas, condições que poderiam fazê-la evoluir.

A recusa de traduzir um produto para todos os idiomas pedidos pelos prospects é o caso clássico: o registro ali não guarda o tema "traduzir para o italiano", guarda a regra que levou a não fazer isso — uma base francês-inglês, um patamar de receita assinada acima disso, e o custo de tradução como condição de reavaliação. Um ano depois, o vendedor que volta com um prospect italiano não reabre uma fila: ele esbarra em uma regra, ou então demonstra que a condição de saída foi cumprida. O registro distingue, portanto, duas coisas que a linguagem confunde: a recusa de um caso e a regra da qual essa recusa decorre; é a segunda que se conserva.

Camada trazida por "Product Decision Record: registrar as escolhas de produto que estruturam a empresa" (2026-06-03).

Camada trazida por "A arte da captura" (2026-06-16). Duas precisões vêm de uma prática individual, onde a regra fica mais dura. A primeira nomeia a forma que o estatuto de espera assume ali: um segundo espaço para as fontes de "talvez mais tarde". Ele não eliminou nada, apenas moveu o problema para um lugar menos visível — é assim que um sistema se enche de cemitérios discretos.

A segunda baixa o patamar abaixo do qual não se deve registrar nada. Em uma fila de capturas pessoais, manter um histórico detalhado das rejeições acaba custando mais do que rende: o sistema serve para pensar, não para administrar os próprios abandonos. A triagem entre recusas registráveis e recusas silenciosas, opcional em um contexto coletivo onde a revisão se argumenta, vira ali a condição para que o registro exista.

A regra se estende à recusa de uma constatação, e não só à recusa de um tema. Uma divergência apontada em um produto e depois desmentida após verificação — a relação entre dois objetos estava bem descrita, ao contrário do que tínhamos anotado — permanece na ficha, marcada como rejeitada, com o motivo da rejeição. Ela não carrega mais nenhum trabalho a fazer, então não atrapalha; e evita que o mesmo erro seja refeito daqui a seis meses por outra pessoa, que partiria do mesmo indício. Errar faz parte do trabalho, desde que o erro deixe um registro aproveitável.

Camada trazida por "Escrevi a ontologia de um produto. Três vezes achei que tinha terminado." (2026-08-11).

Por que isso importa

Isso derruba a objeção que impede fechar: "se a gente jogar fora, vai perder a razão". Dá para guardar a razão sem guardar o tema.

Isso também dá o critério de seleção que falta à maioria dos registros de decisão: registramos aquilo cuja revisão é plausível, não tudo o que foi recusado.

Nuances e limites

A fronteira entre um motivo e uma intenção se embaralha rápido: "recusado por enquanto, revisar se a demanda voltar" tem a forma de uma decisão e a função de uma espera.

E um registro só é útil se alguém o encontrar no momento em que a questão voltar — o que pressupõe uma organização por tema, não por data de recusa.

Questões em aberto

• Como reencontrar uma recusa antiga exatamente no momento em que o mesmo pedido volta por outro canal?