Bonjour les agilistes ! Aujourd’hui, je vous propose de parler ensemble de la confusion auto-infligée entre Product Owner et Product Manager qui a diminué, voir démoli, le rôle de Product Owner.
La tentative de Scrum d’embrasser le monde du Product Management en créant un rôle unique, celui de Product Owner, était une erreur. Pourtant, tout a commencé avec de bonnes intentions : Celle de donner plus d’autorité au Product Manager sur son produit, notamment en l’appelant Product Owner.
Nous pouvons maintenant dire, avec un recul suffisant, que ce changement s’est finalement retourné contre lui. Les Product Owners ont généralement moins d’autorité que les Product Managers.
Ce qui est à l’opposé de ce que cette initiative était censé réaliser.
Lorsque vous discutez avec des Product Managers et que vous leur expliquez que le Product Owner est en fait LA personne responsable du produit avec la plus grande responsabilité sur le produit, ils vous regardent avec incrédulité.
Il existe un grand fossé entre le monde du product management et Scrum, et… il ne fait que s’agrandir !
Les gens ont commencé à attacher leur propre signification au rôle de Product Owner parce que, d’après eux, ce rôle ne peut pas passer à l’échelle. * Pouf *. Il n’en fallait pas plus pour ouvrir la boîte de Pandore et proposer une solution bureaucratique fortement détestée à la fois par le monde du Product management et par Scrum.
Il est dorénavant fréquent de voir des Product Managers travailler en dehors du Sprint, d’ailleurs en dehors de tout, avec des Product Owners. Dans de tels arrangements, les Product Owners sont piégés et se voient généralement accorder moins d’ ownership sur la maximisation de la livraison de valeur que le Product Manager. Même dans les entreprises qui n’ont pas de Product Managers, beaucoup n’ont même pas de véritables Product Owners. Dans la pratique, être Product Owner signifie quelque chose de complètement différent de ce que cela signifie en théorie. Les entreprises ont généralement plusieurs Product Owners par produit et non un seul Product Owner, enfreignant ainsi la règle du Product Owner unique par produit.
Malheureusement, la communauté Scrum semble réticente à inspecter et à s’adapter. Nous nous accrochons à un idéal de Product Owner qui est rarement utilisé dans la pratique et qui n’évolue pas. Il est plus facile de pointer du doigt et de prétendre que les personnes ayant des solutions PM/PO ou plusieurs PO par produit ne “sont pas agiles” que de se remettre en question, n’est-ce pas ?
Comment en sommes-nous arrivés à cette situation folle ? Que devons-nous faire à ce sujet ?
Commençons à remonter dans l’histoire de Scrum pour voir comment le Product Owner est né.
Comment le Product Manager et le Product Management se sont progressivement éloignés de Scrum
Dans les premières versions de Scrum, le product management occupait une place bien plus importante qu’elle n’occupe actuellement.
L’article fondateur de l’OOPSLA de 1995 sur Scrum mentionne le Product Management et le product manager exactement une fois. Cela peut sembler peu, mais gardez à l’esprit qu’à cette époque, aucun mot n’est consacré au Product Owner ou au Scrum Master. Tous deux n’étaient pas encore entrés en scène.
Jetons un coup d’œil sur le chapitre relatif au product manager :
« Management : Piloté par le Product Manager, il définit le contenu initial et le timing de la release, puis gère leur évolution au fur et à mesure de l’avancement du projet. Le Management s’occupe du backlog, des risques et du contenu des releases. » — Processus de développement Scrum, OOPSLA 1995
Pour résumer ce paragraphe : le product management est responsable de la gestion du backlog produit et elle est dirigée par le Product Manager.
Assiste-t-on aux premiers germes du rôle de Product Owner sous les traits du Product Manager ? Je le crois.
Je ne suis pas impressionné par la façon dont les responsabilités du Product manager sont décrites. La description a plus en commun avec un chef de projet qu’un chef de produit. De plus, pas un seul mot dans cet extrait ne parle de valeur. En fait, dans tout l’article, le mot valeur n’est mentionné aucune fois. Pour contraster avec le Scrum Guide actuel : le mot valeur y est mentionné 25 fois.
Examinons ce qui est écrit dans ce document lorsque nous recherchons “Product Management”:
« Chaque Sprint est suivi d’une revue de sprint, dont les caractéristiques sont :
Toute l’équipe et le product management sont présentes et participent. — Processus de développement Scrum, OOPSLA 1995
En 1995, le product management est mentionnée séparément, comme une partie prenante importante, qui devrait être présente lors de la revue de sprint. Pour le reste, il n’y a pas de distinction : l’ensemble est regroupé sous l’étiquette de “l’équipe”. La présence du Product Management lors de la Sprint Review ressemble étrangement à une responsabilité importante actuelle du Product Owner, n’est-ce pas ?
Pour moi, il est tout à fait évident que le Product Manager et le Product Management auxquels il est fait référence relèveraient plus tard de la compétence du Product Owner, au fil des évolutions de Scrum.
Mais attendez, il y a plus ! Dans la première incarnation du Scrum Guide, où le rôle du Product Owner est décrit, le conseil suivant apparaît :
« Pour le développement commercial, le Product Owner peut être le product Manager. Pour les efforts de développement en interne, le Product Owner peut être un représentant des utilisateurs. » — Guide Scrum V1, 2010
À présent, qu’il n’y ait aucune confusion à ce sujet : le rôle de Product Owner a ses racines dans le product management. Une belle étiquette a été apposée dessus, ce qui pourrait donner l’impression ou l’illusion qu’il s’agit de quelque chose de différent, mais le Product Owner est bien censé être un Product Manager après tout !
Quelle était l’idée dans la tête des fondateurs de Scrum qui ont décidé d’appeler le Product Manager différemment ?
Pourquoi le Product Manager de Scrum a-t-il été renommé Product Owner ?
Il me semble que la raison profonde derrière ce changement, de product Manager à Product Owner était qu’il fallait indiquer clairement l’autorité complète, étendue sur la valeur du produit.
Le label “Owner” devait établir sans l’ombre d’un doute qu’une seule personne était responsable, garante du produit, au lieu de plusieurs personnes.
Le Scrum Guide ne s’est pas arrêté à ce changement de nom. Dans sa dernière version, en 2020, toute mention du mot Product Management a été supprimée, augmentant encore plus la séparation entre Scrum et le Product Management.
Je suppose que l’intention était de rendre le Scrum Guide plus générique pour lui permettre d’être encore plus adapté à votre contexte. Cependant, cela n’a fait qu’ajouter à la confusion Product Owner – Product Management.
Inventer un nouveau rôle de Product Owner et plus tard supprimer complètement le Product Management de Scrum était une grosse erreur maintenant exploitée par des frameworks de mise à l’échelle comme Scaled Agile Framework (SAFe) en ayant pour effet de rétrograder le Product Owner en gestionnaire du backlog de l’équipe.
Le problème est qu’il ne s’agit pas uniquement des frameworks de mise à l’échelle.
La semaine dernière, un Product Owner m’a dit que lorsque son Product Manager est parti, un collègue lui a donné le conseil de postuler au poste de Product Manager, car ce serait une promotion. Écrire cela me semble absurde, mais ce n’est pas la première fois que je l’entends.
Le plus gros problème est que, d’après mon expérience, ces rétrogradations de Product Owner ne sont pas des cas isolés, mais systémiques.
Permettez-moi de vous raconter une histoire tirée de mon expérience personnelle :
Il y a quelques temps, je me souviens que mon manager m’avait dit que nous faisions tout de travers et que nous devions engager des Product Managers pour travailler avec nos Product Owners. J’ai essayé d’argumenter et d’expliquer l’idée derrière le rôle de Product Owner. En vain.
Après quelques tentatives, la décision de faire travailler ensemble les Product Managers et les Product Owners a été annulée. Personne n’était satisfait de l’arrangement et personne ne pensait que cela allait réellement fonctionner.
Je crois que ces malentendus deviennent possibles parce que le Guide Scrum n’a pas de lien direct et explicite entre le Product Owner et ses capacités de Product Management. L’étiquette de Product Owner ne semble pas non plus suffisamment sérieuse ou lourde pour le rôle réel. Le titre de Product Manager a plus de poids que celui de Product Owner. C’est absurde lorsque vous réalisez que la véritable responsabilité d’un Product Owner est bien plus grande que celle de votre Product Manager typique.
Au fur et à mesure que le nombre d’équipes Scrum augmente, il est tout à fait difficile de savoir comment les activités de product management doivent évoluer. Un seul Product Owner par produit n’est pas assez bon au-delà de quelques équipes et l’expertise en gestion de produit n’est pas facilement déléguée.
Même si l’histoire de Scrum et du Scrum Guide montre qu’il y avait un lien explicite entre le product management et le Product Owner dans le passé, le lien a été complètement rompu dans le Scrum Guide 2020 et dans la pratique populaire de Scrum.
Et voilà ! Nous y sommes maintenant, avec des gens ayant des discussions Product Manager contre Product Owner, et des frameworks de mise à l’échelle exploitant la confusion en créant une déconnexion entre Product Management et Product Owner.
La fausse déconnexion entre le Product Management et le Product Owner
Voici le combo PM/PO tel que prôné par SAFe et rendu possible par la déconnexion illusoire entre Product Management et Product Ownership :
La seule raison pour laquelle cette solution extrêmement bancale PM/PO devient une option envisageable est que les gens ne comprennent pas quelle est la différence entre un Product Manager et un Product Owner. Pire, dans cette vision des chose, un Product Owner semble moins important qu’un Product Manager. Par conséquent, cette solution d’avoir des demandes d’entonnoir, du Product Manager au Product Owner est tout à fait logique pour les personnes qui ne connaissent pas Scrum.
Scrum définit le Product Owner comme une responsabilité appartenant à une seule personne. C’est quelqu’un qui est finalement responsable de la valeur du produit tel que livré par l’équipe Scrum. Qui assume les responsabilités du Product Owner n’a pas d’importance. Ces responsabilités peuvent être déléguées à toute personne capable de le faire.
Lorsque vous avez quelques équipes, le Product Manager peut être une seule personne. Au-delà de quelques équipes, cela devient difficile voire impossible.
Je pense que c’est la raison pour laquelle nous constatons aujourd’hui une séparation entre les Product Managers et les Product Owners – pour faire face à l’échelle, car Scrum ne fournit pas de solution adéquate prête à l’emploi.
Selon le contexte et l’échelle de votre organisation, votre Product Owner peut être le PDG, le Chief Product Officer (CPO),un PM senior… Bref, quiconque est finalement responsable de maximiser la valeur du Produit. C’est pourquoi demander à un PM de nourrir le backlog des Product Owner à la cuillère n’a aucun sens.
La confusion est encore exacerbée par le fait que les gens croient à tort que le Product Ownership et le Product Managemeent sont quelque chose de différent.
Nous devons nous rappeler que le combo PM / PO est une solution bien intentionnée au problème qu’un seul Product Owner qui assume à la fois l’accountability et les responsabilités ne peut pas passer à l’échelle.
Les équipes auto-organisées ont besoin d’une expertise en Product Management pour créer de la valeur !
Scrum parle d’équipes habilitées / auto-organisées / autogérées, ce qui signifie que l’expertise en Product Management, si nécessaire, fait partie des équipes qui font le travail. Soit par l’intermédiaire du Product Owner si vous avez peu d’équipes, soit en ayant une expertise en Product Management au sein de votre équipe de développement.
Tout le monde connait et sait l’importance d’équipes responsabilisées. C’est pourquoi les équipes Scrum ne devraient pas compter sur une seule personne en dehors de l’équipe. À quel point êtes-vous autonome sans votre product owner ? (Note du traducteur : Je vous invite à lire cet article sur la résilience de votre équipe SCRUM).
Voici à quoi cela ressemblerait si vous aviez un seul Product Owner par produit avec de nombreuses équipes et une expertise en gestion de produit au sein des équipes Scrum :
Le fossé grandissant entre Product Ownership et Product Management
Et donc ? Quelle est ma conclusion ? Il est temps de se réveiller dans la communauté Scrum : au lieu de pointer du doigt ce que le “label” Product Owner était censé accomplir, jetons un coup d’œil aux décombres et à la confusion qu’il laisse derrière lui et prenons nos responsabilités.
A l’échelle, un seul Product Owner par produit ne peut exister sans que l’expertise en gestion de produit ne fasse partie des équipes. Quel que soit le nom de la personne qui apporte ces compétences au sein de l’équipe, un product manager, chef de produit, product owner, po, pm… le nom n’a pas d’importance. Ce n’est que de la sémantique. Il n’est même pas nécessaire que ce soit un titre distinct, tant qu’il est présent.
C’est quelque chose dont nous tous, en tant que praticiens Scrum, devrions nous inquiéter. Donnons à nouveau au Product Management une place centrale dans le Scrum Guide.
Définissons comment cela devrait être, au lieu de laisser libre cours à l’imagination du monde extérieur.
Remplaçons l’étiquette Product Owner par quelque chose de plus facile à comprendre. Se conformer aux étiquettes existantes qui sont bien connues dans le monde du product management peut être un bon point de départ.
De cette façon, Scrum pourrait avoir une chance de se battre contre les solutions Frankenstein PM/PO qui rendent les gens malheureux partout dans le monde et diminuent la livraison de valeur.
Il y a beaucoup à (re)dire ! Principalement :
qu’opposer PO et PM est une guéguerre de praticiens techs qui ne sert pas le client (qui s’en fout royal)
que le PO de Scrum et le PM n’ont ni la même origine ni la même histoire (mais ils ont bien le même objectif : faire un produit qui cartonne)
On pourrait les comparer s’ils venaient tous deux de l’agilité (mais ce n’est pas le cas : le PM vient de l’entrepreneuriat où peu d’équipes – pour ne pas dire aucune :sueur_et_sourire: – travaillent en mode agile contrairement à l’imaginaire collectif véhiculé par les AirBnb & autres Spotify qui sont des ovnis ou font de l’agilité une fois que le produit a trouvé son market fit)
La différence de perspective ne vient pas des rôles de l’un ou l’autre mais du scope de la “méthodo”.
Le scope historique de Scrum est la solution : bien délivrer un bon incrément produit. Peu de PO ont voie au chapitre sur le modèle économique du produit, ses canaux de diffusion, ses moteurs de croissance ou les techniques de guerilla marketing (par exemple) qu’on adopte au démarrage pour faire connaître le produit aux users. Et je parle même pas de l’UX/CX et de la recherche utilisateur.
Le scope historique du Product Management est… le marketing (et la vente : cf les “Chefs Produit” dans la pub). Je devrais dire le “bon marketing”, le marketing vertueux à la Seth Godin.
On a donné un “esprit agile” et entrepreneurial au Product Management avec le Lean Startup (qui est une méthode itérative et incrémentale dont le scope est l’intégralité du modèle d’affaires, pas juste la solution)
Mais on peut avoir une belle culture Produit sans faire de Scrum.
Le P Mgt a le vent en poupe parce que plus que jamais c’est intéressant de couvrir toute la chaîne : la solution (l’incrément) mais aussi son delivery (technique, marketing et commercial) jusqu’au client final, puis mesurer l’adoption, etc. pour peut-être faire de multiples pivots de business model.
Dans le domaine de l’agilité, je trouve qu’il y a tout de même souvent une jolie confusion sur le rôle de PM/PO. Le coté “hiérarchie” est relativant présent, le PM étant souvent vu comme le chef des PO, ou un PO senior, le PO n’étant alors qu’un gentil scribe au plus proche de l’opérationnel sans aucun ownership (je caricature un peu meme si je l’ai deja vecu). Du coup, un PO “seul à bord à tout gérer” ne pourrait pas être “PO” mais serait un “PM”? Le PO peut s’appeler PO, lead PO s’il coordonne d’autres PO, PM, finalement ce qui compte c’est le role et responsabilité défini à son arrivée je trouve.
Robin, purrais tu développer ce qie tu préconises ? Avoir 1 seul PO et développer les compétences en gestion de produit (PM) de l’équipe ? Cela semble plus facile à dire qu’à faire…. je suis dubitative…je pense que la dérive vient du fait que la tâche à accomplir semble gigantesque. D’où le fait et tu n’en parles pas qu’on mette un proxi pour aider le PO ? Qu’en penses tu ?