Souvent lorsque l’on parle de Product Manager (PM) et Product Owner (PO), on a l’impression que ce sont deux métiers complètement séparés. D'un côté le PM 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 ?
Dans ce webinar Thiga, Chloé Dumolard, experte Product Manager chez Thiga, discute des rôles de Product Manager et de Product Owner. Bien que ces deux rôles soient souvent opposés, elle défend la pertinence et la nécessité pour un Product Manager de devenir owner et expert sur la partie delivery.
Les rôles ne doivent donc pas être séparés, 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 sur leurs marché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.
Cette illustration nous a servi de base pour structurer les compétences du poste de Product Manager. Cela nous permet 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 au précédent paragraphe.
De cet apprentissage, nous avons créé un framework Evolve où nous vous proposons de vous évaluer pour évoluer. Il permet 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, ainsi que 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 : évalue tes compétences de Product Manager
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.
À la suite, voici les questions et réponses essentielles du webinar Thiga avec Chloé Dumolard, traitant des rôles de Product Manager et de Product Owner.
En France, beaucoup d'organisations font appel à la fois à un PO et à un PM dans les équipes Produit. Qu’en penses-tu?
C’est vrai, il y a plusieurs cas :
- Dans certaines grandes organisations, un PM est le manager de plusieurs PO. Pour nous, il s’agit ici d’un problème de dénomination. Dans cette logique, il serait préférable d'appeler un PM avec des fonctions de management, un Head of Product.
- Dans d’autres organisations, on retrouve deux professionnels du Produit : une personne owner de la stratégie, des stakeholders, de la communication, et une personne davantage focalisée sur le quotidien. Dans cette configuration, on favorise souvent le découpage des tâches pour éviter qu’ils ne fassent la même chose. Selon moi, ce fonctionnement est risqué : pour la fluidité de l’information, mais aussi pour la synchronisation entre le PM ou le PO, que ce soit pour aligner leur vision, prendre les décisions Produit ou encore 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 interlocuteur 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é dépasser justement en mettant en place une démarche agile. Il n’y a aucune raison de séparer le cadrage et la réalisation.
Pour aller plus loin: Découvre notre formation product owner
Lorsque l’on parle d’agilité, on pense souvent à la méthode SCRUM, parfois décriée. Cette méthode est-elle utile pour devenir un pro du delivery?
Pour moi, SCRUM est vraiment un cadre de travail qui est axé delivery. Lorsque l’on fait du Produit, Scrum n'est pas suffisant car on ne va pas pouvoir gérer l’amont, ni l’aval. Si on revient à notre postulat initial : PM = PO, on doit donc intervenir sur toutes les étapes d’un produit. On associe alors les cadres de travail Scrum Kanban : un Scrumban. Dans cette méthodologie de développement, le Kanban va ici servir de maturation des idées avant qu’elles entrent ensuite dans le board de delivery et se transforment en fonctionnalités.
De façon générale, rien ne 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 donc s’autoriser à adapter les méthodes pour que celles-ci correspondent mieux à l’organisation globale de l'entreprise mais aussi et surtout à l’équipe de développement.
As-tu expérimenté d’autres démarches agiles dans tes équipes ?
Oui, j'ai pu également expérimenter le Mob programming avec une de mes équipes. Pour ceux qui ne connaissent pas le principe, il existe une citation de 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, l'équipe toute entière se réunit pour résoudre ensemble un sujet, qui aura été défini en amont. Chacun des membres de l'équipe va développer à tour de rôle sur la même machine. 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. Il y a des prérequis essentiels à avoir pour que cela fonctionne, notamment la volonté de l'équipe de travailler ensemble. Il faudra également compter sur la souplesse de l'organisation permettant à l'équipe de s'auto-organiser. À titre personnel, ce que j’ai appris de cette démarche c'est sa puissance sur la montée en compétence de toute l'équipe.
Pour résumer, Scrum est une méthode qui permet de gérer le delivery mais qui ne permet pas de gérer le discovery.
Concrètement, si on parle du PM dans le delivery, quelles sont ses responsabilités ?
Je pense qu'il est important de préciser que les missions du delivery ne couvrent pas seulement les ateliers d'écriture des user stories ou l'organisation d'un release plan. L'objectif pour le responsable du delivery est la réalisation de l'ambition fixée en amont. Les responsabilités du PM sont donc multiples. Maintenir le cap sur un ou des objectifs de l'entreprise à l'aide d'une roadmap, assurer l'alignement de l'équipe ou encore donner la visibilité nécessaire à 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 serait d'affiner les sujets, notamment en transformant les epics 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 le travail du PM.
D'ailleurs, en grossissant le trait, dans l'activité de grooming, d’affinage, de refinement - peu importe son nom finalement - il ne s'agit pas seulement de découper en petits morceaux les epics pour ensuite répartir la charge de travail entre les développeurs. Cette activité a pour objectif au contraire de vraiment discuter, s'approprier les objectifs, isoler les chantiers avec l'équipe, identifier clairement quelles seront les priorités et puis s’assurer également que chaque US va délivrer de la valeur finale à l'utilisateur.
Pour cela, il est souvent nécessaire de réaliser des ateliers ou prendre un temps dédiés pour aborder le sujet. Par exemple, prendre 10-15 min après le daily pour échanger sur un sujet avec une ou plusieurs personnes de l'équipe peut être une technique efficace.
Nous n’avons pas encore abordé le sujet du backlog et de sa priorisation : est-ce que cela fait partie 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. Le but est d'assurer la bonne priorisation pour la réalisation de l'objectif.
Pour ce faire, on peut utiliser des matrices de priorisation. Ces matrices seront moins biaisée qu'une évaluation “valeur business versus l'effort”. Elles permettent surtout d'aligner toutes les parties prenantes sur des critères de décision plus objectifs. On peut s’aider de la matrice RICE, très orientée solution, en ajoutant une dimension “problème” pour adapter les critères.
Pour les bugs, la logique sera un peu différente. Il faudra donc surtout identifier quels sont les bugs prioritaires, ceux que l’on pourra corriger plus tard ou ceux qu'il est possible de mettre de côté, puisque le zéro bug n'existe pas. Pour réussir une priorisation, il faut 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. Il n'y a pas besoin de savoir coder, l’important réside dans la compréhension des choix faits pour faciliter les échanges 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 ! C'est d'ailleurs un des atouts du digital, pouvoir s'adapter rapidement à court terme.
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 par l'équipe de développement.
Pour aller plus loin : Découvre notre formation product manager
Penses-tu qu’avoir des connaissances techniques est nécessaire pour être un bon PM ?
C’est important de comprendre le produit : comment il est construit, comment les décisions techniques sont prises… 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 : par exemple il ne faut pas hésiter à participer aux réunions techniques.
Le mob programming était intéressant pour aborder des sujets techniques en tant que PM !
Par ailleurs, je demande systématiquement à mes équipes des schémas d'infrastructures techniques. C’est important de pouvoir accéder à ces documentations et de se l’approprier. Enfin, je dirais qu’internet est votre meilleur ami pour vous documenter …
Pour en savoir plus : Téléchargez notre livre Les Clés du Product Management
