Product Manager VS Product Owner : quelle est la différence ?

read time

6 min

Souvent lorsque l’on parle de PM et PO, on a l’impression que ce sont deux métiers séparés avec d'un côté le PM qui se concentre sur les aspects plus stratégiques et de l'autre le PO qui possède une casquette plus opérationnelle et rédige les user stories.

Mais est-il juste de séparer les rôles ? Peut-on parler de PM vs PO ?

Non, le Product Manager est au centre du business, de l’utilisateur et de la Tech. Ce métier intègre une dimension stratégique et une dimension delivery qui permet d'imaginer et de construire des produits à succès. 

Pour illustrer ce propos, chez Thiga, on prend l’exemple d’un M&Ms. Le PM est un M&Ms et la cacahuète au cœur est le delivery. Autour de cette cacahuète, on va trouver du chocolat qui va se décliner en plusieurs saveurs qui sont en fait les compétences du PM comme les soft skills, le growth, le design, la stratégie, l’organisation, la culture, les compétences tech et la data.

Ce M&Ms nous a servi de base pour structurer les compétences de Product Manager et nous permettre d’évaluer les expertises de chacun au sein de Thiga, puisque tout le monde n'est évidemment pas expert dans tous les domaines cités. 

De cet apprentissage, on a créé un framework Evolve où on vous propose de vous évaluer pour évoluer. D’avoir des idées claires sur vos forces et vos faiblesses pour progresser vite. Vous recevez une cartographie précise de vos compétences en tant que Product Manager, et des recommandations personnalisées pour passer au Product Level suivant !

Lectures, formations, vidéos : sélectionnées avec soin par les Thigirls et les Thiguys, vous choisissez la manière d’apprendre qui vous convient le mieux.

Pour aller plus loin : Cliquez ici pour commencer l’évaluation

En bref, on comprend bien que le delivery fait partie intégrante ou devrait faire partie intégrante du périmètre du PM. Pour résumer, PM=métier, PO= rôle au sein d’une équipe Scrum.

Pourtant en France notamment, on constate qu'il y a beaucoup d'organisations qui font appel à la fois à un PO et à un PM dans les équipes Produit. Qu’en penses-tu? 

C’est très vrai, il y a plusieurs cas :

  • Dans certaines grandes organisations, un PM est le manager de plusieurs PO. Pour nous, s’il s’agit ici, d’un problème de naming car on appellerait alors le PM, un Head of Product.
  • Dans d’autres organisations, on retrouve deux professionnels du Produit et dans cette configuration on favorise souvent le découpage des tâches pour éviter qu’ils ne fassent la même chose. On retrouve une personne chargée de la stratégie, des stakeholders, de la communication, et une personne plus focalisée sur le quotidien. Selon moi, ce fonctionnement est risqué : pour la fluidité de l’information, mais aussi pour la synchronisation entre le PM ou le PO : pour aligner leur vision, prendre les décisions Produit, prioriser de manière incrémentale. C'est une source de complexité aussi pour les parties prenantes et pour l'équipe afin d’identifier facilement le bon contact en cas de besoin. C’est un premier problème !
    Le deuxième problème, c'est que ce découpage des tâches risque de recréer une vision MOE, MOA, qu’on a souhaité casser justement en mettant en place une démarche agile. Il n’y a aucune raison de séparer le cadrage et la réalisation. 

Lorsque l’on parle d’agilité, on pense souvent à SCRUM et cette méthode est souvent décriée. Penses-tu que cette méthode est utile pour devenir un pro du delivery?

Pour moi, SCRUM est vraiment un cadre de travail qui est axé très delivery et lorsque l’on fait du Produit, Scrum ne sera pas suffisant car on ne va pas savoir gérer ni l’amont, ni l’aval. Si on revient à notre postulat de base qui est un PM = PO, on doit donc intervenir sur toutes les étapes d’un produit. On associe alors des cadres de travail Scrum & Kanban : un Scrumban, le Kanban va ici servir de maturation des idées avant qu’elles entrent ensuite dans le board de delivery. 

Mais de façon générale, rien de sert d’appliquer les frameworks à la lettre, comme dicté dans les livres. Le plus important reste l’application et le respect des valeurs de l’Agilité, on peut s’autoriser à adapter les méthodes pour que ça corresponde mieux à l’organisation globale mais aussi et surtout à l’équipe. 

Aurais tu d’autres exemples de démarches que tu as pu expérimenter dans tes équipes ?

J'ai testé le mob programming avec une de mes équipes. Pour ceux qui connaissent pas le principe, je vous cite Woody Zuill, coach agile depuis plus de 20 ans, qui résume cela en une phrase : “All the brilliant people working on the same thing, at the same time, in the same space, and on the same computer”.

Globalement, on a toute l'équipe qui va cracker ensemble un sujet, qui aura été défini en amont, et que chacun va développer sur la même machine à tour de rôle. Le retour d'expérience de mon équipe après l’avoir testé : ON VALIDE LA DÉMARCHE ! Cependant, la dynamique n’est pas forcément simple parce qu'il y a vraiment des prérequis essentiels à avoir pour que cela fonctionne, notamment et surtout la volonté de l'équipe de travailler ensemble. Sans oublier, la souplesse de l'organisation qui va permettre à l'équipe de s'auto-organiser. À titre perso, ce que j’ai appris c'est vraiment la puissance de la démarche notamment sur la montée en compétence de toute l'équipe.

Donc pour résumer, Scrum est une méthode qui permet de gérer le delivery et qui ne permet pas de gérer forcément le discovery. Je voudrais juste qu'on se focalise un peu sur le delivery qu’on creuse un peu sur ce sujet. 

Concrètement, si on parle du PM dans le delivery, quelles sont ses responsabilités ?

Je voudrais préciser que le delivery ne sera pas juste des ateliers d'écriture de user stories ou l’organisation d’un release plan, mais vraiment de réaliser l’ambition qu’on s’est fixé et pour cela  la responsabilité d'un PM sera de maintenir le cap d’un objectif, d'assurer l'alignement de l'équipe et puis aussi de donner de la visibilité à toutes les parties prenantes.

Quelle est la première activité qui te viendrait à l'esprit quand on parle de gérer le delivery ? 

La première activité du delivery est vraiment d'affiner les sujets, de venir transformer les épics en plusieurs user stories. Dans cette activité, il s’agit surtout de discuter avec l’équipe, j'insiste sur ce point c’est vraiment un travail d'équipe et pas uniquement un travail du PM. D'ailleurs, je grossis un peu le trait mais l'activité de grooming, d’affinage, de refinement - peu importe son nom finalement -  il s'agit pas vraiment de découper en petits morceaux les épics pour ensuite les séparer et répartir la charge de travail entre les devs. Cette activité vise au contraire vraiment à discuter, à s'approprier les objectifs, à isoler les chantiers avec l'équipe, identifier clairement quelles seront les priorités et puis s’assurer aussi que chaque US va délivrer de la valeur finale. 

Pour cela, en général on ne peut réaliser des ateliers ou bien finalement prendre 10-15 min après le daily pour aborder un sujet avec une ou plusieurs personnes de l'équipe. Cette technique fonctionne d’ailleurs très bien. 

Nous n’avons pas encore abordé le sujet des backlogs, de la priorisation : est-ce-que ça fait partie ou non des tâches d’un PM ? 

Oui, et l’idée c'est de prioriser tous les éléments du backlog : les US, les chantiers techniques mais aussi les bugs. L’objectif c'est d'assurer la bonne priorisation pour la réalisation de l'objectif.

Pour ce faire,  on peut utiliser des matrices de priorisation qui seront un peu moins biaisée qu'une évaluation “valeur business versus l'effort” et qui permettent surtout d'aligner tout le

monde sur des critères de décision un peu plus objectifs. On peut, par exemple, s’aider de la matrice RICE qui est très orientée solutions mais on peut l’aborder en ajoutant une notion de “problème” pour adapter les critères. 

Pour les bugs, ça va être un peu différent donc ici il faudra surtout identifier quels sont les bugs prioritaires, ceux que l’on pourra corriger plus tard ou voire même finalement jamais corriger, puisque le zéro bug n'existe pas.  Pour réussir une priorisation, il faut vraiment accepter que certaines tâches ne soient pas faites. 

Aurais-tu quelques conseils pour un PM afin de gagner du temps dans le delivery ?

Premièrement, il est important de garder une proximité avec les développeurs et de comprendre les choix techniques. Pas besoin de savoir coder mais l’important c’est de comprendre les choix faits pour échanger avec l’équipe. 

Deuxièmement, il faut savoir être réactif et pouvoir reprioriser en cours de delivery. On va forcément voir apparaître des problématiques qu’on n’avait pas anticipé, et c’est normal !

Enfin, ne jamais oublier de communiquer et donner de la visibilité ! La démo, est par exemple, un très bon moyen de donner du feedback et de valoriser aussi le travail qui a été fait. 

Penses tu qu’il faut avoir des connaissances techniques pour être un bon PM ?

C’est important de comprendre le produit : comment il est construit, quels sont les choix faits… Cependant ce n’est pas essentiel de savoir écrire une ligne de code ! 

J’encourage cependant toutes initiatives pour en apprendre plus sur l’aspect technique : ne pas hésiter à participer aux réunions techniques, par exemple. Le mob programming était intéressant pour aborder cette connaissance technique ! Je demande, par exemple systématiquement à mes équipes, des schémas des infrastructures techniques. C’est important d’avoir cette documentation et de se l’approprier. Enfin, je dirai qu’internet est votre meilleur ami pour vous documenter …

Pour en savoir plus : Téléchargez notre livre sur l'Agile Product Manangement

 

Publié le 10 janv. 2022

Mis à jour le 25 janv. 2023

clipboardCopier le lien
Ecrit par
Chloé Dumolard
Chloé Dumolard

Les prochains évènements

Meetup Discovery Discipline 5 - avec M. Benadek et C. Borghese de Lunii

calendar

26 janv 2023

S'inscrire

La Product Conf Paris

calendar

24 mai 2023

Découvrir

La Product Conf Madrid

calendar

26 mai 2023

Découvrir

Filles_ordinateur

Envie de partager tes idées ?


Plus de 20.000 passioné.e.s du Produit viennent sur notre média chaque mois. Retours d’expérience, opinions clivantes, n’hésite pas à nous proposer des contenus.

 

Contacter la rédaction