Muitas vezes, como times de produto, passamos mensagens contraditórias sem nem perceber. Nós pedimos para as outras áreas nos trazerem problemas ao invés de soluções. “Não nos digam o que fazer, nos digam o que está errado” é uma frase que qualquer product manager já falou ou pelo menos pensou.

Mas o que acontece quando realmente nos trazem problemas? Com muita frequência, respondemos com: “precisamos fazer um discovery”. E, em vez de focarmos em entender como podemos resolver aquele problema, começamos um discovery do próprio problema. Isso é um contrassenso.

O resultado disso? Frustração. De todos os lados.

O contrassenso do discovery

As stakeholders ficam impacientes. “Mas eu já sei qual é o problema! Por que vocês precisam de meses para descobrir algo que já está claro?” É uma pergunta comum e, sejamos honestos, justa. Afinal, nós pedimos para elas confiarem em nossa forma de trabalhar. Pedimos que nos tragam problemas e, quando fazem isso, parecemos questionar a validade do que foi trazido.

Esse comportamento não é apenas ineficiente; ele mina a confiança que queremos construir com as outras áreas.

O que devemos fazer diferente?

Quando uma stakeholder nos traz um problema, precisamos mostrar confiança. Se pedimos que nos tragam problemas, precisamos honrar essa promessa aceitando o ponto de partida e focando em fazer o discovery da solução.

Isso não significa ignorar a possibilidade de que o problema possa estar mal definido. Significa, sim, que o ponto inicial é a confiança no que foi trazido. Se, durante o discovery da solução, surgirem dúvidas sobre a definição do problema, voltamos à origem: conversamos novamente com a stakeholder. Se ela não souber esclarecer, falamos com a cliente diretamente.

O que isso muda na prática?

1. Confiança inicial: Quando recebemos um problema, partimos do princípio de que ele está bem definido e focamos nossas energias em entender como resolvê-lo.
2. Feedback contínuo: Se, durante o discovery de solução, percebemos que algo não está bem esclarecido, voltamos para quem trouxe o problema. Isso cria uma dinâmica de parceria em vez de resistência.
3. Velocidade e foco: Ao não perder tempo “redescobrindo” o problema, aceleramos o discovery da solução e entregamos valor mais rapidamente.

Um exemplo prático

Digamos que o time de Suporte ao Cliente traga o seguinte problema: “Estamos recebendo muitas reclamações de clientes que não conseguem finalizar o cadastro na plataforma.”

O que muitos times de produto fariam nesse ponto é iniciar um discovery para validar se o processo de cadastro realmente é o problema. Isso pode envolver entrevistas, análise de dados e outras atividades que podem levar semanas, senão meses.

Em vez disso, deveríamos assumir que o problema é real e começar a explorar soluções: como podemos simplificar o onboarding? Quais são as principais dores nesse processo? Que melhorias podemos testar rapidamente?

Se durante esse processo percebemos que há dúvidas sobre a natureza do problema, paramos, voltamos para o time de suporte e perguntamos: “Vocês conseguem nos explicar melhor essa parte? Se não, vamos falar com alguns clientes para entender isso a fundo.”

Não é sobre pular etapas; é sobre focar no resultado

Aqui estão mais alguns exemplos de problemas que stakeholders podem trazer:

• O time de Suporte ao Cliente pode relatar um aumento de reclamações sobre atrasos na entrega de pedidos.
• Dados podem mostrar que muitos usuários estão abandonando uma etapa crítica durante o checkout.
• Operações podem identificar gargalos que atrasam processos internos.

Esses exemplos ajudam a ilustrar que, quando as áreas trazem problemas claros, nós precisamos confiar na validade do problema e focar em buscar soluções eficientes.

Discovery é uma parte fundamental do desenvolvimento de produto. Mas precisamos ser mais criteriosos sobre onde e quando focar no discovery do problema ou quando trabalhar diretamente em hipóteses de solução. Fazer discovery do problema quando ele já foi claramente trazido pelas stakeholders é desperdiçar tempo e minar a confiança.

Ao mostrar que sabemos lidar com problemas trazidos pelas outras áreas e focar em fazer um discovery de solução, construímos uma relação de parceria verdadeira. Nós pedimos problemas, então é hora de mostrar que sabemos resolvê-los.

Confiança não se constrói apenas pedindo; ela se constrói entregando resultados.

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.