Construir ficou barato; continuar errado ainda custa caro

O gargalo migrou da construção para a decisão

A IA derrubou o custo de construir software, mas não o custo de estar errado: ficaram mais comuns coisas plausíveis e funcionais que resolvem um problema que ninguém tinha, resolvem mal ou ignoram falhas evidentes do próprio espaço em que entram. Quando construir era caro, construir era o gargalo - e a pesquisa de descoberta parecia um imposto sobre ele. Agora que construir ficou barato, o gargalo é saber o que construir, e cada hora de descoberta rende mais, porque deixou de competir com uma fila de engenharia de seis meses.

A premissa vem da newsletter do consultor e estrategista de IA Robbie Allen, para quem a IA colapsou o custo de transformar um requisito em software funcionando, mas não os custos de propriedade: saber o que deveria existir, decidir o que deve fazer e manter o direcionamento por três anos. Allen propõe reforçar funções como validação, QA, estratégia e liderança de TI. A crítica é que isso cobre o decidir e o conduzir, mas não o conhecer - primeiro item da própria definição dele -, papel que cabe à pesquisa de descoberta.

O caso do Bing e o limite dos experimentos

Em um webinar de 2026 com a GrowthBook, Ronny Kohavi relatou o caso de um terceiro painel na janela de busca do Bing: cerca de 100 engenheiros o construíram, os experimentos não mostraram valor, o recurso foi lançado assim mesmo como movimento estratégico e, um ano depois, após outra rodada de testes infrutífera, foi revertido a um custo elevado. Cem engenheiros, um ano perdido e uma reversão completa: o código era descartável; a aposta organizacional, não.

No livro “Trustworthy Online Controlled Experiments”, escrito com Diane Tang e Ya Xu (Cambridge University Press, 2020), Kohavi sustenta que pessoas são ruins em prever quais ideias terão valor, e propõe experimentos bem delimitados e rigorosamente desenhados. A descoberta atua antes disso: pergunta se a coisa deveria existir. “Alguém quer um terceiro painel?” é pergunta de descoberta, não algo para o qual experimentos tenham sido feitos.

Por que não só experimentar rápido?

Se construir e descartar nunca foi tão fácil, por que não montar três, quatro ou cinco versões e ver o que cola? Porque um protótipo é descartável; o que chega ao usuário, não. Um lançamento consome uma vaga no roadmap, credibilidade junto a partes interessadas, carga de suporte, a atenção das pessoas e a disposição de tentarem o próximo lançamento, além de dados que precisarão ser migrados ou apagados.

À objeção de que talvez o problema não seja falta de descoberta, mas apego - times precisando aprender a matar o que não funciona -, a resposta distingue quem paga cada custo: vagas de roadmap podem ser retomadas e credibilidade se recupera, mas a atenção dos usuários não é algo que o time possa amortizar. Os custos absorvíveis são os que o próprio time carrega; os demais ficam com quem usa.

Quando pesquisar e quando só testar

A descoberta também ganhou eficiência com a IA - em recrutamento, agendamento, transcrição, pesquisa documental e análise competitiva -, embora a síntese profunda sobre o espaço e seus usuários continue indispensável. Nem toda ideia precisa de fase de pesquisa. A regra: faça descoberta quando a incerteza está no problema; faça prototipagem e teste com usuários quando a incerteza está na solução.

Dois casos ilustram. Sabendo que usuários abandonavam o checkout e diante de duas soluções pequenas e testáveis - um indicador de progresso ou uma opção de guest checkout -, o caminho é construir e testar ambas, o que ensinaria mais em duas semanas; pesquisa ali seria cerimônia. Já um cliente pedia um assistente de IA para busca de conteúdo; o estudo mostrou que as pessoas encontravam o conteúdo, mas demoravam a avaliar relevância, vários cliques adentro antes de perceber que ele não servia. A saída foram filtros melhores, metadados expostos e informações para avaliação logo no início da jornada. Sem examinar a premissa, experimentar não traria orientação certa - o erro típico é confundir um tipo de incerteza com o outro, e a confusão pende para a solução, porque essa parece ter conserto pela própria construção.

Pesquisa como velocidade

Numa leitura enxuta, a pesquisa deixa de ser diligência que atrasa o compromisso e passa a ser o que permite abandonar rápido: estressando ideias na ideação, ela afia direções promissoras ou identifica becos sem saída, e o time segue adiante tendo aprendido algo. A conclusão: se a execução já não diferencia ninguém, o que se sabe sobre os próprios usuários é a única coisa que um concorrente não consegue copiar em um fim de semana.