- Le débat sur le nombre de PM à intégrer dans une équipe produit s’est intensifié après la réorganisation de l’organisation product management chez Airbnb et des exemples de startups qui grandissent sans PM
- Plus le nombre de PM augmente, plus une structure peut émerger où le temps est consacré à la gestion de projet et aux mises à jour de roadmap plutôt qu’aux résultats business du produit
- Dans des équipes composées de designers et d’ingénieurs expérimentés, le travail de PM n’a pas forcément besoin d’être à temps plein, et le modèle d’un PM par équipe mérite d’être reconsidéré selon le contexte
- Le bon moment pour recruter un premier PM arrive lorsque les fondateurs ne peuvent plus participer à toutes les décisions produit majeures, généralement autour de 50 à 100 personnes et de 3 à 5 équipes produit
- Augmenter le nombre de PM ne suffit pas à faire d’une organisation une structure centrée produit, et cela peut au contraire affaiblir le sentiment de responsabilité produit que devraient porter designers et ingénieurs
Réduire les PM et élargir la responsabilité produit
- Le débat sur le nombre de PM nécessaires s’est intensifié après des articles sur la réorganisation de l’organisation product management chez Airbnb et sur des startups capables de croître sans PM
- Dans beaucoup d’entreprises, les PM passent souvent leurs journées à des tâches comme la gestion de projet ou la mise à jour de la roadmap, plutôt qu’à optimiser le produit pour l’activité de l’entreprise
- En règle générale, il devrait y avoir moins de PM que d’équipes produit, et le modèle consistant à mettre un PM dans chaque équipe doit être réévalué selon le produit et le contexte de l’équipe
- Si la charge produit est importante et que l’équipe est junior, un PM dédié peut être nécessaire pour une équipe
- Dans une équipe avec des ingénieurs et des designers expérimentés, le rôle de PM n’a pas besoin d’être à temps plein, voire ne devrait pas l’être
- Dans une startup, le bon moment pour recruter un premier PM est celui où les fondateurs ne peuvent plus participer à toutes les décisions produit importantes
- En général, le repère se situe autour de 50 à 100 personnes dans l’organisation et de 3 à 5 équipes produit
- La stratégie produit globale doit déjà être claire, et le PM doit participer à des orientations et décisions d’un niveau plus opérationnel sur cette base
- Pour ce premier recrutement, un PM senior est plus adapté qu’un PM junior ou qu’un CPO
- Le candidat pourra éventuellement endosser plus tard un rôle de CPO à mesure que l’organisation grandit, mais les fondateurs doivent en pratique continuer à jouer le rôle de responsables produit
Mettre en place des équipes vraiment centrées produit
- La responsabilité produit ne doit pas se concentrer sur un seul PM ; le design et l’ingénierie doivent eux aussi comprendre directement les utilisateurs et le contexte produit
- Les designers et les ingénieurs doivent participer activement à la construction du produit et mener les discussions détaillées sur le produit
- Le PM ne doit pas devenir l’unique auteur de l’UX, des wireframes, du suivi d’avancement, de l’animation des stand-up ou des PRD/spécifications
- Le PM doit se concentrer sur l’expression de la vision produit, le choix des bons problèmes, le maintien de la bonne direction produit et l’alignement avec les besoins business
- Le “Guide to product development” de Michael Seibel renvoie à un exemple de mise en œuvre de cette approche chez Social Cam
- L’équipe doit partager activement le contexte et les éléments qui fondent son jugement
- Le design et l’ingénierie doivent aussi pouvoir accéder aux retours utilisateurs
- La résolution de problèmes ne doit pas être centrée sur le PM, mais relever de la collaboration entre produit, design et ingénierie
- Quatre pratiques permettent de construire des équipes orientées produit
- Commencer ensemble : avant d’écrire des tickets ou des spécifications, avant de choisir une solution, design, ingénierie et produit/fondateurs discutent ensemble pour s’aligner sur la manière d’avancer et le plan
- Exposer tout le monde aux utilisateurs : participer directement à la recherche utilisateur et aux tests d’utilisabilité, ou observer les usages via du streaming vidéo et des outils comme Lookback
- Faire attention à la manière de gérer les équipes : si la performance est mesurée au nombre de tickets fermés ou aux story points, l’équipe finira par se concentrer sur le traitement des tickets plutôt que sur la création d’un bon produit
- Ne pas utiliser d’outils PM : si les retours utilisateurs, les insights, les données, les spécifications et la roadmap sont enfermés dans un outil PM distinct, l’ensemble de l’équipe aura du mal à accéder au contexte produit
- Le développement produit est par nature difficile à prédire, et il est plus important de livrer la bonne chose qui a un impact business que de simplement livrer
- Dans les grandes entreprises réellement centrées produit, les PM sont très importants, mais leur nombre nécessaire peut facilement être surestimé, et l’augmentation du nombre de PM ne conduit pas automatiquement à une meilleure focalisation produit
1 commentaires
Avis de Hacker News
En tant qu’engineering manager ou responsable d’une organisation fonctionnelle, j’ai travaillé assez longtemps avec des product managers, et j’ai aussi joué temporairement le rôle de PM pour des produits internes dans une entreprise tech de taille moyenne
Je considère que la gestion de produit fait partie des domaines les plus importants de ce que fait une entreprise. Mais c’est un travail vraiment difficile, et plus un PM manque de compétences, plus il risque de s’en éloigner et de dériver vers le micromanagement ou la politique interne, sous prétexte de « piloter » l’équipe d’ingénierie
Dans les organisations où l’ingénierie et le produit relèvent de chaînes de commandement séparées, ce problème est difficile à traiter, et même si on le fait remonter, la bande passante à ce niveau est naturellement très limitée. Du point de vue d’un EM, ces PM finissent souvent par rendre la vie des meilleurs ingénieurs pénible, ce qui les pousse finalement à partir
Aujourd’hui, je pense que la meilleure approche consiste à placer dans chaque équipe un PM de type mini-CEO et, s’il n’est pas suffisamment solide techniquement, à l’associer à un mini-CTO. Cela laisse beaucoup moins de place à la politique et beaucoup plus au travail d’équipe
Les équipes les plus performantes dans lesquelles j’ai travaillé n’avaient pas de rôle produit dédié, et toutes les décisions étaient prises par les développeurs
Aujourd’hui, je pense que le mieux est d’écarter du chemin des développeurs les profils non techniques, et même les profils vaguement techniques, afin que les développeurs puissent construire sereinement
Ce que je vois, ce sont des gens qui défendent leurs options et essaient d’obtenir du soutien. Je n’ai jamais vu cette politique dont les gens se plaignent. Peut-être que j’ai juste eu de la chance
Est-ce que la politique désigne quelqu’un qui a techniquement tort mais qui défend son point de vue de manière plus convaincante ? Qu’est-ce que la « politique » ? Ou alors je ne suis toujours pas assez haut placé, même en étant senior principal
Cet article, et beaucoup de gens qui essaient d’analyser ce sujet, passent à côté d’un élément central : les incitations
Beaucoup de développeurs sont davantage passionnés par la technologie elle-même : coder, résoudre des problèmes techniques complexes, créer des solutions efficaces. Les récompenses formelles comme les promotions, les bonus ou la reconnaissance sont aussi souvent liées à des réalisations techniques
Si un développeur consacre 40 heures à de la recherche client, il se peut qu’il ne soit pas reconnu ou récompensé officiellement autant que s’il avait livré une prouesse technique, comme développer une nouvelle solution d’authentification utile à toute l’équipe
Changer cette dynamique ne peut pas se limiter à encourager les développeurs à passer plus de temps sur la gestion de produit. Il faut un changement systémique dans ce que l’organisation valorise et dans la manière dont elle le récompense
Faire évoluer la structure d’incitation d’un modèle centré sur la technique vers un modèle centré sur l’utilisateur a un impact important sur le rôle des managers intermédiaires et supérieurs. Ce type de changement ébranle le socle de leurs rôles et responsabilités, et peut se traduire par une perte de contrôle et d’influence
C’est pourquoi ce genre d’évolution risque de rencontrer une résistance discrète mais forte de la part du middle et top management. Ces personnes disposent souvent d’un pouvoir politique et d’intérêts acquis importants au sein de l’organisation
Dans tous les métiers d’artisanat, c’est au contact du réel qu’on apprend. Un réalisateur peut regarder son film mille fois en salle de montage, mais la première projection avec un vrai public lui en apprendra plus que ces mille heures
Un menuisier peut être satisfait de fabriquer un meuble toute la semaine, mais le vrai moment arrive quand ce meuble est installé dans la pièce du client. Le logiciel, c’est pareil
Pour qu’un ingénieur logiciel se soucie des utilisateurs, il doit recevoir du feedback direct sur ce qui fonctionne bien et ce qui est nul, et si possible le voir de ses propres yeux
Un bon ingénieur logiciel a une certaine fierté à faire du bon travail. Si cette fierté n’est liée qu’au code, à l’historique des commits et à d’autres notions abstraites, sans aucun lien avec la qualité de l’usage réel pour les utilisateurs, comment pourrait-il commencer à s’y intéresser ?
Ça n’a presque rien à voir avec l’article, mais la tendance actuelle à utiliser des images IA comme image principale de billets de blog me rend fou
Si, au moment d’écrire, aucune image principale claire ne vous est venue à l’esprit, j’aimerais que vous ne gaspilliez pas ma bande passante à télécharger les rêves absurdes d’un ordinateur
Je suis plutôt favorable aux images IA, parce que c’est un outil très précieux. Mais si vous utilisez une image IA comme seule image de la page, il faut vraiment qu’il y ait une bonne raison, pas simplement pour remplir l’espace
Surtout si vous n’avez même pas correctement vérifié le nombre de doigts de chaque personne dans l’image générée
L’objectif d’une image est de transmettre une impression. Il s’agit de rendre le concept abstrait de l’article un peu plus tangible
Avant, je cherchais sur Internet une image correspondant à cet objectif. Maintenant, je peux la créer moi-même avec DALL-E, et c’est généralement bien mieux
Cette image doit compléter l’article. Tout comme le texte essaie de transmettre des informations, une impression et des concepts, l’image doit en transmettre une partie elle aussi
Personne n’a envie de voir une illustration à l’effet vallée de l’étrange, avec des gens de tous les grands groupes ethniques disposés en cercle et se souriant bizarrement
Cette mode d’illustrations corporate étranges et sans âme avait commencé bien avant l’explosion de la génération par IA
C’est peut-être lié à une certaine croyance autour de l’optimisation pour les moteurs de recherche
Tout en devant simplement être agréables à regarder
Mais il y a un côté assez drôle ici. Le template du blog exige une zone d’image, donc on la remplit sans réfléchir avec quelque chose. Si c’est trop difficile, on cherche une photo de stock fade ; et si c’est encore trop difficile, on génère volontairement une photo de stock fade
Les déchets IA sans inspiration ni goût vont bientôt tout recouvrir
La plupart des problèmes liés aux PM viennent du fait qu’ils ne font pas le travail de terrain. Un bon PM doit sans cesse combler l’écart entre l’ingénierie et les utilisateurs
Il faut répéter cette boucle de feedback
Mais la plupart pensent pouvoir travailler uniquement dans le monde des documents : ils produisent des documents de roadmap et tentent de maintenir l’alignement des parties prenantes avec des check-ins sans fin et du harcèlement. Au final, ils font en réalité du « project management »
Collecte des exigences, gestion des utilisateurs furieux à cause des bugs, réunions d’état hebdomadaires, annonce des mauvaises nouvelles sur les priorités : tout était envoyé aux développeurs seniors ou au tech lead. Il sautait aussi la plupart des rituels agiles, sous prétexte d’être quelqu’un de très occupé. Il n’a jamais écrit ni corrigé un ticket JIRA, disant que c’était à l’organisation technique de gérer ça. Deux autres équipes techniques ont eu exactement le même traitement de la part du PM
Les tech leads et les développeurs seniors ont su dès la première semaine que ce PM n’était pas bon, mais il a tenu plus longtemps que nous tous et n’est parti que quatre ans plus tard, lors d’une réduction d’effectifs
Les managers pris dans le culte de l’agile se laissent facilement séduire par ce genre de personnes, qui peuvent faire dérailler une organisation pendant des années. En théorie, les parties prenantes d’un PM sont les utilisateurs ; en pratique, cela devient le fait de flatter l’ego des dirigeants qui l’ont embauché
Une boucle fermée d’auto-renforcement peut se former entre dirigeants, consultants agiles et PM
Dans les deux cas, ce sont des produits non compétitifs et, en général, ils risquent surtout de rester en place jusqu’à leur arrêt. Pourtant, les entreprises mettent en place des PM et des PO, créent une organisation façon SCRUM, et se comportent comme si elles construisaient un produit révolutionnaire, pression des urgences et des résultats comprise
Dans ce type d’environnement, j’ai souvent vu les PM et PO s’intéresser assez peu à la qualité ou à l’utilité du produit, et se concentrer sur la politique interne pour gravir les échelons
Même s’ils fabriquent un produit fragmenté qui, du point de vue des fonctionnalités et des améliorations, ressemble à une marche aléatoire, ils orientent le projet dans une direction qui les met en valeur auprès de la direction ou des clients
Je ne suis pas assez vieux pour savoir comment on construisait dans les années 60, 70 ou 80, mais j’imagine qu’il n’y avait pas de SCRUM/PM/PO. Le discours pessimiste selon lequel la productivité a fortement ralenti par rapport aux décennies passées, et qu’aujourd’hui nous nous reposons surtout sur ce qui a été construit auparavant, correspond assez bien à ma perception
Ces derniers temps, je fais aussi du mentorat auprès d’autres PM. Il existe bien une roadmap largement partagée, mais on produit aussi énormément de documents et de feuilles de calcul que personne d’autre que moi ne relit jamais. J’ai l’impression qu’ils sont créés pour montrer qu’on travaille, et j’essaie de casser cette habitude
Si je défends fortement le product management technique, c’est parce que, en simplifiant le problème, je pense que certains PM restent coincés à un niveau d’abstraction trop élevé. Comme ils ne peuvent pas discuter chaque jour des détails techniques avec l’équipe, ils finissent dans une étrange zone grise entre gestion de projet et gestion produit
En soi, ça va, mais quand il y a un syndrome HIPPO chez des gens qui veulent prendre les décisions produit, on finit par consacrer la majeure partie de son temps à couvrir ses arrières et à gérer vers le haut
Les PM s’en prennent beaucoup, parfois à juste titre, mais au final ils doivent souvent faire de la politique interne pour que les choses avancent
Un excellent PM ne se contente pas de produire une vision ou un plan : il mène aussi l’exécution et l’itération. Le plan, c’est 20 % du tout
Le meilleur product manager avec qui j’ai travaillé était simplement quelqu’un d’extrêmement compétent, qui comprenait la complexité de l’implémentation tout en étant probablement capable de la réaliser lui-même si nécessaire, et qui comprenait aussi les besoins business
Il apportait de la valeur à l’entreprise sans être engineering manager
Malheureusement, la plupart des product managers ne sont que des personnes assises à ce poste. Ce sont des gardiens de porte qui captent le mérite ou la responsabilité, souvent avec très peu d’enjeu personnel
De manière générale, je pense que si une organisation produit séparée existe, c’est qu’on s’y prend mal
Les meilleurs produits, et les plus réussis, auxquels j’ai participé étaient tous détenus côté produit par les personnes qui les implémentaient réellement : ingénieurs, designers, équipes customer success, etc.
En tant qu’ingénieur, j’aimais être dans la rotation du support, parce que cela comblait le fossé d’abstraction entre mon travail et les vraies personnes qui l’utilisent à chaque seconde
Très rarement, j’ai travaillé avec des PM qui apportaient une valeur nette positive ; dans tous ces cas, ces personnes auraient aussi pu devenir de bons ingénieurs
La raison principale est que si le PM, ou la personne de l’équipe qui joue ce rôle, remonte à la même chaîne de management que l’ingénierie, tout finit par pencher vers les besoins de l’ingénierie
Le travail sur des fonctionnalités indispensables, très susceptibles de faire avancer le business, finit par être dépriorisé parce que la dette technique ou les travaux d’infrastructure bloquent toujours les gens d’une façon ou d’une autre. Parfois, c’est effectivement le bon choix, mais pour prendre ce type de décision, il faut une tension entre deux organisations placées sur un pied d’égalité. Quand c’est intégré à l’ingénierie, cela se produit rarement
Bien sûr, la triste réalité de notre industrie est qu’une organisation PM séparée finit par avoir plus de pouvoir que l’organisation d’ingénierie, au motif qu’elle possède « ce qui est bon pour le business ». Ajoutez à cela des PM qui savent suivre des processus ou des frameworks, mais ne comprennent pas réellement leur produit ni leurs utilisateurs, et cela devient un cauchemar
Je raisonne en termes de ratios
Quel est le ratio entre ingénieurs frontend et ingénieurs backend ? Entre managers d’ingénierie et contributeurs individuels ? Entre rédacteurs techniques et l’ensemble des ingénieurs ? Entre product managers et l’ensemble des ingénieurs ?
Et j’essaie d’ajuster finement ces ratios pour maximiser l’impact tout en minimisant les interférences et le micromanagement
Les chiffres réels de ces ratios varieront selon les organisations, mais si l’on détecte des interférences, ou si le « comment » ne vient pas suffisamment des ingénieurs eux-mêmes, il faut changer le ratio
Il faut augmenter le nombre d’ingénieurs par people manager ou product manager, afin qu’ils ne puissent plus s’immiscer de cette manière, qu’ils soient obligés de prioriser les sujets dans lesquels s’impliquer, et qu’ils se retirent du micro-niveau pour redonner aux ingénieurs l’autonomie sur la méthode
Il en va de même pour les QA, les ingénieurs juniors, les ingénieurs seniors, les architectes, les RH, les vice-présidents et les commerciaux
Je fais de la gestion produit depuis plus de 20 ans, et je suis d’accord avec l’essentiel de ce qui est dit ici. Les ratios comptent
Un CPO peut facilement bâtir un empire avec une armée de PM. L’organisation finit avec des PM qui possèdent de petits fragments de l’expérience client, comme une page unique, optimisent le taux de clic d’un bouton, mais ne contribuent pas réellement à la stratégie ou à la vision produit
Il est difficile d’être product manager sans posséder de produit
Les PM devraient être bien plus concentrés sur les objectifs business qu’ils ne le sont aujourd’hui pour la plupart. Résoudre des problèmes utilisateurs est nécessaire, mais pas suffisant. La résolution de ces problèmes doit aussi se traduire en valeur pour l’entreprise
Pour rendre cela possible, il est indispensable d’avoir des partenaires ingénierie et UX dotés d’un solide sens produit
Pire encore, les développeurs « facilement remplaçables » viennent de sociétés de sous-traitance. Il faut maintenant isoler le développement du client par encore plus de couches de management
Une excellente façon de faire augmenter le PIB
Par exemple, si l’on travaille sur un ERP, Oracle Fusion Apps, WorkDay, SAP ou quelque chose du genre, un seul PM ne peut pas posséder l’ensemble du produit. Il se voit plutôt confier plusieurs fonctionnalités, chacune étant elle-même complexe et, compte tenu de la nature d’un ERP, impliquant généralement aussi des intégrations avec plusieurs autres produits
Cela dit, je suis d’accord avec l’idée générale qu’un PM doit posséder quelque chose de significatif
En tant que développeur et manager de développement, les meilleurs product managers avec lesquels j’ai travaillé s’impliquaient très peu dans le « comment »
Bien sûr, ils peuvent créer des tickets au niveau epic dans le backlog, mais en dessous de ce niveau, ils font confiance à toi et aux responsables du projet pour mener le travail à bien
Le problème, c’est que l’organisation doit soutenir cela. Dans la plupart des entreprises, les sujets qui reçoivent le plus d’attention ne sont pas ceux portés par la vision ou la croissance, mais les plus bruyants
Et ces sujets entrent souvent directement en conflit avec la direction voulue par le responsable produit ou le manager
Les pires PM sont ceux qui ne comprennent pas le « comment », c’est-à-dire qui ne savent pas comment fonctionne leur propre produit
Les meilleurs PM avec lesquels j’ai travaillé avaient un bagage technique
Quand les gens empiètent sur le domaine des autres, cela finit toujours en catastrophe. Dans les deux sens. Les ingénieurs pensent trop souvent sous l’angle du « comment ? », ce qui les rend mauvais sur le « pourquoi ? » et le « quoi ? », et les product managers doivent eux aussi se retirer du « comment ? », sauf si c’est pour clarifier le « quoi ? » ou le « pourquoi ? »
Il faut un équilibre. Les PM/PO ont eux aussi besoin d’une compréhension de base. Il ne faut pas que ce soient des gens qui savent à peine utiliser un ordinateur
Même un bon PM peut se retrouver assez entravé s’il est entouré de trop de PM médiocres
J’ai travaillé avec plusieurs entreprises du Fortune 500 et j’ai vu beaucoup de cultures dysfonctionnelles
Dans ces endroits, les PM résolvent la plupart des problèmes avec le seul outil dont ils disposent : les réunions. Les incitations à la promotion font que plus la réunion est grande, plus on a l’air important
J’ai participé à des centaines d’heures de réunions d’équipes transverses où seules une ou deux personnes travaillaient réellement, où le PM parlait généralement tout du long, et où 10 à 20 personnes restaient en sourdine avant de donner leur validation à la fin, comme pour prouver leur existence
Résultat : les équipes d’ingénierie perdent leur motivation, n’ont plus de temps pour faire le vrai travail technique, et on leur demande sur-le-champ des estimations ou des engagements, sans investigation du code ni compréhension préalable
J’ai aussi vu des PM rejeter des conceptions techniques parce que les chiffres ou les « points » ne leur plaisaient pas, obligeant les ingénieurs à reformater la même idée dans d’autres « tickets » pour satisfaire une esthétique PM indéchiffrable
Des projets entiers sont retardés et déraillent à cause du manque de compréhension et de rituels absurdes d’affichage de statut
À l’inverse, j’ai aussi travaillé avec d’excellents PM : ces personnes protégeaient l’équipe de ces conneries et l’aidaient à se concentrer sur les bons objectifs. Elles sont précieuses, et les premières sont tout aussi nuisibles
Indépendamment du nombre de PM, il s’agit du type de PM avec lequel j’ai envie de travailler
J’ai travaillé dans quatre entreprises du secteur, d’une startup de moins de 40 personnes jusqu’à JP Morgan Chase
Je rejette l’idée selon laquelle les personnes « techniques » seraient plus intelligentes que les personnes « non techniques ». En réalité, en tant qu’ingénieur, il m’arrive souvent de me perdre dans les détails et de passer à côté de la vision d’ensemble, et j’ai souvent besoin qu’un PM m’aide à en sortir
Cela dit, d’après mon expérience, les PM avec lesquels il est le plus facile de travailler en tant qu’ingénieur sont ceux qui ont eu ne serait-ce qu’un minimum d’exposition réelle au code
Pas besoin que ce soit extraordinaire. Avoir créé un site web en HTML et CSS il y a longtemps, écrit une requête SQL ponctuelle, ou suivi un cours de Python pendant un master suffit
Il suffit qu’il y ait quelque chose qui permette au PM de comprendre que l’écriture de code n’est ni une science exacte ni de la magie pure
Ces PM défendent les ingénieurs avec lesquels ils travaillent, ou essaient au moins de trouver un équilibre entre les besoins business et la réalité de l’ingénierie
Les personnes devenues PM sans aucune exposition à la technique ont tendance à être plus « orientées business » ; à un moment donné, c’est peut-être exactement ce dont l’entreprise a besoin, mais ce n’est pas toujours le cas. En tant qu’ingénieur, j’ai envie de travailler avec quelqu’un qui comprend aussi mieux mon point de vue
Je ne suis pas vexé du tout :p