Como eu abordo o discovery

Discovery, pra mim, não é uma fase antes de codar é o hábito de entender o problema humano antes de me apaixonar por qualquer solução. Como cheguei nisso vindo do código, e como aplico no dia a dia.Vou começar com uma confissão: durante boa parte da minha carreira, eu pulei o discovery sem perceber que estava pulando.

Comecei no código. Fui desenvolvedor e líder técnico antes de ser product manager, e por anos a minha primeira reação diante de um problema era abrir o editor. Eu era rápido para construir e foi exatamente essa rapidez que me ensinou, do jeito mais caro possível, que construir a coisa errada com excelência continua sendo construir a coisa errada.

O discovery entrou na minha vida quando percebi que o que mais me movia não era a solução em si, mas o problema humano por trás dela. Esse foi o ponto em que encontrei meu lugar no produto. E desde então, discovery deixou de ser uma "etapa antes de codar" e virou um hábito: o de entender de verdade antes de me apaixonar por qualquer solução.

Tem uma armadilha confortável em tratar discovery como um quadrado no cronograma aquela caixinha que vem antes do delivery e que a gente "fecha" para poder começar a trabalhar de verdade. Eu penso o contrário.

Discovery é a disciplina de reduzir incerteza continuamente. Não acaba quando o desenvolvimento começa; ele caminha junto, alimentado por uso real, dados e conversa com gente. Lidero o ciclo de strategy → discovery → delivery justamente como um ciclo, não como uma esteira de mão única. A descoberta de hoje corrige a entrega de amanhã, e a entrega de amanhã abre a próxima descoberta.

Na prática, isso significa que eu nunca considero o problema "entendido o suficiente". Considero entendido o bastante para dar o próximo passo seguro e volto a duvidar assim que esse passo gera evidência nova.

Se existe uma frase que resume como eu abordo discovery, é esta: entender a dor antes de escrever qualquer linha de código.

Foi exatamente assim no Velador. A ideia de automatizar o acompanhamento de processos de marca no INPI era boa no papel mas eu não escrevi código no primeiro dia. Conduzi discovery com escritórios de marca reais, gente que vivia a dor de controlar centenas de processos em planilhas e ler a RPI manualmente toda semana, sabendo que um despacho ignorado podia custar a marca de um cliente. Só depois de mergulhar nesse domínio jurídico complexo e traduzi-lo em algo simples e confiável é que recortei o MVP em torno do inegociável.

Esse recorte é parte do discovery, não do delivery. Ter coragem de cortar escopo é uma habilidade de descoberta: você só sabe o que é essencial depois de entender profundamente o problema. No Velador, o essencial era integração direta com o INPI, monitoramento automático da RPI e detecção de colisões. O resto podia esperar. E o produto deixou de ser ideia para virar empresa com clientes pagantes porque a fundação era o problema certo, não a feature mais bonita.

Minha forma de fazer discovery não nasceu pronta. Ela foi sendo lapidada em contextos bem diferentes.

Na Concert Technologies, ainda como Tech Lead e Scrum Master, conduzi processos de discovery com Design Thinking e Miro para entender de verdade as necessidades dos clientes antes de comprometer o time com uma solução. Foi ali que internalizei que descoberta é trabalho colaborativo e visual não um documento que alguém escreve sozinho e distribui.

Na eTrilhas, levei isso para a escala de produto contínuo: ciclos de feedback estruturados com usuários, parceiros e comunidades especializadas, usando iniciativas como o PCamp para validar oportunidades e fazer benchmarking. Aqui o discovery virou cultura orientada a dados e aprendizado funis, coortes, testes A/B, feature flags e instrumentação de eventos para validar hipóteses com evidência, não com opinião. Quando liderei o desenvolvimento do aplicativo oficial da Rede Brasileira de Trilhas, foi essa escuta de ecossistema que disse o que importava construir.

Dois contextos, a mesma raiz: descobrir é entender pessoas com método.

Independente da empresa, alguns princípios não mudam:

Outcome acima de output. A pergunta que guia a descoberta nunca é "o que vamos construir?", e sim "que resultado precisamos gerar?". Eu meço valor pelo que foi resolvido, não pelo que foi entregue. Por isso estruturo roadmap por outcome cada iniciativa precisa reduzir um trabalho manual, um risco ou uma fricção real.

Dados como linguagem, não como enfeite. Trato métricas como a forma de conversar sobre decisão: North Star, aquisição, conversão, retenção, satisfação. Mas dado sozinho não descobre nada ele aponta onde olhar. A descoberta acontece quando o número me leva de volta para a pessoa por trás dele.

Empatia é técnica, não suavidade. Lidero com empatia porque acredito que todo bom produto começa por entender de verdade as pessoas. Ouvir bem é uma competência de discovery tão dura quanto modelar um funil. Os melhores produtos nascem no equilíbrio entre o rigor dos dados e a sensibilidade humana.

Priorizar é decidir o que não fazer. Uso frameworks como RICE não para gerar um número mágico, mas para tornar a conversa de priorização honesta e rastreável. Discovery bom termina em foco, não em uma lista de desejos.

IA a serviço da descoberta. Levo IA para o núcleo do processo apoio à análise, geração de justificativas, automação do operacional para liberar tempo de pensar no que realmente importa: o problema.

Minha raiz de engenheiro me deu a fluência técnica para transformar estratégia em execução sem ruído. Mas foi o discovery que me ensinou para onde apontar essa execução.

No fim, abordar discovery, para mim, é uma forma de respeito: pelo tempo do time, pelo dinheiro de quem investe e, principalmente, pela pessoa que vai usar o que construímos. Produto que gera resultado mensurável nunca começa por uma feature. Começa por uma pergunta bem feita e pela disciplina de não desviar dela até entender a resposta.