O discovery inverteu
Quando construir fica mais barato que validar, a ordem do trabalho muda de lugar.
Passei quinze anos fazendo discovery do jeito clássico. Entrevista em profundidade. Landing page com captura de leads. Fake door para medir intenção antes de escrever uma linha de código. Árvore de problemas na parede da sala. Cada uma dessas técnicas nasceu de uma restrição concreta: construir era caro. Errar produto custava meses de engenharia e o salário de um time inteiro.
Então a gente aprendeu a não construir. A gente construía substitutos. A landing page era um substituto do produto. O protótipo navegável era um substituto do produto. A pesquisa de intenção era um substituto do usuário usando de verdade. Todo o arsenal clássico de discovery servia para responder, com o mínimo de código possível, uma única pergunta: vale a pena construir?
Essa pergunta fazia sentido enquanto a resposta errada custava caro. Só que o custo mudou de lugar. Com Claude Code, Cursor e ferramentas de design com IA, construir uma versão enxuta e funcional de um produto ficou mais barato do que montar o experimento que fingiria ser o produto. Pare um segundo no absurdo disso: o proxy ficou mais caro que a coisa real. Montar uma campanha de fake door, comprar mídia, esperar duas semanas de dados e interpretar sinais ambíguos custa mais do que colocar a versão enxuta no ar e ver gente de verdade usando.
Quando isso acontece, a ordem inverte. O caminho deixa de ser validar para depois construir. Passa a ser construir para validar. Construir primeiro, colocar o produto real na frente do usuário real, e aí aprender com comportamento em vez de opinião. O feedback muda de qualidade na hora: em vez de "eu usaria", você vê se a pessoa volta na terça seguinte.
Isso não mata as técnicas clássicas. Reposiciona cada uma. Entrevista em profundidade continua valendo para produtos pequenos e nichados, quando você precisa falar com quem sente o problema na pele e o volume de sinal é baixo. Árvore de problemas continua valendo para problemas genuinamente complexos, aqueles que nenhum MVP de fim de semana resolve e que exigem pensamento estruturado e paciência. O que muda é o critério. Antes, essas técnicas eram o caminho padrão. Agora, cada uma precisa justificar o próprio custo diante de uma alternativa nova: construir logo. O julgamento de produto virou isso: saber quando o proxy ainda paga o que custa, e quando ele é só cerimônia.
Eu testei essa tese na prática. Entreguei recentemente um produto completo, de discovery a produção, em cinco semanas, sozinho. Não porque trabalho rápido, nem porque cortei canto. Porque parei de validar substitutos e passei a validar o produto. A primeira versão foi para a frente de usuários reais em dias, não meses. Cada rodada de feedback aconteceu sobre a coisa real, com dados reais de uso. O discovery não desapareceu do processo: ele passou a acontecer com o produto no ar, continuamente, em vez de antes de o produto existir.
Se você ainda gasta seis semanas validando se vale a pena construir algo que levaria três semanas para construir, a conta não fecha mais. O discovery inverteu.