PO vs PM, like Batman vs Superman

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 !

SOMMAIRE

• PM : looking for the SuperProduct
• PO : leader of the Justice Product
• PM / PO : nothing alike
• PM + PO : dawn of product
• Conclusion : extrasensory perception

PM: looking for the SuperProduct

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 :

• stratégie
• attente du marché
• connaissance des utilisateurs
• adopter la meilleure réponse possible en croisant marché et utilisateurs
• roadmap macro
• réaliser la documentation des spécifications des Epics d’un projet

PO: leader of the Justice Product

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 :

• s’approprier le produit pour comprendre où se trouve la valeur pour l’utilisateur
• faire le lien entre les utilisateurs, le métier et l’équipe de développement
• cadrer et prioriser en amont du développement ce qui doit être réalisé
• réduire les risques en définissant des conditions de réalisation
• apprendre de ses erreurs et des erreurs de l’équipe en améliorant continuellement les process en place

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.

PM / PO: nothing alike

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.

PM + PO: dawn of product

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

• Réduit les intermédiaires avec un unique point d'entrée pour le métier ou les utilisateurs vers les développeurs
• Partialité en prenant et comprenant autant le métier que l'équipe de développement
• Vision utilisateur plus présente et ancrée dans la production
• Meilleure maîtrise au fur et à mesure de l'environnement du produit

Contre

• Manque de temps pour se dédier à la conception stratégique d’un produit sur le long terme ou en fonction d’un marché
• Ou manque de temps pour améliorer le fonctionnement de l'équipe développement
• Risque d'adapter le produit à la production plutôt qu'à une vision utilisateur ou stratégique
• Se renfermer autour de l'équipe de développement en mettant de côté la communication externe (clients, sponsors, utilisateurs)

Conclusion: extrasensory perception

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.