O Que É Discovery de Produto? A Etapa Que Decide Se o Projeto Vai Dar Certo

Discovery de produto é o processo de entender a fundo o que um projeto realmente precisa —o problema real de negócio, as restrições técnicas, a escala esperada e o mínimo indispensável para resolvê-lo— antes de escrever a primeira linha de código ou de escolher com qual time vai construir. Não é "levantar requisitos" numa reunião inicial: é o trabalho que reduz quatro riscos concretos antes de investir orçamento e tempo de desenvolvimento —se o problema vale a pena resolver, se alguém vai conseguir usar a solução, se ela é tecnicamente viável com o tempo e o time disponíveis, e se o negócio sustenta essa solução— antes de comprometer tudo isso para construí-la.

Existe porque o que uma empresa pede no início quase nunca é uma especificação completa: é uma necessidade expressa em linguagem do dia a dia —"precisamos de um sistema que organize melhor os pedidos"— que precisa ser traduzida em um escopo concreto e acionável antes de alguém começar a programar. Pular essa etapa não economiza tempo: só empurra o custo para mais adiante, para um ponto em que corrigir um mal-entendido de escopo custa bem mais do que resolvê-lo numa conversa.

Por que o discovery importa antes de escrever código?

Porque o custo de um erro de escopo cresce quanto mais tarde ele é percebido. O framework dos "quatro grandes riscos" de Marty Cagan (Silicon Valley Product Group) organiza o discovery em torno exatamente dessa ideia: antes de construir, um time precisa resolver o risco de valor (o problema importa de verdade para alguém?), o de usabilidade (as pessoas vão conseguir usar?), o de viabilidade técnica (dá para construir com o tempo e a tecnologia disponíveis?) e o de viabilidade de negócio (funciona também para o negócio, não só para o usuário?). Nenhum dos quatro se resolve olhando código —se resolve conversando, pesquisando e, acima de tudo, antes de escrever a primeira linha.

• Risco de valor — se o problema que será resolvido realmente importa para o usuário ou para o negócio.
• Risco de usabilidade — se as pessoas vão entender como usar o que for construído.
• Risco de viabilidade técnica — se o time consegue construir com o tempo, o stack e as pessoas disponíveis.
• Risco de viabilidade de negócio — se a solução também funciona para o jurídico, o financeiro ou a estratégia comercial, não só para o usuário.

Quando o discovery é pulado ou feito de forma ruim, esses riscos não desaparecem —eles aparecem depois, já com o desenvolvimento pronto. O PMI (Pulse of the Profession, 2014) constatou que 47% dos projetos que não atingem seus objetivos falham por uma gestão de requisitos imprecisa —a causa individual mais citada de fracasso de projeto nesse estudo, à frente de problemas de orçamento ou cronograma.

Discovery é uma etapa única ou um hábito contínuo?

Depende do modelo usado, e a diferença importa. A abordagem tradicional trata o discovery como uma fase que acontece uma vez, no início, antes de passar para o "delivery" e não olhar mais para trás. Teresa Torres, em Continuous Discovery Habits (2021), propõe um modelo diferente: discovery como um hábito semanal do time, não um projeto único —conversar com usuários reais, testar pequenas hipóteses e ajustar o rumo constantemente, em paralelo ao avanço do desenvolvimento (o que ela e Cagan chamam de "dual-track": discovery e delivery rodando ao mesmo tempo, não em sequência).

A diferença prática é esta: no modelo de fase única, uma mudança de contexto —o negócio muda de prioridade, aparece um concorrente, o usuário reage diferente do esperado— quebra um plano que já foi fechado. No modelo contínuo, essa mudança é percebida na conversa da semana seguinte, não seis meses depois, quando o produto já está construído e não encaixa mais.

O que muda quando o discovery é montado ouvindo reuniões com IA em vez de um PM anotando à mão?

A maior parte da informação de discovery não vive num documento: ela está espalhada em reuniões —a que teve com o time de produto, a que teve com o suporte, a que teve com um cliente irritado por uma funcionalidade quebrada. Um PM que anota à mão perde nuances entre uma conversa e outra, e reconstrói o panorama completo de memória. Por isso o software de transcrição e anotação com IA em reuniões deixou de ser uma curiosidade: segundo a pesquisa State of AI Meeting Notetakers 2025, da Fellow.ai, 75% dos profissionais entrevistados já usam um assistente de IA em suas reuniões de trabalho.

Mas a mesma pesquisa mostra o lado incômodo dessa adoção: 84% dos entrevistados disseram que mudam o que falam quando percebem que há um bot de IA gravando, e 47% relataram que um assistente desse tipo gravou ou compartilhou algo que não deveria ter sido registrado. Adotar IA nas reuniões sem ser explícito sobre o que é gravado e para quê não resolve o problema do discovery disperso —piora, porque também quebra a confiança da conversa que deveria ser entendida a fundo.

Como o Kaizen faz isso na Zenit?

O Kaizen é o motor de discovery da Zenit, e começa exatamente aí —não num formulário de intake. Ele participa das reuniões do time do lado empresa como mais um participante, não como um bot escondido, e cruza o que ouve em diferentes conversas para montar um único mapa do processo real: o que existe, o que falta, onde aparecem versões contraditórias da mesma prioridade. Esse mapa vira um briefing vivo —escopo, milestones, requisitos de time— antes de qualquer match com um squad começar.

A diferença em relação a um discovery tradicional não é só velocidade: esse briefing não se perde nem é reescrito de memória seis meses depois. É a mesma memória que depois guia o matching, a execução milestone a milestone e, se for preciso, a transferência de contexto para um squad substituto.

O discovery também é a razão pela qual o matching automático por palavras-chave não é suficiente: sem entender o contexto real do projeto, qualquer match é uma aposta feita com informação incompleta.