O papel de gerente de produto é um erro
(sollecitom.github.io)- Quando uma empresa de produtos de software entende product-led de forma equivocada como “uma estrutura em que o PM toma todas as decisões”, acaba aplicando a PMs de carreira comuns um modelo que só serve para líderes excepcionais do tipo fundador
- Dar o controle do produto a um único líder não é o ponto central por si só; o essencial é a quem esse controle é entregue, partindo do pressuposto de uma pessoa rara, com visão, carisma, capacidade técnica e convicções fortes
- Quando se dá autoridade excessiva a um PM comum, dados, frameworks, processos de aprovação, reuniões e estruturas de papéis deixam de ser ferramentas de julgamento e viram uma barreira de fuga de responsabilidade e política interna
- Esse movimento faz pessoas excelentes irem embora, e a empresa fica presa a tarefas de baixo risco e processos internos, perdendo visão e talento
- A alternativa não é uma estrutura centrada no cargo de PM, mas reunir em um time pessoas obcecadas por técnica e qualidade em cada área, para lidar em conjunto com descoberta de produto, observabilidade de produto, engenharia, design, negócios e conhecimento de domínio
O problema de confundir product-led com uma estrutura monopolizada pelo PM
- Muitas empresas de produtos de software são fundadas por pessoas mais hábeis em captação de recursos e compreensão do setor-alvo do que por pessoas com forte experiência em criar produtos de software
- Esses fundadores começam a empresa com base em sua experiência e seus relacionamentos no setor, mas, se conduzirem diretamente todas as decisões, a convicção de um especialista de domínio pode acabar prejudicando a empresa
- Alguns fundadores reconhecem que eles próprios podem ser um risco e contratam alguém para assumir a tomada de decisões
- É nesse momento que surge o mal-entendido de que “não devemos ser uma organização de serviços, e sim uma empresa de produtos; empresas de produtos são product-led, então o PM deve ser responsável”
- Aqui, product-led não significa que o PM toma todas as decisões
- Quando aparecem opiniões contrárias, é comum surgir a réplica de que grandes empresas como Amazon, Apple e Tesla também delegam o controle a uma única pessoa
- Muitas grandes empresas entregam o controle a uma única pessoa, mas nem todas as grandes empresas usam o mesmo modelo
As premissas do modelo de decisor único
- O modelo de dar o controle da empresa a uma só pessoa não é exatamente errado; seu sucesso ou fracasso depende de a quem ele é dado
- Figuras como Picasso, Jeff Bezos, Mozart, Steve Jobs, Nikola Tesla, Elon Musk, Robert Oppenheimer, Peter Thiel e Leonardo são reverenciadas pelo público por sua visão, carisma, autoconfiança, resiliência e excelência
- São pessoas que imaginam realidades alternativas, mergulham completamente no próprio trabalho e produzem grandes mudanças pela força de vontade
- Se uma pessoa assim de fato existe, o modelo de controle único pode funcionar de maneira poderosa
Pessoas excepcionais não são PMs comuns
- Grandes figuras não eram gerentes de produto
- Eram artistas, matemáticos, inventores, cientistas, CEOs, e às vezes acumulavam vários papéis ao mesmo tempo
- Elas eram obcecadas por sua visão e técnica, mais do que por OKRs, KPIs, dados ou opiniões alheias
- Pessoas excepcionais podem ter opiniões fortes, ego grande, um jeito próprio de fazer as coisas, arestas ásperas e desprezo pela mediocridade
- Por causa dessas características, é difícil contratá-las em empresas comuns, e é provável que elas próprias não queiram trabalhar na maioria das empresas
- Se você conseguir encontrar uma grande pessoa, não atrapalhá-la e suportar sua intensidade, pode entregar a ela o controle do produto e da empresa
- Na prática, é difícil encontrar alguém assim; elas podem não querer trabalhar com você, ou a empresa pode não suportar seu ego e sua intensidade
Quando uma estrutura feita para grandes figuras é aplicada a PMs comuns
- O maior erro é adotar um modelo operacional que exige uma pessoa excepcional sem ter uma pessoa excepcional
- A crítica é que PMs de carreira que a empresa consegue contratar confortavelmente em geral não são pessoas desse nível
- São descritos como lacaios do negócio, fanáticos por frameworks, especialistas no assunto, ex-criadores que subiram a escada corporativa, viciados em métricas, MBAs e afins
- Se “product-led” for entendido como PMs tomando todas as decisões e a empresa contratar PMs de carreira para isso, o resultado pode ser fatal
- Esses PMs agem com segurança e politicamente porque lhes faltam visão, carisma, especialização, convicções fortes e capacidade técnica
- Como sabem de suas próprias limitações, repetem o comportamento de ficar com os méritos e evitar a responsabilidade
Como dados e processos viram instrumentos de defesa
- A primeira etapa é a instrumentalização da tomada de decisão baseada em dados
- Sem reconhecer que é possível encontrar dados de apoio para qualquer afirmação, apresentam apenas sua própria decisão como racional segundo os dados
- Quando algo dá errado, culpam o mercado, a qualidade dos dados ou o azar da empresa, e dizem que a responsabilidade não é deles
- A etapa seguinte é introduzir frameworks e papéis para tudo
- Surgem frameworks de carreira em 18 etapas, avaliações trimestrais de desempenho, PI planning, ADR, PRD, RACI, MOSCOW, OKR, KPI, DORA, SAFe e assim por diante
- Não seguir o processo, não ser data-driven, ter documentação insuficiente ou documentação desatualizada viram motivos para acusação
- Na organização aparecem papéis como Director of KPIs, Deputy Director of Product Operations e Global Head of Digital Whiteboard Solutions
- Tudo passa a exigir aprovação, e nenhum processo ou área fica totalmente sob o controle de uma pessoa
- Em um grande comitê, qualquer um pode dizer “não”, mas ninguém consegue dizer plenamente “sim”
- As reuniões também explodem
- Aumentam relatórios de status, reuniões de alinhamento, 1:1, reuniões de staff, discussões estratégicas, definição de contexto, go/no-go de release, relatórios de projeto e afins
- A última etapa é contratar muita gente ruim
- Contrata-se com base em não representar uma ameaça, e qualquer sinal de excelência vira motivo de rejeição
- O contratado ideal passa a ser uma pessoa generalista que cumpre razoavelmente o que lhe mandam, sem discordar nem se importar com qualidade
- O número de PMs dispara, surgem camadas de PMs em cada time e área, e o mesmo comportamento se repete
O que a organização perde
- Quando começa o movimento de pessoas comuns assumirem o poder, as pessoas excelentes acabam indo embora
- Ou são empurradas para fora por ditadores medíocres, ou saem por conta própria por não suportar o ambiente
- O ritmo de trabalho para, e executar qualquer coisa se torna algo doloroso, um compromisso enorme e uma tentativa arriscada
- Grandes visões são tratadas como irrealistas e rapidamente descartadas
- O trabalho da empresa fica limitado aos frutos mais fáceis e a escolhas seguras
- Mesmo pessoas que não têm tanta paixão por sua técnica sentem dor e vão embora; as que são insensíveis o bastante para ficar pioram ainda mais o problema
- A empresa perde seus melhores talentos, esquece sua visão, torna-se voltada para dentro e perde significado
- No melhor caso, morre em algum momento; no pior, sobrevive pela metade, transformando pessoas apaixonadas em zumbis que odeiam o próprio trabalho
A alternativa é um time de pessoas excelentes no dia a dia
- É possível criar uma empresa de produtos bem-sucedida sem precisar encontrar uma pessoa excepcional, contratá-la, entregar o controle a ela e suportar sua intensidade
- A alternativa é contratar pessoas excelentes no dia a dia
- Cada uma deve ser excelente em alguma área
- Deve ser obcecada pela própria técnica e movida por qualidade
- O time deve ser montado de modo que as áreas de excelência de cada pessoa se sobreponham o mínimo possível
- Em vez de fatiar responsabilidades individuais em pedaços pequenos, deixe essas pessoas fazerem com prazer o trabalho de que gostam e usarem seu tempo e suas habilidades em favor da empresa
- Essas pessoas também podem ser desafiadoras, teimosas, egocêntricas, peculiares e temperamentais
- Se receberem um bom problema e puderem fazer um trabalho excelente, elas se comprometem completamente com o sucesso da empresa
O lugar de líderes e PMs
- Não é preciso abrir mão completamente de líderes; também é possível eliminar líderes de time e colocar líderes de área como coordenadores entre o externo e o interno
- Se houver um líder responsável em cada área, esse papel deve ser ocupado por alguém próximo de uma grande pessoa
- Alguém próximo de Jobs, Musk ou Bezos em visão, carisma, intensidade, paixão e comportamento extremo
- Se, no curto prazo, você colocar como responsável alguém conveniente, obediente a instruções e que exige menos atenção, há o risco de cair na situação descrita acima
- No sentido tradicional, o papel de PM não tem lugar em uma empresa que funciona bem
- Ainda assim, são necessárias pessoas obcecadas por áreas tradicionalmente atribuídas a PMs, como descoberta de produto e observabilidade de produto
- Essas pessoas podem já ter tido o cargo de PM, e isso em si não é um problema
- O motivo da contratação não é o cargo, mas a obsessão e os pontos fortes
- Em vez de colocá-las em um papel separado de PM, elas devem estar no mesmo time que pessoas obcecadas por engenharia, design, desempenho, negócios e conhecimento de domínio
Não é um problema só dos PMs
- O mesmo problema surge quando alguém sem visão, carisma, paixão, capacidade técnica e força de vontade se torna responsável
- O foco em PMs se deve à tendência, no desenvolvimento de produtos de software, de colocar pessoas com o cargo de product manager como responsáveis
- Alguns PMs são realmente excepcionais e podem se sair muito bem em ambos os modelos
- Mas isso não significa que esses PMs necessariamente se saiam melhor do que pessoas excelentes com outros históricos
- Esses PMs são uma minoria muito pequena, e a maioria dos PMs de carreira não chega perto de ter a capacidade de liderar pela excelência
1 comentários
Opiniões no Hacker News
Na empresa atual há muitas pessoas inteligentes, mas por vários motivos não há gerente de produto e, como resultado, o trabalho que um gerente de produto deveria fazer simplesmente não é feito.
Quase nenhum engenheiro quer fazer coisas como manter relações com clientes, entrevistar usuários, descobrir possíveis funcionalidades, convencer a liderança e fazer política para alocação de recursos.
Na empresa anterior, 2 dos 3 gerentes de produto eram incompetentes e foram demitidos, mas 1 era realmente excelente, e apenas uma parte do tempo dessa pessoa realizou em menos de um ano mais do que minha empresa atual fez em mais de 2 anos.
Concordo que não há gerentes de produto bons o suficiente. Acho que o número de pessoas capazes de ser bons gerentes de produto cresce linearmente com a população, mas a indústria de software explodiu exponencialmente, criando a necessidade de 100 vezes mais cargos de PM do que PMs de fato excelentes.
Também não eram técnicos, então não gerenciavam tickets do Jira, e a gestão da liderança ficava em grande parte com os gerentes.
Acho que esses gerentes de produto principalmente participavam de reuniões, conversavam com a liderança, conversavam com engenheiros, escreviam documentos e conduziam reuniões de planejamento de sprint que ficavam longas.
Vejo que um gerente de produto que lide com questões de clientes, usuários e recursos poderia ser muito mais valioso.
Eu ouvia o tempo todo “somos uma empresa engineering-first”, mas, na prática, isso queria dizer que as equipes de engenharia perseguiam à vontade apenas as tecnologias mais recentes.
Temos 3,5 produtos principais, na prática 4,5, cada um feito com uma stack tecnológica diferente, e há mais uns 8 produtos que precisamos dar suporte por exigências legadas. Não há padronização nem interoperabilidade entre produtos, nem transferência de conhecimento, então o custo de desenvolvimento está nas alturas.
Só este ano, tive de explicar duas vezes a engenheiros com 20 anos de casa por que é ruim uma API usar apenas TLS 1.3, outra usar 1.x e outra nem sequer exigir TLS.
Os clientes nos odeiam. No meu produto, primeiro escreveram o material de marketing e deixaram os engenheiros se virarem para construir. Uma etapa para mover dados Oracle para parquet foi feita em três linguagens e dois bancos intermediários (MySQL e PG), e mal consegui impedir que colocassem Redis também.
Felizmente, há 2 anos um fundo de private equity nos adquiriu e agora recebemos o ultimato de que, se não gerarmos dinheiro, acabou. Era uma empresa de 20 anos que nunca ganhou dinheiro, um centro de custos; e, mesmo que não batamos as metas, acho que o universo ficará melhor se o desastre de design de software que criamos desaparecer.
Um gerente de produto burro vira um quase gerente de projetos que acompanha mais um livro de tarefas, enquanto uma pessoa inteligente entende profundamente o negócio e é promovida ou vai embora.
Esse papel também é difícil de governar. Às vezes leva grande crédito pelo trabalho dos outros; às vezes não recebe crédito nenhum e a carreira fica estagnada.
Se você empurra esse papel para engenharia, gestão de engenharia ou gestão geral, enfraquece a capacidade de engenharia. Se vai contratar engenheiros, deve selecioná-los por essa capacidade e protegê-los de pessoas externas; mas, se a equipe também tiver de lidar com interações, você acaba contratando pessoas com competências híbridas e, no fim, o lado de engenharia se dilui.
Manter deliberadamente a capacidade do gerente de produto apertada pode funcionar como um mecanismo de imposição que o faz se concentrar em alto nível e visão, evitando que se aprofunde demais e crie processos inúteis ou defina funcionalidades em excesso.
No setor de tecnologia inflado por mais de 10 anos de crescimento com juros baixos, muita gente basicamente conseguia ter sucesso só por aparecer no trabalho.
É um texto confuso. Diz que “devemos acabar com o papel de PM”, mas também diz que “ainda é preciso haver alguém dedicado ao trabalho que o PM fazia, só não vamos chamar de PM; vamos chamar simplesmente de uma pessoa comum e excelente”
Parece que o autor teve uma experiência ruim com PMs, e isso transparece quando ele fala de MBA; por isso, parece estar querendo jogar o bebê fora junto com a água do banho
Quando o negócio cresce, a especialização de papéis surge e passa a ser necessária. Existem PMs péssimos e é um trabalho difícil, mas eu ficaria realmente decepcionado se nossa equipe perdesse o PM
Pode ser que eu só tenha tido boas experiências com PMs, mas os PMs da minha empresa entendem o que os clientes querem e o que o produto deve oferecer, e equilibram, junto com o gerente de engenharia, o que é tecnicamente possível e a capacidade de implementação
Quando o gerente de engenharia diz “com esse cronograma, de jeito nenhum”, o PM encontra um plano alternativo para o produto
Este texto parece pular a etapa intermediária e simplesmente tentar mudar só o nome, sem motivo
Quem exatamente se imagina que decide quais problemas a equipe deve priorizar? Essa é justamente a responsabilidade central do papel de PM
No fim, parece que tiveram uma experiência ruim com um PM que não conseguiu tomar essa decisão de prioridade
Ainda assim, por causa dessa pessoa, precisei participar da reunião mais constrangedora em que já estive: durante uma hora inteira, do começo ao fim, ela expôs diante de um gestor sênior que não entendia absolutamente nada do produto — e esse gestor sênior entendia o produto
Bons PMs ajudam muito porque entendem o que os clientes querem, o que podemos entregar, cronogramas realistas e como lidar com o jurídico e as partes interessadas do negócio. Eu os ajudo quando precisam validar o lado técnico
Raramente falta à equipe ideias do que construir ou formas de melhorar a experiência de produto e operações. O gerente de produto é a pessoa que tenta garantir que se construa a coisa certa
Sou PM com 20 anos de carreira em TI e estou considerando um MBA para adquirir conhecimento e uma compreensão formal de negócios, e para me ajudar a crescer daqui em diante
PMs parecidos comigo não pegam um MBA e imediatamente começam, pegando emprestada uma expressão militar, a jogar o jogo da enrolação
O problema são as pessoas que saem direto do ensino médio para a faculdade, depois para o MBA e então para cargos de gestão. Tirando talvez um estágio curto no meio da graduação, muitas vezes elas não têm nem um dia de experiência de campo
É um texto estranho. Usa muitas palavras, mas no fim parece estar dizendo apenas que “contratar pessoas de baixo desempenho faz mal para a empresa”
A alternativa também é algo como “contrate pessoas boas, mas não as contrate para o papel de PM”
Parece escrito por alguém que teve uma experiência ruim com um PM que se achava o Steve Jobs. PMs também são pessoas comuns; não entendo por que presumir que todo mundo com esse título é alguém com senso de privilégio
Uma organização pode ter milhares de PMs, e cada um deles tem um chefe. É simplesmente um texto estranho
É algo como: “Não contrate gerentes de produto, porque eles não serão pessoas excelentes. Em vez disso, contrate pessoas excelentes — e não só uma, mas a equipe inteira!”
Contratam pessoas de baixo desempenho todos os dias, e não sei por quê. Um chimpanzé sem treinamento com uma pilha de currículos provavelmente teria uma taxa de acerto melhor
PMs atendem a uma necessidade muito específica. Essa necessidade é difícil de quantificar, mas dá para dizer que, sem um bom PM, tudo desmorona
Normalmente, eles reúnem informações sobre o que funciona ou não para os usuários, ouvem dos executivos o que é necessário para operar a empresa, entendem com líderes do setor para onde a indústria está indo, trabalham com design e refinam tudo isso em funcionalidades que precisam de fato ser construídas
Também trabalham com engenharia para avaliar o que é prático e quanto tempo levaria, de forma aproximada; removem funcionalidades que consomem muito tempo mas têm pouco valor; e ajudam para que as estimativas e a velocidade da equipe sejam minimamente previsíveis
Só isso já descreve o trabalho de 1,5 pessoa. Se você elimina a organização de produto, todo esse trabalho é distribuído pela equipe de engenharia, e nem todos os membros da equipe são bons nisso
Mesmo que se encontre um equilíbrio, quando uma pessoa sai surge uma lacuna invisível que nem sequer estava sendo procurada no recrutamento
Parece que muitas equipes se queimaram com organizações de produto disfuncionais. Essas organizações ficam desconectadas — ou parecem desinteressadas — dos aspectos de clientes, indústria e organização; em vez disso, gastam tempo demais em reuniões iterando mockups, microgerenciam designers a ponto de afastar pessoas boas e prendem engenheiros em reuniões de produto desnecessárias
O PM trabalha de perto com a equipe para definir o roadmap e priorizar o que terá maior impacto para clientes e para o negócio
Quando o PM faz bem seu trabalho, os engenheiros entendem com muita clareza qual problema devem resolver a seguir e por que devem resolvê-lo
Em segundo lugar, também importa se ela tem posição suficiente dentro da organização para se comunicar com a alta liderança sobre o projeto. Se tiver ambos os atributos, a situação é boa
O que aprendi trabalhando por mais de 12 anos no setor de tecnologia é que cargos são apenas uma forma de expressar os desejos da organização
Se você quer que alguém pense em produto, abre uma vaga de PM; se quer um líder de equipe, cria uma posição de gerente de engenharia
Títulos são elementos fictícios que nos permitem jogar o RPG chamado trabalho por vários ângulos. No fim, o que cada pessoa leva para o trabalho é uma combinação única de talentos e experiências
Algumas pessoas frequentemente atravessam essas fronteiras de papéis, e tudo bem. Elas têm ideias e podem até criar seus próprios títulos
A organização precisa ser inteligente o suficiente para deixar essas pessoas crescerem e prosperarem. Isso não quer dizer que alguém não possa ter sucesso como PM ou fazer um ótimo trabalho; quer dizer que, como as organizações geralmente não investem tempo suficiente para conhecer profundamente quem estão trazendo, oferecem papéis pré-cozidos
Um engenheiro também pode desempenhar o papel de PM, mas não pensa em tudo pela perspectiva de PM. Porque sua identidade principal não é a de PM, e sim a de engenheiro
Outra coisa que percebi no contexto de atravessar fronteiras de papéis é que, em geral, a parte mais valiosa do papel de uma pessoa são as responsabilidades que não foram definidas explicitamente
É difícil explicar, mas muitas vezes as pessoas entregam valor de maneiras difíceis de descrever ou quantificar
No geral, é uma visão bem dura, mas sem dúvida há partes corretas. Quando surge uma organização de produto dentro de uma empresa, ela tende a caminhar para comitês, OKRs, ciclos de revisão, planejamento e muita burocracia, como o autor descreveu
Antes, em um papel de engenharia de vendas voltado ao cliente, eu estava conduzindo o produto com bastante sucesso por influência e, achando ingenuamente que passaria a ter controle formal, assumi um cargo de gerente de produto
Quando me sentei na cadeira, era um trabalho de escritório extremamente limitado e que não combinava nada comigo. Era principalmente gestão de tickets e backlog, alinhar em vez de tomar decisões, escrever relatórios intermináveis em PowerPoint, e a tarefa mais criativa era criar o processo pelo qual a empresa formalizaria o roadmap do produto. Fugi em 6 meses
Essa função é bastante útil para dar visibilidade ao que está sendo construído e gerenciar prioridades conflitantes de um produto em crescimento. Mas não é formar ou controlar a direção de evolução do produto
É uma função de alinhamento, filtragem e, com sorte, coleta de dados; cria um rastro auditável de decisões e a impressão de uma tomada de decisão madura, para que os MBAs lá de cima durmam um pouco mais tranquilos
Normalmente eu produzia de 4 a 12 propostas de novos recursos (PRDs) por mês, variando conforme o tamanho da empresa e a quantidade de processo necessária
O formato era sempre: “os usuários atualmente têm o problema X, e para resolvê-lo precisamos construir Y. Y é assim...”
Claro que há dificuldades de alinhamento e comunicação, mas era sempre para descobrir o que construir em seguida
Entendo que nem todo papel de PM seja assim, mas não concordo que PM não possa ser melhor do que “alinhamento/filtragem/teatro de maturidade decisória”
Se o papel fosse apenas ordenar um backlog existente, eu ficaria curioso para saber quem definia os itens novos a serem colocados nesse backlog
Concordo que uma organização de produto pode virar uma entidade política e burocrática, em vez de uma área de apoio
Pessoalmente, acho que papéis de produto deveriam estar incorporados ao time de engenharia e reportar ao mesmo líder. O nível é discutível, mas assim um PM ruim pode ser tratado como um engenheiro ruim
Claro, se a empresa também não consegue demitir engenheiros ruins, aí há outro problema
O autor não oferece muito de um framework para isso
A solução do texto tem cheiro de teoria dos grandes homens
A parte final, de que “pessoas extraordinárias imaginam realidades alternativas, se dedicam completamente ao trabalho e movem montanhas pela força de vontade”, é reducionista demais
Quem move montanhas não é a força de vontade, mas as pessoas abaixo que de fato implementam a visão. Na melhor das hipóteses, essa “grande pessoa” alinha incentivos para mobilizar os executores e especialistas reais
Trabalho atualmente em uma grande empresa de tecnologia que quase não tem o papel de PM, então posso falar da sensação direta
Até agora, é misto. Já trabalhei em organizações com muitos PMs e concordo que elas não são lá grande coisa. Mas, no fim, o trabalho que um PM faria continua sendo necessário
Na nossa organização, essa responsabilidade cai formalmente sobre gerentes de software e desenvolvedores sêniores ou acima
Por exemplo, se você, como engenheiro sênior, lidera uma iniciativa da equipe, precisa assumir todas as atividades que um PM faria. Outras atividades ficam com o gerente ou gerente sênior
Do ponto de vista do desenvolvedor, é bem difícil. Como contribuidor individual, você precisa entregar seu próprio trabalho e ainda coordenar outras pessoas e garantir que as coisas sejam concluídas
Além de ser trabalho extra, sinceramente muitos desenvolvedores não têm as habilidades para serem PMs eficazes. A colaboração entre equipes também fica difícil, porque é preciso coordenar pessoas com linhas de reporte diferentes
Esse modelo frequentemente leva a falta de ownership, falta de responsabilização, esforços duplicados, coisas caindo pelas brechas e desordem geral
Dito isso, funciona bem para iniciativas internas de equipes pequenas com poucas pessoas envolvidas. Ele elimina o overhead de PM e dá controle a quem está construindo. Mas não tenho certeza de que sirva para iniciativas maiores
É verdade que muitos desenvolvedores não têm as habilidades de um PM eficaz, mas, para ser justo, muitos PMs também não têm habilidades de PM eficazes
A dificuldade de coordenar com pessoas em linhas de reporte diferentes também vale para PMs
A diferença central parece ser o julgamento sobre “vale a pena separar isso em um papel dedicado?”. Eu tendo a achar que, para engenheiros, quase nunca vale
Só pelo título, já me preparei para detestar. Achei que seria o típico texto do tipo “PMs são burros e a empresa só precisa de engenheiros inteligentes que dominem o mundo”
Mas não era esse tipo de texto, e acho que ele identificou o problema em si quase perfeitamente
Só que a solução desaparece como um passe de mágica. É algo como “contrate pessoas comuns, porém excelentes, cada uma muito boa em alguma coisa, obcecadas por seu ofício e movidas por qualidade; junte-as em uma equipe e faça-as trabalhar sem responsabilidade individual”
Parece ótimo, mas quem consegue citar um caso em que esse modelo tenha dado certo de fato em uma empresa com mais de 100 pessoas? Não sei como isso poderia funcionar na realidade
A Valve faz, ou pelo menos fazia, algo muito parecido. O manual de funcionários[0] era presença frequente no HN antigamente, mas hoje não vejo tanto. Fico curioso para saber se isso está funcionando bem para eles
[0] https://steamcdn-a.akamaihd.net/apps/valve/Valve_NewEmployee...
O autor parece ter trabalhado com gerentes de produto realmente medianos. Sou PM com formação autodidata em engenharia e já vi muita gente mediana em várias áreas
Vejo meu trabalho principalmente como gestão de riscos. Mesmo uma equipe de ótimos engenheiros e designers enfrenta muitos riscos no processo de lançar um bom produto
Talvez eles não tenham a habilidade de explicar a visão e convencer outras pessoas, ou a equipe jurídica pode impor requisitos ou restrições sobre o que pode ou não pode ser feito
Meu trabalho é administrar essas coisas para extrair o melhor da equipe e ajudá-la a se concentrar no que realmente importa: criar e lançar um bom produto
Julgo meu sucesso pelo quanto me tornei desnecessário. O objetivo é que eu não seja necessário, que a equipe tenha o contexto, a confiança e o apoio para tomar boas decisões sem mim
Gosto de trabalhar com engenheiros para que desenvolvam essas capacidades, e com meus parceiros de gestão de engenharia para entender os pontos fortes, fracos e objetivos de cada engenheiro e encontrar formas de crescimento
Entendo o argumento de que, em uma utopia ideal, talvez eu não fosse necessário. Mas, na maioria dos casos, fazer um trabalho realmente excelente envolve encarar desafios e riscos, e um bom PM é um agregador líquido de valor que colabora com a equipe para superá-los
É garantir que a equipe tenha o contexto, os requisitos, os insights, as métricas, os objetivos etc. de que precisa para fazer seu melhor trabalho, e que entenda qual problema resolver, para quem e por quê
Um bom PM cria um ambiente tão bem estruturado que o engenheiro pensa “PM não faz nada, então não é necessário”. Esse julgamento é míope e, sinceramente, ofensivo