Descoberta: como a gente decide o que construir

Existe uma fantasia sobre descoberta de produto: um processo elegante, cheio de entrevistas roteirizadas, mapas de empatia coloridos e workshops com post-it. Na prática, descoberta é mais parecida com trabalho de detetive do que com dinâmica de grupo. É juntar pistas de fontes diferentes, desconfiar das versões bonitas e ir atrás do que realmente acontece na operação do cliente.

Aqui na ClubPetro, descoberta não é uma fase que acontece antes do trabalho. É o trabalho. Antes de qualquer linha de código, a pergunta que a gente precisa responder é simples de enunciar e difícil de responder: esse problema existe de verdade, dói o suficiente e é nosso pra resolver?

De onde vêm os sinais

A gente não espera o problema chegar formatado. Os sinais vêm de vários lugares ao mesmo tempo, e parte do ofício é cruzá-los:

• Conversa com o cliente. Dono de posto e gestor de rede falam com a gente direto. Não é pesquisa trimestral — é contato contínuo, do tipo que revela o problema no meio de uma reclamação sobre outra coisa.
• O time de CS. Quem acompanha o cliente todo dia sabe onde ele trava antes de ele saber. Os padrões que o CS enxerga — a mesma dúvida repetida, o mesmo recurso ignorado — são matéria-prima de descoberta.
• O uso do produto. O que as pessoas fazem diz mais do que o que elas falam. Tela que ninguém abre, fluxo que todo mundo abandona no meio, gambiarra que o cliente inventou por fora: tudo isso é o produto contando onde ele falha.
• A operação real. Posto de combustível é chão de pátio, fila, turno, frentista com a mão suja de óleo. Descoberta que não considera esse contexto produz feature bonita no Figma e inútil na pista.

Separar o que dói do que incomoda

Todo cliente tem uma lista infinita de coisas que incomodam. Poucas doem de verdade. A diferença aparece em perguntas concretas: o que você fez da última vez que isso aconteceu? Quanto tempo você gastou? Você montou alguma planilha, algum processo paralelo, alguma gambiarra pra contornar?

Se a resposta é "nada, eu só acho que seria legal", o problema incomoda. Se a pessoa te mostra uma planilha mantida à mão toda semana, o problema dói. A gente constrói pra dor, não pra achismo — inclusive o nosso próprio achismo, que é o mais perigoso de todos porque vem disfarçado de convicção.

Prototipar é parte da descoberta

Tem uma coisa que mudou nos últimos anos e a gente abraçou sem cerimônia: com IA, o custo de transformar uma hipótese em algo tocável despencou. Antes, validar uma ideia exigia semanas de desenvolvimento ou um protótipo de mentira que não enganava ninguém. Hoje a gente consegue colocar uma versão funcional na frente do cliente em dias, às vezes em horas.

Isso muda a natureza da descoberta. Em vez de discutir uma ideia no abstrato — reunião, documento, opinião contra opinião — a gente discute uma coisa concreta que o cliente pode clicar. A reação a um protótipo real vale mais que dez entrevistas sobre uma ideia hipotética. As pessoas são educadas com ideias; com produto na tela, elas são honestas.

O protótipo não encerra a descoberta, ele acelera. Se a reação for morna, a gente descarta cedo e barato. Se for forte, a gente já aprendeu metade do que precisava sobre como a solução deve funcionar.

Descoberta nunca termina

O erro clássico é tratar descoberta como um portão: passou, agora é só executar. Não funciona assim. Toda decisão de construção carrega hipóteses, e hipóteses continuam sendo testadas depois do lançamento — pelo uso, pelo feedback, pelos números. Quando a realidade contradiz a hipótese, a gente muda. Sem drama, sem apego. Estar errado rápido é barato; insistir no erro é que custa caro.

Se você quer trabalhar com produto, essa é talvez a habilidade mais subestimada da área: a disposição de investigar antes de opinar e de mudar de ideia diante de evidência. Não exige genialidade. Exige curiosidade, humildade e um certo prazer em descobrir que o mundo é diferente do que você imaginava. Se isso te descreve, a gente tem muito problema interessante pra você investigar.