Porque eu ensino um curso de gestão de produtos na Harvard Business School, perguntam-me rotineiramente “Qual é o papel de um gestor de produto? O papel de gestor de produto (PM) é frequentemente referido como o “CEO do produto”. Discordo porque, como assinala Martin Eriksson, “os gestores de produto simplesmente não têm qualquer autoridade directa sobre a maioria das coisas necessárias para fazer com que os seus produtos tenham sucesso – desde a pesquisa de utilizadores e dados, passando pela concepção e desenvolvimento, até ao marketing, vendas, e apoio”. Os PM não são o CEO do produto, e as suas funções variam muito dependendo de uma série de factores. Portanto, o que se deve considerar se se estiver a pensar em seguir um papel de PM?
As PMs aspirantes devem considerar três factores primários ao avaliar um papel: competências nucleares, inteligência emocional (EQ), e adequação da empresa. Os melhores PM com quem trabalhei dominaram as competências nucleares, têm uma elevada EQ, e trabalham para a empresa certa para eles. Para além de enviarem novas características numa cadência regular e manterem a paz entre a engenharia e a equipa de design, os melhores PMs criam produtos com forte adopção por parte dos utilizadores que têm um crescimento exponencial de receitas e talvez até perturbam uma indústria.
Core Competencies
Existem competências nucleares que cada PM deve ter – muitas das quais podem começar na sala de aula – mas a maioria é desenvolvida com experiência, bons modelos e mentoria. Alguns exemplos destas competências incluem:
- condução de entrevistas a clientes e testes a utilizadores
- desenvolvimento de sprints de design
- priorização de características e planeamento de road map
- a arte da atribuição de recursos (não é uma ciência!)
- translação de requisitos business-totechnical, e vice-versa
- modelação de preços e receitas
- definição e acompanhamento de métricas de sucesso
avaliações de mercado com bom desempenho
Estas competências nucleares são a linha de base para qualquer PM, e os melhores PM aperfeiçoam estas competências ao longo de anos de definição, expedição, e iteração em produtos. Estas PMs primam pela reflexão sobre onde cada uma destas competências contribuiu para o sucesso ou fracasso dos seus produtos e ajustando continuamente a sua abordagem com base no feedback dos clientes.
E Inteligência emocional
Uma boa PM pode saber o que fazer ou não numa entrevista com um cliente, mas as melhores PMs têm a capacidade de empatizar com os clientes nessa entrevista, estão sintonizadas com a sua linguagem corporal e emoções, e podem astuciosamente sussurrar os pontos de dor que o produto ou característica irá abordar. Um PM com uma elevada EQ tem fortes relações dentro da sua organização e um apurado sentido de como navegar tanto por obstáculos internos como externos para enviar um grande produto. Eis um olhar mais profundo sobre como os quatro traços chave da EQ, tal como definidos por Daniel Goleman, se relacionam com o papel da PM:
Gestão da relação. Provavelmente uma das características mais importantes de um grande PM é a sua capacidade de gestão de relacionamento. Ao formar ligações autênticas e de confiança com as partes interessadas internas e externas, os melhores PMs inspiram as pessoas e ajudam-nas a atingir o seu pleno potencial. A gestão de relações é também vital para o êxito das negociações, a resolução de conflitos e o trabalho com outros para um objectivo comum, o que é especialmente desafiante quando um PM é encarregado de equilibrar as necessidades dos clientes, equipas de engenharia com recursos limitados, e os objectivos de receitas da empresa. Relações autênticas e de confiança dentro de uma organização podem levar a mais apoio quando é necessário financiamento adicional para um produto ou quando um engenheiro deve ser convencido a incluir uma rápida correcção de bugs no próximo sprint. Fora de uma organização, estas competências poderiam encorajar os clientes existentes a testar em fase beta uma nova funcionalidade para um feedback precoce ou convencer um cliente alvo a experimentar o MVP de um produto ainda em modo furtivo. Estas competências de relacionamento também podem ser o que faz a diferença entre ter clientes irritados por causa de um bug introduzido no produto e aqueles que dizem: “Não se preocupe, sabemos que vai resolver isto!”
Self-awareeness. Os PM devem ser auto-conscientes de modo a permanecerem objectivos e evitar projectar as suas próprias preferências nos utilizadores dos seus produtos. Se um PM está apaixonado por uma característica porque aborda os seus próprios pontos de dor – os PM são frequentemente super-utilizadores dos produtos pelos quais são responsáveis – podem fazer com que um utilizador diga que também o ama, apenas para agradar ao PM (“validação de característica falsa positiva”). Se não tiver consciência de si próprio, um PM pode pressionar para dar prioridade a uma característica que concebeu, mesmo quando todas as entrevistas e provas dos clientes são empilhadas contra ele. Esta falta de auto-consciência pode descarrilar prioridades mais importantes ou prejudicar a relação do PM com os engenheiros, que podem perder a confiança no seu PM quando a característica não for prontamente adoptada pelos utilizadores.
Self-management. Ser um PM pode ser incrivelmente stressante. O CEO quer uma coisa, a equipa de engenharia outra, e os clientes têm as suas próprias opiniões sobre as prioridades da funcionalidade. Gerir prazos apertados, objectivos de receitas, exigências do mercado, conflitos de prioridades, e restrições de recursos de uma só vez não é para os fracos de coração. Se um PM não conseguir manter as suas emoções e mantê-las frescas sob pressão, pode rapidamente perder a confiança de todos os seus eleitores. Os melhores PMs sabem como pressionar com urgência as prioridades certas, mas sem transmitir uma sensação de pânico ou stress. Estes PMs também sabem quando respirar e afastar-se para se reagruparem.
Sensibilidade social. De acordo com Goleman, as competências associadas à consciência social são empatia, consciência organizacional e serviço. Os PM devem compreender as emoções e preocupações dos clientes sobre o seu produto tanto quanto compreendem as preocupações da equipa de vendas sobre como vender esse produto, ou da equipa de apoio sobre como apoiá-lo, ou da equipa de engenharia sobre como construí-lo. Os PM têm de ter uma compreensão profunda de como a organização funciona e devem construir capital social para influenciar o sucesso do seu produto, desde a obtenção de orçamento e pessoal até à obtenção de um engenheiro de topo para trabalhar no seu produto. Finalmente, a consciência social assegura o melhor serviço de PMs aos seus clientes com um produto que se dirige ao seu trabalho a ser feito, que é, em última análise, o que conduz à adequação do produto ao mercado.
(Leia mais sobre o que Paul Jackson tem a dizer sobre EQ e PMs aqui. E aqui está uma entrevista com Sam Lessin, antigo VP de gestão de produtos no Facebook, que diz ter “nunca treinado com sucesso empatia”)
Company Fit
Se os melhores PMs têm competências nucleares bem desenvolvidas e um elevado EQ, será que isso significa que estão destinados ao sucesso, independentemente do local onde trabalham? Não necessariamente. De facto, pegar nestas competências e traços de personalidade e aplicá-las à empresa certa é o que acabará por garantir o sucesso.
Ainda tenho de ver uma descrição de funções padrão para um gestor de produto, porque cada função é em última análise definida pela dimensão, tipo de produto, fase, indústria, e mesmo cultura da empresa. Se possuir as competências essenciais e um elevado EQ necessário para ser um PM de sucesso, o passo seguinte é desembalar quem está a contratar e o que procuram verdadeiramente.
Aqui estão algumas das áreas chave em que as empresas diferem no que querem de um PM:
Tecnologia. O tipo de produto, quem o utiliza, e o tipo de empresa determinará o quão técnico um PM precisa de ser. Por exemplo, o Google exige que as PM passem num teste de competências técnicas, independentemente do produto em que vão trabalhar. Se a empresa estiver a construir um CRM SaaS, poderá haver mais requisitos em torno da experiência com os ciclos de vida de produtos e clientes do que em torno da forma como o produto é construído. Pelo contrário, se for um produto de ciência de dados com algoritmos de aprendizagem de máquinas e APIs, o papel pode exigir muito mais profundidade técnica para compreender não só como construir o produto mas também como falar de forma credível com os clientes que o irão utilizar. Dito isto, ter uma compreensão técnica básica do que está sob a capa e o domínio das ferramentas que os PMs utilizam é definitivamente importante para o papel, onde quer que esteja. Colin Lernell tem aqui mais a dizer sobre estas competências necessárias. Se é um aspirante a PM e está preocupado com a falta de competências técnicas básicas para o papel, pode considerar a possibilidade de fazer cursos on-line, tais como o famoso curso de Introdução à Informática (CS50) oferecido pela Universidade de Harvard ou um dos muitos cursos de introdução e tecnologia avançada oferecidos pela The Flatiron School.
Filosofia da empresa sobre PM. Cada empresa tem uma filosofia diferente sobre o processo de desenvolvimento de produtos e onde as PM se enquadram nesse processo. Abaixo encontram-se os três tipos mais comuns, com prós e contras:
- PM conduz a engenharia. Esta é uma abordagem de “atirar por cima da parede”, onde as PM reúnem requisitos, escrevem o documento de requisitos quintessenciais do produto, e entregam-no à engenharia para especular os requisitos técnicos. As organizações contemporâneas podem fazer este processo de uma forma mais ágil e colaborativa, mas a expectativa é que os PMs saibam melhor o que os clientes precisam e a engenharia está lá para servir.
- Pro: A engenharia pode concentrar-se na codificação sem muita distracção; isto tende a funcionar bem para as lojas de desenvolvimento Waterfall com ciclos de vida longos.
- Con: Os engenheiros perdem de vista o panorama geral e não desenvolvem empatia para com os clientes, o que pode levar a uma má experiência do utilizador. Muitas vezes existem tensões insalubres quando é necessário dar prioridade ao débito técnico e ao trabalho de “canalização” sobre os requisitos do cliente.
- Produto de condução de engenharia. As empresas de produtos mais tecnicamente orientadas (nuvem, grandes dados, redes) tendem a ser orientadas pela engenharia, onde os engenheiros estão a avançar a ciência no seu domínio e as PMs validam soluções ou criam pontos de acesso front-end (UIs, APIs) para explorar esta nova tecnologia. Pode haver uma relação de colaboração e loop de feedback entre clientes, PMs, e engenharia, mas normalmente os PMs estão a servir a engenharia nestas empresas.
- Pro: A tecnologia inovadora pode oferecer aos clientes coisas de que eles nem sequer sabiam que precisavam. A VMotion na VMware foi um grande exemplo disto. Um engenheiro pensou que seria fixe fazê-lo, um PM descobriu como monetizá-lo, e tornou-se um alterador de jogo mil milhões de dólares para a empresa.
- Con: Engenheiros perseguem a coisa nova e brilhante, super-arquitetam a solução, ou iteram para sempre, procurando a perfeição antes de obter o feedback dos clientes. A entrada PM sobre prioridades é ignorada, o que por vezes inclui as necessidades mais básicas dos clientes.
- A parceria PM-engineering. Nestes casos, existe um forte yin-yang entre PM e engenharia, com descoberta conjunta, tomada de decisões, e responsabilidade partilhada. Os engenheiros juntam-se aos PM em entrevistas a clientes, e os PM estão em reuniões de sprint para ajudar a desbloquear tarefas ou clarificar requisitos. Mas os dois papéis respeitam a linha em que um começa e o outro pára. Os PM compreendem o que está a ser codificado, mas não dizem aos engenheiros como codificar, e os engenheiros têm empatia pelas necessidades dos clientes, mas deixam a priorização para os PM.
- Pro: Um processo de priorização simplificado que valoriza a dívida técnica e os projectos de canalização; melhores processos de concepção conducentes a uma experiência mais positiva para o utilizador; equipas de maior desempenho com melhor velocidade, qualidade, e, tipicamente, clientes mais felizes.
- Con: A inovação revolucionária pode não se tornar mais ecológica; o time-to-market pode parecer desfasado (embora eu argumentasse que o que é lançado está muito melhor alinhado com as necessidades do cliente e com maior probabilidade de ser escalado com sucesso).
Sou claramente tendencioso a favor do terceiro tipo de filosofia sobre PM (tal como o capitalista de risco Fred Wilson), pois experimentei os três e achei o yin-yang mais eficaz. Mas isso não quer dizer que os outros sejam notavelmente maus – depende realmente do tipo de produto que se está a construir, do estágio da empresa, e muito mais. Independentemente disso, ao considerar um papel de PM, a filosofia de PM na empresa poderia ser o factor decisivo para o papel.
Etapa da empresa. O papel do PM numa empresa em fase de arranque é muito mais susceptível de ser responsável por “todas as coisas”, enquanto que numa empresa madura o seu papel será mais claramente definido. (Banfield, Eriksson, e o livro Walkingshaw’s book Product Leadership tem uma secção que tem muito mais detalhes sobre este tópico.)
- Startup. Para além da descoberta, definição e envio, os PMs podem também ser responsáveis pelo preço, marketing, apoio, e potencialmente até pela venda do produto. Estes PMs prosperam num ambiente de sucata e são confortáveis com ambiguidade e frequentes mudanças de direcção à medida que a empresa trabalha no sentido de um produto adequado ao mercado e aprende a operar à escala.
- Pro: É provável que os PMs estejam mais envolvidos com a estratégia da empresa, obtenham exposição à liderança sénior e ao conselho de administração, sejam capazes de assumir mais riscos e tenham um maior impacto. Têm também mais influência e autoridade sobre os recursos da empresa.
- Con: Normalmente não há muito ou muito pouco mentor, modelos, ou melhores práticas dentro da empresa. (Pode ter de o procurar externamente.) Os orçamentos são tipicamente apertados, e os PMs podem não ter a experiência necessária para ter sucesso em algumas das coisas que são incumbidos de fazer.
- Empresa madura. O PM pode ter um âmbito mais restrito e ter colegas de trabalho que lidam com a fixação de preços, estratégias de comercialização, e assim por diante. E é provável que façam parte de uma equipa maior de gestores de produtos.
- Pro: É mais provável que os PM tenham mentores e modelos a seguir, bem como normas de desenvolvimento e melhores práticas. A estreita associação com uma equipa de engenharia pode criar fortes relações ao longo do tempo, o que é óptimo para o impacto a longo prazo e o crescimento da carreira. E se o produto se adequar ao mercado, existe uma base de clientes estabelecida e uma linha de base de desempenho a partir da qual se pode trabalhar, versus adivinhar até que se acerte.
li>Con: os PM têm menos exposição à estratégia da empresa e são apenas uma das muitas vozes do cliente. Podem ficar “perdidos” no sistema e têm de lidar com mais política e orçamentos apertados.
Fundador/CTO/CEO relação com PM. Especialmente em empresas em fases anteriores, é importante saber como o fundador/CEO/CTO está envolvido no processo do produto. Se estiverem profundamente envolvidos, o papel de PM pode desempenhar um papel mais de apoio, para dar corpo às suas ideias ou validar conceitos com os clientes, versus conceber e conduzir ideias próprias. Isto pode ser muito divertido para alguns PMs que gostam de estabelecer parcerias com fundadores e executivos de nível C e de colaborar na evolução do produto. Mas para outros PMs, pode ser muito frustrante se preferirem tomar mais posse da direcção do produto. Também pode ser um desafio se os fundadores mais técnicos ou os executivos de nível C preferirem trabalhar directamente com engenheiros. Isto pode deixar os PMs fora do circuito ou minar (por vezes involuntariamente), causando não só frustrações pessoais mas também atrasos. Ao considerar uma função PM que possa trabalhar em estreita colaboração com a equipa de liderança fundadora, não deixe de descobrir as suas expectativas em relação à função PM e decidir se esta é a mais adequada aos seus interesses.
Há, evidentemente, muitos outros factores a considerar para qualquer função, tais como o tipo de produto que está a construir (B2B, B2C, indústria), as pessoas com quem vai trabalhar, a cultura geral da empresa (diversidade, inclusivé, horários de trabalho flexíveis, cultura remota), e, claro, a compensação e os benefícios. Há também muitos artigos sobre a contratação de gestores de produto para obter perspectivas sobre o que os gestores de produto procuram – recomendo especialmente a peça do meu amigo Ken Norton “Como Contratar um Gestor de Produto”. No entanto, se está a esforçar-se por ser um grande gestor de produto, considere todos os pontos acima antes de assinar o seu próximo concerto. O desenvolvimento de competências nucleares será uma actividade contínua ao longo da sua carreira, e alavancar o EQ garantirá uma experiência mais positiva. Mas onde trabalha, como funcionam, e com quem e para quem trabalha determinará, em última análise, o seu sucesso a longo prazo.
Uma versão deste artigo apareceu pela primeira vez no website do autor.