Product Oversee

Nomes estranhos e progressão de carreira de um PM

Entender onde está e como evoluir é o mais importante

Imagem de destaque de Nomes estranhos e progressão de carreira de um PM

Para falar sobre carreira, gostaria que você tentasse abstrair um pouco os nomes dos cargos e níveis que são usados no mercado. Não existe um padrão claro e você vai encontrar nomes diferentes para as mesmas responsabilidades em empresas diferentes. Não se preocupar em primeiro lugar com o nome do cargo, mas sim nas responsabilidades exercidas é um sinal de maturidade que é raro encontrar nesse mundo, e no mercado de produtos não seria diferente.

Um resumo básico das nomenclaturas que você pode encontrar no mercado são:

  • APM (Associated Product Manager): Muito comum em startups da moda. É um nome para Product Manager Junior. Essa pessoa fica mais próxima do time, geralmente exercendo muito o papel tático, o que um PO faria, contudo, é importante que comece a aprender bastante sobre o mercado e o negócio, já que um PM deve ter um olhar tático e estratégico.
  • Product Manager: Um PM comum. Ele pode ou não cuidar de um APM. Depende do tamanho da empresa e quantidade de pessoas. Mas o PM basicamente é o responsável pela visão do produto, entendimento de mercado, alinhamento de necessidades do usuário e expectativas do negócio. Num mundo perfeito, existiriam só PM Junior, PM Pleno, PM Sênior. Mas, sabe como é, precisamos de faixas salariais diferenciadas para justificar investimentos, desenvolvimento profissional e etc. então, as outras camadas devem existir.
  • Head de Produtos: A responsabilidade de um Head de Produtos, no início, era cuidar apenas de Product Managers. Depois evoluiu para cuidar de PMs e Designers. Mas hoje, é muito comum encontrar Heads (meu caso), que lideram todas as especialidades que participam da construção de um Produto, liderando Tecnologia, Design e PMs. Diferente do GPM, que lidera grupos de gestores de Produto, não envolvendo as outras especialidades.
  • GPM (Group Product Manager): Líder de um grupo de Product Managers. Não cuida do produto diretamente, geralmente está mais perto da estratégia, mas seu foco é organização, evolução e desenvolvimento das pessoas (no caso os PMs liderados) e direcionamento de produto. Nesse caso ele não lidera ninguém de tecnologia e muito raramente lidera designers. Diferente do Head de Produtos.
  • CPO (Chief Product Office ou Diretor de Produtos): C-Level ou Diretoria. Em algumas empresas são dois cargos diferentes. Em outras, o Diretor reporta para o C-Level. Nem sempre eles lideram Tecnologia, que é delegado para o Diretor de Tecnologia ou CTO. Na maioria da vezes, o CPO/Diretor de Produtos lideram o time de Design e o de Produtos, mas podem liderar times de tecnologia. Contudo, existem empresas que não há um CPO, mas o CTO faz o papel idêntico do CPO.

É muito difícil dizer que há um processo linear de progressão, pois isso vai depender muito da estrutura e do fundamento hierárquico da empresa. Mas uma coisa é certa: quanto maior o cargo, maior o impacto no negócio, mais afastado da parte tática do produto, maior impacto no processo e na cultura, menor impacto na evolução direta das pessoas dos times, maior necessidade de alinhamento dos gestores, maior necessidade de delegação de decisões técnicas.

Embora o Diretor / CPO tenham responsabilidades e escopos mais focados no estratégico e no negócio, isso não quer dizer que eles pararam de cuidar do time, pelo contrário: eles não estão no dia a dia trabalhando no tático, decidindo processos por exemplo, mas eles influenciam o time viabilizando decisões, motivando e fornecendo visibilidade sobre o negócio e a estratégia da empresa e direcionando as decisões. Guardando as devidas proporções, isso acontece com todos os níveis.

Dando um exemplo bastante pessoal, foi bem importante eu construir uma carreira diversificada. Eu fui desenvolvedor, fui coordenador de times técnicos, fui Product Manager, fui Diretor e Head. Por exemplo: ser desenvolvedor me ajudou muito como PM para entender qual o timing certo de priorização de débitos técnicos, saber quando uma estimativa estava sub ou superestimada, entender qual impacto técnico de uma história de usuário e também saber como funciona processos. Isso me ajudou também a liderar times técnicos, inclusive quando eu fui Diretor, onde havia um gerente de tecnologia liderando times técnicos multidisciplinares.

Ter sido PM, me ajudou a entender como eu posso liderá-los e entender quais as dores e bloqueios que eles podem encontrar ao tentar se relacionar outras áreas, ao tentar ganhar influência com o time de desenvolvimento e também para tentar analisar o mercado. Sem ter sido PM, não daria para virar Diretor ou Head. Seria um caminho bem mais difícil.

Esse assunto vai longe, podemos falar mais sobre ele em outras Letters.\