Product Discovery — Validando Hipóteses Antes de Codar

O custo de descobrir que uma feature não resolve o problema real do usuário é radicalmente diferente dependendo de quando você descobre. Durante o discovery, uma entrevista ou protótipo descartável custa horas. Depois do desenvolvimento, custa semanas ou meses de sprint. Product Discovery é o conjunto de práticas que move essa descoberta para o início do ciclo, reduzindo o risco de investimento em soluções para problemas que não existem ou que não são prioritários.

O que é discovery e o que não é

Discovery não é análise de requisitos. Análise de requisitos parte da premissa de que o problema é conhecido e o trabalho é detalhar a solução. Discovery parte da premissa de que o problema precisa ser investigado antes de qualquer decisão de solução.

Discovery também não é pesquisa acadêmica — não tem o objetivo de gerar conhecimento definitivo, mas de reduzir incerteza suficientemente para tomar uma decisão de produto com confiança razoável.

A distinção entre discovery e delivery é operacionalmente importante. Discovery é paralelo ao delivery, não anterior a ele. Enquanto o time de engenharia executa o sprint atual, o PM e o designer fazem discovery para o próximo ciclo. Separar essas faixas de trabalho evita que o ritmo de delivery atropele o pensamento cuidadoso necessário para fazer boas escolhas de produto.

O mapa de oportunidades

Antes de falar em soluções, é preciso entender a estrutura do espaço de oportunidades. Uma ferramenta útil para isso é a Opportunity Solution Tree (Teresa Torres): uma árvore que começa com um objetivo de negócio no topo, desce para as oportunidades (problemas ou necessidades de usuários que, se resolvidas, contribuem para o objetivo), e só então desce para soluções possíveis.

Essa estrutura impede um vício comum em times de produto: ir diretamente de "o negócio precisa de X" para "vamos construir feature Y" sem passar pela pergunta intermediária "qual problema de usuário essa feature resolve e por que resolvê-lo contribui para o objetivo?".

Mapear oportunidades exige contato direto com usuários. Entrevistas semanais com clientes — mesmo que curtas (30 minutos por semana) — criam um fluxo contínuo de insights que alimenta o discovery de forma muito mais eficaz do que pesquisas pontuais a cada trimestre.

Formulando hipóteses testáveis

Uma hipótese de produto bem formulada tem três elementos: o problema que estamos assumindo que existe, a solução que estamos propondo, e o resultado que esperamos observar se a hipótese for válida.

Formato útil: "Acreditamos que [tipo de usuário] tem dificuldade em [situação específica]. Se oferecermos [solução proposta], esperamos observar [resultado mensurável] em [prazo]."

A hipótese precisa ser falsificável — deve ser possível definir antecipadamente o que constituiria evidência contrária. Uma hipótese que só pode ser confirmada não é uma hipótese: é uma crença disfarçada de hipótese.

Selecionando o método de validação certo

Diferentes perguntas de discovery exigem métodos diferentes. A escolha deve ser guiada pela incerteza que você precisa reduzir:

A oportunidade existe? (Tem gente com esse problema?) → Entrevistas de descoberta, análise de dados de suporte, análise de comportamento no produto atual.

A solução resolve o problema? → Teste de protótipo com usuários, wizard of oz (simular a feature manualmente antes de construí-la), fake door test (medir demanda antes de existir a feature).

A solução resolve o problema melhor do que alternativas? → Teste comparativo A/B, análise de soluções de concorrentes e substitutos.

A solução resolve o problema para escala suficiente? → Survey quantitativo, análise de segmentação de usuários.

Protótipos de baixa fidelidade como ferramenta de aprendizado

Um protótipo de découvery não precisa ser bonito — precisa ser suficientemente concreto para que o usuário consiga reagir a ele. Um fluxo em Figma com boxes e texto placeholder, um storyboard desenhado à mão, ou uma série de slides que simula o comportamento do produto são todos protótipos válidos para discovery.

A armadilha é investir em fidelidade antes de validar a premissa. Um protótipo com UI polida leva mais tempo para construir, mas sobretudo cria um viés de confirmação nos testes — usuários tendem a suavizar críticas quando o trabalho parece acabado. Um protótipo obviamente inacabado sinaliza que a opinião do usuário é genuinamente buscada.

Da hipótese à decisão: o papel das evidências

Discovery gera evidências, não certezas. A decisão de investir em desenvolvimento é sempre uma aposta — o objetivo do discovery é que seja uma aposta informada.

Um framework simples para avaliar evidências antes de codar: (1) Qual a força das evidências? (quantas pessoas, com qual profundidade, com qual consistência?). (2) Qual o custo de estar errado? (quanto tempo de engenharia, reversibilidade da mudança?). (3) Existe uma forma mais barata de continuar reduzindo incerteza?

Quando as evidências são fracas e o custo de estar errado é alto, mais discovery é justificado. Quando as evidências são razoáveis e o custo de um MVP é baixo, pode valer a pena construir e aprender com dados reais de produção.

Discovery contínuo vs. discovery por projeto

O modelo mais maduro de discovery não é uma fase que precede o desenvolvimento de um projeto específico, mas uma prática contínua integrada ao ritmo de produto. Times que fazem discovery contínuo têm sempre um conjunto de oportunidades em exploração, um portfólio de hipóteses sendo testadas e um fluxo de aprendizado que alimenta a priorização do backlog de forma permanente.

Chegar a esse nível de maturidade exige que PM e designer reservem tempo de agenda explicitamente para discovery — não como atividade paralela que acontece quando sobra tempo, mas como trabalho de produto tão legítimo quanto um sprint de desenvolvimento.