O que é discovery em produto
Discovery é a etapa em que o time valida se o problema existe, antes de decidir como resolver. Acontece antes do design, antes da arquitetura, antes do código. É a fase em que o objetivo não é construir, é entender.
A pergunta central do discovery é: "esse problema é doloroso o suficiente pra alguém pagar pra resolver?" Se a resposta é não, todo o resto do projeto desaba. Se a resposta é sim, o discovery descreve quem sente a dor, quando ela aparece, o que as pessoas fazem hoje pra contornar, e quanto elas pagariam por uma solução melhor.
Sem essas quatro respostas, qualquer roadmap é palpite com confiança imerecida.
Por que 42% das startups morrem aqui
A CB Insights analisou as causas de fracasso de centenas de startups. O número mais consistente entre os estudos: 42% morrem por falta de Product-Market Fit. Não morrem por falta de talento técnico, nem por design ruim, nem por escassez de capital. Morrem porque construíram algo que ninguém precisava.
O padrão é quase sempre o mesmo. Founder identifica um problema, sente forte certeza de que é universal, levanta capital, contrata engenharia, gasta de 12 a 18 meses construindo, lança, descobre que a demanda real era nula. O custo médio desse erro fica entre 50 mil e 500 mil dólares, dependendo do escopo.
Discovery resolve isso barato. Três semanas de entrevistas estruturadas com 15 a 30 pessoas custam menos do que uma semana de engenharia. E mostram, antes do código, se vale a pena codar.
A Regra do Retrabalho 1:10:100
Existe uma regra prática em engenharia de software que se aplica diretamente à decisão de pular ou não o discovery. Corrigir um problema de produto na fase de pesquisa custa 1 unidade de esforço. O mesmo problema, se passar despercebido até o protótipo, custa 10 unidades. Se chegar até a produção, custa 100 unidades.
A regra explica por que pular discovery sai caro. Cada hipótese errada que escapa da fase de pesquisa vira código. Código errado vira refatoração. Refatoração vira atraso de roadmap. Atraso vira time desmotivado e burn de capital. O efeito cascata começa na decisão pequena de não validar a hipótese inicial.
Empresas maduras tratam discovery como mitigação de risco financeiro. Startups que tratam como "etapa cara que atrasa o lançamento" são exatamente as que entram nos 42%.
O processo: como discovery roda em 3 semanas
Discovery não é sessão de brainstorm de uma semana. É um processo estruturado em três fases sequenciais.
Fase 1 — Hipótese e mapeamento de dor (3 a 5 dias)
O ponto de partida é escrever a hipótese em linguagem objetiva. Não "criar um app pra freelancers", mas "freelancers de design gastam mais de 4 horas por semana cobrando clientes inadimplentes, e topariam pagar R$ 50/mês por uma ferramenta que automatiza isso".
Hipótese boa tem quatro elementos: quem (segmento específico), o que (dor mensurável), evidência atual (o que esse alguém faz hoje pra resolver) e disposição a pagar (preço hipotético). Sem esses quatro elementos, a hipótese é palpite.
Ferramentas que ajudam aqui: Matriz CSD pra separar o que o time sabe do que está supondo, mapa de empatia pra detalhar o segmento, análise crítica de reviews 1-3 estrelas de concorrentes no G2 ou Capterra pra identificar falhas que o mercado já admite ter.
Fase 2 — Entrevistas com usuários reais (10 a 15 dias)
A regra dos cinco usuários do Nielsen Norman Group resolve essa fase: cinco entrevistas estruturadas por segmento identificam mais de 80% dos problemas de uso reais. Pra validação de hipótese de mercado, recomenda-se 15 a 30 entrevistas no total, distribuídas entre 2 ou 3 segmentos.
O framework crítico aqui é o Mom Test (livro de Rob Fitzpatrick). A regra central: nunca pergunte se a pessoa gostaria de usar seu produto. Pergunte sobre o comportamento atual dela. "O que você fez ontem pra resolver X?" vale mais que "você usaria um app que faz X?". Hábito histórico é fato. Opinião sobre futuro é cortesia.
A entrevista boa termina com três respostas concretas: a pessoa tentou resolver isso antes? Pagou por alguma solução? Mostrou frustração quando contou a história? Se as três respostas vierem juntas em mais de 60% das entrevistas, a hipótese tem PMF potencial.
Fase 3 — Protótipo de baixa fidelidade pra teste de proposta (5 a 7 dias)
Discovery não termina no insight. Termina em protótipo testável. Não protótipo em alta fidelidade, com tipografia ajustada e animação. Protótipo wireframe, em Figma ou no papel, suficiente pra mostrar a proposta de solução pro mesmo grupo entrevistado.
O teste do protótipo responde uma pergunta diferente da entrevista: "isso resolve a sua dor?". Se 4 em 5 pessoas dizem que sim e descrevem como usariam, a hipótese passou. Se as respostas vêm difusas, com "talvez", "depende", "interessante", a hipótese não passou. Ainda há tempo de pivotar antes de codar.
Os erros mais comuns de quem pula discovery
Três padrões aparecem repetidamente em projetos que pularam discovery e estouraram budget:
- Confundir validação com permissão: o time mostra o protótipo pra família e amigos, ouve "ficou lindo", e considera validado. Família é cortês, não é mercado.
- Entrevistar concorrência por proxy: usar reviews da App Store como única fonte de pesquisa. Reviews enviesam pra extremos. A maioria silenciosa não escreve review.
- Tratar a planilha de respostas como roadmap: discovery não dita o que construir, dita o que não construir. A função primária é cortar hipóteses, não validar todas.
Insight Otther: discovery como gestão de risco
Na Otther, tratamos discovery como gestão de risco financeiro do projeto. Cada hipótese não validada é uma posição em aberto que o time vai descobrir tarde. Toda hora que o discovery economiza em código depois compensa três horas no caixa do cliente.
O critério prático que aplicamos: nenhum projeto entra em codificação sem ter respondido as quatro perguntas básicas (quem, o quê, como hoje, quanto). Quando o cliente quer pular discovery por pressão de prazo, a conversa é honesta: o prazo curto sem discovery não é prazo curto, é prazo errado. Lançar rápido o produto errado custa mais do que lançar 3 semanas depois o produto certo.
Se você está prestes a iniciar um produto novo, ou está repensando um existente com retenção baixa, vale a primeira conversa. 90 minutos de discovery focado costumam mostrar o caminho mais econômico antes de qualquer escopo formal.