Le rôle de product manager est une erreur

• Lorsqu’une entreprise de produits logiciels interprète à tort product-led comme « une structure où le PM prend toutes les décisions », elle applique à des PM de carrière ordinaires un modèle qui ne convient qu’à des leaders exceptionnels de type fondateur
• Le fait de confier le contrôle du produit à un seul leader dépend moins du principe lui-même que de la personne à qui on le confie ; cela suppose l’existence d’un profil rare, doté de vision, de charisme, de compétences techniques et de convictions fortes
• Quand un PM ordinaire reçoit trop d’autorité, les données, frameworks, procédures d’approbation, réunions et structures de rôles cessent d’être des outils de jugement pour devenir un rempart de déresponsabilisation et de politique interne
• Cette dynamique pousse les meilleurs à partir, et l’entreprise se retrouve enfermée dans des tâches à faible risque et des processus internes, perdant peu à peu vision et talents
• L’alternative n’est pas une organisation centrée sur le titre de PM, mais une équipe réunissant, dans chaque domaine, des personnes obsédées par la technique et la qualité, afin de traiter ensemble découverte produit, observabilité produit, ingénierie, design, business et connaissance du domaine

---

Le problème de confondre product-led avec un monopole du PM

• Beaucoup d’entreprises de produits logiciels sont fondées par des personnes plus compétentes en levée de fonds et en compréhension du secteur ciblé qu’en création de produits logiciels
• Ces fondateurs lancent l’entreprise grâce à leur expérience sectorielle et à leur réseau, mais s’ils pilotent directement toutes les décisions, les certitudes de l’expert métier peuvent nuire à l’entreprise
• Certains fondateurs reconnaissent qu’ils peuvent eux-mêmes représenter un risque et recrutent quelqu’un à qui confier la prise de décision
  • C’est alors qu’apparaît le malentendu suivant : « Nous devons être une entreprise produit, pas une organisation de services ; une entreprise produit est product-led, donc le PM doit en être responsable »
  • Ici, product-led ne signifie pas que le PM prend toutes les décisions
• Quand des objections sont formulées, on entend souvent l’argument selon lequel de grandes entreprises comme Amazon, Apple ou Tesla délèguent elles aussi le contrôle à une seule personne
• Beaucoup de grandes entreprises confient le contrôle à un individu unique, mais toutes les grandes entreprises n’utilisent pas le même modèle

Les prérequis du modèle à décideur unique

• Le modèle qui donne le contrôle de l’entreprise à une seule personne n’est pas tant erroné en soi ; sa réussite dépend de la personne à qui ce contrôle est donné
• Des figures comme Picasso, Jeff Bezos, Mozart, Steve Jobs, Nikola Tesla, Elon Musk, Robert Oppenheimer, Peter Thiel ou Léonard de Vinci sont admirées par le public pour leur vision, leur charisme, leur confiance, leur résilience et leur excellence
• Ce sont des personnes capables d’imaginer une réalité alternative, de s’immerger totalement dans leur travail et de provoquer de grands changements par leur seule volonté
• Si une telle personne existe réellement dans une organisation, le modèle de contrôle unique peut fonctionner avec une grande puissance

Les personnalités exceptionnelles ne sont pas des PM ordinaires

• Les grands personnages cités n’étaient pas des product managers
  • C’étaient des artistes, mathématiciens, inventeurs, scientifiques, CEO, et parfois plusieurs de ces rôles à la fois
• Ils étaient obsédés par leur vision et leur technique davantage que par les OKR, KPI, données ou avis des autres
• Une personnalité exceptionnelle peut avoir des opinions tranchées, un ego important, sa propre manière de faire, des aspérités et du mépris pour la médiocrité
  • Ces traits la rendent difficile à recruter dans une entreprise classique, et il est probable qu’elle-même n’ait pas envie de travailler dans la plupart des entreprises
• Si vous pouvez trouver une grande personne, ne pas l’entraver et supporter son intensité, vous pouvez lui confier le contrôle du produit et de l’entreprise
• En pratique, il est difficile de trouver ce type de personne ; il est probable qu’elle ne veuille pas travailler avec vous, ou que l’entreprise ne supporte pas son ego et son intensité

Quand on applique à un PM ordinaire une structure conçue pour une grande personnalité

• La plus grande erreur consiste à adopter un modèle opérationnel qui exige une personnalité exceptionnelle sans disposer d’une telle personnalité
• L’auteur critique le fait que les PM de carrière que l’entreprise peut recruter confortablement ne sont généralement pas de ce calibre
  • Ils sont décrits comme des larbins business, des fanatiques de frameworks, des experts thématiques, d’anciens makers ayant gravi l’échelle corporate, des obsédés des métriques, des diplômés de MBA, etc.
• Interpréter « product-led » comme le fait que le PM prend toutes les décisions, puis embaucher un PM de carrière, peut être fatal
• Comme ces PM manquent de vision, de charisme, d’expertise, de convictions fortes et de compétences techniques, ils avancent prudemment et agissent politiquement
• Conscients de leurs limites, ils répètent des comportements consistant à s’attribuer les réussites tout en évitant la responsabilité

Comment les données et les processus deviennent des moyens de défense

• La première étape est la militarisation de la prise de décision data-driven
  • Sans reconnaître qu’on peut trouver des données pour étayer presque n’importe quelle affirmation, ils présentent leurs propres décisions comme les seules rationnelles au regard des données
  • Quand les choses tournent mal, ils blâment le marché, la qualité des données ou la malchance de l’entreprise, en affirmant que ce n’est pas leur responsabilité
• L’étape suivante consiste à introduire des frameworks et des rôles partout
  • Apparaissent alors des frameworks de carrière en 18 étapes, des évaluations trimestrielles de performance, le PI planning, les ADR, PRD, RACI, MOSCOW, OKR, KPI, DORA, SAFe, etc.
  • Ne pas suivre le processus, ne pas être data-driven, manquer de documentation ou avoir une documentation non à jour deviennent des motifs de reproche
• L’organisation voit émerger des rôles comme Director of KPIs, Deputy Director of Product Operations ou Global Head of Digital Whiteboard Solutions
• Tout finit par nécessiter une approbation, et aucun processus ni domaine n’est entièrement contrôlé par une seule personne
  • Dans les grands comités, tout le monde peut dire « no », mais personne ne peut vraiment dire « yes »
• Les réunions explosent également
  • Les points de statut, réunions d’alignement, 1:1, réunions d’équipe dirigeante, discussions stratégiques, mises en contexte, décisions de release go/no-go et rapports projet se multiplient
• La dernière étape consiste à recruter beaucoup de mauvaises personnes
  • On recrute selon le critère de l’absence de menace, et toute trace d’excellence devient un motif de rejet
  • Le candidat idéal devient une personne polyvalente capable d’exécuter passablement ce qu’on lui demande, sans avis contraire ni intérêt particulier pour la qualité
  • Le nombre de PM explose, et chaque équipe et domaine se dote d’une couche de PM qui répète les mêmes comportements

Ce que l’organisation perd

• Quand la dynamique qui donne le pouvoir à des personnes ordinaires s’installe, les personnes excellentes finissent par partir
  • Elles sont écartées par un dictateur médiocre, ou partent d’elles-mêmes parce que l’environnement devient insupportable
• Le rythme de travail s’arrête, et exécuter quoi que ce soit devient douloureux, engageant et risqué
• Les grandes visions sont rapidement abandonnées, car jugées irréalistes
• Le travail de l’entreprise se limite aux gains faciles et aux choix sûrs
• Même des personnes qui ne sont pas extrêmement passionnées par leur métier ressentent la souffrance et partent ; celles qui sont assez anesthésiées pour rester aggravent le problème
• L’entreprise perd ses meilleurs talents, oublie sa vision, se replie sur elle-même et devient dénuée de sens
  • Dans le meilleur des cas, elle meurt à un moment donné ; dans le pire, elle survit à moitié en transformant des personnes passionnées en zombies qui détestent leur travail

L’alternative : des équipes de personnes excellentes au quotidien

• Il est possible de construire une entreprise produit qui réussit sans chercher une personnalité exceptionnelle, l’embaucher, lui confier le contrôle et supporter son intensité
• L’alternative consiste à recruter des personnes excellentes au quotidien
  • Chacune doit exceller dans un domaine
  • Elles doivent être obsédées par leur métier et animées par la qualité
  • L’équipe doit être composée de façon à minimiser le chevauchement entre leurs domaines d’excellence
• Plutôt que de morceler les responsabilités individuelles, on les laisse faire avec plaisir ce qu’elles aiment et consacrer leur temps et leurs compétences à l’entreprise
• Ces personnes peuvent aussi être exigeantes, têtues, avoir un ego fort, être atypiques ou changeantes
• Si on leur donne de bons problèmes et la possibilité de faire un excellent travail, elles se consacrent pleinement à la réussite de l’entreprise

La place des leaders et des PM

• Il n’est pas nécessaire d’abandonner totalement les leaders ; on peut aussi supprimer les team leads et placer des domain leads comme coordinateurs entre l’externe et l’interne
• Si l’on met un leader responsable dans chaque domaine, il faut placer à ce rôle une personne proche d’une grande personnalité
  • Il s’agit de quelqu’un qui se rapproche de Jobs, Musk ou Bezos par la vision, le charisme, l’intensité, la passion et le comportement extrême
• Si l’on met en responsabilité une personne confortable à court terme, obéissante et demandant moins d’attention, on risque de tomber dans la situation décrite plus haut
• Le rôle de PM au sens traditionnel n’a pas sa place dans une entreprise qui fonctionne bien, selon l’auteur
• En revanche, il faut des personnes obsédées par des domaines traditionnellement confiés aux PM, comme la découverte produit ou l’observabilité produit
  • Ces personnes peuvent avoir déjà porté le titre de PM, et ce n’est pas un problème en soi
  • La raison de les recruter n’est pas leur titre, mais leur obsession et leurs forces
  • Plutôt que de les placer dans un rôle de PM séparé, on les met dans une équipe avec des personnes obsédées par l’ingénierie, le design, la performance, le business et la connaissance du domaine

Le problème ne concerne pas seulement les PM

• Les mêmes problèmes apparaissent lorsqu’une personne dépourvue de vision, de charisme, de passion, de compétences techniques et de volonté devient responsable
• L’accent est mis sur les PM parce que, dans le développement de produits logiciels, il existe une tendance à placer aux responsabilités des personnes portant le titre de product manager
• Certains PM sont réellement exceptionnels et peuvent très bien réussir dans les deux modèles
• Mais ces PM ne sont pas nécessairement meilleurs que d’excellentes personnes issues d’autres parcours
• Ces PM constituent une très petite minorité, et l’auteur estime que la plupart des PM de carrière sont loin d’avoir la capacité de diriger par l’excellence

[GN⁺]

Avis sur Hacker News

• Dans mon entreprise actuelle, il y a beaucoup de gens intelligents, mais pour diverses raisons nous n’avons pas de product manager, et, résultat, le travail qu’un product manager devrait faire n’est tout simplement pas fait.
  Maintenir les relations clients, mener des entretiens utilisateurs, identifier des fonctionnalités potentielles, convaincre la direction, faire de la politique pour l’allocation des ressources : très peu d’ingénieurs ont envie de faire ce genre de choses.
  Dans mon entreprise précédente, 2 des 3 product managers étaient incompétents et ont été licenciés, mais l’un était vraiment excellent ; avec seulement une partie de son temps, il accomplissait en moins d’un an plus que ce que mon entreprise actuelle a fait en plus de deux ans.
  Je suis d’accord pour dire qu’il n’y a pas assez de bons product managers. Le nombre de personnes capables de devenir de bons product managers augmente linéairement avec la population, mais l’industrie du logiciel a explosé de façon exponentielle, si bien qu’il faut aujourd’hui, à mon avis, 100 fois plus de rôles de PM qu’il n’existe réellement d’excellents PM.

  • Ah, donc c’était ça le travail d’un product manager. Quand des product managers ont été introduits dans mon ancienne entreprise, ils ne faisaient presque rien de tout cela, et ne parlaient pas non plus aux clients.
    Ils n’étaient pas techniques non plus, donc ils ne géraient pas les tickets Jira, et la gestion de la direction était surtout assurée par les managers.
    Ces product managers semblaient surtout assister à des réunions, parler avec la direction, parler avec les ingénieurs, rédiger des documents et présider des réunions de planification de sprint qui s’allongeaient.
    Je pense qu’un product manager qui s’occupe des questions clients, utilisateurs et ressources pourrait avoir beaucoup plus de valeur.
  • Tout cela me semble juste. J’ai travaillé 20 ans comme ingénieur, puis je suis devenu engineering manager, et l’an dernier j’ai pris mon premier rôle de PM. L’état est catastrophique, car cette société de logiciels de 20 ans n’a jamais vraiment fait de bonne gestion produit.
    J’entendais sans cesse « nous sommes une entreprise engineering-first », mais en pratique cela voulait dire que les équipes d’ingénierie couraient après les dernières technologies comme bon leur semblait.
    Nous avons 3,5 produits principaux, en réalité presque 4,5, chacun construit avec une stack technique différente, et environ 8 autres produits à prendre en charge à cause d’exigences legacy. Il n’y a ni standardisation ni interopérabilité entre les produits, et aucun transfert de connaissances, ce qui fait exploser les coûts de développement.
    Deux fois cette année, j’ai dû expliquer à des ingénieurs présents depuis 20 ans pourquoi c’était problématique qu’une API utilise uniquement TLS 1.3, qu’une autre soit en 1.x, et qu’une autre encore n’exige même pas TLS.
    Les clients nous détestent. Pour mon produit, les supports marketing ont été rédigés d’abord, puis on a laissé les ingénieurs se débrouiller pour le construire. Une seule étape consistant à déplacer des données Oracle vers du parquet a été réalisée avec trois langages et deux bases intermédiaires (MySQL et PG), et j’ai tout juste réussi à les empêcher d’y ajouter Redis.
    Heureusement, un fonds de private equity nous a rachetés il y a deux ans et nous avons maintenant reçu un ultimatum : gagner de l’argent ou disparaître. C’était un centre de coûts dans une entreprise de 20 ans qui n’a jamais gagné d’argent ; et même si nous n’atteignons pas nos objectifs, l’univers s’en portera probablement mieux si le désastre de conception logicielle que nous avons créé disparaît.
  • La gestion produit est un métier difficile. Il faut être assez technique pour comprendre ce qui se passe et détecter les absurdités, tout en ayant aussi une grande intelligence émotionnelle pour parler aux gens.
    Un product manager médiocre devient une sorte de chef de projet qui suit un registre de tâches supplémentaire ; quelqu’un d’intelligent comprend profondément le business, puis obtient une promotion ou s’en va.
    Ce rôle est aussi difficile à gouverner. Parfois, on s’attribue beaucoup de mérite pour le travail des autres ; parfois, aucun mérite n’est reconnu et la carrière stagne.
    Si l’on rejette ce rôle sur l’ingénierie, le management d’ingénierie ou le management général, on affaiblit la capacité d’ingénierie. Si l’on doit recruter des ingénieurs, il faut les sélectionner sur cette compétence et les protéger des personnes extérieures ; mais si l’équipe doit aussi gérer toutes ces interactions, on finit par recruter des profils aux compétences hybrides, et l’aspect ingénierie se dilue.
  • Le fait qu’une fraction du temps d’un bon product manager ait permis d’accomplir davantage que dans une entreprise sans aucun product manager est un bon témoignage.
    Garder volontairement la capacité des product managers sous tension peut servir de mécanisme de contrainte : cela les force à se concentrer sur le niveau d’exigence et la vision, et évite qu’ils s’enfoncent trop dans les détails, créent des processus inutiles ou surdéfinissent les fonctionnalités.
  • S’ils ignorent ce genre de choses, sont-ils vraiment si intelligents ? Parler aux utilisateurs a toujours fait partie de la liste des choses nécessaires pour un ingénieur.
    Dans une industrie tech gonflée par plus de dix ans de croissance à taux bas, beaucoup de gens pouvaient réussir simplement en se présentant au travail.

• C’est un texte confus. Il affirme qu’il faudrait « supprimer le rôle de PM », tout en disant qu’« il faut toujours quelqu’un dédié aux tâches que faisaient les PM, mais ne l’appelons pas PM, appelons-le simplement une personne ordinairement excellente ».
  L’auteur semble avoir eu une mauvaise expérience avec des PM, et l’allusion aux MBA en porte la trace ; on dirait donc qu’il veut jeter le bébé avec l’eau du bain.
  Quand une entreprise grandit, la spécialisation des rôles apparaît et devient nécessaire. Il existe de mauvais PM et c’est un métier difficile, mais si notre équipe perdait notre PM, ce serait vraiment décevant.

  • En particulier, vu la manière répétée dont le texte parle de céder le contrôle de l’entreprise aux PM, cela donne l’impression d’un texte né d’une mauvaise expérience avec un PM.
    Peut-être que je n’ai eu que de bonnes expériences avec des PM, mais dans mon entreprise, les PM comprennent ce que veulent les clients et ce que le produit doit fournir, puis équilibrent avec l’engineering manager ce qui est techniquement possible et la capacité de mise en œuvre.
    Quand l’engineering manager dit : « avec ce planning, c’est absolument impossible », le PM trouve un plan alternatif pour le produit.
  • Un mode d’échec très courant dans le leadership d’organisation, c’est : « ce rôle/cet objet ne sert à rien, supprimons-le… ah, en fait on en avait besoin. Faisons-le revenir sous un autre nom pour ne pas reconnaître l’erreur ».
    Ce texte donne l’impression de sauter l’étape intermédiaire et de vouloir simplement changer le nom, sans vraie raison.
  • Il dit qu’il suffit que tout le monde construise une équipe formidable, mais réussir cette magie du recrutement est déjà difficile ; ensuite il dit qu’il suffit de « leur donner de bons problèmes ».
    Qui est censé décider exactement quels problèmes l’équipe doit prioriser ? C’est précisément la responsabilité centrale du rôle de PM.
    Au final, il semble avoir eu une mauvaise expérience avec un PM qui n’a pas su prendre ces décisions de priorité.
  • J’ai eu la chance de travailler constamment avec de très bons product managers, et la seule exception n’a pas tenu longtemps avant de causer de gros dégâts.
    Cela dit, à cause de cette personne, j’ai dû assister à la réunion la plus gênante à laquelle j’aie jamais participé : pendant une heure entière, du début à la fin, elle a montré devant un cadre supérieur qu’elle ne comprenait absolument pas le produit, alors que ce cadre, lui, le comprenait.
    Les bons PM aident beaucoup parce qu’ils comprennent ce que veulent les clients, ce que nous pouvons fournir, les délais réalistes, ainsi que la gestion du juridique et des parties prenantes métier. Moi, je les aide quand ils doivent vérifier l’aspect technique.
    Il est rare qu’une équipe manque d’idées à construire ou de moyens d’améliorer l’expérience produit et opérationnelle. Le product manager est la personne qui cherche à faire construire les bonnes choses.
  • Ce serait vraiment bien que les MBA exigent une expérience préalable dans l’industrie. Certains le savent déjà, mais il faudrait que ce soit plus répandu.
    Je suis PM avec 20 ans d’expérience dans l’IT, et j’envisage un MBA pour acquérir des connaissances et une compréhension formelle du business, et pour m’aider à progresser.
    Les PM comme moi ne commencent pas, dès qu’ils obtiennent un MBA, à jouer — pour reprendre une expression militaire — à des jeux de connerie.
    Le problème, ce sont les gens qui passent directement du lycée à l’université, au MBA, puis à un poste de management. À part peut-être un court stage au milieu du cursus de licence, ils n’ont souvent pas un seul jour d’expérience de terrain.

• C’est un texte étrange. Il utilise beaucoup de mots, mais au fond, j’ai l’impression qu’il dit simplement : « recruter des personnes peu performantes nuit à l’entreprise ».
  L’alternative proposée ressemble aussi à : « recrutez de bonnes personnes, mais pas dans un rôle de PM ».
  On dirait un texte écrit par quelqu’un qui a eu une mauvaise expérience avec un PM qui se prenait pour Steve Jobs. Les PM sont juste des gens ordinaires ; je ne comprends pas pourquoi on suppose que toutes les personnes qui portent ce titre sont des individus imbus de leurs privilèges.
  Une organisation peut avoir des milliers de PM, chacun avec son propre manager. C’est juste un texte bizarre.

  • J’ai plutôt compris ce passage dans le sens inverse. Steve Jobs était un leader hors du commun qui créait de bons produits grâce à une volonté énorme, et si l’on essaie de remplacer ce genre de personne par un product manager ordinaire, on obtient un produit ordinaire.
  • J’allais dire à peu près la même chose.
    C’est du genre : « ne recrutez pas de product managers, ils ne seront pas formidables. Recrutez plutôt des gens formidables, et pas seulement une personne : toute une équipe ! »
  • Les personnes qui recrutent semblent tout simplement incapables d’arrêter d’embaucher des profils peu performants. Surtout celles qui parlent beaucoup de la nécessité de processus pour éviter que ce genre de chose arrive.
    Elles recrutent des profils peu performants tous les jours, et je ne comprends pas pourquoi. Un chimpanzé non entraîné avec une pile de CV aurait probablement un meilleur taux de réussite.

• Le PM répond à un besoin très précis. Ce besoin est difficile à quantifier, mais on peut dire que sans un bon PM, tout s’écroule.
  En général, il recueille des informations auprès des utilisateurs sur ce qui fonctionne ou non, écoute les dirigeants sur ce dont l’entreprise a besoin pour fonctionner, comprend auprès des leaders du secteur où va l’industrie, travaille avec le design, puis distille tout cela en fonctionnalités qu’il faut réellement construire.
  Il travaille aussi avec l’ingénierie pour déterminer ce qui est praticable et combien de temps cela prendra à peu près, supprime les fonctionnalités coûteuses en temps mais peu utiles, et aide à rendre les estimations et la vélocité de l’équipe relativement prévisibles.
  À ce stade, on a déjà décrit l’équivalent d’un poste et demi. Si l’on supprime l’organisation produit, tout ce travail se retrouve réparti dans l’équipe d’ingénierie, et tout le monde dans l’équipe n’est pas forcément bon à ce jeu-là.
  Même si l’équilibre se fait, si une personne part, il se crée un vide invisible que vous ne cherchiez même pas à combler au recrutement.

  • Je suis vraiment d’accord. Je ne voudrais pas travailler sans une organisation produit qui fonctionne.
    Beaucoup d’équipes semblent avoir été échaudées par des organisations produit dysfonctionnelles. Ces organisations paraissent déconnectées ou désintéressées des dimensions client, industrie et organisation, et consacrent à la place énormément de temps à des réunions où l’on itère sur des mockups, micromanagent les designers au point de faire partir les bons, et bloquent les ingénieurs dans des réunions produit inutiles.
  • Cela inclut aussi le fait de défendre l’obtention d’un budget pour le projet et d’impliquer les parties prenantes.
  • Les PM avec lesquels j’ai travaillé récemment se souciaient surtout des envies des dirigeants. Littéralement toutes les autres responsabilités mentionnées ci-dessus étaient prises en charge par d’autres personnes.
  • En tant que PM, cette description est exacte. Un PM ne devrait pas être un décideur autoritaire qui dit à l’équipe quoi construire, comme le suggère le texte ; il devrait être un allié proche de l’équipe.
    Le PM travaille étroitement avec l’équipe pour définir la roadmap et prioriser ce qui aura le plus grand impact pour les clients et le business.
    Quand un PM fait bien son travail, les ingénieurs comprennent très clairement quel problème ils doivent résoudre ensuite et pourquoi.
  • J’ai du mal à être d’accord avec l’idée qu’un excellent product management soit difficile à quantifier. Il y a une dimension créative, mais l’un des indicateurs faciles à voir est la compréhension d’une analyse concurrentielle stratégique, et non un simple bingo de fonctionnalités.
    Deuxièmement, il est important d’avoir aussi la stature interne nécessaire pour communiquer avec la direction générale au sujet du projet. Si ces deux attributs sont réunis, on est dans une bonne situation.

• Ce que j’ai appris en plus de 12 ans dans la tech, c’est qu’un rôle n’est qu’une manière pour une organisation d’exprimer ce qu’elle souhaite
  Si elle veut que quelqu’un pense produit, elle ouvre un poste de PM ; si elle veut un team lead, elle crée un poste d’engineering manager
  Les intitulés sont des éléments fictifs qui nous permettent de jouer au RPG du travail sous différents angles. Au final, ce qu’on apporte au travail, c’est la combinaison unique de ses talents et de son expérience
  Certaines personnes franchissent souvent ces frontières de rôle, et ce n’est pas grave. Elles ont des idées et peuvent même inventer leur propre intitulé
  Les organisations devraient être assez intelligentes pour laisser ces personnes grandir et s’épanouir. Cela ne veut pas dire qu’on ne peut pas réussir comme PM ni faire du très bon travail ; cela veut dire que, comme les organisations ne prennent généralement pas assez le temps de vraiment comprendre les personnes qu’elles recrutent, elles proposent des rôles préfabriqués

  • Oui. Ces derniers temps, j’ai vraiment fini par adopter cette idée. Un rôle, c’est recruter quelqu’un pour qu’il pense toujours depuis un certain point de vue
    Un ingénieur peut aussi jouer le rôle de PM, mais il ne pense pas tout du point de vue PM. Parce que son identité principale n’est pas celle d’un PM, mais celle d’un ingénieur
    Une autre chose que j’ai comprise, dans ce contexte de franchissement des frontières de rôle, c’est que la partie la plus précieuse du rôle d’une personne est généralement constituée de responsabilités qui ne sont pas explicitement définies
    C’est difficile à expliquer, mais les gens apportent souvent de la valeur d’une manière difficile à décrire ou à quantifier
  • Je suis d’accord à 100 % avec l’idée que les organisations devraient être assez intelligentes pour permettre aux gens de grandir et de s’épanouir. Mais j’ai vu beaucoup d’échecs précisément sur ce point, surtout dans les grandes organisations

• Dans l’ensemble, c’est un point de vue assez harsh, mais il y a clairement une part de vrai. Quand une organisation produit apparaît dans une entreprise, elle a tendance à dériver vers des comités, des OKR, des cycles de revue, de la planification et beaucoup de bureaucratie, comme le décrit l’auteur
  Dans un ancien rôle de sales engineering au contact des clients, je pilotais très efficacement le produit par l’influence, et j’ai naïvement accepté un poste de product manager en pensant obtenir un contrôle formel
  Une fois installé, j’ai découvert un poste de bureau extrêmement contraint, qui ne me convenait pas du tout. L’essentiel consistait à gérer des tickets et un backlog, à coordonner au lieu de décider, et à produire d’interminables rapports PowerPoint ; le travail le plus créatif était de concevoir le processus par lequel l’entreprise formaliserait la roadmap produit. Je me suis enfui au bout de six mois
  Cette fonction est assez utile pour donner de la visibilité sur ce qui est construit et gérer les priorités contradictoires d’un produit en croissance. Mais elle ne consiste pas à façonner ni à contrôler la direction d’évolution du produit
  C’est une fonction de tri, de filtrage et, avec un peu de chance, de collecte de données ; elle crée une trace décisionnelle auditable et une impression de maturité décisionnelle qui aide les MBA d’en haut à dormir un peu mieux

  • Pour ajouter un autre point de vue, dans les trois entreprises B2C, sur deux secteurs, où j’ai travaillé comme PM, j’ai été étroitement impliqué dans la définition et le contrôle de la direction d’évolution du produit
    En général, je produisais 4 à 12 propositions de nouvelles fonctionnalités (PRD) par mois, le nombre variant selon la taille de l’entreprise et la quantité de processus nécessaire
    La forme était toujours : « les utilisateurs ont actuellement le problème X, et pour le résoudre, nous devons construire Y. Y ressemble à ceci… »
    Bien sûr, il y avait des difficultés de coordination et de communication, mais c’était toujours pour déterminer quoi construire ensuite
    Je comprends que tous les rôles de PM ne soient pas comme ça, mais je ne suis pas d’accord avec l’idée qu’un PM ne peut pas être meilleur que du “tri/filtrage/théâtre de maturité décisionnelle”
    Si le rôle se limitait à ordonner un backlog existant, je me demande qui définissait les nouveaux éléments à y ajouter
  • Au fond, le problème vient du manque de définition claire du rôle et des responsabilités du PM, ainsi que du manque de responsabilité
    Je suis d’accord sur le fait qu’une organisation produit peut devenir une entité politique et bureaucratique, plutôt qu’un soutien
    Personnellement, je pense que les rôles produit devraient être intégrés dans les équipes d’ingénierie et reporter au même responsable. Le niveau hiérarchique peut se discuter, mais c’est ce qui permet de traiter un mauvais PM comme un mauvais ingénieur
    Bien sûr, si l’entreprise n’arrive pas non plus à se séparer de mauvais ingénieurs, alors elle a un autre problème
  • D’accord. La question est donc de savoir comment mettre en place efficacement la stewardship et la responsabilité sur les problèmes produit sans organisation dédiée
    L’auteur ne propose pas vraiment de framework à ce sujet

• La solution de l’article sent la théorie du grand homme
  La dernière partie — « les personnes extraordinaires imaginent des réalités alternatives, se consacrent entièrement à leur travail et déplacent des montagnes par leur volonté » — est beaucoup trop réductrice
  Ce ne sont pas la volonté qui déplace les montagnes, mais les personnes en dessous qui mettent réellement la vision en œuvre. Au mieux, ce “grand personnage” aligne les incitations pour faire bouger les exécutants et les experts réels

  • Il y a aussi le coup classique contre les MBA
  • Oui. “Au mieux”, cela revient à agir comme le démon de Maxwell, donc à ne servir à rien

• Comme je travaille actuellement dans une grande entreprise tech qui a très peu de rôles de PM, je peux donner mon ressenti direct
  Pour l’instant, c’est mitigé. J’ai aussi travaillé dans des organisations avec beaucoup de PM, et je suis d’accord pour dire que ces organisations ne sont pas terribles. Mais, au final, le travail que font les PM reste nécessaire
  Dans notre organisation, cette responsabilité retombe officiellement sur les software managers et les développeurs seniors ou plus
  Par exemple, quand on dirige une initiative d’équipe en tant qu’ingénieur senior, on doit prendre en charge toutes les activités que ferait un PM. D’autres activités sont assumées par le manager ou le senior manager
  Du point de vue d’un développeur, c’est assez difficile. Il faut faire son propre travail en tant que contributeur individuel, tout en coordonnant d’autres personnes et en s’assurant que les choses aboutissent
  Ce n’est pas seulement du travail supplémentaire ; honnêtement, beaucoup de développeurs n’ont pas les compétences nécessaires pour être des PM efficaces. La collaboration entre équipes devient aussi difficile, car il faut coordonner des personnes qui ne dépendent pas de la même chaîne hiérarchique
  Cette approche mène souvent à un manque d’ownership, un manque de responsabilité, des efforts dupliqués, des sujets qui passent entre les mailles du filet et un désordre général
  Cela dit, elle fonctionne bien pour de petites initiatives au sein d’une équipe avec quelques personnes impliquées. Elle supprime l’overhead PM et donne le contrôle aux personnes qui construisent. Mais je ne suis pas sûr qu’elle convienne aussi aux initiatives plus importantes

  • Vu autrement, faire son travail de contributeur individuel tout en coordonnant d’autres personnes et en faisant en sorte que le travail aboutisse, c’est pour moi la définition d’un ingénieur senior/lead
    C’est vrai que beaucoup de développeurs n’ont pas les compétences pour être des PM efficaces, mais, pour être juste, beaucoup de PM n’ont pas non plus les compétences pour être des PM efficaces
    La difficulté de coordonner des personnes relevant d’autres chaînes hiérarchiques vaut aussi pour les PM
    La différence centrale semble être le jugement sur la question : “est-ce que cela vaut la peine d’en faire un rôle dédié ?” Pour les ingénieurs, j’ai tendance à penser que cela n’en vaut presque jamais la peine

• Rien qu’en lisant le titre, je m’étais préparé à détester. Je pensais que ce serait le genre de texte typique du type « les PM sont idiots, et une entreprise n’a besoin que d’ingénieurs intelligents qui dominent le monde »
  Mais ce n’était pas ça, et je trouve qu’il cerne presque parfaitement le problème lui-même
  En revanche, la solution disparaît d’un revers de main. En gros : « recrutez des gens ordinaires mais formidables, chacun excellent dans quelque chose, obsédé par son métier et mû par la qualité, mettez-les en équipe et faites-les travailler sans responsabilité individuelle »
  Ça sonne bien, mais qui peut citer un cas où cette approche a réussi dans une entreprise de plus de 100 personnes ? Je ne vois pas comment ça pourrait fonctionner dans la réalité

  • Nous faisons ça, mais comme nous sommes 15, ça ne s’applique pas
    Valve applique, ou du moins appliquait, une méthode très similaire. Le manuel des employés[0] était autrefois un habitué de HN, mais on le voit moins ces temps-ci. Je me demande si cela fonctionne bien pour eux
    [0] https://steamcdn-a.akamaihd.net/apps/valve/Valve_NewEmployee...
  • Cette « solution » ne fonctionne pas non plus universellement dans les entreprises de moins de 10 employés

• L’auteur semble vraiment avoir travaillé avec des chefs de produit très ordinaires. Je suis PM avec un parcours d’ingénieur autodidacte, et j’ai vu beaucoup de gens ordinaires dans de nombreux domaines
  Je vois mon travail principalement comme de la gestion des risques. Même une équipe composée d’excellents ingénieurs et designers rencontre de nombreux risques au moment de lancer un bon produit
  Elle peut ne pas avoir les compétences nécessaires pour expliquer la vision et convaincre les autres, ou l’équipe juridique peut imposer des exigences ou des contraintes sur ce qui est possible ou non
  Mon travail consiste à gérer tout cela pour faire ressortir les forces de l’équipe et l’aider à se concentrer sur ce qui compte vraiment : construire et lancer un bon produit
  Je juge le succès à l’aune du degré auquel je suis devenu inutile. L’objectif est que l’on n’ait plus besoin de moi, que l’équipe dispose du contexte, de la confiance et du soutien nécessaires pour prendre de bonnes décisions sans moi
  J’aime travailler avec les ingénieurs pour les aider à développer ces capacités, et avec mes partenaires engineering managers pour comprendre les forces, les faiblesses et les objectifs de chaque ingénieur, afin de trouver comment les faire progresser
  Je comprends aussi l’argument selon lequel, dans une utopie idéale, je pourrais ne pas être nécessaire. Mais dans la plupart des cas, pour faire un travail vraiment excellent, on se heurte à des défis et à des risques, et un bon PM est un apporteur net de valeur qui collabore avec l’équipe pour les surmonter

  • Je suis PM moi aussi et je suis d’accord. Je juge si je fais bien mon travail à la fluidité avec laquelle tout fonctionne pour l’équipe
    Il s’agit de faire en sorte que l’équipe dispose du contexte, des exigences, des insights, des métriques, des objectifs, etc. dont elle a besoin pour faire son meilleur travail, et qu’elle comprenne quel problème résoudre, pour qui et pourquoi
    Un bon PM crée un environnement si bien huilé que les ingénieurs en viennent à penser : « le PM ne fait rien, donc il ne sert à rien ». Ce jugement est myope et, franchement, insultant