Opinião: As responsabilidades do PM estão distorcidas
Por vezes parece que ainda estamos nos anos 2000
Eu entrevistei mais de 50 PMs recentemente que estavam interessados em trabalhar com a gente aqui na Vindi. Na Vindi, nós temos um processo seletivo bem definido e em uma das etapas nós sempre perguntamos quais as responsabilidades que ele tem no seu trabalho atual. Depois de ter falado com tanta gente, comecei a notar padrões de certas distorções no papel que o PM exerce em cada uma dessas empresas.
Eu chamo de distorção porque na minha visão e na visão de muita gente do mercado por aí, o PM tem um papel muito bem definido, então fica fácil de saber o que um PM não faz. Uma das melhores definições que eu conheço é a do nosso querido Martinho (apesar de eu não concordar com quase tudo que ele fala)
"to discover a product that is valuable, usable and feasible" - Marty Cagan
Essa definição diz muito sobre as atribuições de um PM, pois quando falamos que um produto tem que gerar valor, estamos falando que ele deve melhorar de alguma forma a vida do usuário e só assim, só quando deixarmos os usuários mais felizes, com mais tempo, aliviados, menos estressados, é que de fato o negócio será impactado continuamente e ele vai nos dar o seu suado dinheirinho com gosto.
Quando falamos que o produto precisa ter boa usabilidade, estamos falando que não adianta o produto resolver a dor do usuário, mas eu ter que ter 245345345 pessoas tendo que ajudá-los a usar o produto porque ele é muito complexo. O impacto no negócio, nessas situações acaba sendo muito baixo porque o custo operacional vai nas alturas, sem contar que a satisfação será baixa no geral. Fica mais difícil manter o usuário com você se outra solução disponível também deixá-lo mais feliz e ser muito mais simples de usar.
E por último, quando falamos que ele deveria ser factível, estamos falando que com a velocidade que o mercado muda e que a tecnologia avança, se ficarmos 1 ano fazendo algo complexo, mesmo que com interações curtas, pode ser que quando a entregarmos o valor final, tudo já mudou e nossa solução não seja tão mais relevante, por isso o PM tem que ser capaz de conseguir encontrar soluções simples para problemas complexos.
Olhando para esses três pontos, fica claro quais são as responsabilidades de um PM e o quanto elas já são complicadas de atingir. Melhorar a vida do usuário a ponto de conseguir impactar o negócio, conseguindo isso da maneira mais simples e rápida possível, não sei vocês, mas eu já fico cansado só de ler! Por isso, quando alguém me fala na entrevista que é responsável pelas cerimônias do time, que muitas vezes é responsável pela gestão direta do time, que é gestor dos POs, que é gestor dos PMs (tirando se você for um GPM), que é também Scrum Master, que é PO e só tem a responsabilidade de escrever histórias e gerenciar backlog, eu fico pensando "What are you doing man?".
Essa última me deixa intrigado, pois tem empresa que contrata um profissional caro só para escrever histórias e gerenciar o backlog no dia a dia, como assim? Tem uma disfunção muito grande nessa estrutura de produto quando você precisa de um PO só pra fazer isso, simplesmente porque se você está tratando seu backlog como hipóteses e está rodando ciclos de experimentos curtos, dificilmente você vai gerenciar muitas histórias por semana no backlog. De 10 ideias que temos, geralmente 9 ou as 10 falham, então você vai estar mais invalidando ideias do que desenvolvendo, a não ser que a sua empresa esteja presa na armadilha de focar entregas mais que em resultados (uma analogia ao livro da Melissa Perri "Escaping the build trap").
No geral, se o PM não está passando a maior parte do seu tempo descobrindo como gerar valor para o usuário, tem alguma coisa errada. Ou o processo está mal definido ou a organização de produto está com problemas. Qualquer coisa diferente das três atribuições que falei acima, pegando emprestado a definição do Marty, na minha visão está subutilizando a capacidade de um PM. PM que é PM impacta o negócio e torna a vida do usuário melhor, "nada além disso", como se já fosse pouco né!
Referências:
