Working Backwards: escreva o resultado da IA antes de construir

O jeito mais comum de começar um projeto de IA é também o mais errado: alguém se encanta com um modelo, monta uma prova de conceito, e só então parte para descobrir que problema aquilo resolve. A Amazon tem, há quase duas décadas, um método que torna esse erro quase impossível de cometer. Chama-se Working Backwards, e a ideia é literalmente trabalhar de trás para frente: começar pelo resultado que o cliente vai viver e voltar até o que precisa ser construído. Para quem coloca IA em produção, é um dos freios mais úteis que existem contra o teatro de tecnologia.

De onde vem o método

Working Backwards nasceu dentro da Amazon nos anos 2000, no mesmo período que gerou Kindle, Prime e AWS. Foi codificado como método repetível e depois contado ao público no livro Working Backwards, de 2021, por Colin Bryar e Bill Carr, dois executivos que somaram 27 anos de casa. Bryar entrou em 1998, Carr em 1999, e ambos viveram por dentro a fase em que a empresa transformou intuição em processo.

A inversão que dá nome ao método é simples de enunciar e difícil de praticar. Em vez de partir da ideia ou da tecnologia disponível e empurrar isso para o mercado, você parte da experiência final do cliente e caminha de volta até as decisões de construção. A pergunta que abre o projeto não é o que podemos construir com isto. É que benefício o cliente vai ter, e essa resposta precisa vir antes de qualquer linha de código.

O PR/FAQ, a ferramenta central

O coração do método é um documento chamado PR/FAQ, e ele tem duas partes.

A primeira é um press release fictício. Você escreve o anúncio do produto como se ele já estivesse lançado, em uma única página. A regra é dura: linguagem simples, foco no benefício concreto para o cliente, zero jargão técnico, nada de adjetivo vazio. Se o seu anúncio precisa da palavra revolucionário para parecer interessante, ele não é interessante. O press release força você a articular, em termos que um cliente entenderia, o que muda na vida dele.

A segunda parte é o FAQ, uma lista das perguntas difíceis que clientes, imprensa e a própria equipe fariam, com respostas honestas. Quanto custa? Como isso se paga? O que acontece quando falha? Por que agora? O que pode dar errado? O FAQ é onde o otimismo do press release encontra a realidade. Juntas, as duas partes viram um documento que é escrito, lido em silêncio pela sala e criticado sem dó, tudo antes de a construção começar.

Se você não consegue escrever um anúncio honesto e específico do resultado, você não tem um projeto. Tem uma tecnologia à procura de um problema.

Por que a IA precisa tanto disso

Nenhuma categoria de projeto sofre mais do vício de começar pela tecnologia do que a IA. O modelo é sedutor, a demo impressiona, e é fácil confundir uma capacidade técnica impressionante com um produto que alguém quer. Working Backwards ataca exatamente esse ponto cego.

Tente escrever o PR/FAQ de um projeto de IA vago, do tipo vamos usar IA para melhorar a experiência do cliente, e a dificuldade aparece na primeira frase. Melhorar como? Que cliente? Que tarefa? Quanto melhor, medido como? A folha em branco do press release é implacável com projetos que não sabem o resultado que perseguem. E essa é a boa notícia: o método entrega o sinal de alerta na fase mais barata possível, a da escrita, antes de gastar mês de engenharia num piloto que ninguém pediu.

O oposto também vale. Quando o PR/FAQ de um projeto de IA sai fácil, específico e honesto, você ganhou uma bússola. O press release vira o critério de pronto: o produto está bom quando entrega aquilo que o anúncio prometeu, nem mais nem menos. E o FAQ já mapeou os riscos, os custos e os modos de falha que, em IA, quase sempre são a parte que decide se o piloto vira operação.

Como aplicar, na prática

O roteiro é direto e cabe em uma tarde. Antes de aprovar qualquer projeto de IA, peça um PR/FAQ de uma a duas páginas.

No press release, escreva o anúncio do produto pronto para um cliente real e específico, descrevendo o benefício em linguagem que a mãe dele entenderia. Inclua uma citação fictícia mas plausível desse cliente dizendo o que mudou para ele. Se a citação soar falsa, o benefício provavelmente é falso.

No FAQ, force as perguntas incômodas. Quanto custa rodar isto por mês, incluindo compute? O que acontece quando o modelo erra, e com que frequência ele erra? Quem assume quando a IA não dá conta? Como medimos que funcionou, com que métrica e em quanto tempo? Que dados isso exige e de onde eles vêm? Responda com números quando possível e com honestidade sempre.

Depois, leia em grupo e critique sem piedade. Um bom PR/FAQ costuma passar por várias versões antes de convencer, e cada versão descartada custa uma página, não um trimestre.

Working Backwards conversa diretamente com outros fundamentos que já cobrimos. Ele é primo do Lean UX, que cobra medir o resultado e não a entrega, e do service design, que desenha o serviço inteiro em volta do modelo. O PR/FAQ é a peça que amarra as duas no começo do projeto: obriga a nomear o desfecho para o cliente antes de escolher a tecnologia. É o mesmo hábito da casa, pensar no resultado antes de pensar na máquina, aplicado ao momento mais perigoso, o da ideia entusiasmada.

Bryar e Carr contam que, na Amazon, muitos PR/FAQs simplesmente morrem na revisão, e que isso é considerado um sucesso do processo, não um fracasso. Matar no papel uma ideia que não se sustenta é o resultado mais barato que um método pode entregar. Para quem coloca IA em produção, com o custo real de compute e o risco real de erro, escrever o anúncio antes de escrever o código não é burocracia. É o filtro que separa a IA que entrega valor da IA que só rende slide.

Se você quer testar seus projetos de IA com um PR/FAQ antes de gastar engenharia, escrevendo o resultado antes do código, fala com a gente no WhatsApp.