Como fazer discovery de produto que muda o que você constrói

Discovery é uma das palavras mais usadas e menos praticadas em produto. O conceito é simples: entender o problema antes de construir a solução. A execução é onde a maioria trava.

Esse artigo é sobre como fazer discovery de forma que mude concretamente o que você decide construir — não só adicione uma fase no processo que todo mundo sabe que é pra inglês ver.

O que é discovery de produto (e o que não é)

Discovery é qualquer atividade que reduz a incerteza sobre um problema ou uma solução antes que o time invista tempo construindo. Pode ser uma conversa com cinco usuários. Pode ser uma análise de funil. Pode ser um protótipo de papel testado em vinte minutos.

O que não é discovery: reunião de brainstorming onde o time lista features. Entrevista com usuário onde você já chegou com a solução pronta e quer validação. Análise de dados para justificar uma decisão que já foi tomada.

Discovery contínuo vs discovery por projeto

Discovery por projeto acontece antes de um desenvolvimento específico: você pesquisa, aprende, decide o que construir, e passa para o time. Discovery contínuo é uma mentalidade onde você nunca para de aprender sobre seus usuários, independente de onde está no ciclo de entrega.

Times maduros fazem discovery contínuo. Eles têm uma cadência regular de entrevistas com usuários, mantêm um repositório de insights e usam o que aprendem para ajustar o backlog em tempo real — não só quando estão prestes a começar um projeto grande.

Quando fazer discovery (e quando não fazer)

Fazer discovery de tudo é tão problemático quanto não fazer de nada. Para ajustes pequenos com evidência clara, a análise de dados é suficiente. Para features novas onde há incerteza sobre o problema ou a solução, discovery estruturado reduz o risco antes de comprometer semanas de engenharia.

Os sinais de que você precisa de discovery

Você está debatendo a solução antes de ter clareza sobre o problema. O time não consegue descrever em uma frase qual comportamento do usuário vai mudar. A última vez que alguém falou com um usuário real sobre aquele problema foi há mais de duas semanas. Esses são os sinais.

Um sinal mais sutil: quando o argumento principal para construir algo é "o stakeholder pediu" sem nenhuma conexão com um problema de usuário documentado. Nesse caso, a pergunta de discovery é: o que o usuário está tentando fazer que gerou esse pedido? Ignorar esses sinais e avançar sem discovery é um dos erros mais comuns de PMs iniciantes — e um dos mais custosos, porque o custo aparece só depois de semanas de desenvolvimento.

As técnicas que funcionam na prática

Discovery não exige um método único. As técnicas mais úteis na prática são também as mais simples.

Entrevistas de problema

Cinco conversas de trinta minutos com usuários reais focadas em entender o comportamento atual — não em mostrar uma solução ou coletar opinião sobre uma feature. "Me conta como você faz hoje quando precisa [descrever o job]" é o tipo de pergunta que abre discovery real. Para aprender como conduzir essas conversas, veja o guia sobre como conduzir entrevista com usuário.

Análise de comportamento

Onde os usuários chegam e onde saem. Qual feature tem mais uso e qual tem mais abandono. Qual métrica está caindo sem explicação óbvia. Os dados de comportamento contam uma história sobre o que os usuários estão encontrando de atrito — mas só a entrevista explica o porquê. Para saber quais métricas olhar primeiro, veja o guia de métricas de produto.

Testes de conceito

Antes de desenvolver, você pode mostrar um protótipo de baixa fidelidade para usuários e observar o comportamento deles. Não pergunte se eles gostam. Peça para eles usarem e observe onde travam, o que ignoram e o que perguntam. Isso valida a solução — o que é diferente de validar o problema.

Como saber se seu discovery está funcionando

O teste real é simples: o discovery mudou o que você estava prestes a construir? Se você fez research e construiu exatamente o que tinha planejado antes, ou o discovery confirmou uma hipótese muito bem formulada — ou foi um ritual sem efeito real.

O que um bom discovery produz

Um insight específico sobre o comportamento do usuário que você não sabia antes. Uma hipótese de causa para uma métrica que estava caindo. A descoberta de que o problema que você ia resolver não era o problema real. Uma solução completamente diferente da que o time tinha imaginado, gerada a partir do que você aprendeu.

Discovery que confirma o que o time já pensava sem nenhuma surpresa ou ajuste é suspeito. Usuários raramente se comportam exatamente como imaginamos.

Discovery com pouco tempo

"Não temos tempo para discovery" é frequentemente verdade no curto prazo e falso no longo. O que não tem tempo é construir a coisa errada por três sprints e depois refazer. Mas discovery não precisa de semanas.

Cinco entrevistas de trinta minutos em uma semana são suficientes para revelar padrões. Uma análise de funil focada em um único ponto de atrito pode ser feita em duas horas. Um teste de conceito com protótipo de papel leva um dia. O discovery mínimo que muda uma decisão é mais rápido do que a maioria imagina.

Como encaixar discovery numa sprint

Times que fazem discovery contínuo não precisam de um sprint separado para pesquisa. Eles têm entrevistas agendadas toda semana, revisam os insights em cada planning, e usam o que aprenderam para ajustar o backlog antes de comprometer estimativas. O discovery acontece em paralelo com o delivery — não antes dele.