Gothelf: priorize por aprendizado e reversibilidade, não esforço

Jeff Gothelf publicou em 6 de julho um texto que resolve um problema que muita equipe de produto ainda finge não ter: quando a IA torna o construir barato, a estimativa de esforço para de servir como critério de priorização. Gothelf é referência em Lean UX e coautor do trabalho sobre resultados acima de entregas, e aqui ele ataca de frente o hábito que sobreviveu a todas as ondas de método. A tese cabe numa frase: se o esforço saiu da conta, priorize pelo que o trabalho ensina e pelo quanto ele dá para desfazer.

O denominador que a IA esvaziou

O ponto de partida de Gothelf é certeiro. Quase todo framework de priorização que usamos, do RICE ao WSJF e ao humilde quadrante de valor por esforço, foi construído para proteger o recurso mais escasso de todos: o tempo de engenharia. Em todos eles, o esforço de construir mora no denominador. Divide-se o impacto esperado, que é um palpite, pelo custo de construir, que também é um palpite, ordena-se o resultado e o roadmap quase se escreve sozinho.

A IA muda o que entra nesse denominador. Quando um engenheiro capaz constrói uma versão funcional de uma feature em uma tarde, o esforço deixa de ser a restrição. Os modelos feitos para proteger o esforço perdem sentido e, nas palavras dele, tudo passa a parecer que vale a pena fazer. O efeito é perverso: quando nada custa, nada é de fato priorizado, e roadmap, plano de produto e backlog viram listas de tarefas glorificadas. Gothelf é honesto sobre os limites, integração, revisão de conformidade e qualquer coisa que toque dado de produção ainda custam tempo real. Mas a direção é inequívoca, e o protótipo que chega antes da estimativa já deixou os velhos rituais de planejamento em terreno movediço.

Os dois critérios que substituem o esforço

No lugar do esforço, Gothelf propõe dois inputs que ainda significam algo. O primeiro é o valor de aprendizado: o quanto construir a coisa ensina sobre se valia a pena construí-la. Uma feature que resolve uma discussão real que o time vive repetindo, ou que testa uma suposição em que a estratégia inteira se apoia, tem alto valor de aprendizado. Uma feature sobre a qual você já está confiante e está só entregando tem baixo valor de aprendizado, mesmo que o cliente acabe gostando. É a mesma disciplina de escrever OKRs voltados a resultado: a pergunta é o que vai mudar no comportamento do cliente, não o que teremos entregue.

O segundo é a reversibilidade: o quanto é fácil voltar atrás se você errar. Algumas decisões são um botão que você liga e desliga num instante. Outras remodelam seu modelo de dados, retreinam seus usuários ou fazem ao mercado uma promessa que você não consegue retirar de fininho. Gothelf resgata a ideia das portas de mão única e mão dupla, de Jeff Bezos, e observa por que ela ficou mais relevante: o construir barato tenta a gente a atravessar portas caras depressa só porque dá.

A matriz e as quatro decisões

Cruzando os dois eixos, saem quatro caixas, cada uma com uma diretriz clara.

Alto aprendizado e fácil de reverter: construa agora, de verdade. São os itens que mais ensinam e quase nada custam para desfazer, então o construir barato é um presente. Entregue e meça o que os usuários realmente fazem, em vez de declarar vitória no lançamento.

Alto aprendizado e difícil de reverter: prototipe antes. O aprendizado vale a caça, mas a porta só abre para um lado, então gaste um pouco da capacidade barata de construção para tirar risco da decisão antes de se comprometer. Aqui os movimentos clássicos de Lean Startup continuam valendo: teste Mágico de Oz, porta falsa, entregar para dez usuários em vez de dez mil. A meta é capturar o aprendizado sem travar as consequências.

Baixo aprendizado e fácil de reverter: faça uma aposta pequena e siga. Não convoque reunião. Entregue uma versão, marque no calendário uma data para checar se fez diferença e volte para o trabalho que ensina algo. O perigo na era da IA não é subconstruir esses itens, é sobreinvestir neles justamente porque são fáceis de produzir.

Baixo aprendizado e difícil de reverter: fique fora dessa caixa. Ensina pouco e você não consegue voltar atrás, o pior uso possível da sua capacidade de construção recém-barateada. Quando algo cai aqui, espere, junte mais evidência ou ache um caminho reversível para o mesmo objetivo antes de comprometer um único sprint.

Output ficou quase de graça e o julgamento virou a única coisa cara que sobrou. Priorizar deixou de ser sobre o que dá para construir e passou a ser sobre o que vale a pena aprender.

Minha leitura, para quem opera IA no Brasil

Concordo com o Jeff, e acrescento um aviso de quem vive isso em operação. O primeiro é que a matriz não é um framework novo para anunciar na retrospectiva. Ele mesmo pede: não renomeie a reunião, não crie cerimônia. Troque a coluna de esforço da sua planilha de priorização por duas perguntas, o que isso vai nos ensinar e o quão difícil é desfazer, e observe onde a discussão acontece. É ali, na conversa, que a priorização de verdade mora.

O segundo é que esse método casa com o problema que mais custa dinheiro por aqui: o piloto que impressiona e não vira produto. Quando construir é caro, a gente erra por não fazer. Quando construir é barato, a gente erra por fazer demais, enchendo o roadmap de quick wins que não ensinam nada. É a mesma armadilha que descrevi em por que os pilotos de IA não viram produção, vista do outro lado: o risco migrou da execução para o julgamento. E julgamento não se automatiza, ele se exercita com critério.

O terceiro é que reversibilidade merece virar item de arquitetura, não só de priorização. Boa parte do que torna uma decisão difícil de reverter em IA é técnica: modelo acoplado ao produto, dado que não dá para reprocessar, dependência de um único fornecedor. Quem projeta para trocar de peça sem reescrever o sistema move itens da caixa cara para a caixa barata, e ganha o direito de aprender mais rápido. A régua do Gothelf e a régua de automatizar só o que dá para verificar apontam para o mesmo lugar: numa era em que produzir é fácil, a vantagem é de quem decide melhor o que produzir.

Rode o exercício uma vez e conte quantos dos seus quick wins caem na caixa da aposta pequena. Esse número, como o Jeff sugere, é uma boa aproximação de quanto do seu roadmap estava sendo priorizado por baratice, e não por aprendizado. Vale ler o texto original dele na íntegra, a matriz com os quatro quadrantes ajuda a fixar a ideia.

Se o seu time está reformulando como prioriza roadmap agora que a IA barateou o construir, a AI Boutique ajuda a montar esse processo sem cerimônia nova. Chame a gente no WhatsApp.