Product Discovery na Era da IA: Quando Construir Não É Mais o Difícil

Durante décadas, equipes de produto navegaram quatro riscos: desejabilidade, viabilidade, factibilidade e usabilidade. O equilíbrio entre eles moldou como alocávamos tempo, orçamento e atenção. Construir software era caro. Testar viabilidade exigia investimento significativo. Iterar em usabilidade era lento.

A IA comprimiu três desses quatro riscos. O único que ela não tocou é agora o único que importa.

Os Quatro Riscos, Revisitados

Teresa Torres codificou a descoberta contínua como um ritmo semanal: entrevistar clientes, mapear oportunidades, testar suposições, iterar. Sua Opportunity Solution Tree deu às equipes um framework visual para conectar resultados de negócio a necessidades não atendidas e soluções testáveis. O método continua válido. O que mudou é a estrutura de custos por baixo dele.

Factibilidade costumava dominar as conversas sobre produto. Capacidade de engenharia era o gargalo. Funcionalidades que exigiam duas sprints de trabalho dedicado agora são prototipadas em uma tarde. David Hoang, VP de Design (IA) na Atlassian, construiu a primeira versão do seu projeto Tapestry—um CRM funcional com capacidades de IA—em poucas horas. Esse cronograma seria impensável dois anos atrás.

Viabilidade era cara de testar. Você precisava de um produto funcional, usuários e tempo para coletar sinais de mercado. Agora é possível implantar um protótipo em produção a baixo custo, coletar dados reais de uso e pivotar antes de comprometer recursos. O ciclo de feedback entre hipótese e evidência encurtou de meses para dias.

Usabilidade tinha iteração restrita pelos ciclos de design-desenvolvimento. Gerar múltiplas variações de interface, testá-las com usuários e refinar exigia esforço coordenado entre disciplinas. Ferramentas assistidas por IA comprimem esse ciclo. A distância entre conceito e interface testável diminuiu.

Desejabilidade permanece inalterada. Nenhuma persona sintética, nenhuma entrevista simulada, nenhuma pesquisa gerada por IA substitui o que acontece quando você observa uma pessoa real interagir com seu produto e descrever problemas que você não havia considerado. Desejabilidade requer humanos conversando com humanos.

Quando três de quatro riscos se tornam baratos de endereçar, o restante se torna o diferencial.

O Problema do Processo

Jenny Wen, líder de design do Claude.ai na Anthropic e ex-Diretora de Design na Figma, levantou uma observação incisiva na Hatch Conference em 2025: os processos que estabelecemos estão se tornando indicadores defasados. Equipes cultuam artefatos de processo—o relatório de pesquisa, a especificação de design, o plano de sprint—em vez dos resultados que esses artefatos deveriam viabilizar.

Isso não é um argumento contra processos. É um argumento contra inércia processual. Quando o custo de construir cai para quase zero, processos projetados para gerenciar o custo de construir se tornam sobrecarga. A disciplina muda de gerenciar o que podemos construir para entender o que deveria existir.

Há uma nuance que vale preservar aqui. Indústrias reguladas ainda precisam de processos documentados. Sistemas complexos ainda precisam de governança. A afirmação de que “no momento em que você documenta um processo, ele se torna irrelevante” se aplica a contextos de produto em rápida evolução, não a todo contexto organizacional. Mas a direção do insight é correta: processo deve servir à descoberta, não substituí-la.

Rascunhando com Código

Hoang descreve uma prática que chama de “rascunhar com código”—criar protótipos em vários níveis de fidelidade usando código real em vez de ferramentas de design. Um rascunho de código de baixa fidelidade pode ser uma página HTML simples com dados fixos, suficiente para demonstrar um fluxo e provocar uma reação. Um rascunho de alta fidelidade conecta-se a APIs reais e trata casos extremos.

O rascunho em papel ainda acontece. O que muda é o meio de comunicação. Papel captura o pensamento. Código comunica.

Isso não é uma ideia nova—design technologists prototipam em código há anos. O que torna diferente agora é que a IA colapsou a barreira de habilidade. Um product manager sem experiência em frontend consegue gerar um protótipo funcional. Um designer pode ir de wireframe a interface funcional sem abrir um ticket.

As implicações são estruturais. Quando qualquer pessoa do time consegue produzir um artefato testável, a função de gatekeeping da capacidade de engenharia diminui. Isso não torna engenharia menos valiosa—muda o papel da engenharia de “construir a coisa” para “construir a coisa que escala.”

Prototipando em Produção

Hoang vai além: em vez de ambientes de homologação, ele prototipa em produção. Implantou o Tapestry como aplicação real, convidou usuários e coletou dados reais de uso. A partir desses dados, pivotou o produto de uma aplicação CRUD tradicional para um servidor MCP que se integra com Claude e ChatGPT.

Produção como ambiente de teste é mais informativo que homologação. Dados reais, padrões reais de uso, restrições reais. Mas essa abordagem requer disciplina. Ter algo em produção não significa lançar. Pode permanecer como beta fechado. A distinção entre “implantado” e “lançado” se torna operacionalmente importante.

Há preocupações legítimas aqui. Requisitos de privacidade de dados, postura de segurança e expectativas dos usuários variam por contexto. Um MVP voltado ao consumidor para uma ferramenta de CRM carrega riscos diferentes de uma aplicação de saúde ou um produto de serviços financeiros. O princípio—testar com condições reais—é válido. A aplicação requer julgamento sobre o que “condições reais” significam no seu domínio específico.

A Questão da Realocação de Tempo

Se a IA comprime o tempo gasto em factibilidade, viabilidade e usabilidade, para onde vai esse tempo? A resposta otimista é desejabilidade—mais conversas com usuários, compreensão mais profunda dos problemas, melhor julgamento sobre o que deveria existir.

A resposta realista é menos clara. Muitas organizações não realocarão o tempo economizado para descoberta. Realocarão para velocidade—entregar mais, mais rápido, com menos reflexão. A compressão do tempo de construção se torna uma aceleração do ciclo de entregar-e-torcer em vez de uma melhoria no ciclo de entender-e-então-construir.

É aqui que disciplina organizacional importa. Equipes que deliberadamente investem o tempo de construção comprimido em tempo expandido de descoberta construirão produtos melhores. Equipes que tratam IA como ferramenta para ir mais rápido em vez de ir mais fundo construirão mais produtos, mas não necessariamente melhores.

A Nova Pergunta

Quando construir se torna praticamente gratuito, a pergunta competitiva muda. A pergunta antiga era “Conseguimos construir isso?”—uma questão sobre capacidade de engenharia e factibilidade técnica. A nova pergunta é “Isso deveria existir?”—uma questão sobre insight do cliente, julgamento de mercado e clareza estratégica.

Essa pergunta sempre existiu na teoria. Product managers sempre foram orientados a validar antes de construir. Mas quando construir era caro, a pergunta carregava peso prático porque o custo de errar era alto. Agora que construir é barato, o custo de errar é baixo por tentativa, mas se acumula quando uma organização lança dezenas de ideias não testadas.

Product Discovery não é menos importante na era da IA. É mais importante. Também é mais difícil de justificar para organizações que internalizaram velocidade como sua métrica primária.

As equipes que vencerão não são as que constroem mais rápido. São as que entendem mais profundamente o que vale a pena construir.

Esta análise baseia-se no artigo “How Product Discovery changes with AI” de David Hoang (Proof of Concept, fevereiro de 2026), no framework Continuous Discovery Habits de Teresa Torres, e na palestra “Don’t Trust the Process” de Jenny Wen na Hatch Conference 2025.