Para dar início aos trabalhos, na minha opinião a resposta pra pergunta é NÃO. Um PM não deve ser líder do time de desenvolvimento, de UX ou quaisquer outros papéis que estejam sendo praticados dentro da Squad. Se a pergunta fosse “PMs podem liderar times de desenvolvimento?”, a resposta seria diferente, pois o verbo poder nos traz uma gama de possibilidades, e como eu já vi esse cenário acontecendo, eu diria que, os PMs podem sim liderar, mas não deveriam.
Qual é o Job Description de um Product Manager?
Segundo Marty Cagan no artigo publicado no SVGP, “o Product Manager contribui com o time de produto, com um conhecimento sólido sobre as regras do negócio, por exemplo, marketing, vendas, serviços, finanças, leis e privacidade. Contribui também com um conhecimento profundo sobre usuários e clientes, dados de engajamento. Finalmente, o PM deve acompanhar as tendências do setor e o cenário competitivo no que se refere ao produto.”
Em resumo, um Product Manager, como o próprio nome do cargo diz, gerencia um produto e tudo o que tem relação a ele, mas não gerencia pessoas.
Um Product Manager que gerencia pessoas tem mais uma função no seu dia-a-dia que vai concorrer em tempo com a gestão do próprio produto, o que DEVE ser a prioridade dele.
Além disso, existem outros problemas que podem ser causados quando um PM lidera o time de produto, os quais serão explorados a seguir.
Os times de Produto
Os times de produto são também conhecidos como “Squads” de acordo com o modelo abaixo, utilizado por muitas empresas para organização de times. O modelo proposto foi publicado neste vídeo, pelo Henrik Kinberg.
Nesse artigo, o Joca Torres explica com detalhes como eles funcionam. Normalmente, o time é formado por Product Manager, Product Design e Engenheiros de Software, porém, dependendo do tamanho da organização, do tipo de produto, da quantidade de recursos que a organização possui, esses times podem ter vários papéis associados, especializando funções que muitas vezes estão concentradas nesses três papéis iniciais.
Esses times de produto, podem ser organizados de acordo com objetivos específicos, que variam bastante, mas pode ser por: produto, funcionalidade, usuário, jornada, objetivo ou até times mesclados.
Os times são assim organizados, de forma multidisciplinar, pois a visão e a contribuição de cada um dos papéis tende a tornar as decisões tomadas sobre o produto mais corretas e abrangentes, pois cada papel em sua especialidade saberá opinar, confrontar e apoiar em cada etapa do Discovery e do Delivery.
Os riscos e o papel do time de produto
Segundo Marty Cagan, o processo de desenvolvimento de produtos digitais envolve 4 grandes riscos, conforme descrito aqui.
- Risco de Valor: os clientes vão comprar ou usar o produto?
- Risco de Usabilidade: os clientes saberão como utilizar esse produto?
- Risco de Viabilidade: os engenheiros conseguirão construir com o tempo, habilidade e tecnologia que possui?
- Risco de Viabilidade de Negócio: essa solução também atenderá aos vários aspectos do negócio?
Se for analisar os quatro riscos, e os três papéis que temos dentro de um time de produto com especialistas, nenhum dos três papéis saberá medir sozinho se os quatro riscos estão cobertos na construção do produto. Um PM saberá medir risco de valor e viabilidade de negócio, mas não é o especialista para responder usabilidade e viabilidade. O Product Designer saberá medir melhor a Usabilidade do Produto e o Engenheiro a Viabilidade.
A dinâmica dos três poderes
Com isso, os três papéis funcionam como três poderes dentro do time de produtos, cada um fazendo as suas ponderações e cumprindo com o seu papel na análise da construção do produto.
Fazendo uma comparação com o que é aplicado em um sistema democrático, Montesquieu criou um sistema de Separação dos Três Poderes: Judiciário, Executivo e Legislativo.
Os três poderes funcionam muito bem juntos, e da mesma forma, um pode anular o papel do outro, como se fosse um jogo de “pedra, papel e tesoura”.
Com isso, nenhum dos três poderes consegue funcionar sozinho, nem aprovar nada sozinho, pois precisará do apoio dos outros dois poderes. Isso diminui muito o risco de algo ser feito errado.
Da mesma forma, um PM, um PD e um Engenheiro, com opiniões sólidas e cientes de suas habilidades e responsabilidades, poderão decidir da melhor forma e em conjunto o que fazer com o produto. Eles devem ser vistos como pares, um não se sobrepondo ao outro.
Motivos para um PM não liderar o time de desenvolvimento
Diante do exposto até aqui, eu coloco três pontos essenciais para que um PM não lidere o time de desenvolvimento:
- O PM tem por responsabilidade gerenciar o produto e não pessoas. São diversas as variáveis que um PM deve considerar na hora de gerenciar o produto, e por mais que muitas vezes exerça um papel de liderança dentro do time, visto o conhecimento do mercado e do produto, o PM não gerencia pessoas, isso é o papel de um Team Leader ou CTO.
- A dinâmica dos três poderes acaba sendo quebrada quando um PM exerce liderança sobre outro poder. Um PM líder, pode influenciar a tomada de decisão de viabilidade sobre uma feature, ou começar a misturar demais o que é produto para o mercado e o que é análise técnica de uma ferramenta, ou seja, o “porquê” e o “como” se tornam muito próximos.
- O PM precisa olhar pro mercado, muito mais do que para o desenvolvimento das features, ou seja, olhar muito mais para Research e Discovery do que para o Delivery. Isso permite que pelo menos um dos três papéis esteja atento ao mercado, sem dividir as atenções com as linhas de código que estão entrando no produto.
CTO, CPO e Product Lead
Quando falo que um PM não deve gerenciar o time de desenvolvimento, eu estou falando especificamente do PM, aquele que gerencia o produto, dentro da Squad.
Isso não se aplica a papéis de gestão específicos como o CTO, o CPO ou até ao Product Lead.
Esses papéis são de liderança, então, na minha opinião, podem sim ter um olhar sobre mais de um dos três papéis do time de produto, sem influenciar nos três pontos que coloquei como importantes para que um PM não lidere o time de desenvolvimento.
Dependendo da situação da empresa, ou do perfil de quem está em um desses três papéis, é até interessante que a visão seja aplicada ao todo e não apenas a uma parte do processo.
Conclusão
O assunto é complexo, e abre muita margem para discussão.
Ao contrário do que expus, existem cenários em determinadas empresas, os papéis vão sendo encaixados com o tempo, utilizando pessoas que estão a disposição. Um PM com características de liderança (ou em alguns cenários nem isso), pode estar sendo encaixado para gerenciar um time de engenharia pois é o que os recursos da empresa e o cenário atual comportam. Pode funcionar, e no fim, pode dar muito certo mesmo assim.
Porém, na minha opinião, existem riscos grandes em trabalhar com esse método, e portanto eu não indico. O PM deve se preocupar com o produto e não com a gestão de pessoas.
