Para ganhar confiança, devemos parar de redescobrir o problema

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.

The post Para ganhar confiança, devemos parar de redescobrir o problema first appeared on Gyaco.