Product Manager ?
Les qualités que l'IA ne remplace pas — et si ce métier est fait pour vous
Patrick T. Hoffman
En 2015, on pouvait comprendre le product management en un long week-end. Lire quelques articles de blog — Shreyas Doshi sur la pensée systémique, Ken Norton sur le recrutement des PM, les vieux essais de Joel Spolsky sur le travail avec les ingénieurs. Suivre un PM en immersion dans une entreprise qui l'acceptait. Écrire un PRD, mal d'abord, puis un peu moins mal. Postuler. Décrocher un poste.
Ce chemin n'existe plus. Non que les articles fussent mauvais. C'est le métier qui a bougé.
Je ne parle pas des intitulés de poste, des grilles de salaires ou des organigrammes. Je parle du travail lui-même — ce qui remplit vos journées, la compétence qui vous vaut une place à la table, la raison pour laquelle une entreprise emploie un PM au lieu de laisser ingénieurs et designers prendre eux-mêmes les décisions produit. Ce travail est aujourd'hui substantiellement différent de ce qu'il était il y a dix ans, et il le sera plus encore le temps que vous finissiez ce livre.
Soyons précis sur ce qui a bougé et pourquoi, parce que les généralités sur « l'IA qui change tout » ne vous aideront à décider de rien.
Ce qui a réellement changé
En 2015, un PM débutant consacrait une bonne partie de ses journées à des tâches qui demandaient du savoir-faire, mais pas de jugement : rédiger des critères d'acceptation détaillés, monter des matrices de comparaison concurrentielle, extraire des analytics de base, synthétiser des notes de recherche utilisateur, maquetter des parcours dans Balsamiq ou Sketch, écrire des tickets. Rien de trivial là-dedans. Bien faites, ces tâches produisaient de la clarté ; mal faites, de la confusion. Mais elles s'apprenaient, et c'est en les apprenant qu'on se forgeait le muscle pour le travail plus difficile à venir.
Cette échelle a en grande partie disparu. Un PM débutant équipé d'un bon assistant IA — et en 2026, tous les PM en ont un — produit en un après-midi ce qui demandait un mois. L'analyse concurrentielle qui exigeait des heures de recherche structurée : un premier jet en vingt minutes. La synthèse de cinquante entretiens utilisateurs : faite. Les parcours de prototype : générés. La structure du PRD : posée. La qualité varie ; il faut toujours relire, juger, affiner. Mais le volume d'heures passées à produire des artefacts s'est effondré.
Dit comme cela, on croirait un gain net. Par certains côtés, c'en est un. Mais regardez ce qui a disparu au passage.
Ce travail de production, c'était précisément là que les PM apprenaient. Vous compreniez quelles questions comptaient en écrivant cinquante tickets et en remarquant lesquels les ingénieurs ignoraient. Vous appreniez ce que les utilisateurs disaient réellement — et non ce que vous vouliez entendre — en passant dix heures dans les transcriptions d'entretiens. Vous découvriez les coutures architecturales de votre produit en dessinant chaque cas limite d'un diagramme de flux. La corvée, c'était le programme. Les heures, c'était la formation.
Les débutants qui entrent dans le métier aujourd'hui sautent l'essentiel de ce programme. Ils passent directement au résultat. Et le résultat a l'air compétent — souvent il l'est — mais on peut produire un résultat compétent sans comprendre pourquoi il l'est, ni savoir corriger le tir le jour où il cesse de l'être.
Voilà la première chose qui a changé : l'apprentissage s'est cassé.
Le pouvoir s'est déplacé — mais pas vers les PM
Voici ce que presque tout le monde comprend de travers dans le débat IA et product management : on suppose que l'IA renforce le PM par rapport à ses coéquipiers. C'est faux. Elle renforce tout le monde à peu près également — ce qui veut dire que les vieux avantages du PM ne tiennent plus comme avant.
En 2018, un PM détenait un avantage informationnel structurel. Vous étiez la personne qui avait lu à la fois la recherche utilisateur, les métriques business et le paysage concurrentiel. Vos ingénieurs étaient experts du code, vos designers des patterns d'interaction, vos data scientists du modèle. Vous étiez le généraliste de la pièce. Ce généralisme était un levier.
Aujourd'hui, vos ingénieurs obtiennent une analyse concurrentielle en quinze minutes de prompts. Vos designers extraient leurs propres analytics. Vos data scientists rédigent eux-mêmes leurs synthèses de scénarios utilisateurs. L'IA a donné à chacun l'accès à ce travail de collecte d'information qui justifiait autrefois la présence du PM dans la pièce.
Conséquence : les parties du métier qui ont toujours été invisibles — le jugement, la conviction, la capacité à se tromper devant les autres et à continuer — sont désormais tout le métier. L'échafaudage qui entourait ces parties invisibles, et qui les masquait en partie, a été démonté. Vous voilà debout au milieu de la pièce, et la question est simple : savez-vous faire la chose qui compte ?
La chose qui compte, c'est décider. Pas au sens d'en avoir l'autorité formelle — ça, c'est de la politique d'organisation, un autre problème. Décider au sens de prendre un tas d'informations incomplètes et contradictoires et de le réduire à une direction que vous êtes prêt à défendre. L'IA excelle à générer des options. Elle ne sait pas choisir. C'est dans cette asymétrie que réside la valeur du PM moderne.
Pourquoi j'ai écrit ce livre
Je suis PM depuis bientôt quinze ans. Je l'ai été dans des startups si petites que « l'équipe produit », c'était moi et un fichier Figma partagé. Je l'ai été dans des entreprises si grandes que mes métriques tournaient sur une infrastructure au service de milliards de personnes. J'ai fait du hardware — de vrais objets physiques, qui existent dans le monde et tombent en panne autrement que le logiciel, avec des chaînes d'approvisionnement, des tolérances, et cette anxiété particulière de savoir qu'un défaut dans votre spécification sera fabriqué en dix mille exemplaires avant que vous ne le repériez. J'ai géré des produits réglementés dans des villes qui avaient des opinions bien arrêtées sur ce qui pouvait circuler dans leurs rues, et à quelle vitesse. J'ai géré des plateformes pour des commerçants qui n'étaient pas ingénieurs et ne voulaient pas le devenir — ils avaient juste besoin que le commerce fonctionne.
Chacun de ces contextes m'a appris quelque chose de différent sur ce qu'est réellement ce métier. Pas ce qu'en disent les blogs de PM. Pas ce qu'en disent les fiches de poste. Ce qu'il est vraiment — sa texture, ce qui fait du bien et ce qui épuise, les compétences qui se révèlent décisives et celles qui se révèlent du théâtre.
Depuis plus de dix ans, on me pose deux questions : le product management est-il une bonne carrière, et comment y entrer ? J'y ai répondu des centaines de fois — avec des mentorés, en permanences, dans des fils de conseils, à la fin de conférences. Les réponses données en tête-à-tête touchent au mieux quelques centaines de personnes ; celles que ces personnes transmettent à leur tour, quelques centaines de plus. J'ai écrit ce livre pour porter ces conversations au-delà de ce qu'un individu peut faire dans une salle ou en visio.
Et s'il fallait l'écrire maintenant, précisément, c'est que les portes d'entrée sont en train de changer. L'IA a rétréci certains chemins, fluidifié d'autres, et commencé à transformer la nature même du travail — d'une façon que le canon PM existant n'a pas rattrapée. La réponse honnête à « devrais-je devenir PM ? » n'est plus celle d'il y a trois ans à peine. Je veux que ceux qui posent cette question disposent d'une réponse réfléchie — pas la version marketing du métier, pas ce que racontent les blogs, mais ce que le travail est réellement, et s'ils auraient réellement du plaisir à le faire.
J'étais las de voir des gens découvrir trop tard que PM n'était pas le métier qu'ils imaginaient. Non que le métier soit mauvais — je l'ai aimé la plupart du temps, et je le tiens pour l'un des artisanats véritablement intéressants de la tech — mais l'écart entre sa version publicitaire et sa réalité est assez grand pour devenir un vrai problème. Des gens prennent un poste de PM pour construire, et se retrouvent en réunion. D'autres y cherchent l'autonomie, et se retrouvent à négocier chaque centimètre de la roadmap. D'autres encore y viennent parce qu'on leur a dit que c'était la voie vers le poste de CEO — ce qui, pour la plupart, est faux, et si c'est vraiment votre objectif, le détour par le product management sera un calvaire.
Le modèle que j'avais en tête est un livre intitulé Architect? A Candid Guide to the Profession, publié par MIT Press. Ce livre ne vous raconte pas que l'architecture est glamour. Il vous dit ce que font les architectes de leurs journées, quel genre de personne s'y épanouit, quelles en sont les réalités économiques, ce que la version romantique perd quand on exerce pour de bon. Il respecte assez le lecteur pour lui donner de quoi faire un vrai choix. Je voulais écrire ce livre-là pour le product management.
Ce livre est ma tentative de le faire.
La question à laquelle ce livre répond
Ce n'est pas : comment devenir PM ?
Pour cela, les ressources abondent. Des cours, des bootcamps, des guides de préparation aux entretiens, des portfolios d'études de cas à constituer, des simulations d'entretien avec d'anciens de Google qui vous factureront quatre cents dollars de l'heure pour vous expliquer ce que signifie CIRCLES. Cet écosystème existe et vous servira si ce qu'il vous faut est une aide tactique pour décrocher un poste.
Ce livre répond à une autre question : voulez-vous vraiment ce métier ?
Cela paraît évident. Bien sûr que vous le voulez — sinon, pourquoi lire ceci ? Mais vouloir un poste et vouloir faire le travail dont ce poste est fait sont deux choses différentes, et les confondre coûte cher. Cher en temps. Cher de cette fatigue particulière qui vient d'un travail qui ne vous convient pas. Cher en coût d'opportunité — tout ce que vous n'avez pas fait pendant que vous échouiez à devenir PM, ou que vous y parveniez pour détester le résultat.
Le livre Architect? pose la question ainsi : aimez-vous le travail, ses problèmes, la personne que vous devenez en l'exerçant ? C'est le bon cadre. Une profession ne vous donne pas seulement un salaire et un titre. Elle façonne votre manière de penser, ce que vous remarquez, ce qui vous importe, qui vous devenez en dix ans. La meilleure PM que je connaisse voit tout comme un problème d'incitations et de comportement utilisateur — au restaurant, en observant un pâté de maisons, en lisant les nouvelles. Voilà ce que quinze ans de product management ont fait de sa pensée. Ce n'est pas un costume ; c'est une restructuration.
La question n'est donc pas de savoir si PM est une bonne carrière. C'est de savoir si c'est une bonne carrière pour vous — pour votre style cognitif, votre tolérance à l'ambiguïté, votre rapport à l'autorité, votre besoin de paternité créative visible. Et la seule façon honnête d'y répondre est de vous montrer le travail de près — un mardi à 14 heures, quand le sprint est en retard, que la partie prenante est mécontente et que les données se contredisent.
C'est ce que ce livre essaie de faire.
Ce que le product management n'est pas
Avant de décrire ce qu'est le product management, il faut déblayer le terrain de ce qu'il n'est pas. Les idées fausses sont si tenaces que, faute de les traiter d'emblée, elles teinteraient toute votre lecture.
Le PM n'est pas un mini-CEO. Je sais que cette formule est partout. Ben Horowitz l'a écrite. Toutes les fiches de poste la citent. C'est l'idée la plus toxique du product management, et je veux être clair sur le pourquoi.
Un CEO détient une autorité formelle. Il peut embaucher et licencier. Réallouer un budget. Casser une décision. Il répond de ses actes devant un conseil d'administration — sa responsabilité a des dents. Le PM n'a rien de tout cela. Le PM répond de tout et n'a autorité sur presque personne. Il « possède » le produit en ce sens qu'il est responsable de ses résultats — mais il ne contrôle ni les ingénieurs qui le construisent, ni les designers qui lui donnent forme, ni les data scientists qui l'instrumentent, ni les juristes qui le contraignent, ni les dirigeants qui, en dernier ressort, le financent.
La formule du mini-CEO séduit parce qu'elle sonne valorisante. Ce qu'elle fait en réalité, c'est installer un décalage entre responsabilité et autorité qui broie ceux qui n'y sont pas préparés. Si vous entrez dans le métier en vous attendant à être un CEO, vous passerez votre carrière dans la confusion et la frustration, coincé entre ce qui devrait être vrai (je possède ce produit, donc je décide) et ce qui est vrai (je possède ce produit, donc je rends des comptes quand d'autres décident mal).
Le bon modèle mental n'est pas le CEO. C'est plutôt l'éditeur, au sens du monde du livre. Un grand éditeur n'écrit pas le livre. Il comprend ce que le livre cherche à devenir, aide l'auteur à y parvenir, tranche dans le vif sur ce qu'il faut couper et ce qu'il faut développer, et endosse une part du blâme si le livre ne rencontre pas son public. Une influence énorme, sans autorité formelle. Voilà un cadre plus utile.
Le PM n'est pas la voix du client. Celle-ci est plus subtile. Les PM font de la recherche utilisateur. Ils parlent aux clients. Ils synthétisent les retours. Mais les appeler « la voix du client » est à la fois inexact et contre-productif. Inexact, parce que les retours clients ne forment pas une voix unique — les clients veulent des choses contradictoires, hiérarchisent différemment, et vous disent ce qu'ils veulent plutôt que ce dont ils ont besoin. En tirer un signal utile relève du jugement, pas de la collecte. Contre-productif, parce que cela autorise tout le reste de l'organisation à se décharger de son devoir de comprendre les utilisateurs. Quand seul le PM parle aux clients, vous obtenez un produit filtré par un PM, pas un produit qui fonctionne.
Le PM ne construit rien. Encore une. Le romantisme autour du métier entretient l'idée que le PM crée comme créent les designers ou les ingénieurs. Ce n'est vrai que dans un sens très limité et très particulier. Le PM décide de quoi construire, ce qui est un acte créatif d'un genre à part. Mais il ne dessine pas l'interface, n'écrit pas le code, ne lance pas la requête. Le principal produit du travail d'un PM n'est pas une chose. C'est une décision, une direction, un alignement entretenu qui permet aux autres de construire sans renégocier en permanence les principes de base. Si vous avez besoin de faire quelque chose de vos mains — ou d'incarner directement votre vision créative — le product management vous frustrera.
Le product management n'est pas une fiche de poste stable. Je veux être direct sur un point : ce que fait un PM varie énormément selon le stade de l'entreprise, son type, la composition de l'équipe et le parcours du PM lui-même. Un PM dans une startup de vingt personnes fait quelque chose de sensiblement différent d'un PM dans une entreprise de cinq mille, lequel fait autre chose encore qu'un PM dans une entreprise plateforme dotée d'un écosystème de développeurs. Ce livre signalera ces différences, mais sachez-le d'entrée : « PM » est davantage une catégorie qu'un poste. La catégorie se définit par la responsabilité des résultats du produit et par le travail de transformation de problèmes ambigus en décisions exécutables. La forme concrète de cette responsabilité et de ce travail varie plus que la plupart des contenus sur le métier ne l'admettent.
Sur l'ère de l'IA, en particulier
Je me suis appliqué, dans cette préface, à décrire l'effet de l'IA sur le travail du PM sans verser ni dans l'apocalypse ni dans le déni — les deux travers sont courants, et aucun n'est utile.
La version apocalyptique : l'IA va éliminer le product management. Les PM seront remplacés par des systèmes qui parlent aux utilisateurs, synthétisent les retours, génèrent les spécifications et pilotent les produits tout seuls. Cela n'arrivera pas à court terme, pour une raison précise : la partie difficile du métier n'est pas le traitement de l'information, c'est le jugement dans l'incertitude ; le jugement exige une responsabilité, et la responsabilité exige une personne. Quand la stratégie produit proposée par l'IA se révélera fausse — et elle se révélera fausse —, quelqu'un devra l'assumer, l'expliquer, réaligner l'organisation et se réengager sur une nouvelle direction. C'est un travail d'humain, et il le restera plus longtemps qu'on ne le prédit généralement.
La version du déni : l'IA n'est qu'un outil, un PM reste un PM, les fondamentaux ne changent pas. Faux également. La palette de compétences se déplace. Le travail qui prenait du temps et servait de formation sur le tas s'automatise plus vite que la plupart des praticiens ne s'adaptent. Les PM qui prospéreront dans la décennie à venir seront différents — dans leur façon de penser leurs leviers, d'employer leurs heures et de définir leur cœur de compétence — de ceux qui prospéraient en 2018.
La version honnête : l'IA a changé substantiellement les conditions d'exercice du métier, en exposant davantage — et en rendant plus critiques — les parties liées au jugement et à la conviction, tout en rendant la production d'artefacts et la collecte d'information plus rapides et moins chères. Si vous aimiez le product management pour l'écriture des PRD, cette satisfaction se fera plus rare. Si vous l'aimiez pour la décision — la vraie, avec une information incomplète, sous contraintes réelles, puis en vivant avec les conséquences —, vous y trouverez plus d'espace que jamais.
Ce livre sert en partie à découvrir laquelle des deux vous aimez vraiment.
Comment lire ce livre
Chaque chapitre se termine par un exercice. Faites les exercices. Non que les exercices soient utiles en soi — la plupart des exercices de développement professionnel sont de l'occupation déguisée en réflexion — mais parce que la question de ce livre (voulez-vous vraiment ce métier ?) ne se règle pas par la seule lecture. Il faut essayer cette façon de penser, observer l'effet qu'elle vous fait, noter si elle vous stimule ou vous vide.
Certains exercices sont conçus pour faire émerger vite une vraie réponse. Ils sont calibrés : ceux à qui le travail de PM plaira les trouvent en général intéressants ; les autres, fastidieux ou arbitraires. Je ne vous dirai pas lesquels — ce serait ruiner le principe. Surveillez votre réaction, pas seulement votre réponse.
Les chapitres ne se lisent pas forcément dans l'ordre, mais je les ai écrits pour qu'ils s'appuient les uns sur les autres. Le premier — ce que font vraiment les PM — est la fondation. Tout le reste suppose que vous l'avez lu. Les chapitres ultérieurs sur les qualités et les schémas de pensée sont plus difficiles à interpréter sans ce socle.
Enfin : ce livre est écrit depuis mon point de vue, qui est particulier. J'ai été PM dans les transports, le commerce, l'éducation et la publicité. J'ai travaillé dans des startups, des scale-ups et de très grandes entreprises technologiques. J'ai géré des produits hardware, software et plateforme. Mais je n'ai pas tout fait, et mon expérience a façonné mes opinions. Là où j'avance une affirmation générale, j'ai essayé de l'appuyer sur davantage qu'une anecdote personnelle. Là où j'exprime un avis personnel, j'ai essayé de le signaler comme tel.
Ce métier mérite d'être compris avec clarté. Il ne mérite ni d'être survendu, ni d'être déprécié. Commençons par ce qu'il est réellement.