Tenho apresentado os “Equívocos do Discovery” em conferências de produto e em apresentações in-company em minhas clientes para ajudá-las a fazer o discovery de produto mais efetivo. Nessa talk falo sobre os 4 equívocos mais comuns que vejo times de produto cometerem:

• Equívoco #1: Achar que discovery é um processo. Não, discovery não é um proceso. É um conjunto de ferramentas de mitigação de risco e um mindset.
• Equívoco #2: Achar que é preciso fazer discovery de tudo. Não necessariamente. Exemplo: se for algo conhecido, questões regulatórias, necessidades urgentes.
• Equívoco #3: Achar que discovery é sobre entender o problema. Sim, mas Discovery é também sobre criar hipóteses de solução. Não fazer discovery de solução é a razão de falha de muitos produtos. Discovery de solução é onde a mágica da inovação acontece.
• Equívoco #4: Achar que engenharia deve focar no delivery. Engenharia é essencial no discovery de solução, trabalhando junto com Produtos e Design na criação e teste de hipóteses de solução para escolher a que trará resultados mais rápido.

Revisando meus artigos vi que não escrevi sobre o equívoco #4, então aqui vai!

Engenharia é muito mais do que foco em entrega

Em um cenário onde o “foco na entrega” costuma ser exaltado como principal indicador de sucesso, é fácil cair na armadilha de acreditar que o trabalho da engenharia se resume a transformar requisitos em código. Contudo, essa visão é limitada e pode frear a inovação. Ao entendermos que a engenharia é uma peça fundamental no processo de discovery, percebemos que seu papel vai muito além de “entregar” um produto pronto, trata-se de descobrir, testar e validar soluções, em conjunto com as áreas de Design e Produto.

A crença de que a engenharia deve concentrar-se apenas na entrega é comum em ambientes onde a pressão por resultados imediatos sobrepõe a necessidade de pensar profundamente na solução. Essa visão estreita ignora que, ao focar unicamente na execução, a equipe tende a repetir os mesmos padrões, sem explorar alternativas capazes de gerar resultados mais robustos e inovadores. Reduzir a engenharia a um mero executor impede que ela exerça sua expertise técnica desde o início, criando um ciclo de “entregar e corrigir” que raramente conduz à solução ideal.

Essa separação em que Design e Produtos foca em discovery enquanto Engenharia foca em Delivery vem dessa imagem:

Discovery e Delivery

Apesar de chamarmos de o trio essencial de um time de produto, com Design, Produtos e Engenharia, separamos suas responsabilidades com Design e Produto focados em discovery e Engenharia em delivery. Acontece que o foco de Design e Produto acaba ficando centrado no problema, em entender mais sobre o problema, sobre quem tem esse problema e qual a motivação para resolver esse problema. Aí surge uma ideia de solução que rapidamente é transformada em protótipo e requisitos que são passados para Engenharia fazer o Delivery.

Discovery de solução

Quando a engenharia é vista como parte integrante do discovery, ela se torna uma aliada estratégica na identificação e validação de hipóteses de solução. Em vez de esperar que as decisões estejam pré-definidas por Produto ou Design, as engenheiras podem contribuir com insights técnicos sobre novas abordagens possíveis graças à avanços tecnológicos e quais abordagens são viáveis e escaláveis

O verdadeiro ponto de mágica no processo de discovery acontece no Solution Discovery, quando Produto, Design e Engenharia trabalham juntos. Não basta apenas Produto e Design discutirem hipóteses e depois passarem para a engenharia como uma tarefa. A engenharia precisa estar envolvida desde o começo, trazendo a visão técnica, explorando possibilidades e, muitas vezes, propondo as soluções mais inovadoras.

O discovery de solução

O maior valor gerado pela Engenharia não está no delivery. Está no solution discovery. É nesse espaço de cocriação entre Produto, Design e Engenharia que surgem as soluções mais inovadoras, e é exatamente aí que a Engenharia precisa estar desde o início.

Discovery de solução é a parte mais divertido do trabalho do time de desenvolvimento de produto e, como mostrado na figura acima, deve ter participação igual de pessoas de Produto, Design e Engenharia. Não é necessário que todas as pessoas do time de Engenharia participem, mas importante ter pelo menos uma ou duas pessoas engenheiras junto com Produtos e Design criando e avaliando hipóteses de solução.

Exemplo Prático: App de Corretores da Lopes

Esse ponto fica claro com o exemplo do desenvolvimento do app para corretores na Lopes. Quando cheguei, o app estava sendo tratado como um “MVP”, mas já havia sete meses de desenvolvimento, algo que não condiz com o conceito de um MVP. Um MVP que já estava em desenvolvimento há sete meses, e que levaria um ano para ser entregue, perde totalmente o “M” de mínimo e o “V” de viável. A equipe passou cinco meses no discovery, expandindo o escopo ao identificar as diversas ações que o corretor precisava realizar, como:

• Consultar a base de dados para verificar ou cadastrar o cliente.
• Pesquisar imóveis similares para apresentar ao cliente.
• Desenhar uma área no mapa para delimitar onde buscar os imóveis.

Essas funcionalidades, embora úteis, desviaram o foco do problema central: garantir que o corretor recebesse o lead rapidamente para aumentar as chances de conversão. Esse foco diluído levou a um MVP que deveria levar um ano para ser entregue. A situação só mudou quando a engenharia fez uma pergunta fundamental: “Por que precisamos fazer um app para isso?”

A solução proposta pela engenharia foi simples e eficaz: em vez de um app complexo, eles sugeriram enviar notificações via SMS. Em apenas 10 dias, a solução foi implementada, permitindo que os corretores recebessem os leads instantaneamente. O que parecia ser um projeto de um ano foi resolvido em dias, graças à visão estratégica da engenharia durante o discovery.

Esse exemplo mostra como a engenharia é mais do que um agente de execução. Ela tem o poder de contribuir com soluções criativas e eficientes, antecipar riscos técnicos e evitar longos ciclos de desenvolvimento. Quando envolvemos a engenharia desde o início, conseguimos:

• Acelerar a inovação: A troca de ideias entre Produto, Design e Engenharia gera abordagens mais inovadoras e ágeis.
• Reduzir riscos: A antecipação de possíveis desafios técnicos evita surpresas desagradáveis no futuro.
• Economizar tempo e recursos: Validações rápidas e decisões bem-informadas garantem foco no que realmente importa.

Conclusão

Engenharia não deve ser vista apenas como responsável por entregar o que foi decidido por outros. Quando trabalhamos juntos, Produto, Design e Engenharia, fazemos um discovery mais poderoso e eficiente, focado em encontrar soluções viáveis e escaláveis que realmente geram impacto.

O verdadeiro valor da Engenharia está em sua capacidade de contribuir para o Solution Discovery e propor soluções que muitas vezes passam despercebidas por Produto e Design. Ao abandonar a visão limitada de “engenharia como entrega” e adotarmos uma abordagem colaborativa, conseguimos transformar desafios complexos em oportunidades reais de sucesso.

O exemplo da Lopes é só um entre muitos. Quando deixamos de tratar discovery e delivery como processos separados e passamos a encará-los como uma colaboração contínua, desbloqueamos o verdadeiro potencial das equipes de produto e, especialmente, da Engenharia.

Para quem tiver curiosidade de ver a talk sobre “Os Equívocos do Discovery”, ela está disponível aqui:

Treinamento e consultoria em gestão de produtos e transformação digital

Ajudo líderes de produto (CPOs, heads de produtos, CTOs, CEOs, tech founders, heads de transformação digital) a enfrentarem seus desafios e oportunidades de produtos digitais por meio de treinamentos e consultoria em gestão de produtos e transformação digital.

Gestão de produtos digitais

Você trabalha com produtos digitais? Quer saber mais sobre como gerenciar um produto digital para aumentar suas chances de sucesso, resolver os problemas do usuário e atingir os objetivos da empresa? Confira meu pacote de gerenciamento de produto digital com meus 4 livros, onde compartilho o que aprendi durante meus mais de 30 anos de experiência na criação e gerenciamento de produtos digitais. Se preferir, pode comprar os livros individualmente:

• Transformação digital e cultura de produto: Como colocar a tecnologia no centro da estratégia de sua empresa
• Liderança de produtos digitais: A ciência e a arte da gestão de times de produto.
• Gestão de produtos: Como aumentar as chances de sucesso do seu software.
• Guia da Startup: Como startups e empresas estabelecidas podem criar produtos de software rentáveis.