A progressão de carreira de gestão de produtos pode ser vista iniciando com o Business Analyst (BA), tendo por responsabilidade a especificação do que o time de desenvolvimento de produto vai construir, avançando para Product Owner (PO), que além de especificar deve priorizar o que o time deve fazer, e chegando ao topo da carreira com o Product Manager (PM), que, além de especificar e priorizar, deve definir a visão e estratégia do produto ou pedaço de produto de que ele cuida.
Uma outra forma que muitas empresas têm adotado para enxergar essa evolução de carreira é considerar as fases de BA e PO como Associate Product Manager (APM), com a responsabilidade de especificar e priorizar. É o primeiro passo na carreira de gestão de produtos.
Como gestão de produtos é um papel de grande responsabilidade, recomendo que as pessoas que ingressem na carreira de produtos tenham alguma experiência prévia em outras áreas, tais como engenharia, design e marketing.
Já vi também ótimos gestores de produto vindos de operações, suporte, gestão de projetos, financeiro, e até mesmo jurídico. Ao longo da minha carreira tenho notado que pessoas que acabaram de sair da faculdade não têm a bagagem necessária para conseguir ser bons gestores de produto. É importante ter esse conhecimento em outras áreas até mesmo para ajudar a entender como seu produto impacta essas outras áreas.
A pergunta que fica é: o que vem depois? De APM para PM, que pode chegar a PM sênior, mas qual é o próximo passo da carreira de gestão de produtos?
Um time mínimo de desenvolvimento de produtos é composto por alguns engenheiros. Normalmente começa com 2, podendo chegar a até 7 engenheiros, sendo um deles alguém mais sênior, com um papel de tech lead, mais um product designer (PD) e um product manager (PM). Quando há a necessidade de criar um segundo time para cuidar de uma outra parte do produto, há duas formas de fazer essa expansão:
Em ambos os casos, se a PM original for mais sênior, podemos contratar para essa posição de segundo PM alguém mais júnior ou até mesmo um associate product manager e dar à PM mais sênior a oportunidade de ajudar o mais júnior a se desenvolver. Seria uma primeira oportunidade de gestão de pessoas para essa PM sênior, se isso for algo que ela está buscando para a sua carreira. Enquanto ela ainda cuida de um produto ou pedaço de produto com o primeiro time, ela pode começar a experimentar na prática como é liderar um outro PM júnior.
Depois de um a dois trimestres rodando nessa configuração é possível entender se a PM mais sênior gostou desse novo papel, de ajudar um PM mais júnior a se desenvolver. Se esse papel for algo que faça sentido para a PM sênior, é possível pensar em colocar mais PMs para ela ajudar. Nesse ponto vai ficar cada vez mais difícil para essa PM sênior gerenciar um produto ou um pedaço de um produto.
Estou focando na carreira de PM, mas existe um caminho similar tanto em engenharia quanto em product design. O tech lead mais sênior pode vir a liderar o tech lead do outro time, assim como o product designer mais sênior pode liderar o product designer do outro time.
Esse é o momento em que o PM sênior se torna um Group Product Manager (GPM). Esse é o primeiro passo em uma carreira de head de produto, quando o product manager não cuida diretamente de um produto ou de um pedaço de um produto e tem a responsabilidade de ajudar outros PMs a se desenvolverem e a gerenciarem seus produtos. Normalmente isso acontece quando a pessoa está liderando 3 ou mais product managers e é responsável por um conjunto de funcionalidades ou mesmo um produto inteiro. Em algumas empresas essa posição é chamada de head de produto, ou diretor de produto ou até mesmo de vice-presidente de produto.
Na Conta Azul, tínhamos GPMs que cuidavam de pedaços do produto. Um GPM ficava mais focado nas funcionalidades financeiras do produto tais como relatório financeiro, emissão de boleto etc. enquanto ou outro tinha foco maior em funcionalidades contábeis e fiscais tais como registro de compra e venda, gestão de estoque, emissão de notas fiscais etc.
No Gympass, tínhamos diretores de produto focados em cada ator de nosso marketplace. Um diretor de produto focado nas academias, outro focado no RH de nossos clientes e um terceiro focado nos funcionários de nossos clientes.
Em uma empresa pequena, o GPM pode ser o nível mais alto de carreira de produtos. Por exemplo, em uma empresa com até uns 6 ou 7 PMs, um único GPM para coordenar esses PM pode ser suficiente. Quando passa desse número, pode ser interessante ter um segundo GPM, ou mesmo um CPO ou VP de produto que lidera o GPM e alguns PMs.
Além de liderar PMs, o GPM também tem o papel de coordenar a definição da visão e da estratégia de um grupo de produtos ou de funcionalidades. Por exemplo, o diretor de produtos para RH no Gympass tem que liderar os PMs que trabalham em pedaços do produto para os RHs, que chamávamos de Portal do RH, bem como em definir a visão de futuro desse Portal RH, ou seja, onde queríamos chegar com o Portal RH e a estratégia, ou seja, o caminho para chegar lá. E com os PMs, é responsável pela execução dessa estratégia.
Imagino que você já tenha visto alguma situação em que a pessoa é uma excelente colaboradora, recebe uma promoção para liderar pessoas e, por não estar preparada ou até mesmo por descobrir que não gosta de liderar pessoas, acaba tendo um perfomance ruim como gestora. Só que essa pessoa entende que não pode voltar atrás, voltar a uma posição de contribuidor individual pode ser visto como um retrocesso na carreira, como uma falha.
Uma ferramenta interessante para prevenir situações como essa é o conceito de interinidade. Ao invés da pessoa já assumir um cargo permanente de GPM e liderar uma ou mais pessoas, pode-se usar o conceito de GPM interino, ou seja, é a pessoa assume esse papel de forma temporário, como um teste para ela ver se gosta e se sente confortável fazendo a função de líder. Essa ferramenta pode ser usada em qualquer carreira, não somente na carreira de gestão de produtos. De engenheiro para líder de engenheiros, de product designers para líder de UX etc.
Essa ferramenta cria uma salvaguarda, uma rede de proteção para as pessoas que nunca lideraram pessoas e querem experimentar essa opção de carreira. Com essa ferramenta há espaço para voltar atrás caso a pessoa não goste ou não se sinta preparada para exercer essa função. É o famoso conceito de change rollback ou undo que permite desfazer uma mudança e voltar à versão anterior caso a gente perceba que a mudança feita não está funcionando como esperado.
O Chief Product Officer (CPO) ou Vice-Presidente de Produtos é o cargo mais alto de produtos em uma empresa. Lidera GPMs ou diretores de produto e tem por responsabilidade coordenar a definição da visão e da estratégia de todos os produtos da empresa, bem como pela execução dessa estratégia, em conjunto com os GPMs e diretores de produto. Em alguns casos pode fazer sentido a área de UX reportar para o CPO. Idealmente, dada a importância da estratégia digital nas empresas, o cargo de CPO deve reportar para o CEO e ter acesso aos membros do Conselho.
A nomenclatura pode ser um pouco confusa. Algumas empresas chamam essa posição de head de produto, outras de diretor de produto ou vice-presidente de produto ou CPO. Apesar disso, o importante é a estrutura estar clara para todos dentro e fora do time de desenvolvimento de produtos.
Existem dois modelos de estrutura de liderança de times de desenvolvimento de produto, cada um com os seus prós e seus contras, a depender do contexto onde está esse time:
Tanto na Locaweb quanto na Conta Azul eu tive o papel de CPO com a responsabilidade de liderar todo o time de desenvolvimento de produto, ou seja, gestores de produto, product designers e engenharia.
A liderança única funciona quando se tem pessoas sêniores para ajudar na gestão de engenharia assim como na gestão de design e de produtos. Na Conta Azul, o time chegou a ter 130 pessoas e eu tinha um head de engenharia, 4 GPMs e um head de design para me ajudar. Na Locaweb, com um time de 100 pessoas eu tinha dois gerentes seniores de engenharia, 5 PMs seniores e um head de UX.
Gosto dessa configuração pois sempre vi o time de desenvolvimento de produto como um único time, com objetivos comuns de entregar o melhor produto para atender aos objetivos da empresa enquanto resolve problemas e necessidades dos usuários. Essa configuração ajuda no alinhamento e nessa visão de time único.
Esse tipo de configuração funciona muito bem para times pequenos, de até umas 80 a 100 pessoas. Quando chega nesse tamanho, existe o risco de sobrecarregar esse líder único responsável por todo o time de desenvolvimento de produto. É uma infinidade de temas diferentes, daí a importância de ter pessoas seniores ajudando na liderança.
Em algumas empresas, ao invés de CPO, essa liderança única é chamada de Chief Technical Officer (CTO) ou de Vice-Presidente de Desenvolvimento de Produtos.
Pode fazer sentido pensar em dividir a área em duas lideranças quando o time cresce para mais de 100 pessoas, tendo um CPO e um CTO fazendo a liderança compartilhada. Vale lembrar de que a liderança compartilhada, apesar de ser benéfica no sentido de dividir responsabilidades, pode ter efeitos colaterais prejudiciais se não for bem gerenciada pelo CEO.
No Gympass rodamos durante 18 meses com um CTO e dois CPOs, sendo um de produtos para consumers e eu focado em produtos para empresas e parceiros. Optamos por essa configuração pois prevíamos um crescimento considerável do time. Quando o time estava ainda com 60 pessoas, já vislumbrávamos um crescimento até 400 pessoas. Poder dividir a responsabilidade, principalmente quando o time cresce rápido para números acima de 100 pessoas, ajuda a colocar mais atenção e ir mais fundo nos temas de que cada líder cuida. Isso evita a sobrecarga que comentei acima.
No Gympass, o time de UX reportava para o CPO de consumers enquanto eu tinha, além dos times de produto para empresas e parceiros, um time de Professional Services (PS) que era responsável por fazer as integrações customizadas com sistemas de academias e de sistemas de RH de nossos clientes. Esse trabalho de professional services é mais orientado a projetos, com definição clara de escopo e prazos bem definidos, por isso criamos uma área separada para cuidar dessas integrações.
Na Conta Azul, quando eu saí de lá em meados de 2018, estávamos começando a pensar em dividir os papéis entre CTO e CPO. Tanto que em 2020 a estrutura ficou com a liderança compartilhada do time de desenvolvimento de produtos.
Outra possibilidade de liderança compartilhada de times de produto é ter head de engenharia, de produtos e de UX.
A liderança compartilhada tem por efeito colateral o risco inerente de criação de silos, ou seja, de haver times trabalhando de forma isolada e sem a necessária colaboração. No Gympass, tínhamos uma preocupação forte em evitar esse comportamento. Sentávamos nós 3 lado a lado e reservávamos no mínimo três horas por semana para conversarmos sobre temas do time de desenvolvimento de produtos, sendo uma hora entre nós 3, uma hora junto com business partner de RH, e uma hora com o CEO. Além disso, buscávamos setar os objetivos de forma comum para os times e tratávamos o orçamento como um orçamento único da área de desenvolvimento de produtos.
Contudo, apesar de nossos esforços, ainda assim havia situações de falta de colaboração entre os membros de diferentes times. Por este motivo, tenho preferência por configurações com liderança única de time de desenvolvimento de produtos, apesar da eventual sobrecarga que isso possa causar nessa liderança. Uma forma de diminuir essa sobrecarga é contar com líderes seniores.
Como comentei anteriormente, a área de desenvolvimento de produtos é uma área só, com objetivo comum de criar o melhor produto para atender aos objetivos estratégicos da empresa enquanto resolve problemas e necessidades dos clientes. Ter duas ou mais lideranças para essa área requer bastante coordenação entre elas para garantir que os times estão colaborando e evoluindo na mesma direção. A forma mais comum de dividir essa liderança é ter duas pessoas, CPO e CTO, para liderar o time de desenvolvimento de produtos. Enquanto o CPO lidera pessoas de produto e de UX, o CTO lidera as pessoas de engenharia.
Essa imagem ilustra bem as responsabilidades de cada liderança. O CTO cuida do desenvolvimento propriamente dito do produto, ou seja, tem que se preocupar com a qualidade do que está sendo desenvolvido, bem com a velocidade de desenvolvimento. Também cuida de questões de infraestrutura e operacionais tais como a estabilidade, performance e disponibilidade do produto. O CPO cuida do produto tanto do ponto de vista do negócio quanto do ponto de vista do cliente. Do ponto de vista do negócio, é responsável por definir a visão de produto alinhada com os objetivos estratégicos do negócio. Do ponto de vista do cliente, precisa garantir que o produto resolve um problema ou necessidade do cliente com qualidade e, para isso, ele precisa entender a satisfação e o engajamento do cliente com o produto.
Em conjunto, CTO e CPO devem definir e evoluir a estrutura do time de desenvolvimento de produto, com times de produto e times estruturais (SRE, Data etc.) como veremos no capítulo Estrutura de times, bem como definir e evoluir os processos que esse time usará no seu dia a dia.
Carreira Y é a opção que se dá para as pessoas optarem pela carreira gerencial ou seguir na carreira de especialista. Alguns PMs mais seniores podem não querer gerir pessoas, só produtos. Isso significa que não há espaço para ela evoluir na carreira, uma vez que o caminho de progressão visto acima passa pela liderança de outros PMs? Não necessariamente.
Em empresas com produtos mais complexos ou até mesmo com um portfólio de mais de um produto, pode haver espaço para um papel pouco conhecido no mercado brasileiro, mas que pode ajudar bastante nesse contexto, o Principal Product Manager. Esse é um papel que não gerencia pessoas mas que, pela sua senioridade, tem um impacto relevante na organização. Suas principais responsabilidades são:
Ajudar a conectar o trabalho dos GPMs: Ã medida que a empresa cresce e temos mais de um time de desenvolvimento de produto, cada um com seu GPM muitas vezes focado no dia a dia desse time, sem olhar muito para o que os outros times estão fazendo, normalmente é papel do CPO manter a conexão entre o trabalho dos diferentes times e seus GPMs mas, em algumas estruturas, pode fazer sentido ter algum PM bem sênior fazendo esse papel.
Garantir a sincronia e consistência entre os times de produto: por independentes que tentemos fazer a estrutura de times de produto, sempre haverá situações em que um time dependerá do trabalho de outro time. Um exemplo no Gympass são os times de produto para academia e para usuário final. O time de academia faz uma funcionalidade que permite ao gestor da academia criar o horário de aulas, e o time focado no usuário final precisa colocar esse horário de aulas disponível no app para que os usuários passam ver e agendar aulas. Essa coordenação normalmente é feita pelos próprios PMs desses dois times, mas eles podem se beneficiar de ter uma terceira pessoa ajudando nessa coordenação. Essa terceira pessoa pode ser um GPM, o CPO ou mesmo um PM mais sênior, nesse papel de Principal Product Manager.
Note que essas responsabilidades são um subconjunto das responsabilidades de um head de produto ou mesmo de um CPO, sem a responsabilidade pela gestão e desenvolvimento dos PMs, o que pode ser atraente como progressão de carreira para pessoas que não queiram gerir outras pessoas. Esse papel ainda é novo. Algumas empresas o enxergam como sendo somente um PM muito sênior, mas acho que faz sentido pensar nesse papel com uma contribuição maior do que somente em um time.
No próximo capítulo vamos olhar uma das principais responsabilidades do head de produtos, a criação da visão e da estratégia de produto.
Estou publicando os 30 capítulos do meu mais novo livro, Liderança de produtos digitais: A ciência e a arte da gestão de times de produto, um por semana. Caso você queira ler o livro completo, pode adquiri-lo diretamente da editora. Você também pode se interessar pelos meus outros dois livros: