Progressão de carreira de Produto Managers

Mapeando os caminhos que product managers fazem em sua carreira. Cargos e responsabilidades.

Minha percepção é que as profissões dentro do mercado de tecnologia evoluem muito mais rápido do que outras. Existem várias hipóteses para justificar isso, como evolução rápida da stack tecnológica e dos métodos e processos utilizados no mercado. Só isso já faz com que os profissionais precisem se atualizar numa velocidade maior que em outros mercados.

A quebra em especializações é outro fator bem interessante que acontece com essas profissões. Se você percebe, todas as especialidades começaram aglutinando responsabilidades, depois tiveram alguns níveis de amadurecimento que criaram divisões e quebras de responsabilidades. Em alguns casos essa quebra faz sentido e foi bem benéfica, em outros casos, na minha opinião, prejudicou mais do que ajudou.

Um dos exemplos benéficos é da área de programação. No início só existiam programadores e pronto. Não quero pegar a timeline histórica muito longa, mas antes só existiam programadores. Geralmente desenvolvedores de software offline ou de hardware. Com a vinda de novas tecnologias como a internet e depois a web, a gente viu os programadores web surgirem.

Ainda no início eram só programadores, mas logo depois uma quebra surgiu, criando programadores back-end, depois front-end. E nessa também alguns já foram para área de arquitetura e infraestrutura. Hoje, programação está em toda parte que faz sentido. Mas não surgiu nenhum tipo de programador que só aperta um tipo de parafuso ou que faz só uma parte muito específica do processo que não pudesse ser feita dentro de um contexto completo. O que não é o caso de design.

Design, para mim, é o exemplo que não houve tantos benefícios. Houve uma linha muito parecida com os programadores. No início eram designers "offline" por assim dizer. Arquitetos entram nessa também. Tudo muito atrelado ao mundo físico. Mesmo aqueles que trabalham com design gráfico. Se você separar por contextos, essas quebras fazem muito sentido.

Quando a web veio, ainda continuou fazendo sentido com os designers dominando e controlando todo processo de design, desde sua descoberta, planejamento, aplicação, manutenção e evolução. Num passado recente isso se quebra em diversas micro-partes, onde seus contextos muito pequenos. Eu entendo que em alguns momentos existem necessidades de execuções muito específicas... mas o problema é que o mercado transformou disciplinas em contextos de execução. Isso vale para research, vale para writing e outros. Hoje, há um movimento de aglutinação dessas especialidades de novo, criando novamente um designer que entende do processo como um todo e sabe se adaptar à necessidade de cada projeto. Mas, esse é um assunto espinhoso, que nem todo mundo gosta de discutir com maturidade. Deixo para próxima.

Essa evolução de maturidade também aconteceu com Gestão. E nem quero me alongar muito, puxando o histórico lá de trás com nomes como Taylor. Quero começar a discussão a partir de agora, da nossa vida mais conhecida e recente. A Gestão de Projetos evoluiu e sofreu disrupções interessantes até chegarmos onde estamos agora.

A gestão de projeto se quebra

Quando falamos sobre gestão de projetos, nós imaginamos ao famoso PMO, Project Management Office, que tinha como principal função garantir que o projeto fosse entregue dentro do tempo, com o escopo pedido e sem furar o budget. Para garantir isso, métodos e frameworks de processos são aplicados e uma série de rotinas de report são feitos para garantir que todos estão alinhados quanto aos principais pontos do projeto.

Logo, quem gere projetos precisa ter uma visão clara sobre processos. Isso não quer dizer que se aplica apenas a software, pelo contrário. Se você pega a história do PMI (Project Management Institute), você vai ver que eles fizeram um aeroporto. Eles participaram do programa Apollo. Eles participaram da criação do primeiro celular feito pela Nokia. Hoje a galera de produtos torce a boca quando fala sobre gestão de projetos, desdenhando de uma especialidade que eles não sabem fazer.

Gestão de produtos é uma derivação (não encaro como evolução) da gestão de projeto. Muitos PMs e líderes de produto não sabem gerir projetos, ou por falta de oportunidade, ou por que migraram de outras áreas, onde essa habilidade não era necessária. Talvez essa seja uma grande causa da síndrome da não entrega. Falta organização e processo. Mas essa é outra história.

Com a vinda da internet e da web, a popularização do smartphone, a evolução da Web 2 e todas as alavancas que fizeram as pessoas ficarem cada vez mais conectadas e viciadas em software, fez com que essa profissão também amadurecesse. A gestão de software é complexa, porque faz parte de um ambiente complexo. Embora construir prédios seja perigoso e pode acontecer uma série de problemas durante o caminho, há um processo bem estabelecido que traz alta previsibilidade da entrega atrelada a alta qualidade. Isso por que embora sejam projetos grandiosos, são projetos que rodam na sua maioria das vezes na camada complicada. Diferente da camada de software, que geralmente está na camada complexa.

A construção e desenvolvimento de software roda na camada complexa e caótica. Nosso esforço em gestão de produtos e gestão técnica é uma vigília constante para diminuir incertezas para tentar posicionar e manter o nosso produto na camada complicada. E muita gente se perde nesse ponto.

Diferente de uma construção de prédio que o trabalho vai ficando progressivamente mais "simples" conforme as partes são construídas, o software vai ficando cada vez mais complexo. E isso se potencializa quando há pessoas usando.

https://www.agilemindshift.com/blog/complexity-levels-closed-systems

É aí que entram as metodologias ágeis. E quando as metodologias ágeis chegam, a gestão de projetos se quebra. Por que se antes a gestão de projeto cuidava da liderança do projeto cuidava da garantia de que as coisas fossem entregues no escopo, data e budget, agora ela precisa sustentar a continuidade das entregas, então, o budget que tinha um limite claramente estabelecido no projeto, agora precisa ter uma visão mais conectada à sustentação financeira do negócio. Não que o dinheiro é infinito, porque não é, vide os layoffs que temos ultimamente, mas é que nessa visão de produto, a sustentação da continuidade para geração de resultado é mais importante que a finalização do projeto.

O Impacto do Agile

Então, com a vinda do Agile, uma visão maior e estrutura de processo de entrega sustentada, com eficiência e qualidade, com frequência de entregas constantes, se criou na maneira com que criamos produto.

Acontece que há um outro lado da gestão que não envolve apenas processos e métodos, mas geração de valor. A gestão de projeto tinha em mente a geração de valor para o negócio por meio da entrega do projeto. O único problema com isso, é que atualmente, projetos baseados em comportamento de usuário, que procuram entregar valor constante para seus usuários, não tem fim. E se não tem fim, cria-se um ciclo de entrega constante de valor para o usuário, que se reflete com valor no negócio. Então, não dá para entregar o projeto e pronto, tem que entregar, aprender, evoluir, testar e monitorar, para construir e entregar de novo. Daí que vem o Dual Track Agile Discovery Delivery Cicle Hiper Blaster Master Beta Gama que todo mundo fala.

Dual Track Development is not Duel Track – We help you create successful product culture and process - https://jpattonassociates.com/dual-track-development/

A derivação para a gestão de produto

E quando esse ciclo acontece, a gestão de produto surge. Porque o trabalho de priorização que acontece na gestão de projetos tradicional, se torna um trabalho contínuo, então, a fase de entrega final não acontece. E essa gestão contínua, procurando a eficácia e a diminuição de incertezas, tentando posicionar e manter o software na camada "complicada", evitando que ele entre na área "complexa", enquanto gera valor pro negócio por meio da geração de valor para o usuário.

Então, a gestão de projeto, na verdade, não morreu. Existem ainda projetos que acontecem cross empresa, que precisam de pessoas que façam a costura entre todas as áreas, inclusive a área de produtos, trazendo para mais perto de um objetivo comum. Isso nunca vai ter fim e o pensamento de gestão de produto não se encaixa nesse caso.

E a gestão de produto entra como uma vertente desse tipo de gestão. Gestão de produtos precisa fazer gestão de projetos. Cada feature, cada entrega, cada previsão, roadmap, expectativa, é uma prática de gestão, que migrou da gestão de projeto.

Quando falamos sobre a entrega continuada de valor, nós precisamos definir o contexto de impacto de cada uma das fases e níveis de maturidade de um profissional de produto.

Nomenclatura, cargos e contextos de impactos

Participar do contexto do seu nível de experiência faz parte da evolução da maturidade nessa profissão (e também de qualquer outra). Entender o contexto que você está inserido, também ajuda a não se preocupar com alçadas que você não controla. Isso quer dizer menos desperdício de energia, menos frustração, mais tempo para fazer seu trabalho com qualidade.

Muita gente que entra na área fica preocupada com a sua atuação com um anseio de querer atuar em contextos maiores, mais "importantes". Existe uma percepção errada no mercado de que quanto mais próximo do negócio e do topo da pirâmide, mais importante e mais sucesso você tem. Esse é outro assunto, mas minha opinião sobre isso é que você precisa encontrar o equilíbrio entre conforto, evolução, dinheiro e saúde. Você precisa saber o que é suficiente para você.

https://miro.com/app/board/uXjVM85WecU=/?moveToWidget=3458764557689099810&cot=14

Quando somos APM, ou seja, acabamos de chegar nesse mercado, seja migrando de outro mercado ou começando do zero, nosso contexto é muito mais controlado. Não precisamos nos preocupar com o mercado, nem precisamos nos preocupar com o posicionamento do produto, nem precisamos saber para que lado o negócio está se direcionando. Obviamente os ótimos futuros PMs vão querer saber dessas coisas. Mas numa posição de APMs, você não conseguirá (nem poderá) atuar em nenhuma dessas esferas. O impacto será nulo. Mas o seu impacto no time vai ser enorme e será percebido.

Diferente do CPO, que está numa visão muito mais ampla, com impacto numa camada bem mais genérica, que impacta diretamente o negócio, com o board e outras mesas mais "pesadas", que tomam decisões responsáveis por posicionar e direcionar o bloco na totalidade, não uma parte específica. Isso quer dizer que o CPO não deveria decidir o que o APM está fazendo, e vice-versa. Nenhum dos dois tem controle total nessas esferas. Obviamente, uma decisão do CPO pode influenciar o trabalho do APM, mas isso por que o movimento do grupo todo vai com certeza influência a natureza e os resultados esperados da empresa.

Progressão e carreira Y

A progressão de carreira de gestão de produto teve um avanço gigante nos últimos anos. Antes você começava como PM Jr e terminava como PM Sênior, depois podia passar para Head e Diretor. Terminava assim.

https://miro.com/app/board/uXjVM85WecU=/?moveToWidget=3458764557689099811&cot=14

No início, PMs não realizavam gestão de pessoas. Mas isso só ocorreu num pequeno espaço de tempo, exatamente devido à maturidade do mercado e da profissão. Era difícil ver empresas com um grande número de PMs, então, todo mundo reportava uma pessoa, seja head, seja diretor. PMs eram a primeira ponta.

Com a maturidade do mercado e da profissão, e com a importância dessa cadeira para as empresas, a densidade de PMs nas empresas aumentou. Então, cuidar de pessoas começou a fazer parte da trilha de progressão de carreira.

Dessa forma, um nível chamado Group Product Manager foi criado, para conseguir adequar a visão de gestão de pessoas. Então, começou a ser comum Heads fazerem a liderança de GPMs, que por sua vez fazem a gestão de PMs, que em algum momento podem ou não fazer gestão de APMs.

https://miro.com/app/board/uXjVM85WecU=/?moveToWidget=3458764557689099831&cot=14

Mas veja bem: desde o início o PM já era uma cadeira "especialista", por assim dizer. Não havia gestão de pessoas até pouco tempo e era responsável por resolver problemas específicos.

Entretanto, me parece que gerir pessoas virou o padrão de mercado, o que não agrada parte das pessoas, obviamente. Contudo, temos agora um contexto onde o PM se torna novamente um individual contributor, focado em grandes problemas que estejam mais conectados com a sustentação e evolução do negócio. É o que o mercado está chamando de Principal PM.

Principal PM não faz gestão de outras pessoas, é como se fosse uma referência de negócio e gestão de produto no grupo. Essa pessoa precisa ter um profundo conhecimento da empresa, do negócio e do mercado na qual estamos atuando. Além disso, é imprescindível que essa pessoa tenha entenda com muitos detalhes como outras áreas da empresa trabalham nesse mercado. Obviamente, nem preciso comentar sobre habilidade em produto, principalmente em Product Sense e Product Execution.

O Principal PM é aquele individuo que será escolhido pela empresa, por exemplo, para morar em outro país quando o objetivo é internacionalização. É aquele PM que será selecionado para ajudar a empresa a entrar em um mercado transformacional. Por isso, não pode ser uma pessoa que conhece pouco da empresa e do mercado que estamos atuando.

PMs especialistas

PMs são generalistas em um mundo cercado por especialistas. Ele se relaciona com pessoas que fazem partes de times especialistas em suas áreas como Marketing, Dados, Design, Desenvolvimento, Vendas... Por isso, é um processo constante de absorção de informação de todas as linhas de execução da empresa. Isso é bastante importante saber para quem está começando: se você não se sente útil quando você não tem o controle de executar o que realmente trará o resultado e a realização da solução do problema, pense duas vezes antes de trabalhar nesse mercado.

Eu passei por um momento de dúvida pessoal. Sabe aquele pensamento de não estar encaixado em uma tribo? Pois é. Até que um dia eu me assumi generalista. Eu entendi que pessoas generalistas conseguem ter um papel importante em um grupo de pessoas mergulhadas em seus viéses e fechadas nos seus próprios contextos. Pessoas generalistas conseguem transitar em diversas esferas, enxergando suas conexões e possíveis integrações e oportunidades entre essas esferas. Quando eu assumi que sou um generalista, isso me deixou mais leve.

Mas, mas, mas em alguns momentos é importante ser um generalista com uma especialidade anterior em um determinado assunto. É isso que o mercado de gestão de produtos tem sentido quando se trata da necessidade de ter alguns perfis de PMs que são pessoas generalistas por natureza, mas que já se especializaram em um determinado assunto durante a sua carreira.

Dessa forma, alguns tipos mais especialistas de Product Managers surgiram, como Technical Product Manager (TPM), Data Product Managers e Product Marketing Manager, só para citar os mais comuns no mercado.

Technical Product Manager (TPM): com um background altamente técnico, pode ter sido um desenvolvedor no passado ou até mesmo um arquiteto. Trabalha melhor em produtos que sejam mais de plataforma, que não entregam necessariamente uma interface de uso para os usuários, mas que criam serviços que potencializam a entrega de outros times. Muito necessário em empresas que precisam desenvolver seus aspectos mais técnicos de produto visando escala ou sustentação;
Data Product Managers (Data PMs): esse PM deve ter um contexto mais adaptado a gestão de produtos de dados, ou seja, ele trabalha muito próximo dos especialistas de dados que atendem times ou a empresa inteira. Muito necessário, por exemplo, em times de Risco e Fraude, empresas com áreas que necessitam de conhecimentos pesados em como usar dados para gerar soluções de inteligência artificial, machine learning, ou até mesmo análises de negócio;
Product Marketing Manager (PMM): cuida das preocupações que temos entre produto e marketing. Não é quem fará as análises de marketing, mas ajudará o time em momentos como o antes e o depois do product launch (go-to-market), ajudando a definir o planejamento de distribuição para os diversos segmentos de clientes, ajudando a procurar product market fit, trabalhando muito próximo do time de produtos e também do time vendas. Tem que ter uma visão gigante sobre mercado e como os mecanismos do mercado estão se movimentando, entendendo o timing e servindo como indicador de que há oportunidades mais latentes de novos produtos ou features que devemos adotar para que o produto se adeque melhor às tendencias externas;

Para você ter uma ideia de que esse tipo de visão de PM mais especializado ainda está se cristalizando no mercado, se você procurar a definição de Data PM em sites gringos, eles vão atrelar muito à um pessoa que vai definir testes A/B, que vai até trabalhar em definições de metas como OKRs. Eu não acho que isso deveria ser função desses PMs.

https://www.productplan.com/learn/product-marketing-manager/

Também existem muitas dúvidas sobre o trabalho do PMM: essa pessoa deveria estar dentro do contexto de marketing ou deveria ser alguém de produto inserido no contexto de marketing? Qual a resposta? Depende. Como sempre, vai depender da empresa, depender do timing dos times, da maturidade da empresa e das pessoas que estão gerindo e liderando produto e as outras áreas correlatas.

Eu enxergo esses movimentos como uma evolução das próprias áreas especialistas, inserindo pessoas que entendem de gestão para que seus times possam priorizar e entregar melhor. Não necessariamente esses PMs deveriam ficar dentro do time de produto, pelo contrário. Essas pessoas são gestoras. Devem aprender a fazer gestão de projetos e de produtos.

Como as áreas especialistas são áreas que são altamente demandadas por outras áreas da empresas, a necessidade de ter alguém que gere essas expectativas é inevitável. E como eu disse, não precisa ser alguém de produto, mas alguém que faz gestão, e de preferencia, que entenda muito da área especialista que ela está inserida.

Conclusão

A gestão de produtos é algo multifacetado e nada estático. Muito difícil ter uma resposta correta para todas as perguntas. Diversos cenários devem ser pesados para darmos respostas tão claras sobre as responsabilidades de alguém que gere produtos. Acho que o momento da empresa, dos times, do mercado, da pessoa devem ser colocadas em questão e nem sempre todos esses pontos terão as conexões perfeitas. Muito por isso nós nunca estamos satisfeitos com emprego atual, com o mercado, com o produto, com as pessoas do time, com o dinheiro que ganhamos ou com o glamour do nosso cargo.

Dessa forma, penso que é necessário você medir muito bem qual é o problema que você quer enfrentar. Basicamente, você pode controlar duas variáveis quando se trata de profissão:

Área/Responsabilidade que você quer assumir dentro das empresas. Quer executar, quer fazer gestão, quer trabalhar com processo? Procure saber quais as especialidades se encaixam com a sua experiência e com o seu conhecimento;
Segmento de Mercado que você deseja atuar ou que tem mais fit com o seu comportamento;
Empresa desse mercado: quais as empresas tem mais fit com o seu propósito?

E provavelmente você não consegue definir coisas como:

Salário e cargo;
Time que vai trabalhar;
Produto ou área que vai atuar;
Clientes ou sub-segmentos de mercado;

Então, atenha-se apenas às coisas que você provavelmente consegue ter mais controle de decisão e não se preocupe com o resto. O problema dos PMs é que eles deveriam ser mais estoicos do que pensam, mas preferem cair nos extremos da vida. Isso daria um ótimo texto: seja um PM estoico.