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. O ponto é: não existe só uma pessoa por trás de um produto, mas um time inteiro. Logo, alguns PMs insistem em cair nas armadilhas da vida. 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 áreas de diferentes. 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 é privilegiada porque é como se você tivesse olhos em todos os lugares, recebendo percepções diferentes e tendo uma visão panorâmica dos problemas que os usuários podem estar passando. Um bom PM consegue compilar toda essa informação e usar a favor do produto, que aliás, essa é uma das obrigações do PM. 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 que diferença do bom e do mal PM, é conseguir ajudar 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. Além disso, você também é 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 rasgado, os créditos pela ideia, pelo seu bom desenho e 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 produtos propôs fazer um MVP. Ele estava extremamente correto naquele momento e eu me senti um lixo, porque fazer um MVP faz parte do dia a dia do produto. Eu deveria ter dado aquela ideia e não ele. 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 ideia 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. 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.