Quando todo mundo entende o problema
Como criar as condições para que o time inteiro entenda o problema profundamente o suficiente para tomar decisões melhores.
Como criar as condições para que o time inteiro entenda o problema profundamente o suficiente para tomar decisões melhores.
Dá para fazer tudo o que costuma ser considerado um bom discovery e ainda assim tomar decisões ruins. Fazer entrevistas toda semana, manter a OST atualizada, ter uma boa cadência de trabalho. Nada disso garante que o time está entendendo o problema certo. Já vi times muito disciplinados em discovery chegarem a soluções pouco relevantes. Com o tempo, comecei a perceber que isso acontece quando o processo vira o foco principal. A equipe continua executando todas as etapas, mas para de questionar algumas premissas básicas.
Nos times que mais me marcaram, a diferença não estava na quantidade de rituais ou artefatos, e sim no quanto as pessoas entendiam o contexto por trás das decisões. O engenheiro conseguia olhar para uma ideia e perceber algo estranho antes dela ser construída, o designer levantava dúvidas sobre uma solução antes mesmo de começar a prototipar. E essas atitudes nasciam do alto contexto que eles estavam inseridos, contexto esse, que obviamente não nascia sozinho.
Uma das coisas que mais me ajudou foi incluir o trio de produtos (PM, designer, engenharia) em algumas entrevistas com usuários sempre que a conversa tinha potencial para influenciar decisões importantes.
O que acontecia era que cada pessoa saía da mesma entrevista com observações diferentes. O engenheiro prestava atenção em detalhes operacionais que eu talvez ignorasse, o designer captava comportamentos e expectativas que passariam despercebidos para mim. E quando a conversa acabava, a discussão era muito mais rica do que qualquer repasse que eu pudesse fazer depois.
Lembro de um caso envolvendo um filtro de datas em um dashboard.
A ideia parecia simples: dar liberdade para que o usuário escolhesse qualquer período que quisesse analisar.
Durante uma entrevista, o engenheiro que estava participando comentou uma coisa que mudou nossa leitura do problema. O usuário não falava em datas específicas. Ele falava em períodos. Últimos 7 dias. Últimos 30 dias. Últimos 90 dias. Era assim que ele organizava o trabalho.
A partir dali, a solução mudou.
A experiência ficou mais simples para o usuário e, por consequência, evitamos um problema técnico que ainda nem tinha aparecido, mas que já estava na cabeça do engenheiro. Nossa arquitetura provavelmente sofreria se começássemos a permitir consultas muito extensas.
Nenhuma dessas coisas tinha surgido nos refinamentos anteriores.
Outro aprendizado veio das próprias entrevistas.
No começo da minha carreira, eu fazia muitas perguntas sobre opinião. O que você acha disso? Você usaria essa funcionalidade? O que te incomoda no produto?
As respostas quase sempre pareciam úteis na hora, mas raramente ajudavam a tomar decisões melhores depois.
Com o tempo, comecei a pedir exemplos concretos. Em vez de perguntar o que incomodava alguém, eu perguntava quando tinha sido a última vez que aquela pessoa enfrentou um problema usando o produto. Em vez de perguntar o que ela faria no futuro, tentava entender o que ela já tinha feito.
A diferença nas respostas era enorme.
As pessoas costumam ser muito melhores em relatar comportamentos do que em prever comportamentos.
A Opportunity Solution Tree acabou entrando como uma forma de organizar essas conversas e manter o time alinhado ao longo do tempo.
Normalmente eu começava com um outcome vindo das discussões com liderança e, a partir daí, a árvore ia sendo construída junto com o trio. Qualquer pessoa podia trazer uma oportunidade para discussão, e os encontros serviam para explorar essas oportunidades antes de falar sobre solução.
A OST ficava visível para todo o time.
Nunca funcionou bem para mim quando era tratada como um documento do PM. Ela sempre fez mais sentido quando servia como um espaço compartilhado para organizar o que estávamos aprendendo.
Hoje, quando penso nos melhores times com que trabalhei, as memórias mais vívidas não são de processos, e sim das conversas, das pessoas que entendiam o problema profundamente o suficiente para discordar, complementar e perceber algo que os outros ainda não tinham visto.
Talvez seja isso que mais importa: criar condições para que esse entendimento seja compartilhado pelo time. Porque quando todo mundo entende o problema, as decisões costumam ficar melhores quase como consequência.