Product discovery na prática: frameworks testados em casos reais

A parte mais cara de construir um produto não é a engenharia. É construir a coisa errada com competência. Times inteiros gastam meses entregando, com qualidade técnica impecável, uma solução que ninguém pediu para um problema que não existia.

Product discovery existe para evitar exatamente isso. É o conjunto de práticas que responde, antes da construção, a uma pergunta brutal: vale a pena construir isto? Para quem? Por quê?

Frameworks de discovery ajudam a estruturar essa investigação. Mas a teoria deles é fácil de elogiar e difícil de aplicar. Por isso este texto parte de casos reais, situações em que o discovery decidiu o destino do produto, para o bem ou para o mal.

O caso da feature que ninguém usou

Comece pelo erro mais comum. Uma empresa decide construir uma funcionalidade porque "os clientes pediram". O time executa, lança, comemora, e a adoção é quase zero.

O que aconteceu? Os clientes de fato pediram, mas pediram uma solução, não descreveram um problema. Quando você constrói o que o cliente pede literalmente, sem investigar o problema por trás, frequentemente entrega algo que ele imaginou mal.

Discovery teria mudado o jogo aqui. Uma rodada de entrevistas focada em entender o contexto, não a feature, mas a dor, revelaria que o problema real era outro, com uma solução muito mais simples. A lição: o pedido do cliente é um sintoma, não o diagnóstico.

O caso do governo digital que ninguém conseguia usar

No setor público, o padrão se repete com consequências mais graves. Imagine uma prefeitura que digitaliza um serviço, digamos, o agendamento de uma consulta ou a emissão de um documento, investindo em tecnologia robusta.

O sistema entra no ar, é anunciado como modernização, e a fila presencial continua igual. Por quê? Porque ninguém validou se o cidadão real conseguia usar aquilo. O público-alvo incluía pessoas com baixa familiaridade digital, conexão instável, dúvidas que o fluxo não previa.

Discovery, aqui, não é luxo de startup. É o que evita gastar dinheiro público em sistemas que não cumprem sua função social. Algumas conversas com cidadãos reais, antes de construir, teriam revelado barreiras que nenhuma reunião interna anteciparia. O custo do discovery é irrisório perto do custo de um serviço que exclui quem deveria atender.

Os frameworks que funcionam quando levados a sério

Casos reais mostram que alguns frameworks de discovery se sustentam melhor que outros sob pressão.

Continuous Discovery (entrevistas contínuas). Em vez de pesquisa pontual antes do projeto, conversas semanais com usuários ao longo do tempo. O caso típico de sucesso é o time que descobre uma objeção crítica cedo, porque mantinha contato constante com quem usava o produto.
Opportunity Solution Tree. Conecta resultado de negócio, oportunidades descobertas e soluções candidatas em uma árvore visível. Funciona porque obriga o time a justificar por que uma solução resolve uma oportunidade real, e não uma intuição.
Teste de protótipo antes de código. O caso clássico é validar uma ideia com um protótipo navegável e descobrir, em uma tarde, que o fluxo não fazia sentido, economizando semanas de desenvolvimento.

O ponto comum desses frameworks bem-sucedidos é o contato direto e frequente com a realidade. Discovery que acontece só em sala de reunião, com hipóteses sobre o usuário em vez de conversa com o usuário, costuma falhar no caso real.

O caso do discovery que virou desculpa

Há também o lado oposto, e é honesto reconhecê-lo. Discovery pode virar paralisia. Já vi times usarem "ainda estamos em discovery" como escudo para nunca decidir.

A investigação que nunca converge não é cuidado, é medo. Em um caso real de uma startup, meses de pesquisa adiaram um lançamento que o mercado já estava pedindo, e um concorrente menos cuidadoso, porém mais decidido, ocupou o espaço.

Discovery tem que ter prazo e propósito. O objetivo nunca foi entender tudo, foi reduzir a incerteza o suficiente para decidir com responsabilidade. Quando o time confunde discovery com a busca de certeza absoluta, ele troca o risco de errar pelo risco, igualmente real, de nunca agir.

O caso do discovery que mudou a estratégia, não só a feature

Vale um caso que mostra discovery operando em outro nível, não para decidir uma funcionalidade, mas para corrigir o rumo de toda uma aposta.

Imagine uma empresa convencida de que seu público queria um produto mais completo, cheio de recursos. A intuição da liderança era clara: a concorrência era simples demais, e diferenciação viria pela profundidade. O roadmap inteiro apontava nessa direção.

Uma rodada séria de discovery, conversas contínuas, observação de uso real, revelou o oposto. Os usuários não queriam mais recursos; queriam que o pouco que já existia funcionasse de forma mais simples e confiável. A complexidade que a empresa pretendia construir era exatamente o que afastava as pessoas.

O valor do discovery, nesse caso, não foi economizar algumas semanas de desenvolvimento. Foi evitar que a empresa investisse meses construindo na direção errada da própria estratégia. Discovery, levado a sério, às vezes não ajusta o que você constrói, ele questiona se você deveria estar construindo aquilo.

Esse é o uso mais difícil e mais valioso. Exige que a liderança esteja disposta a ouvir que sua convicção pode estar errada. Times que fazem discovery só para confirmar o que já decidiram não estão investigando; estão buscando aplauso. E aplauso não protege ninguém de uma aposta ruim.

Quando o discovery realmente vale o investimento

A decisão sobre quanto discovery fazer é, no fundo, uma análise de risco. Quanto maior a incerteza e maior o custo de errar, mais discovery se justifica.

Construir uma feature pequena, reversível e barata? Às vezes vale arriscar e aprender no uso real, discovery extenso seria desperdício. Construir uma aposta cara, difícil de reverter, que define a estratégia da empresa ou afeta milhares de cidadãos? Aí o discovery não é custo, é seguro.

Líderes maduros calibram isso caso a caso. Tratar discovery como obrigatório em tudo é tão ingênuo quanto tratá-lo como opcional em tudo. A pergunta certa é sempre proporcional: o quanto eu perco se estiver errado, e o quanto custa descobrir antes?

Fechamento

Os casos reais ensinam a mesma lição por caminhos diferentes. Quem investiga o problema antes de construir desperdiça menos, acerta mais e dorme melhor. Quem pula essa etapa paga depois, em retrabalho, em dinheiro, às vezes em exclusão de quem mais precisava ser atendido.

Discovery não garante acerto. Garante que, quando você erra, erra barato e cedo, com chance de corrigir. Em produto, isso é quase tudo.

Se a sua organização costuma construir primeiro e descobrir depois, talvez valha inverter a ordem antes da próxima aposta cara. Há outros artigos por aqui sobre frameworks de discovery e design que aprofundam o tema.