3 coisas que um Product Manager não deve fazer

Ser um Product Manager é chato. Muita gente acha que existe um glamour em ser a pessoa por trás do produto e é isso que seduz muita gente desavisada a se tornar um PM/PO. O ponto é: não existe só uma pessoa por trás de um produto, mas um time inteiro. Logo, alguns PMs insistem em cair na armadilha dos holofotes. Separei 3 coisas que na minha opinião, ajudam a esfolar a relação do PM com o resto da empresa:

  • Não tente construir algo que você acha correto;
  • Não esqueça de dar os créditos;
  • Não espere que o time execute cegamente suas ideias;

Não tente construir algo que você acha correto

É normal que um PM colha todos os dias opiniões e críticas sobre o produto de pessoas de diversas áreas. São pessoas com perspectivas e expectativas diferentes, que muitas vezes tem opiniões sobre uma parte do problema que as afetam todos os dias. Essa posição é bastante privilegiada, pois é como se você tivesse olhos em todos os lugares, tendo acesso a percepções diferentes, com uma visão panorâmica dos problemas que os usuários podem estar enfrentando. Um bom PM consegue compilar toda essa informação e usar a favor do produto. Contudo, se você se deixar levar, é como se toda essa massa de informação tivesse se originado de você. Logo, você se torna o dono da verdade e acha que tudo o que está escrito na sua User Story é a coisa correta a se fazer.

Provavelmente você deve trabalhar em um time misto, composto por designers, front-ends, back-ends, testers, BI/dados e marketing… todos eles, de alguma forma, lidam com o cliente. Embora uma das suas obrigações seja advogar pelos usuários, eles também tem esse papel, cada um da sua forma e ponto de vista. A “junção dos seus poderes” deveria refletir as necessidades e feedbacks do usuário. O bom PM ajuda o time a entregar o produto certo para os usuários, e muitas vezes isso significa entregar um resultado de que você não acha o ideal, mas que o time tem plena certeza da solução. Eu sei que isso dói na alma. É como se você estivesse perdendo poder, ficando com o ego ferido por achar que você deveria ser o responsável por todas as ideias executadas no produto… mas relaxa, não é bem por aí. Não tente construir algo que só você acha correto.

Não esqueça de dar os créditos

Se você levar ao pé da letra a observação anterior, muitas das ideias que serão implementadas no produto não serão suas. Não fique triste por isso, você não é o único responsável por ter boas ideias para o produto, você só é responsável pelo produto. Isso significa que você é responsável por validar se uma ideia é boa ou ruim e geralmente você não faz isso sozinho.

Designers, geralmente, tem ótimas ideias enquanto eles estão prototipando e investigando uma tarefa. Os stakeholders vivem tendo ideias, boas e ruins. Eu sei que rasga seu ego quando alguém, que não está ali na trincheira, que nunca conversou com qualquer usuário tem uma ótima ideia. Mas por mais que seu ego esteja dolorido, os créditos pela ideia, pelo seu bom desenho ou pela execução devem ser dados aos seus respectivos donos.

Outro dia que chorei por dentro porque um dos diretores, que não conhece nadica de nada sobre produtos propôs fazer um MVP. Ele estava extremamente correto naquele momento e eu me senti um lixo, porque a ideia de fazer um MVP deveria ter sido minha, do PM do produto. Mas caramba, que bom que ele teve essa ideia… :-)

Dar os créditos encoraja a colaboração do time. Geralmente eu tento dar sempre os créditos para o time e tento encorajar cada um dos integrantes a fazerem o mesmo. Se tudo der certo, uma boa ideia e uma execução impecável nunca virá apenas de um individuo, mas do coletivo. Isso também se aplica às más ideias e as execuções mal feitas.

Não espere que o time execute cegamente suas ideias

Uma das tarefas mais tediosas e mais importantes do PM é transcrever todas as ideias em um formato que o time consiga ler, entender e executar, que são resumidas nas famosas User Stories. Essas mesmas ideias devem ser apresentadas de uma maneira palatável para o C-Level, obviamente, não em formato de User Stories. Mas geralmente nós escrevemos essas histórias nos colocando no papel do cliente, seja interno ou externo, juntamente com todos os critérios que o time deverá executar ao pé da letra antes de dizer que a tarefa foi terminada.

Um time fraco executa as tarefas seguindo estritamente os critérios escritos, sem nem ao menos questionar o objetivo final daquela história. Um PM fraco não contextualiza o time sobre o problema de negócio ou do usuário que aquela história está resolvendo. Geralmente, antes de escrever uma User Story, eu faço um documento muito maior, onde contém não apenas a história, mas todo o contexto usado para defender aquela ideia perante os stakeholders e também perante o time.

O PM não deveria esperar que o time executará cegamente suas ideias, e o time deveria questionar o PM sobre as motivações para eles executarem aquela história. Não estou dizendo aqui que o time precisa ser convencido o tempo inteiro sobre cada tarefa. Em um ambiente onde o time é bem informado e entende a visão do produto e da empresa, as motivações por trás da história estarão claras desde de antes ela ser escrita e priorizada. E esse mesmo time sabe que o PM passou por um processo gigante de descoberta sobre a solução sugerida.

Concluindo

Esses três pontos parecem ser bem óbvios, mas eu vejo todos os dias pessoas quebrando a cabeça por causa deles. Fique atento aos sintomas. A confiança do time no PM diz muita coisa. A responsabilidade colocada no PM pelo C-Level diz muita coisa. A forma como o PM lida com esses problemas, diz o quanto ele está engajado e comprometido com o time, empresa e produto.

Para ler mais: