Dans mon quotidien professionnel, j’entends régulièrement ce genre de phrase : “Toi qui est PM, ou PO… Enfin, c’est pareil quoi”. Alors non. Même si ces deux casquettes peuvent se combiner, un PM et un PO ne sont pas interchangeables et ils ont bien deux jobs différents.
Ça ne viendrait à l’esprit de personne de dire que Superman et Batman sont la même personne et font la même chose.
Ce qui m’a donné envie de faire une petite mise au point là-dessus, autant pour moi-même que pour vous autres. Et un petit retour aux origines s’impose avant tout !
Le rôle de Product Management est arrivé très tôt dans la gestion de projet des entreprises. Plus précisément en 1931 du côté de chez Procter & Gamble, initié par un certain Neil H. McElroy, grand visionnaire à l’époque, avec son memo sur le “Brand Man”.
McElroy ne s’est d’ailleurs pas arrêté là, et à notamment aidé à fonder la NASA et a fortement influencé Bill Hewlett et David Packard, -les créateurs de HP- avec sa vision du product management. Et oui. Rien que ça…
À l’origine, ce rôle n’est donc pas du tout lié à l’agilité. Le Product Manager a pour objectif la réalisation d’un produit dans sa vision globale :
Le terme Product Owner, à contrario, est arrivé avec le premier manifeste Agile en 2001. Factuellement, dans ce manifeste, le PO est désigné comme une personne “proxy” entre l’utilisateur et l’équipe de développement.
Dans les faits aujourd’hui, un PO est souvent considéré en tant que tel s’il fait partie des utilisateurs finaux du produit en question. Est alors considérée comme “Proxy Product Owner” la personne jouant réellement le rôle de Product Owner dans l’équipe de développement.
Son rôle, beaucoup plus opérationnel dans le développement d’un produit au jour le jour, a notamment pour objectifs de :
Finalement, d’avancer pas à pas vers le produit final souhaité par le client et / ou l’utilisateur, de la manière la plus lisse possible.
Le rôle de “Product Owner” a donc très rapidement été confondu avec celui de “Product Manager”. En réalité, ce dernier est essentiellement stratégique et très peu opérationnel.
Le Product Manager doit s’assurer que le produit ou les fonctionnalités imaginées ont de la valeur pour son utilisateur final, prioriser en fonction de cela les objectifs du produit mais aussi réduire les risques qui pourraient faire échouer son produit sur le marché.
Le Product Owner doit s’assurer que le produit est développé en fonction de cette vision et de ces objectifs. Il priorise avec l’appui de l’équipe de développement, donc avec la réalité opérationnelle, ce qui doit être mis en place pour atteindre ces objectifs de la manière la plus efficiente.
Voici un tableau récapitulatif, avec une vision macro, de la répartition des rôles entre le product manager, le product owner, et toute la team dans un projet agile :
Pour conclure sur ces comparatifs, le PO est défini par SCRUM et l’agilité de manière générale, il n’existe pas sans l’équipe de développement.
Le PM est défini par le produit lui même et les différents états de la vie du produit, c’est ce qui fait que son travail au jour le jour évolue.
Mais pour que le développement d’un produit fonctionne bien, un PO ne peut se contenter d’écrire des US toute la journée sans réfléchir à quoi ces nouvelles fonctionnalités serviront, ni pourquoi il est nécessaire de le faire de cette manière ou mieux, de le faire d’une autre manière.
Il ne pourra pas non plus comprendre les réels besoins de l’utilisateur, le challenger, lui faire tester le produit au fur et à mesure de sa conception, comprendre ses habitudes d’utilisation face à un nouveau produit. De ce fait il ne pourra non plus lui proposer les fonctionnalités les plus adaptées, qui sont parfois différentes de ce qu’il pensait initialement vouloir.
D’où l’importance de travailler main dans la main et de se partager la vision produit, différente et complémentaire.
Dans un monde idéal, il est évident que ces deux rôles doivent être remplis par deux personnes différentes, autant par la différence de périmètre que par le poids de l’activité qui incombe à chacun.
Il est aussi évident que toutes les sociétés n’ont pas les moyens de se payer deux ressources pour mener à bien ces deux rôles, et qu’il incombe au PO+PM de remplir le job pour deux.
Voici une petite liste des pours et des contres à cette solution :
Pour conclure, à l'image de nos supers héros et de leur Justice League, le PM et le PO ont bien chacun leurs spécificités et un rôle différent, mais oeuvrent dans le même but. La communication entre les deux est essentielle et l'union fait leur force.
Cependant, ils peuvent tout aussi bien exister indépendamment et être autonome, en assumant partiellement la charge de l'autre. On peut facilement faire le parallèle avec un développeur qui serait aussi scrum master. Ce n'est pas l'organisation la plus idéale au monde, mais en faisant attention à l'impartialité et au temps à allouer aux différentes casquettes, elle peut également fonctionner.
Auteur(s)
Vous souhaitez en savoir plus sur le sujet ?
Organisons un échange !
Notre équipe d'experts répond à toutes vos questions.
Nous contacterDécouvrez nos autres contenus dans le même thème
La qualité est un enjeu très important dans le développement logiciel, cet article vous permettra de (re)découvrir les impacts de la non-qualité, les bienfaits de la qualité et les bonnes pratiques qualité.
Aujourd’hui on parle de product management pour qualifier tout et n’importe quoi, ce qui entraîne la mise en place d’organisations produits sur des bases bancales. Quelles sont les principales erreurs commises ? Comment les éviter ? La liste n’est pas exhaustive mais vous permettra assurément de mieux appréhender votre méthodologie produit.
Cet article présente mes méthodes préférées pour bien appréhender un nouvel environnement de travail, incluant des outils pratiques comme le rapport d'étonnement, le Value Stream Mapping, le mandat de mission, la matrice des attendus et les Moving Motivators, afin de faciliter l'intégration, améliorer les processus et renforcer la collaboration au sein de l'équipe