Product Discovery

O que e product discovery, Dual Track Agile, tecnicas de entrevista de usuario, job stories, assumption mapping e prototipos.

O que e?

Product Discovery e o processo de entender o problema antes de construir a solucao. E 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 desperdicio nao e construir errado. E construir a coisa certa da forma errada. Mas pior ainda e construir perfeitamente algo que ninguem precisa.

Discovery responde quatro perguntas criticas (Marty Cagan):

Valor — Os usuarios querem isso?
Usabilidade — Os usuarios conseguem usar?
Viabilidade — Conseguimos construir?
Negocio — 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 usuarios            ├── Sprint planning
├── Prototipos e testes                 ├── Desenvolvimento
├── Validacao de hipoteses              ├── 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, nao em fases sequenciais.

Tecnicas de Discovery

1. Entrevistas de usuario

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

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

Perguntas ruins (enviesadas):
├── ❌ "Voce gostaria de um botao que faz X?"
├── ❌ "Voce usaria nosso produto?"
├── ❌ "Quanto pagaria por isso?"
└── ❌ "Isso nao e frustrante?" (leading question)

Regra de ouro: pergunte sobre o PASSADO, nao sobre o FUTURO.
Pessoas sao pessimas em prever comportamento futuro.

2. Job Stories (Jobs to be Done)

Evolucao da user story focada no contexto e motivacao:

User Story:
"Como gerente, quero exportar relatorios em PDF."

Job Story:
"Quando preciso apresentar resultados para a diretoria,
 quero gerar um relatorio visual com os KPIs do mes,
 para que eu consiga demonstrar progresso sem criar slides manualmente."

A diferenca: job story captura o CONTEXTO (quando),
a MOTIVACAO (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. Prototipos

Tipo	Fidelidade	Tempo	Melhor para
Sketch em papel	Baixa	10 min	Explorar conceitos iniciais
Wireframe	Baixa-media	1-2h	Validar fluxo e estrutura
Prototipo clicavel	Media	1-2 dias	Teste de usabilidade
Prototipo funcional	Alta	3-5 dias	Validar viabilidade tecnica

Por que importa?

Product discovery e essencial porque:

Reduz desperdicio — nao constroi features que ninguem usa (40-60% das features de software sao raramente ou nunca usadas)
Aumenta confianca — o time constroi sabendo que ha demanda real
Melhora a qualidade — entender o problema leva a solucoes melhores
Acelera o ciclo — paradoxalmente, "perder tempo" com discovery acelera o delivery
Alinha stakeholders — evidencias de discovery facilitam priorizar e dizer "nao"

Sem discovery, o time de produto opera como uma "fabrica de features" — constroi o que stakeholders pedem, sem questionar se e o certo.

Exemplo pratico

Discovery para feature de "dashboard de metricas"

Contexto: Stakeholder pediu "dashboard com todas as metricas do negocio"

Sprint de Discovery (1 semana):

Dia 1-2: Entrevistas (5 usuarios)
├── Persona: gerente de operacoes
├── Descobertas:
│   ├── Nao querem "todas as metricas" — querem 3-4 KPIs
│   ├── Precisam ver dados pela manha no celular
│   ├── Gastam 40 min/dia montando relatorios no Excel
│   └── O problema real: "nao consigo saber rapidamente se algo esta errado"

Dia 3: Assumption Mapping
├── Premissa 1: Usuarios querem dashboard customizavel → Medio risco
├── Premissa 2: Usuarios acessam pelo celular → Alto risco (testar!)
├── Premissa 3: 3-4 KPIs sao suficientes → Alto risco (testar!)
└── Premissa 4: Alertas automaticos resolvem → Medio risco

Dia 4: Prototipo (Figma, 4h)
├── Versao A: Dashboard completo com 15 metricas
├── Versao B: Dashboard minimal com 4 KPIs + alertas
└── Mobile-first

Dia 5: Teste de usabilidade (5 usuarios)
├── Resultado: 5/5 preferiram Versao B
├── Insight: "Quero saber se algo esta errado, nao ver numeros"
├── Decisao: construir Versao 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

Termos relacionados

MVP — o discovery informa o que deve entrar no MVP
User Story — discovery gera insumos para user stories melhores
PMF — discovery continuo e o caminho para encontrar product-market fit

On this page