- A discussão sobre quantos PMs uma equipe de produto deve ter ganhou força após a reorganização da área de gestão de produto do Airbnb e exemplos de startups que crescem sem PMs
- À medida que o número de PMs aumenta, pode surgir uma estrutura em que eles passam mais tempo com gestão de projetos e atualizações de roadmap do que com resultados de negócio do produto
- Em equipes com designers e engenheiros experientes, o trabalho de PM não precisa necessariamente ser em tempo integral, e o modelo de 1 PM por equipe também deve ser reavaliado conforme o contexto
- A contratação do primeiro PM costuma ser considerada no momento em que os fundadores passam a ter dificuldade para participar de todas as principais decisões de produto, geralmente quando a empresa tem 50 a 100 pessoas e 3 a 5 equipes de produto
- Apenas aumentar o número de PMs não transforma uma organização em product-led; pelo contrário, pode enfraquecer o senso de responsabilidade pelo produto que designers e engenheiros deveriam ter
Uma estrutura para reduzir PMs e ampliar a responsabilidade pelo produto
- A discussão sobre quantos PMs são necessários ficou mais ativa após a reorganização da área de gestão de produto do Airbnb e artigos sobre startups que crescem mesmo sem PMs
- Em muitas empresas, PMs acabam preenchendo o dia com tarefas como gestão de projetos e atualizações de roadmap, em vez de otimizar o produto para o negócio
- Em geral, o número de PMs deve ser menor que o número de equipes de produto, e a estrutura de ter 1 PM em cada equipe precisa ser reavaliada conforme o produto e a situação da equipe
- Se há muito trabalho de produto e a equipe é júnior, pode ser necessário ter um PM dedicado a uma equipe
- Em equipes com engenheiros e designers experientes, o papel de PM pode não precisar — ou talvez não deva — ser em tempo integral
- O momento adequado para contratar o primeiro PM em uma startup é quando se torna difícil para os fundadores participarem de todas as decisões importantes de produto
- Em geral, a referência é uma organização com 50 a 100 pessoas e 3 a 5 equipes de produto
- A estratégia geral de produto já deve estar clara, e o PM deve participar de direções e decisões em níveis mais baixos com base nessa estratégia
- Para o primeiro PM, um PM sênior é mais adequado do que um PM júnior ou um CPO
- O candidato pode vir a assumir o papel de CPO conforme a organização cresce, mas os fundadores devem continuar atuando, na prática, como responsáveis pelo produto
Práticas para criar equipes centradas em produto
- A responsabilidade pelo produto não deve se concentrar em um único PM; design e engenharia também precisam entender diretamente os usuários e o contexto do produto
- Designers e engenheiros devem participar ativamente da formação do produto e liderar discussões detalhadas sobre ele
- O PM não deve ser o único responsável por UX, wireframes, acompanhamento do andamento, condução de standups ou redação de PRDs/especificações
- O foco do PM deve ser expressar a visão de produto, escolher os problemas certos, manter a direção do produto e garantir alinhamento com as necessidades do negócio
- O “Guide to product development”, de Michael Seibel, se conecta a um exemplo de implementação dessa abordagem na Social Cam
- A equipe deve compartilhar ativamente o contexto e a base das decisões
- Design e engenharia também devem ter acesso ao feedback dos usuários
- A resolução de problemas não deve ser centrada no PM, mas sim na colaboração entre produto, design e engenharia
- As práticas para criar uma equipe orientada a produto podem ser resumidas em quatro pontos
- Começar juntos: antes de escrever tickets ou especificações, e antes de definir uma solução, design, engenharia e produto/fundadores discutem juntos para alinhar a forma de condução e o plano
- Expor todos aos usuários: participar diretamente de pesquisas com usuários e testes de usabilidade, ou usar streaming de vídeo e ferramentas como Lookback para ver usuários utilizando o produto
- Ter cuidado com a forma de gerir a equipe: se o desempenho for medido por número de tickets fechados ou story points, a equipe passará a se orientar pelo processamento de tickets, não pela criação de um bom produto
- Não usar ferramentas de PM: quando feedback de usuários, insights, dados, especificações e roadmaps ficam presos em ferramentas separadas de PM, fica mais difícil para toda a equipe acessar o contexto do produto
- O desenvolvimento de produto é, por natureza, difícil de prever, e lançar a coisa certa, que impacta o negócio, é mais importante do que o lançamento em si
- Em grandes empresas centradas em produto, PMs são muito importantes, mas a quantidade necessária de PMs pode ser facilmente superestimada, e aumentar o número de PMs não leva automaticamente a uma maior concentração no produto
1 comentários
Comentários do Hacker News
Como gerente de engenharia ou líder de organização funcional, trabalhei com gerentes de produto por bastante tempo e também já atuei como PM interino de produtos internos em uma empresa de tecnologia de médio porte
Gestão de produto me parece uma das áreas mais importantes do que uma empresa faz. Mas o trabalho é realmente difícil, e quanto menos competente o PM, mais ele tende a se afastar disso e escorregar para microgerenciamento ou política interna sob o pretexto de “liderar” a equipe de engenharia
Em organizações onde engenharia e produto estão divididos em cadeias de comando separadas, é difícil lidar com esse problema, e mesmo quando ele é escalado, a capacidade da liderança acima naturalmente é muito limitada. Do ponto de vista de um EM, esses PMs muitas vezes tornam a vida dos melhores engenheiros um inferno, e no fim isso frequentemente faz com que eles saiam
Hoje, acho que a melhor abordagem é colocar em cada equipe um PM no estilo mini-CEO e, se ele não tiver bagagem técnica suficiente, pareá-lo com um mini-CTO. Isso reduz muito o espaço para política e amplia bastante o espaço para trabalho em equipe
As equipes mais bem-sucedidas em que estive não tinham uma função de produto dedicada, e todas as decisões eram tomadas pelos desenvolvedores
Hoje, acho que o melhor é tirar da frente dos desenvolvedores tanto o pessoal não técnico quanto as pessoas tecnicamente meia-boca, para que eles possam construir em paz
O que eu vejo são pessoas defendendo suas opções e tentando obter apoio. Nunca vi essa política de que as pessoas reclamam. Talvez eu só tenha tido sorte
Política seria alguém defendendo de forma mais persuasiva algo que está tecnicamente errado? O que é “política”? Ou será que ainda não estou em um cargo alto o bastante, mesmo sendo senior principal
Muita gente tentando analisar este texto e este tema está deixando passar um elemento central: incentivos
Muitos desenvolvedores são mais apaixonados pela tecnologia em si — programar, resolver problemas técnicos complexos, criar soluções eficientes. As recompensas formais, como promoção, bônus e reconhecimento, também muitas vezes estão ligadas a conquistas técnicas
Se um desenvolvedor gastar 40 horas com pesquisa de clientes, isso pode não ser reconhecido nem recompensado formalmente na mesma medida que uma conquista técnica como desenvolver uma nova solução de autenticação que ajude toda a equipe
Mudar essa dinâmica não é algo que se resolva apenas incentivando desenvolvedores a gastar mais tempo com gestão de produto. É preciso uma mudança sistêmica em como a organização define valor e recompensa as pessoas
Mudar a estrutura de incentivos de algo centrado em tecnologia para algo centrado no usuário afeta fortemente o papel da gerência média e superior. Essa mudança abala a base de seus papéis e responsabilidades e pode levar à perda de controle e influência
Por isso, é muito provável que esse tipo de mudança enfrente resistência sutil, mas forte, da gerência média e superior. Muitas vezes essas pessoas têm considerável poder político e interesses estabelecidos dentro da organização
Todo trabalho artesanal se aprende de verdade no momento do contato real. Um diretor de cinema pode ver o filme mil vezes na sala de edição, mas a primeira vez em que o vê com o público de verdade ensina mais do que aquelas mil horas
Um marceneiro pode passar a semana inteira satisfeito construindo móveis, mas o momento real chega quando aquele móvel é colocado no quarto do cliente. Com software é a mesma coisa
Para fazer um engenheiro de software se importar com os usuários, ele precisa receber feedback direto sobre o que funciona e o que é péssimo, e, se possível, ver isso com os próprios olhos
Todo engenheiro de software decente tem algum orgulho de fazer bem o seu trabalho. Se esse orgulho estiver ligado apenas ao código, ao histórico de commits e a outros conceitos abstratos, sem tocar em nada no quanto aquilo é realmente bem usado por usuários reais, então como ele começaria a se importar?
Quase não tem relação com o texto, mas essa tendência atual de usar imagem gerada por IA como imagem principal de post de blog está realmente me deixando louco
Se você não conseguiu imaginar uma imagem principal clara ao escrever o texto, eu preferia que não desperdiçasse minha largura de banda baixando o delírio de um computador
Sou a favor de imagens de IA, porque são uma ferramenta muito valiosa. Mas, se você vai usar uma imagem de IA como a única imagem da página, precisa haver um motivo realmente bom para isso — não pode ser só para preencher espaço
Ainda mais se você nem conseguiu fazer uma curadoria mínima, como verificar se todas as pessoas na imagem gerada têm o número certo de dedos
A imagem serve para transmitir uma sensação. Ela tenta tornar os conceitos abstratos do texto um pouco mais tangíveis
Antes, eu procurava na internet uma imagem adequada para esse propósito e usava isso. Agora posso criá-la diretamente com o DALL-E, e em geral fica muito melhor
Essa imagem deve complementar o texto. Assim como o texto tenta transmitir informação, sensação e conceito, a imagem também deve fazer parte disso
Ninguém quer ver uma imagem com pessoas de todos os grandes grupos raciais em círculo, sorrindo de forma estranha umas para as outras, com aquela sensação de vale da estranheza
Essa moda de ilustrações corporativas bizarras e sem alma começou antes mesmo de a geração por IA explodir em popularidade
Talvez por alguma crença ligada a otimização para mecanismos de busca
Ao mesmo tempo, só precisam parecer bonitas
Mas há algo de engraçado aqui. O template do blog exige uma área de imagem, então a pessoa preenche qualquer coisa sem pensar muito. Se isso for difícil demais, procura uma foto de banco sem graça; se isso também for difícil, gera de propósito uma foto de banco sem graça
Lixo de IA sem inspiração nem gosto parece prestes a cobrir tudo
A maioria dos problemas de PM vem do fato de não fazer trabalho de campo de verdade. Um bom PM precisa fazer a ponte continuamente entre engenharia e usuários
Esse loop de feedback precisa ser repetido
Mas a maioria acha que pode trabalhar só no mundo dos documentos, produzindo roadmaps sem parar e tentando manter o alinhamento das partes interessadas com check-ins intermináveis e cobranças constantes. No fim, estão fazendo trabalho de “gerente de projeto”
Coleta de requisitos, atendimento a usuários irritados com bugs, reuniões semanais de status, até comunicar más notícias sobre prioridades — mandava sempre um desenvolvedor sênior ou um tech lead. Também pulava a maior parte dos rituais ágeis dizendo que era uma pessoa ocupada. Nunca escreveu nem corrigiu tickets no JIRA, dizia que isso era coisa da organização técnica. As outras duas equipes técnicas também recebiam o mesmo tipo de “gestão” desse PM
Os tech leads e desenvolvedores sêniores sabiam desde a primeira semana que aquele PM não era bom, mas ele durou mais do que todos nós e só saiu 4 anos depois, em uma redução de quadro
Uma gestão obcecada pelo culto ao ágil se deixa encantar facilmente por esse tipo de pessoa, e isso pode desviar uma organização por anos. Em teoria, o stakeholder do PM é o usuário, mas na prática vira um trabalho de inflar o ego da alta liderança que o contratou
Pode surgir um ciclo fechado de auto-reforço entre alta liderança, consultores ágeis e PMs
Nos dois casos, são produtos sem competitividade, e em geral tendem a continuar assim até serem descontinuados. Mesmo assim, a empresa coloca PMs e POs e monta uma estrutura parecida com SCRUM, agindo como se estivesse criando um produto revolucionário. Inclusive com urgência e pressão por resultados
Nesse ambiente, muitas vezes PMs e POs têm pouco interesse em fazer um bom produto ou um produto minimamente útil, e ficam mais focados na política para subir na escada de promoção interna
Eles conduzem o projeto na direção que os faz parecer bem para a liderança ou para os clientes, mesmo que acabem criando um produto fragmentado que parece uma caminhada aleatória em termos de funcionalidades e melhorias
Não tenho idade suficiente para saber como se construía nas décadas de 60, 70 e 80, mas imagino que não havia SCRUM/PM/PO. O discurso pessimista de que a produtividade desacelerou muito em comparação com décadas passadas e que hoje em geral vivemos do que foi criado antes combina bastante com a minha percepção
Recentemente tenho feito mentoria para outros PMs. Existem roadmaps amplamente compartilhados, mas também se cria uma quantidade enorme de documentos e planilhas que ninguém além de mim volta a ver. Dá a sensação de que são feitos para mostrar que se está trabalhando, e estou tentando quebrar esse hábito
Defendo fortemente a gestão técnica de produto porque, simplificando o problema, acho que parte dos PMs fica presa em um nível de abstração alto demais. Como não conseguem conversar todos os dias com o time sobre questões técnicas detalhadas, acabam presos em uma zona cinzenta estranha entre gestão de projeto e gestão de produto
Isso em si tudo bem, mas se existe a síndrome do HIPPO querendo tomar decisões de produto, você acaba passando a maior parte do tempo se defendendo e gerenciando para cima
PMs apanham muito, às vezes com razão, mas no fim muitas vezes precisam fazer política interna para as coisas acontecerem
Um PM excelente não só cria a visão ou o plano, como também lidera a execução e a iteração. O planejamento é 20% do todo
O melhor gerente de produto com quem trabalhei era simplesmente uma pessoa muito competente, entendia a complexidade da implementação e, se necessário, provavelmente até conseguiria fazer ela mesma, além de entender as necessidades do negócio
Era alguém que agregava valor à empresa sem ser gerente de engenharia
Infelizmente, a maioria dos gerentes de produto é só gente ocupando a cadeira. São porteiros que ficam com o crédito ou com a culpa, e muitas vezes têm pouquíssimo interesse pessoal envolvido
No geral, acho que se existe uma organização separada de gestão de produto, algo está sendo feito errado
Os melhores e mais bem-sucedidos produtos dos quais participei tinham sempre a propriedade do produto nas mãos de quem realmente implementava. Engenheiros, designers, pessoas de customer success e afins
Como engenheiro, eu gostava de entrar na rotação de suporte porque isso fechava o gap de abstração entre o meu trabalho e as pessoas reais que usavam aquilo a cada segundo
Em casos muito raros, também trabalhei com PMs que de fato agregavam valor líquido, e em todos esses casos eram pessoas que também poderiam ter sido engenheiros decentes
O principal motivo é que, se o PM ou a pessoa do time que assume esse papel responde à mesma cadeia de gestão da engenharia, tudo acaba pendendo para as necessidades da engenharia
Até trabalho de funcionalidades realmente necessário, com grande chance de fazer o negócio avançar, acaba perdendo prioridade porque dívida técnica ou trabalho de infraestrutura sempre bloqueiam alguém de algum jeito. Às vezes essa pode até ser a escolha certa, mas para tomar esse tipo de decisão é preciso haver tensão entre duas organizações em pé de igualdade. Quando isso vira parte da engenharia, isso não acontece bem
Claro que a triste realidade do nosso setor é que uma organização separada de PM acaba tendo mais poder do que a organização de engenharia porque “cuida do que é bom para o negócio”. Se somar a isso PMs que sabem seguir processos ou frameworks, mas não entendem de verdade o próprio produto nem os usuários, vira um pesadelo
Eu penso em proporções
Qual é a proporção entre engenheiros de frontend e engenheiros de backend? Entre gerentes de engenharia e contribuidores individuais? Entre redatores de documentação técnica e o total de engenheiros? Entre gerentes de produto e o total de engenheiros?
E então tento ajustar essas proporções com cuidado para maximizar o impacto e minimizar interferência e microgerenciamento
Os números reais dessas proporções variam de organização para organização, mas se a interferência começa a aparecer ou se o “como” não está vindo o suficiente dos próprios engenheiros, então a proporção precisa mudar
É preciso aumentar o número de engenheiros por gerente de pessoas ou gerente de produto para que eles não consigam se intrometer desse jeito, sejam forçados a priorizar onde vão se envolver e recuem do nível microscópico, devolvendo aos engenheiros a autonomia sobre o método
O mesmo vale para QA, engenheiros júnior, engenheiros sênior, arquitetos, pessoal de RH, vice-presidentes e vendedores
Trabalho com gestão de produto há mais de 20 anos e concordo com a maior parte do que foi dito aqui. Proporções importam
É fácil para um CPO montar um império com um exército de PMs. A organização acaba num estado em que os PMs são donos de pequenos pedaços da experiência do cliente, como uma única página, e otimizam taxa de clique em botão, mas sem contribuir de forma relevante para a estratégia ou visão do produto
É difícil ser um gerente de produto sem ser dono do produto
PMs deveriam estar muito mais focados em objetivos de negócio do que a maioria está hoje. Resolver problemas dos usuários é necessário, mas não suficiente. Resolver esse problema também precisa gerar valor para a empresa
Para isso ser possível, é essencial ter parceiros de engenharia e UX com forte senso de produto
Pior ainda quando os desenvolvedores “facilmente substituíveis” vêm de empresas terceirizadas. Agora é preciso isolar o desenvolvimento do cliente com ainda mais camadas de gestão
Uma ótima forma de aumentar o PIB
Se você lida com ERP, Oracle Fusion Apps, WorkDay, SAP e coisas do tipo, um único PM não consegue ser dono do produto inteiro. Em vez disso, ele assume várias funcionalidades, e cada funcionalidade já é complexa por si só e, pela natureza de ERP, normalmente também envolve integração com vários outros produtos
Ainda assim, concordo com a direção geral de que o PM precisa ser dono de algo significativo
Como desenvolvedor e gerente de desenvolvimento, os melhores gerentes de produto com quem trabalhei quase não se envolviam no “como”
Claro, eles podem criar tickets em nível de épico no backlog, mas abaixo disso confiam que você e os responsáveis pelo projeto conseguem levar o trabalho até o fim
O problema é que a organização precisa dar suporte a isso. Na maioria das empresas, o trabalho que recebe mais atenção não é o orientado por visão ou crescimento, mas sim o mais barulhento
E esse trabalho muitas vezes entra em conflito direto com a direção desejada pelo líder ou gerente de produto
O pior tipo de PM é o que não entende o “como”, ou seja, não sabe como o próprio produto funciona
Os melhores PMs com quem trabalhei tinham background técnico
Quando as pessoas tentam invadir a área dos outros, sempre termina em desastre. Vale para os dois lados. Engenheiros tendem a pensar demais pela ótica do “como?”, então são fracos no “por quê?” e no “o quê?”, e gerentes de produto também precisam recuar do “como?”, a menos que seja para esclarecer melhor o “o quê?” ou o “por quê?”
Tem que haver equilíbrio. PM/PO também precisa ter entendimento básico. Não pode ser alguém que mal consegue usar um computador
Até um bom PM pode acabar bastante amarrado se estiver cercado de PMs medianos
Trabalhando com várias empresas da Fortune 500, vi muita cultura quebrada
Nesses lugares, PM resolve a maior parte dos problemas com a única ferramenta que tem: reuniões. O incentivo para promoção faz com que, quanto maior a reunião, mais importante a pessoa pareça
Já participei de centenas de horas de reuniões com equipes multifuncionais em que só 1 ou 2 pessoas realmente trabalhavam, normalmente o PM falava o tempo todo, e outras 10 a 20 ficavam no mudo e só davam aprovação no final como se estivessem provando que existiam
No fim, as equipes de engenharia perdem a motivação e deixam de ter tempo para fazer trabalho técnico de verdade, além de serem pressionadas a dar estimativas ou promessas na hora, sem investigar nem entender o código
Também já vi PM rejeitar um desenho técnico porque não gostou dos números ou dos “pontos”, e os engenheiros tiveram que reformatar a mesma ideia em outro “ticket” para satisfazer uma estética obscura de PM
Projetos inteiros atrasam e saem dos trilhos por falta de entendimento e por rituais vazios de demonstração de status
Por outro lado, também já trabalhei com PMs excelentes, e essas pessoas protegiam o time desse tipo de besteira e mantinham todos focados nos objetivos certos. Essas pessoas são valiosas, e as do primeiro tipo são prejudiciais na mesma medida
Independentemente do número de PMs, isto é sobre o tipo de PM com quem eu gostaria de trabalhar
Trabalhei em quatro empresas no setor, de startups com menos de 40 pessoas até a JP Morgan Chase
Rejeito a ideia de que uma pessoa “técnica” seja mais inteligente do que uma “não técnica”. Na verdade, como engenheiro, muitas vezes fico preso aos detalhes e perco a visão geral, e frequentemente preciso que um PM me puxe de volta
Ainda assim, pela minha experiência, os PMs mais fáceis de trabalhar como engenheiro são os que tiveram algum contato real com código
Não precisa ser nada extraordinário. Basta ter feito um site com HTML e CSS há muito tempo, escrito uma consulta SQL ad hoc, ou feito uma aula de Python no mestrado
Basta haver alguma coisa que faça o PM entender que escrever código não é uma ciência exata nem uma magia completa
Esses PMs tendem a defender os engenheiros com quem trabalham ou, pelo menos, tentar equilibrar as demandas do negócio com a realidade da engenharia
Pessoas que viraram PM sem nenhuma exposição técnica tendem a ser mais “orientadas ao negócio”; em certos momentos isso pode ser exatamente o que a empresa precisa, mas nem sempre é assim. Como engenheiro, prefiro trabalhar com alguém que também entenda melhor o meu ponto de vista
Não estou nem um pouco ressentido :p