Discovery de Produto: O Guia Prático para Founders Não-Técnicos

Discovery é a etapa que a maioria dos founders pula — e se arrepende depois.

O motivo é simples: parece abstrato. Parece que você está atrasando a construção. Parece que é coisa de empresa grande com PM dedicado.

Não é. E ignorar essa etapa é um dos erros mais caros em construção de produto.

O que é discovery de produto

Discovery é o processo de entender o problema real antes de decidir o que construir.

Não é pesquisa infinita. Não é reunião de alinhamento. É um período focado de 1–2 semanas onde você sai com:

• Clareza sobre o problema que o produto precisa resolver
• Hipóteses priorizadas sobre como resolver
• Critérios de sucesso mensuráveis
• Decisão sobre o que construir primeiro — e o que deixar para depois

Por que founders pulam

Três razões:

1. Urgência percebida. "Preciso lançar logo." O problema é que construir sem discovery normalmente leva mais tempo, não menos — porque você constrói a coisa errada.

2. Certeza prematura. "Eu sei o que meu usuário precisa." Talvez. Mas founders têm um viés natural em direção à solução que já imaginaram. Discovery questiona esse viés.

3. Falta de método. Não é que o founder não quer fazer — é que não sabe por onde começar.

O framework em 4 etapas

Etapa 1: Mapeamento do problema (dias 1–3)

Documente o problema que você está tentando resolver. Não a solução — o problema.

Perguntas guia:

• Quem tem esse problema?
• Com que frequência ele acontece?
• Qual o custo atual de não resolver? (tempo, dinheiro, frustração)
• Como as pessoas resolvem hoje?

Etapa 2: Entrevistas (dias 3–7)

5 a 8 conversas com usuários reais (ou potenciais). Não para validar sua solução — para entender o problema deles.

Regra de ouro: não mencione sua solução nas primeiras duas perguntas. Deixe o usuário falar sobre o problema antes de apresentar qualquer coisa.

Etapa 3: Síntese (dias 7–10)

Agrupe os insights. O que apareceu em múltiplas conversas? O que foi surpresa? Onde as hipóteses iniciais estavam erradas?

Você vai ter padrões. Esses padrões viram hipóteses priorizadas.

Etapa 4: Decisão (dias 10–14)

Com as hipóteses em mãos, priorize: o que você vai testar primeiro? Qual entregável valida a hipótese mais importante?

Isso vira o briefing do próximo sprint de construção.

Discovery vs diagnóstico de produto

Discovery responde: "O que construir?"

Diagnóstico de produto responde: "Qual problema está travando o produto — e quem pode resolvê-lo?"

São complementares. O diagnóstico da Mallo inclui elementos de discovery — mas com foco específico em entender o gargalo e recomendar o perfil profissional certo para destravá-lo.

Quando contratar ajuda para o discovery

Se você está com o produto travado e não consegue responder com clareza qual é o problema raiz, você precisa de ajuda externa.

Não porque você é incapaz — mas porque é difícil ver com clareza o que você está dentro.

Um profissional externo traz o método, faz as perguntas certas, e te entrega um mapa do problema sem o viés do fundador.