Fundamentos
Continuous Discovery: descobrir antes de construir IA
O Continuous Discovery, de Teresa Torres, ensina a validar problemas com clientes toda semana. Aplique o método antes de construir a sua próxima feature de IA.
Em 2026, a pergunta errada domina as reuniões de produto: onde a gente encaixa IA? Ela parece moderna, mas é a velha armadilha de começar pela solução. O Continuous Discovery, framework popularizado por Teresa Torres no livro Continuous Discovery Habits, existe justamente para inverter essa ordem: descobrir qual problema de cliente vale resolver antes de decidir o que construir. Num momento em que construir IA ficou barato de começar e caro de manter, esse método deixou de ser boa prática e virou defesa financeira.
O que é Continuous Discovery
A ideia central é simples e exigente ao mesmo tempo. Discovery contínuo é o hábito de manter contato frequente com clientes, no mínimo semanal, feito pela mesma equipe que decide e constrói o produto, para embasar as decisões do dia a dia. A palavra que carrega o peso é contínuo. Não é uma fase de pesquisa que acontece uma vez, entrega um relatório e morre. É uma rotina, pequenas entrevistas encaixadas toda semana, que mantém o time em contato com a realidade em vez de com as próprias suposições.
Teresa Torres contrasta isso com dois vícios comuns. O primeiro é o discovery de projeto, aquela pesquisa grande e cara feita no começo, cujas conclusões envelhecem antes do produto sair. O segundo é a ausência total de discovery, quando o time recebe uma lista de features prontas e apenas executa. Entre os dois extremos, o discovery contínuo propõe um fluxo constante e leve de evidência, alimentando decisões enquanto elas ainda podem mudar de rumo.
A ferramenta central: a árvore de oportunidades
O instrumento mais conhecido do método é a opportunity solution tree, a árvore de oportunidade e solução. Ela organiza o pensamento em quatro níveis, de cima para baixo. No topo, o resultado de negócio que você quer mover, um número, não um desejo vago. Abaixo, as oportunidades, que são as necessidades, dores e desejos reais dos clientes, descobertos nas entrevistas. Abaixo delas, as soluções candidatas para cada oportunidade. E, na base, os testes de suposição que dizem se aquela solução resolve mesmo aquela dor.
A força da árvore está na disciplina que ela impõe: nenhuma solução existe solta. Toda ideia precisa estar pendurada em uma oportunidade, e toda oportunidade precisa estar ligada ao resultado de negócio. Quando alguém chega com esse recurso precisa de IA, a árvore faz a pergunta que desarma o hype: pendurado em qual dor de cliente? Ligado a qual número? Se não há resposta, a ideia não sobe para a construção. É um filtro barato contra projetos caros.
Como aplicar isso a IA em produção
O erro mais comum de IA em 2026 é começar pela tecnologia. Alguém decide que precisa de um chatbot, de um agente, de um resumo automático, e só depois procura um problema para justificar. O Continuous Discovery inverte a sequência e, com isso, ataca a raiz de um problema que a grande mídia acabou de escancarar: metade das empresas com IA em produção não sabe provar que ela entrega valor. Boa parte desses casos nasceu de uma solução em busca de problema.
Na prática, aplicar o método a IA tem três passos concretos.
Primeiro, defina o resultado no topo da árvore antes de escrever qualquer prompt. Não IA no atendimento, e sim reduzir o tempo de primeira resposta em 30%. Esse número vira o juiz de todas as ideias abaixo. É a mesma lógica que defendemos em OKRs para IA, resultado e não entrega.
Segundo, entreviste para achar a oportunidade, não para validar a solução que você já quer. A pergunta certa não é você usaria um assistente de IA aqui?, é me conta a última vez que essa tarefa te travou. A dor real quase nunca é a que a demo imaginou. Uma semana de conversas costuma revelar que o gargalo do cliente está três passos antes de onde você ia colocar o modelo.
Terceiro, teste a suposição mais arriscada com o menor esforço possível. Antes de construir o agente, um protótipo tosco, um humano fingindo ser a IA por trás da tela, ou um fluxo manual já responde se a solução move o número. Se não move, você economizou a conta de token, de dados e de manutenção de uma feature que morreria em produção. Achar esse ponto de maior risco com o menor gasto é o mesmo espírito de encontrar o gargalo antes de otimizar.
Construir IA ficou fácil o bastante para virar armadilha. O discovery contínuo é o freio que garante que a coisa fácil de construir seja também a coisa que valia a pena existir.
O valor do Continuous Discovery, no contexto de IA, é econômico antes de ser metodológico. Cada feature de modelo carrega custo recorrente: inferência, dados, monitoramento, correção. Colocar uma solução no ar sem ter descoberto a dor é assinar uma conta mensal por algo que talvez ninguém use. Uma semana de entrevistas leves, encaixada na rotina, é o seguro mais barato que um time de IA pode contratar. Descobrir primeiro não atrasa a entrega, protege ela de virar desperdício.
No fim, o método de Teresa Torres devolve a IA para onde ela dá resultado: a serviço de um problema de cliente que alguém se deu ao trabalho de entender. A tecnologia mudou, a disciplina não. Fale com quem usa, ligue tudo a um número, teste barato antes de construir caro.
Se o seu time está prestes a construir uma feature de IA e ninguém consultou o cliente ainda, fale com a AI Boutique no WhatsApp. A gente ajuda a montar a rotina de discovery e a árvore de oportunidades antes do primeiro prompt.
Perguntas frequentes
Continuous Discovery não atrasa a entrega de features de IA?
Ao contrário, ele evita o atraso mais caro, que é construir a coisa errada rápido. O método de Teresa Torres não propõe uma fase longa de pesquisa antes de começar, propõe pequenas conversas frequentes com clientes, encaixadas na rotina de quem já está construindo. A ideia é entrevistar de forma leve toda semana, mapear as oportunidades reais numa árvore que sai do resultado de negócio, e só então escolher qual ideia testar. Em IA isso é ainda mais valioso, porque o custo de construir subiu: cada feature de modelo tem conta de token, de dados e de manutenção. Gastar uma semana descobrindo que a dor não existe é infinitamente mais barato do que colocar um agente em produção que ninguém pediu e ninguém usa.