Si le product management entrait à l’Académie Française, cela donnerait probablement lieu au plus grand débat sémantique du siècle. Head of Product People chez Wivoo, je vous donne MON avis sur LE grand débat : faut-il différencier les rôles de product owner et product manager ?
Je commencerai par décrire la nature du débat product owner versus product manager et les arguments en place. Je m’indignerai ensuite contre cette (mauvaise) pratique, tout en expliquant pourquoi cette distinction me semble contre-productive. Je formulerai quelques hypothèses pouvant expliquer cet état de fait. Enfin, je proposerai un plan d’action.
Tout commence par un ressenti doublé d’un constat.
En France, dans le monde en pleine expansion de l’agilité et du product management, nombreux sont les postes à pourvoir commençant par cet acronyme de “PO”, aka “product owner”.
À titre d’exemple, chez Wivoo, une majorité des fiches de postes des missions proposées à nos consultants s’intitulent de cette manière “recherche product owner”. À l’opposé, plus rares sont les missions de “product manager” inscrites dans un contexte de product management au sens digital du terme.
Et nous voilà face à ce qui crée le débat : deux appellations distinctes bien que cousines, product owner & product manager, et bien souvent opposées par le ou les sens que chacun confère à l’une et l’autre.
Et pour ajouter de l’huile sur cette flammèche dormante, le monde anglo-saxon, et notamment le foyer originel des Etats-Unis, ne semble en rien préoccupé par ce débat. Nous voilà nous, francophones, à débattre de termes en langue anglaise !
Tous les ingrédients sont désormais réunis pour un embrasement généralisé des exégètes du product management.
Nul exercice de synthèse ne saurait retranscrire les 1001 nuances de comment product owner et product manager sont des métiers généralement différenciés en France.
Il est possible de commencer par l’idée, vraie, qu’avant tout :
> Product owner est un rôle au sein d’une équipe produit, tel que cela fut introduit par un des innombrables frameworks (ou cadre de travail) de l’agilité : Scrum. Le fait que Scrum soit au passage le framework le plus massivement diffusé et utilisé aujourd’hui ne saurait d’ailleurs être omis dans notre réflexion.
> Product manager fait avant tout référence au “product management”, c’est-à-dire une discipline ou un domaine d’expertise(s) s’intéressant au produit. Dans son acception moderne et digitale, ce “product management” désigne une discipline relativement jeune, avec une trentaine d’années d’existence tout au plus.
Cette distinction a pour limite qu’elle s’arrête à une vision très théorique.
Aussi, pour révéler bien plus clairement les différences des deux acronymes PO (product owner) et PM (product manager), il s’avère davantage pertinent de regarder les fiches de poste associées à chacun.
En caricaturant, et le trait ne déformera pas tant la réalité, cet exercice révèle que :
> Un poste de product owner désignerait un rôle intrinsèquement tourné vers des tâches opérationnelles. Comme décrit dans le Scrum Guide (document décrivant le framework Scrum, écrit par Ken Schwaber et Jeff Sutherland, voir ressources utiles), le product owner est en charge d’un produit. Il en gère le backlog (la liste des tâches à accomplir pour donner vie aux évolutions du produit). Avec son équipe (la Scrum Team), il assure la priorisation de ce qui doit être fait. Parce que ces tâches relèvent généralement du développement logiciel, le product owner collabore quotidiennement avec une équipe technique, constituée notamment de développeurs, testeurs, QA… Pour reprendre le jargon du métier, le delivery (ou build) est son champ d’action.
> A l’inverse, un poste de product manager caractériserait un rôle double, voire triple. Premièrement, le product manager aurait une portée stratégique : le product manager définit, incarne et défend la vision de son produit (la direction globale à suivre et les objectifs à atteindre). Pour ce faire, il discute avec les stakeholders et questionne les utilisateurs. Il mène la discovery et la recherche utilisateur. A cela s’ajouterait un deuxième dimension : celle du management. Il incomberait ainsi au product manager de manager un ou plusieurs product owners, hiérarchiquement et/ou de facto rattachés à lui. Enfin, ce rôle de manager d’équipe et cette vision stratégique ajoutent assez naturellement un degré de séniorité à ce rôle de product manager. Le tiercé du product manager : stratégie, management & séniorité.
Au cas où mon propos ne saurait être suffisamment clair, je me permets d’insister sur le négatif, implicite, de ma synthèse, qui fera office d’ultime révélateur. Par principe :
> Un product owner ne ferait QUE de l’opérationnel. Il exécute la stratégie. Il ne contribue pas à la discovery. Il ne manage pas et ne parlerait qu’à son équipe produit. Son horizon de temps est celui du sprint (itération de 1 à 4 semaines, au cœur de certaines méthodologies agiles).
> À l’inverse, le product manager n’interviendrait PAS sur la phase de delivery. Son horizon de temps est celui de la roadmap et de la vision. C’est un stratège, un décideur, et bien souvent un manager.
En résumé : product owner = backlog (et pas vision), product manager = vision (et pas backlog).
Pour comprendre pourquoi je me battrai corps et âme contre cette distinction, il ne vous reste qu’à lire la suite !
Oui, cette distinction me fâche.
Non, elle ne me fâche pas pour des raisons dogmatiques, mais bien parce que, intrinsèquement, viscéralement, elle s’inscrit dans une manière de penser et d’agir qui va à l’encontre de grands principes du product management.
Le product management repose, entre autres, sur cinq grands principes :
1. Une équipe produit autonome, auto-organisée et pluridisciplinaire
2. Une proximité avec ses utilisateurs, pour mieux capter leurs besoins, frustrations et motivations dans le but, ENSUITE, de concevoir les meilleures solutions
3. Des itérations raccourcies afin de minimiser les risques et de maximiser la création de valeurs, et cela, à chaque itération
4. Une pratique d’apprentissage en continu via le test & learn
5. L’utilisation de la donnée, à tous les moments du cycle de vie, pour prendre les bonnes décisions
Mais alors, dans un monde où la distinction s’exerce, on peut se poser les questions suivantes :
> Si, en tant que product owner, un product manager décide de la stratégie de mon produit, et qui plus est si ce product manager est également celui qui m’évalue chaque année, peut-on vraiment parler d’ownership et d’autonomie de l’équipe produit ?
> Si, en tant que product manager, je ne connais pas l’actualité de l’équipe de développement, puis-je vraiment prévoir ce sur quoi celle-ci travaillera dans quelques itérations ou quelques mois ? Et suis-je plus légitime pour le faire qu’un product owner ?
> Si, en tant que product owner, je suis obligé d’attendre les résultats de la recherche menée par mon product manager pour corriger ou améliorer un parcours, avons-nous réellement les cycles les plus courts pour répondre aux besoins de nos utilisateurs ?
> Si, en tant que product owner, j’écris des user stories qui vont à l’encontre des besoins utilisateurs et de ce que révèlent les données utilisateurs, suis-je vraiment fautif si je n’ai pas accès ou au moins de droit de regard sur celles-ci ?
Ces questionnements révèlent comment cette distinction product owner versus product manager sous-entend inéluctablement des problématiques très opérationnelles :
> celle de la transmission de l’information entre product owner et product manager,
> celle de la clarté des rôles et responsabilités de chacun.
Si ces enjeux ne sont pas insurmontables, ils vont, dans la pratique, très souvent de pair avec de l’inefficience, de la perte d’information et des délais rallongés, ce qui va, encore une fois, à l’encontre d’itérations courtes et porteuses de valeur.
Un acteur du produit, qu’il soit product owner ou product manager en titre, ne sera que plus efficace s’il intervient sur l’ensemble du cycle de vie du produit. La vision et la stratégie ne sont rien sans une exécution concrète, et l’exécution n’est rien (ou est totalement incohérente) sans une direction claire. Mener la recherche utilisateur et utiliser les données disponibles sont tout aussi importants pour définir la vision que pour rédiger des user stories créatrices de valeur.
La connaissance du delivery et la proximité avec l’équipe produit sont absolument fondamentales pour fédérer celle-ci.
Ne plus faire cette distinction, c’est avant tout donner accès aux connaissances, méthodes et outils qui permettront de mieux exercer chacun des deux rôles distingués à tort, tout en apportant une cohérence d’ensemble, en faveur de la création de valeur.
Et de la même manière qu’un product owner (ou un product manager) n’est jamais le chef (hiérarchique ou managériale) des membres d’une équipe produit, toute subordination d’un product owner à un product manager, dans une telle séparation des tâches, ne me semble pas souhaitable, car contraire aux idées de responsabilisation, d’autonomie et de confiance.
Rien ne remplace une analogie un peu provoc’ (et pas très réaliste) !
> Sabrina est spécialiste du genou (product manager) : elle a demandé de faire l’IRM d’un patient hier, elle a regardé les analyses. Elle a préconisé, dans l’intérêt du patient bien sûr, d’opérer sa jambe demain. Après-demain, elle ira voir le patient et lui demandera si l’opération a bien "marché". Si ce n’est pas le cas, elle ira voir le chirurgien qui aura opéré pour savoir ce qu’il a fait.
> Pierre est chirurgien (product owner) : il n’a pas vu les IRM et analyses réalisées par Sabrina, il n’a jamais vu son patient. Il arrive au bloc, il opère la jambe de son patient tel que communiqué juste avant de rentrer au briefing. Après, il rentre se coucher. Demain, il a 5 autres opérations avec 5 autres patients. Il apprend le lendemain que le patient opéré a eu des complications dans la nuit, mais c’est à Sabrina de s’en charger.
L’intérêt du patient ne résiderait-il pas dans l’idée que Pierre et Sabrina devraient être une seule et unique personne ?
Il en va de même dans le produit.
Enfin, et pour conclure cette partie, n’oublions pas aussi que derrière tout product owner ou product manager, il y a un employé. À l’heure où les employés n’ont jamais autant cherché de sens dans ce qu’ils font, priver un tel product owner de la stratégie, ou à l’inverse, un tel product manager du delivery revient à leur arracher un bon bout de ce qui donne tout son sens à leur métier.
Vous l’avez compris, cette distinction ne me convient guère. Toutefois, il me semble intéressant d’essayer de comprendre pourquoi beaucoup d’entreprises françaises font encore cette distinction en 2022.
Quand l’agilité et le product management ont fait leurs premiers pas dans l’écosystème produit embryonnaire français, le vecteur fut souvent celui de la méthode Scrum, toujours majoritairement utilisée. Dans bien des cas, l’expérimentation devient exemple, l’exemple devient référence, la référence devient norme.
Beaucoup d’entreprises ne réfléchissent peut-être plus vraiment à ce que l’intitulé véhicule et l’impact que cela peut avoir.
Après tout, comme product owner est le terme communément utilisé pour décrire ce-type-de-métier-du-produit-que-personne-ne-maîtrise-vraiment-la-preuve-chacun-en-a-sa-définition, et bien faisons comme tout le monde, et appelons ça product owner…
Rappelons ici que le Scrum Guide, qui, le premier, a introduit le rôle de product owner est un document de 14 pages. Je ne cherche pas à en critiquer le contenu.
Tout comme le Manifeste Agile, ce document est exemplaire dans l’essentialité des concepts proposés. Mais cette essentialité s’avère aussi son principal ennemi en cela qu’une bonne application de ces concepts est, dans la pratique, complexe, et peut prendre bien des aspects. C’est pour cela que deux personnes occupant un rôle de product owner dans deux entreprises différentes, voire dans deux équipes d’une même entreprise, n’exerceront parfois pas -du tout- le même métier.
Les rôles de product owner et product manager ne sont pas des apparitions miraculeuses et spontanées. Dans bien des cas, ces rôles se sont créés en substituts, en prolongements ou en compléments de rôles préexistants. Chef de projet, AMOA, AMOE, PMO, sans oublier le chef de produit (sous-entendu marketing) ont façonné, et continuent de le faire parfois, bon nombre d’organisations produit.
On pourrait caricaturer en voyant dans le product owner un héritier du rôle de chef de projet (proche de l’équipe de production, de profil ingénieur) alors que le product manager serait plutôt l’héritier du chef de produit (celui qui définit la stratégie produit, de profil école de commerce). Cette hypothèse se vérifie plutôt bien chez certaines grandes entreprises avec un lourd passif du mode projet, mais ne saurait être généralisée.
J’épargne au lecteur une digression entière -et caricaturale- sur le mode projet mais cette hypothèse soulève évidemment les enjeux du management du changement, notamment au niveau des nouvelles compétences requises et de l’évolution des mindsets individuels.
Pour ne rien simplifier, rappelons que la traduction, toujours en vigueur, de chef de produit dans le monde anglo-saxon n’est autre product manager… Ceci pourrait d’ailleurs expliquer un autre phénomène du produit : l’apparition (ou le rebranding) du marketing product manager dans les équipes produit.
Ce point m’a été inspiré par les échanges que j’ai eus avec Thomas Rolf, Head of Product chez Alan et Louis Lecat, Product Leader, lors de l’After Produit du 7 décembre 2022. Thomas soulignait que le product management ne fait pas exception au syndrome du “je cherche un [remplacer par n’importe quel métier], mais avec plusieurs années d’expérience.”
Fort de ce constat, il émettait l’hypothèse que la nomenclature de product owner pourrait être un moyen détourné de répondre à la difficulté de recruter un product manager débutant, tout en s’assurant qu’il maîtrise certaines compétences clés, jugées essentielles. Dans cette hypothèse, la maîtrise du delivery constituerait les fondations (fertiles) d’une expertise en product management.
Cette hypothèse s’inscrit parfaitement dans l’idée que le terme de product manager revêt aujourd’hui une connotation de séniorité.
Cette dernière hypothèse fait la synthèse des trois précédentes.
Les entreprises ont tendance à aimer l’ordre et les processus. Mettre des étiquettes, ranger, codifier sont la seule raison d’exister de certaines personnes dans des entreprises. La difficulté apparaît vite dès lors qu’il s’agit pour un recruteur de définir, avec précision, un rôle dans un domaine encore jeune (le product management), et qui plus est lorsque le produit en question, son contexte de marché, la vision de l’entreprise, la maturité de l’équipe et bien d’autres facteurs encore font émerger une liste de responsabilités et de savoir-faire pléthoriques.
Face à cet exercice compliqué, l’erreur commise par beaucoup d’entreprises est de simplifier l’équation en utilisant la mauvaise variable d’ajustement.
Pour simplifier (cette fois-ci à des fins explicatives), deux alternatives se présentent à moi en tant que recruteur :
> Soit j’accepte de confier à mon employé l’ensemble des tâches nécessaires à la création de valeur mais sur un périmètre produit restreint.
> Soit je maintiens le périmètre produit, mais je décide de concentrer mon employé sur un sous-ensemble de tâches.
Cette seconde option, aussi destructrice de valeur et de sens, tel que vu précédemment, sera malheureusement le choix rassurant fait par beaucoup. Après tout, n’est-il pas plus facile de rechercher un tourneur-fraiseur dont je saurai aisément tester les compétences de tourneur-fraiseur qu’un ouvrier complet capable d’assembler n’importe quel lave-vaisselle ou voiture ? Si cette stratégie peut s’avérer efficace à court terme, on peut s’interroger sur sa réelle pertinence dans un métier encore très changeant.
En croisant les différentes hypothèses, on imagine assez facilement comment, pour bien des aspirants au product management, le rôle de product owner ne constitue désormais qu’une étape pour, ensuite, devenir product manager. Et comme toute étape imposée dans un parcours, celle-ci revêt très vite une connotation négative. C’est là un problème que l’on rencontre parfois chez Wivoo avec des consultants en product management débutants exprimant le souhait d’être, tout de suite, product manager, ou même celui de ne pas/plus vouloir être product owner, comme si ce rôle était dégradant.
Adoptons une démarche produit en 4 étapes :1 - Recherche et analyse
2 - Apprentissages & hypothèses
3 - Actions
4 - Résultats
Tout ce qui précède dans cet article devrait faire office de recherche et d’analyse.
> Distinguer les métiers de product owner et product manager est antinomique avec les principes du product management, et en conséquence, contre-productif.
> Le rôle du product owner est dévalorisé de manière injustifiée, et le terme trop souvent utilisé de manière restrictive.
> Continuer de distinguer product owner et product manager contribue à valider une distinction que l’on cherche à combattre.
> La véritable variable d’ajustement entre des profils débutants et expérimentés ne devrait jamais être celle des tâches qui lui incombent, mais bien son périmètre produit. Plus un product manager gagnera en séniorité, plus on lui confiera des produits à forte valeur ajoutée, des produits stratégiques voire des portfolios de produits nécessitant un alignement fort.
À l’inverse, limiter un profil débutant à un rôle d’exécutant (delivery) l’exclura du sens apporté par la vision globale et lui fermera les portes de beaucoup d’opportunités d’expérimenter sur son (petit) périmètre produit. A ce titre, dans un intitulé de poste, je préconiserai l’emploi de product manager, plus complet et porteur de sens que product owner [et cela même si, dans bien des équipes, le rôle de product owner, au sens Scrum, sera incarné par ce même product manager].
> Chez Wivoo, une première action a consisté à revoir les intitulés des niveaux de séniorité de nos consultants en product management. PM (junior) / PM confirmé / PM Senior, Lead PM a permis de faire disparaître le terme de product owner du premier niveau. Certes, l’impact de ce changement de nomenclature en interne reste limité, mais il constitue néanmoins le fruit de notre réflexion sur le sujet. Si nous avons décidé de supprimer la notion de product owner, c’est bien parce que son sens commun a parfois, hélas, une connotation restrictive.
> Nous avons aussi décidé d’aborder et d’apporter un regard critique sur cette distinction product owner versus product manager lors des formations dispensées par la WiAcademy. Notre ambition est ici de toujours plus rappeler (et incarner) l’essence même du product management auprès des formés.
Jean Denouvilliez, co-founder et CEO de la WiAcademy me disait récemment “Nous n’apprenons pas à nos formés à être des product owners, nous leur donnons les clés du product management. Ces clés s’appellent marketing, technique, user experience, data, stratégie, business…”
> Si nous ne contrôlons pas les intitulés des postes ouverts par nos clients, nous nous efforçons, avec nos consultants, d’en lire les détails et d’évaluer l’envergure du champ d’action décrit. À nous, en connaissance des enjeux et attendus, de proposer les consultants les mieux armés en fonction de chaque contexte, indépendamment des rôles et postes qu’ils ont occupés auparavant.
> Forts de leurs savoir-faire, nous incitons nos consultants à être eux-mêmes les ambassadeurs d’un product management à 360°, en prouvant leur valeur par la pratique et des résultats concrets. Ce n’est pas parce que leur intitulé est celui de product owner qu’ils ne peuvent pas faire du product management. Tous en ont envie, tous.
Wait & see !
Enfin, rappelons que le titre importe très peu au final.
Assurons-nous de toujours donner du sens à ce poste en lui associant l'autonomie, la liberté d'action et les outils nécessaires pour bien incarner ce rôle, tout en veillant à définir un périmètre produit adapté au niveau de compétences du product manager en question.
Lorsqu'un besoin de coordination surviendra, un product manager ayant accumulé de l'expérience dans des contextes variés sera évidemment mieux armé qu'un profil plus junior pour assumer cette activité transverse.
Au quotidien, les champs d'action de chacun auront tendance à diverger : l'un agira à un niveau plus opérationnel, l'autre adoptera une posture plus haute et sera le garant permanent de l'alignement. Le métier n'en restera pas moins le même.
Cela ne fonctionnera que parce que leur objectif restera le même : créer de la valeur pour les utilisateurs et pour l'entreprise.
Alors, appelons ce rôle comme bon nous semble, soyons mêmes créatifs, mais, par pitié, ne cantonnons plus jamais un product owner à la seule rédaction de user stories.
Wivoo est une agence de conseil de référence en Product Management ! Depuis plus de 3 ans, nos wivers aident nos clients - grands groupes et scale-ups - à transformer leurs produits en véritables succès et à faire monter leurs équipes en compétences.