Discovery de Produto

Nível: Júnior | Duração estimada de leitura: 16 minutos | Categoria: Trilha Júnior — Módulo 1

Introdução

Na trilha Iniciante, você aprendeu a executar: escrever histórias, organizar o backlog, trabalhar com o time. São habilidades fundamentais — e necessárias. Mas existe uma diferença entre o PO que executa bem e o PO que constrói o produto certo.

Essa diferença tem um nome: discovery.

Discovery é o processo contínuo de entender o problema do usuário antes de decidir o que construir. É a diferença entre um time que entrega features e um time que entrega resultado. Entre um backlog cheio de demandas e um backlog cheio de apostas fundamentadas.

A maioria dos POs júniors sente uma pressão enorme para ir logo para o delivery — para o refinamento, para a sprint, para a entrega. Discovery parece lento, parece custo, parece que "ainda não está produzindo nada". Essa percepção é o erro mais caro que um time de produto pode cometer.

Neste módulo você vai entender o que é discovery de verdade, como conduzi-lo de forma contínua e como usá-lo para tomar decisões de produto com muito mais confiança — e muito menos desperdício.

O que é Discovery (e o que não é)

Discovery não é uma fase que acontece uma vez antes do desenvolvimento começar. Não é um workshop de dois dias com post-its na parede. Não é entrevistar usuários quando o produto não está crescendo.

Discovery é uma prática contínua de reduzir a incerteza sobre três perguntas fundamentais:

1. Estamos resolvendo o problema certo? Antes de qualquer solução, você precisa ter evidências de que o problema que está priorizando é real, relevante e recorrente para um número significativo de usuários.

2. Estamos resolvendo para a pessoa certa? Diferentes segmentos de usuários têm problemas diferentes. Uma solução que resolve perfeitamente para um segmento pode ser completamente irrelevante para outro. Saber para quem você está otimizando é fundamental.

3. Nossa solução realmente resolve? A solução que você imaginou é apenas uma hipótese. Discovery é o processo de testar essa hipótese antes de gastar semanas ou meses desenvolvendo algo que pode não funcionar.

Sem discovery contínuo, o backlog é uma lista de apostas no escuro. Com discovery, ele se torna um conjunto de hipóteses validadas — com diferentes níveis de confiança, mas todas fundamentadas em evidências reais.

Os dois modos do trabalho de produto

Teresa Torres, referência mundial em product discovery, popularizou o conceito de Dual Track: dois fluxos de trabalho acontecendo em paralelo, o tempo todo.

Discovery Track — O time está constantemente aprendendo: entrevistando usuários, testando protótipos, analisando dados, validando hipóteses. O objetivo é reduzir incerteza e identificar oportunidades de valor.

Delivery Track — O time está construindo e entregando: refinamento, sprint, desenvolvimento, QA, lançamento. O objetivo é transformar oportunidades validadas em produto funcionando.

O erro mais comum é tratar esses dois fluxos como sequenciais — "primeiro descobrimos tudo, depois construímos". Na prática, discovery e delivery acontecem ao mesmo tempo, alimentando-se mutuamente. Enquanto o time entrega a sprint atual, o PO já está descobrindo o que vai entrar nas próximas três.

O PO que só faz delivery vira gerente de backlog — executa bem, mas não cria as condições para o produto crescer.

O PO que só faz discovery perde o contato com a realidade do desenvolvimento — tem muitas ideias, mas nenhuma chega ao usuário.

O equilíbrio entre os dois é o que separa o PO júnior do PO pleno.

As fontes de discovery: onde o aprendizado acontece

Discovery não tem uma única fonte. Os melhores POs constroem um sistema de aprendizado que combina múltiplas fontes de forma contínua.

Entrevistas com usuários

A fonte mais valiosa e mais subutilizada. Uma conversa de 30 minutos com um usuário real revela nuances que nenhum dado quantitativo consegue capturar. Você descobre o vocabulário que ele usa para descrever o problema, o contexto em que o problema aparece, as soluções alternativas que ele já tentou — e por que não funcionaram.

A regra prática de Teresa Torres: pelo menos uma entrevista por semana. Não precisa ser longa, não precisa ser formal. Uma conversa focada já é discovery.

O que evitar nas entrevistas:

• Perguntar se o usuário usaria determinada feature ("Você usaria um botão que faz X?") — as pessoas tendem a dizer sim para não decepcionar
• Defender a solução que você já tem em mente durante a conversa
• Falar mais do que ouvir

O que buscar:

• Comportamento passado ("Me conta a última vez que você teve esse problema")
• Contexto e frequência ("Com que frequência isso acontece? O que você estava fazendo quando surgiu?")
• Soluções alternativas ("O que você faz hoje para resolver isso?")

Dados de produto (Analytics)

Os dados mostram o que os usuários fazem — não o que dizem que fazem. Taxas de conversão, funis de abandono, features com baixa adoção, caminhos inesperados no produto. Cada anomalia nos dados é uma pergunta para investigar no discovery.

Dados sem entrevista dizem o quê, mas não o porquê. Entrevista sem dados diz o porquê, mas pode não ser representativo. Os dois juntos formam o quadro completo.

Tickets de suporte e reclamações

O suporte é um repositório gratuito de problemas reais de usuários reais. Categorize os tickets por tema toda semana. Os problemas que aparecem com mais frequência são candidatos diretos ao backlog.

Feedbacks de vendas e sucesso do cliente

Se a empresa tem times de Vendas e Customer Success, esses profissionais têm contato diário com as dores dos clientes. Uma reunião semanal de 30 minutos com alguém dessas áreas pode revelar padrões que você não veria de dentro do produto.

Pesquisas quantitativas

NPS, CSAT, pesquisas de satisfação, surveys in-product. Úteis para medir percepção em escala. Não substituem a profundidade das entrevistas, mas complementam com representatividade estatística.

Testes de usabilidade

Coloque um usuário real para usar o produto enquanto você observa. Sem ajudar, sem intervir. O que ele trava, o que ele ignora, o que ele entende errado — tudo isso é ouro para o discovery.

Oportunidades vs. Soluções: a distinção mais importante do discovery

Um erro clássico: confundir oportunidade com solução.

Oportunidade é um problema do usuário que, se resolvido, gera valor. "Clientes ficam frustrados porque não conseguem acompanhar o status da devolução sem ligar para o SAC" é uma oportunidade.

Solução é uma forma específica de resolver esse problema. "Criar uma página de acompanhamento de devolução com status em tempo real" é uma solução.

O problema é que a maioria dos POs recebe soluções — dos stakeholders, do CEO, dos clientes — e trata como se fossem oportunidades. "Precisamos de um portal de devoluções" não é uma oportunidade de negócio — é uma solução para um problema que precisa ser investigado.

Sempre que uma demanda chegar, traduza-a de solução para oportunidade:

"Precisamos de [solução X]" → "Por que? Qual problema isso resolve?" → "Quem tem esse problema? Com que frequência?" → "O que acontece se esse problema não for resolvido?"

Só depois de entender a oportunidade você está em posição de avaliar se a solução proposta é realmente a melhor — ou se existe uma forma mais simples, mais rápida ou mais eficaz de resolver o mesmo problema.

Opportunity Solution Tree: a ferramenta central do discovery moderno

O Opportunity Solution Tree (OST) é uma ferramenta visual desenvolvida por Teresa Torres que organiza o raciocínio de discovery de forma estruturada. É um dos frameworks mais poderosos que um PO júnior pode aprender.

A estrutura é uma árvore com quatro níveis:

1. Resultado desejado (raiz) — O objetivo de negócio que o produto precisa atingir. Geralmente derivado dos OKRs do time. Exemplo: "Aumentar a taxa de retenção de clientes nos primeiros 30 dias."

2. Oportunidades (primeiro nível de galhos) — Os problemas ou necessidades dos usuários que, se resolvidos, contribuem para o resultado. Descobertos via entrevistas e dados. Cada oportunidade é um "porque" que explica por que os usuários não estão atingindo o resultado desejado.

3. Soluções (segundo nível de galhos) — As formas de resolver cada oportunidade. Múltiplas soluções por oportunidade — o OST evita que você fique preso na primeira ideia.

4. Experimentos (terceiro nível de galhos) — As formas de testar cada solução antes de construir. Protótipos, testes A/B, landing pages, wizard of oz. O experimento mais barato que valida a hipótese mais crítica.

O poder do OST está em tornar visível a conexão entre o objetivo de negócio e cada decisão de produto. Quando alguém questiona uma prioridade, você consegue mostrar exatamente onde ela se conecta ao resultado que o time persegue.

Como conduzir uma entrevista de discovery que gera insight real

A entrevista de discovery tem estrutura própria. Não é uma conversa aleatória — é uma investigação focada.

Antes da entrevista:

• Defina o tema que quer investigar (um problema específico, um comportamento, uma parte do produto)
• Prepare 5 a 7 perguntas abertas — nunca um script fechado
• Recrute o usuário certo: alguém que realmente vive o problema que você quer entender

Durante a entrevista:

Abertura (5 min): Contextualize sem revelar o que você espera ouvir. "Estou pesquisando como as pessoas lidam com [tema geral]. Me conta um pouco sobre como você usa o produto hoje."

Exploração (20 min): Perguntas abertas focadas em comportamento passado. Use o silêncio — quando o usuário para de falar, espere. O que vem depois do silêncio costuma ser o mais revelador.

Aprofundamento (5 min): Quando algo interessante surgir, aprofunde. "Você mencionou que faz X de uma forma alternativa. Me conta mais sobre isso."

Encerramento (5 min): "Tem algo que você gostaria que eu tivesse perguntado e não perguntei?" Essa pergunta frequentemente traz os insights mais valiosos.

Depois da entrevista:

• Documente imediatamente — a memória de conversas é altamente seletiva
• Registre citações diretas do usuário, não interpretações suas
• Identifique padrões que aparecem em múltiplas entrevistas — um insight de uma pessoa é anedota; o mesmo insight de cinco pessoas é sinal

Discovery ágil: como fazer com pouco tempo e recursos limitados

"Não tenho tempo para fazer discovery" é a justificativa mais comum — e mais cara — do PO júnior. A verdade é que você não tem tempo para não fazer discovery.

Cada feature construída sem validação prévia é uma aposta. E features erradas são muito mais caras do que entrevistas.

Guerrilla research: Uma entrevista de 15 minutos por semana já é melhor do que nada. Não precisa ser formal, não precisa de sala de usuabilidade. Um café com um cliente, uma chamada rápida com alguém que usa o produto, uma pergunta aberta no chat de suporte.

Testes de protótipo assíncronos: Ferramentas como Maze ou UserTesting permitem lançar um teste de protótipo para dezenas de usuários em horas, sem precisar agendar entrevista por entrevista.

Fake door test: Antes de construir, coloque um botão ou link para a feature imaginada no produto. Meça quantas pessoas clicam. Se ninguém clica, o problema pode não ser tão relevante quanto você pensava.

Análise de dados como ponto de partida: Reserve 30 minutos por semana para olhar os dados do produto com a pergunta "o que está se comportando diferente do esperado?". Cada anomalia é uma hipótese para investigar.

Os erros mais comuns no discovery

Confirmar em vez de descobrir Entrar na entrevista com a solução já decidida e buscar confirmação de que o usuário quer aquilo. É o viés de confirmação em ação — e ele é poderoso. Discipline-se para entrar em cada entrevista querendo ser surpreendido.

Perguntar sobre o futuro, não sobre o passado "Você usaria uma feature que faz X?" não é discovery — é wishful thinking. O usuário diz sim porque não quer decepcionar. "Me conta a última vez que você precisou de X" revela comportamento real.

Entrevistar só os usuários satisfeitos Os usuários que te dão mais acesso são geralmente os que mais gostam do produto. Eles não te contam o que está errado — te confirmam o que você quer ouvir. Busque ativamente os usuários que abandonaram, os que reclamam, os que usam de forma inesperada.

Fazer discovery isolado do time Discovery que só o PO vê não gera ownership no time. Compartilhe os insights das entrevistas, envolva devs e designers nas sessões de vez em quando, construa junto a árvore de oportunidades. Time que participa do discovery constrói com muito mais propósito.

Paralisia por analysis Discovery é para informar decisão, não para postergar. Em algum momento você precisa fazer uma aposta com a informação que tem e aprender com o resultado. Discovery contínuo significa que você aprende antes, durante e depois de construir — não que você espera certeza absoluta antes de agir.

Certificações e onde estudar

Livro fundamental:

• Continuous Discovery Habits — Teresa Torres. O livro que definiu o estado da arte em product discovery moderno. Leitura obrigatória para todo PO júnior que quer ir além da execução.

Cursos:

• Product Talk Academy (Teresa Torres): A fonte original do Opportunity Solution Tree e das melhores práticas de entrevistas de discovery. Conteúdo em inglês, referência global.
• Reforge — Product Strategy: Para quando você estiver mais avançado, o Reforge tem os programas mais densos de desenvolvimento de produto disponíveis. Caro, mas vale o investimento.
• Alura — Formação Product Manager: Alternativa em português com boa cobertura de discovery e metodologias ágeis para quem está iniciando.

Certificações relevantes:

• PSPO II (Scrum.org): O segundo nível do PSPO tem forte componente de discovery e estratégia de produto. Recomendado após 1-2 anos de experiência.
• PMI-ACP: Cobre metodologias ágeis incluindo práticas de discovery. Reconhecida globalmente.

Comunidades:

• Slack da Product-Led Alliance: Comunidade global de POs com canais específicos sobre discovery
• Product Managers Brasil (LinkedIn e Slack): Comunidade brasileira ativa com discussões sobre casos reais

Conclusão

Discovery não é atividade paralela ao trabalho de produto. É a metade mais importante dele.

O PO que entrega com consistência não é aquele que tem o backlog mais organizado — é o que tem mais clareza sobre qual problema está resolvendo, para quem, e por que isso importa para o negócio. Essa clareza vem de discovery contínuo, de conversas reais com usuários reais, de dados interpretados com curiosidade genuína.

Cada semana sem discovery é uma semana construindo com mais incerteza do que precisaria. Cada entrevista, cada análise de dados, cada teste de hipótese é um investimento que reduz o risco de construir a coisa errada.

No próximo módulo, vamos falar sobre as métricas que todo PO precisa conhecer — porque discovery sem métricas é aprendizado sem direção, e métricas sem discovery são números sem contexto.

Até lá.