Product Discovery: O Que É, Dual Track Agile, Entrevistas e Assumption Mapping

40 a 60% das features de software são raramente ou nunca usadas. Isso significa que mais da metade do trabalho de engenharia é desperdício — não porque o time não sabe programar, mas porque o time não descobriu o problema certo antes de construir. Product Discovery existe para mudar essa estatística.

O que é?

Product Discovery é o processo de entender o problema antes de construir a solução. É a fase onde o time de produto investiga se vale a pena construir algo — antes de gastar semanas de engenharia.

A premissa fundamental:

O maior desperdício não é construir errado. É construir a coisa certa da forma errada. Mas pior ainda é construir perfeitamente algo que ninguém precisa.

Discovery responde quatro perguntas críticas (Marty Cagan):

Valor — Os usuários querem isso?
Usabilidade — Os usuários conseguem usar?
Viabilidade — Conseguimos construir?
Negócio — Faz sentido para a empresa?

Como funciona

Dual Track Agile

A abordagem mais moderna de produto separa o trabalho em dois trilhos paralelos:

Dual Track Agile:

Track 1: DISCOVERY (explorar)          Track 2: DELIVERY (construir)
├── Entrevistas com usuários            ├── Sprint planning
├── Protótipos e testes                 ├── Desenvolvimento
├── Validação de hipóteses              ├── Code review e QA
├── Assumption mapping                  ├── Deploy e monitoramento
└── Output: backlog validado            └── Output: incremento de produto

       Discovery alimenta o Delivery
       ────────────────────────────→
       Delivery gera dados para Discovery
       ←────────────────────────────

O time faz discovery e delivery ao mesmo tempo, não em fases sequenciais.

Técnicas de Discovery

1. Entrevistas de usuário

Formato: 30-45 minutos, 1-on-1

Perguntas boas (abertas):
├── "Me conte sobre a última vez que você [problema]..."
├── "O que você fez para resolver?"
├── "O que foi mais frustrante nesse processo?"
├── "Se você pudesse mudar uma coisa, o que seria?"
└── "Como você resolve isso hoje?"

Perguntas ruins (enviesadas):
├── ❌ "Você gostaria de um botão que faz X?"
├── ❌ "Você usaria nosso produto?"
├── ❌ "Quanto pagaria por isso?"
└── ❌ "Isso não é frustrante?" (leading question)

Regra de ouro: pergunte sobre o PASSADO, não sobre o FUTURO.
Pessoas são péssimas em prever comportamento futuro.

2. Job Stories (Jobs to be Done)

Evolução da user story focada no contexto e motivação:

User Story:
"Como gerente, quero exportar relatórios em PDF."

Job Story:
"Quando preciso apresentar resultados para a diretoria,
 quero gerar um relatório visual com os KPIs do mês,
 para que eu consiga demonstrar progresso sem criar slides manualmente."

A diferença: job story captura o CONTEXTO (quando),
a MOTIVAÇÃO (para que) e o RESULTADO DESEJADO.

3. Assumption Mapping

         Alta incerteza
              │
    ┌─────────┼─────────┐
    │  TESTAR │  TESTAR  │
    │  DEPOIS │  PRIMEIRO│ ← Comece aqui
    │         │          │
────┼─────────┼──────────┤
    │  SAFE   │  TESTAR  │
    │  (ok)   │  DEPOIS  │
    │         │          │
    └─────────┼──────────┘
              │
         Baixa incerteza
    Baixo risco    Alto risco

Mapeie suas premissas e teste primeiro as de
ALTO RISCO + ALTA INCERTEZA.

4. Protótipos

Tipo	Fidelidade	Tempo	Melhor para
Sketch em papel	Baixa	10 min	Explorar conceitos iniciais
Wireframe	Baixa-média	1-2h	Validar fluxo e estrutura
Protótipo clicável	Média	1-2 dias	Teste de usabilidade
Protótipo funcional	Alta	3-5 dias	Validar viabilidade técnica

Por que importa?

Product discovery é essencial porque:

Reduz desperdício — não constrói features que ninguém usa (40-60% das features de software são raramente ou nunca usadas)
Aumenta confiança — o time constrói sabendo que há demanda real
Melhora a qualidade — entender o problema leva a soluções melhores
Acelera o ciclo — paradoxalmente, "perder tempo" com discovery acelera o delivery
Alinha stakeholders — evidências de discovery facilitam priorizar e dizer "não"

Sem discovery, o time de produto opera como uma "fábrica de features" — constrói o que stakeholders pedem, sem questionar se é o certo.

Exemplo prático

Discovery para feature de "dashboard de métricas"

Contexto: Stakeholder pediu "dashboard com todas as métricas do negócio"

Sprint de Discovery (1 semana):

Dia 1-2: Entrevistas (5 usuários)
├── Persona: gerente de operações
├── Descobertas:
│   ├── Não querem "todas as métricas" — querem 3-4 KPIs
│   ├── Precisam ver dados pela manhã no celular
│   ├── Gastam 40 min/dia montando relatórios no Excel
│   └── O problema real: "não consigo saber rapidamente se algo está errado"

Dia 3: Assumption Mapping
├── Premissa 1: Usuários querem dashboard customizável → Médio risco
├── Premissa 2: Usuários acessam pelo celular → Alto risco (testar!)
├── Premissa 3: 3-4 KPIs são suficientes → Alto risco (testar!)
└── Premissa 4: Alertas automáticos resolvem → Médio risco

Dia 4: Protótipo (Figma, 4h)
├── Versão A: Dashboard completo com 15 métricas
├── Versão B: Dashboard minimal com 4 KPIs + alertas
└── Mobile-first

Dia 5: Teste de usabilidade (5 usuários)
├── Resultado: 5/5 preferiram Versão B
├── Insight: "Quero saber se algo está errado, não ver números"
├── Decisão: construir Versão B + sistema de alertas
└── Escopo reduzido: 3 sprints → 1 sprint

Economia:
├── Sem discovery: 6 semanas construindo dashboard completo
├── Com discovery: 2 semanas construindo o que importa
└── Economia: 4 semanas de engenharia + produto melhor

Discovery como caminho para PMF

Product Discovery contínuo é o caminho para encontrar e validar o product-market fit. O PMF não é encontrado de uma vez — é refinado iterativamente através de ciclos de discovery e delivery, onde cada iteração revela mais sobre o que os usuários realmente precisam.

A conexão com A/B testing é direta: discovery gera hipóteses qualitativas sobre o que o usuário quer; A/B testing valida quantitativamente qual solução performa melhor. Discovery sem A/B testing é intuição; A/B testing sem discovery é otimização sem direção.

O que o discovery descobre alimenta também a North Star Metric: ao entender profundamente qual é o "trabalho a ser feito" pelo produto, fica mais claro qual métrica captura o valor central entregue ao usuário.

Construa o produto certo com processo de discovery estruturado

A RedBlock aplica metodologias de product discovery — entrevistas, protótipos e testes de usabilidade — antes de iniciar o desenvolvimento, garantindo que cada feature construída resolve um problema real.

Falar com especialista

Do discovery ao MVP em semanas, não meses

A RedBlock desenvolve MVPs com stack moderno (Next.js, Node.js, automações n8n) com processo de validação antes do código — para lançar mais rápido o que o mercado realmente quer.

Falar com especialista