Recentemente tivemos uma discussão interessante na Resultados Digitais sobre tomada de decisões. Basicamente a pergunta que estava na mesa era: existe alguma metodologia, framework ou whatever que garanta que um PM qualquer tome uma boa decisão em um timeframe adequado? Isso rendeu um bom tempo de discussão e a resposta curta é: não!
As táticas você consegue ensinar para alguém explicando o conceito por detrás delas, mostrando exemplos e etc. No contexto de gerenciamento de produto, em se falando de Problem Discovery e tomada de decisões, uma das táticas (frameworks) mais interessantes e simples que conheço é os dois tipos de decisões do Jeff Bezos. Ele basicamente fala que existem dois tipos de decisão, as do tipo 1 e as do tipo 2. As decisões do tipo 1 não são reversíveis e por isso elas precisam ser tomadas com muita cautela. Já as decisões de tipo 2 são reversíveis, ou seja, se algo der errado você sempre pode voltar atrás. Nesse último caso, o quanto antes a decisão for tomada melhor.
Diferentemente das táticas, fundamentos não são facilmente ensinados, basicamente a única forma de aprender é praticando indefinidamente. Não existe uma forma de aprender a chutar, nadar ou andar de bicicleta apenas com uma aula teórica. Para aprender um fundamento você precisa treinar muito, repetir o mesmo movimento inúmeras vezes e cada vez que você repete esse fundamento você fica um pouco melhor, mas nesse contexto existem duas certezas: 1) Você nunca vai ficar bom ao ponto de que não pode mais melhorar e 2) Você vai errar! E isso faz parte do aprendizado, se você tiver medo de cair da bicicleta você nunca vai aprender a andar direito! O mesmo vale para a tomada de decisões.
Isso tudo quer dizer que, na prática, não tem como um Product Manager aprender apenas na teoria como tomar uma boa decisão. É necessário que ele pratique isso exaustivamente e quanto mais experiente o PM for, melhores vão ser as decisões que ele vai tomar. Agora, algumas coisas influenciam na qualidade e na velocidade que essas decisões são tomadas. As principais estão relacionadas a se criar um ambiente onde o erro é tratado como uma oportunidade de aprendizado e não uma falha propriamente dita, a garantir que quando analisamos um problema nós estamos quebrando ele no menor problema possível (que gere valor para o cliente) e a se certificar que o PM tenha o contexto correto da decisão que ele precisa tomar, o que normalmente está associado a manter um PM (e o restante do time) um bom tempo em um mesmo contexto/time e você, como líder, fazer o seu dever de casa.
Um último insight sobre isso é com relação a escolha do problema mais prioritário. Muitos PMs travam na hora que chegam a uma lista onde você tem um grau de importância muito semelhante entre os problemas que você está escolhendo atacar (ou não entendem o que é um problema não estruturado e ficam estudando ele indefinidamente). Nesse contexto, a minha dica é: pare de tentar escolher o problema mais importante e escolha um deles, seguindo o seu instinto mesmo! Na prática todos os problemas dessa shortlist que você tem na mão são importantes e você provavelmente vai resolver todos eles mais cedo ou mais tarde, então muito possivelmente a ordem que você escolher não vai fazer muita diferença no resultado final. E, nesse caso, a pior decisão é não tomar nenhuma decisão, ou demorar muito para fazer isso. Get shit done!
