Discovery de produto é a fase em que você descobre se vale construir algo, para quem, e que forma essa coisa deve ter — antes de escrever uma linha de código. É o que separa produto que cresce de produto que vira cemitério de features.
O erro mais caro em produto é pular discovery. Quando isso acontece, o time entrega no prazo, com qualidade técnica boa, uma solução que ninguém quer. O custo não é só o código jogado fora — é o tempo de mercado perdido e a moral do time.
As 4 etapas de um discovery enxuto
- Problema: que dor real estamos resolvendo? Para quem ela é insuportável hoje?
- Persona e contexto: quem vive essa dor, em que situação, com que frequência?
- Solução candidata: 2-3 formatos possíveis. Qual resolve melhor o problema?
- Validação: protótipo, entrevista, smoke test ou waitlist — qualquer sinal real antes de codar.
Perguntas de entrevista que destravam
- Me conta da última vez que você [enfrentou o problema]. O que aconteceu?
- Como você resolveu isso? O que era frustrante nessa solução?
- Quanto tempo/dinheiro isso te custou?
- Se isso fosse mágico amanhã, como seria? O que mudaria pra você?
- Por que você não resolveu isso antes?
Armadilhas comuns
- Perguntar 'você usaria isso?' — todo mundo diz que sim por educação. Pergunte sobre o passado, não o futuro.
- Entrevistar só amigos e gente da bolha — viés garantido.
- Discovery infinito — passar 6 meses pesquisando vira procrastinação. Defina um limite de tempo (2-4 semanas) e decida.
- Discovery sem hipótese — você precisa de uma tese pra refutar ou confirmar, não uma pergunta aberta.