Nous sommes en 2004, à l’Université on nous parle de notre futur professionnel : développeur ou chef de projet. Souvent le premier avant de poursuivre sur l’autre. Puis pendant 5 ans d’études, on nous parle de cahier des charges, de courbe en V, de MOA, de MOE. Plein de choses qui n’avait pas de sens pour moi à l’époque et qui en ont encore moins aujourd’hui ! Pourquoi tout planifier au départ alors que cela n’est pas planifiable ? Pourquoi perdre du temps à planifier au lieu de faire des choses concrètes et utile ? Pourquoi tout simplement planifier alors que cela ne fonctionne pas ?
Nous sommes en 2021, on ne parle plus de courbe en V, on ne parle plus de Chef de projet. Enfin ! Cela me semble désormais plus censé : un projet est vivant, comme le dev, il ne faut pas tenter de tout planifier ! Place désormais aux méthodes agiles et au Product Owner.
Qu’est-ce qu’un Product Owner (PO) ?
Le Product Owner est la version agile du Chef de projet, il joue le rôle du AMOA en quelque sorte (mais avec pas mal de différences !). Nous ne sommes pas tous d’accord là dessus mais c’est en tout cas ma vision. Ce que j’aime également dans cette approche est que le Product Owner (PO) n’est pas un chef, c’est un leader. Il n’est pas au dessus de l’équipe au niveau hiérarchique mais au même niveau. Adieu la gouvernance hiérarchique des années 80 !
Le PO fait donc partie intégrante de l’équipe. Il faut savoir que l’élément central du Scrum (la méthode agile la plus utilisée) est l’équipe. Ce n’est pas le produit. Le PO travaille donc avec l’équipe de dev et le SM (Scrum Master). Le SM va appliquer Scrum au quotidien et remonter les obstacles au PO, il accompagne l’équipe pour réaliser ce que demande le PO. Ce n’est pas un chef non plus. Tout le monde est au même niveau hiérarchique.
Il est généralement déconseillé que le PO soit aussi SM. Personnellement je pense que c’est possible et que c’est de toute façon le cas avec des équipes de moins de 4 personnes. De même, il est déconseillé d’être PO en remote. Je ne suis pas d’accord non plus. Ce postula part du principe que Scrum fonctionne mieux en présentiel et que donc le PO a besoin d’être physiquement là. Certes cela apporte de nombreux avantages mais la crise sanitaire que nous venons de traverser a semble-t-il montré notre capacité à nous adapter et à travailler en télétravail et, par conséquent comme tout autre job, un PO peut être en remote.
Quel est le rôle du Product Owner ?
Le rôle du PO a des similitudes avec ce que faisait un chef de projet mais en ne gardant que le meilleur et le plus logique. Il va :
- Remplir le backlog avec des users stories
- Prioriser, affiner ce backlog en fonction des feedbacks des parties prenantes (clients, utilisateurs, data)
- Répondre aux questions produit
- Faire de la veille concurrentielle
- Définir les conditions d’acceptation avec l’équipe (dans le cadre de Scrum)
- Vérifier la terminaison des éléments avec l’équipe
- Parfois être en binôme avec un dev pour vérifier le fonctionnement d’une story
- Participer aux planifications de sprints, aux revues, aux rétrospectives et parfois aux mêlées
- Mettre en place des KPI (des KPI d’équipe) , les analyser et agir en fonction
- Discuter et collaborer avec les devs, les sales, le marketing et les clients / utilisateurs
Les plus gros pièges à éviter lorsqu’on est Product Owner sont de :
- Trop écrire de users stories
- Ne pas partager son backlog de manière ouverte et transparente
- Ne pas être assez disponible
- Trop écouter le côté client (utilisateurs)
- Mettre en place des KPI individuel
- Tester les Users stories tout seul. Il faut que l’équipe et les parties prenantes participent aux tests.
Comment le Product Owner gère-t-il son backlog ?
Le PO peut utiliser l’impact mapping pour identifier les features à développer et les priorités (sous forme de mindmap). Pour cela il est d’usage de définir un seul objectif SMART par saison.
Exemple : Multiplier par deux le nombre d’utilisateurs actifs (Goal de la saison – Why?)
- Utilisateurs (Actors – Who?)
- Parrainage (Impact – How?)
- Système de parrainage dans le logiciel (Deliverable / Feature – What?)
- Signup facilité (Impact – How?)
- Amélioration de la page de Signup (Deliverable / Feature – What?)
- Nouvelle option de paiement via Paypal (Deliverable / Feature – What?)
- Parrainage (Impact – How?)
- Support (Actors- Who?)
- Meilleure gestion du support (Impact – How?)
- Marketing (Actors- Who?)
- Travailler sur les messages des landings pages (Impact – How?)
- A/B test de messages (Deliverable / Feature – What?)
- Travailler sur les messages des landings pages (Impact – How?)
A l’issue de l’impact mapping, on obtient des features à développer. Ces fonctionnalités sont ensuite utilisées dans la méthodologie, comme Scrum, pour le Backlog.
Le story mapping est parfois également utilisé. Cela permet d’ajouter une dimension de priorité tout en permettant une visualisation globale du produit (et de toutes ses users stories). Exemple :
| Système de parrainage dans le logiciel | Amélioration de la page de Signup | Nouvelle option de paiement via Paypal |
| Story A | Story B | Story C | Story D | Story G | Story F |
| Story I | Story H | Story L | Story K | Story E | Story O |
| Story N | Story M |
Pour cette saison, sur le 1er sprint, les stories A, B, C, D, G et F seront implémentées. I, H, L, K, E, O sur le 2nd sprint. N et M sur le 3ème. Les stories A, B, C, D, G et F sont prioritaires, I, H, L, K, E, O un peu moins et N, M encore moins.
Le Product Owner va aussi avoir des KPIs à sa disposition. L’essence de Scrum est la simplicité, il ne faut donc pas tomber dans l’excès de KPIs.
Burnup de sprint (en tâches)
Vélocité de sprint
De manière générale, afin de remplir, affiner et prioriser le backlog, le Product Owner va utiliser toutes les informations qu’il peut obtenir (feedbacks des parties prenantes, data, KPI, veille, feedback de l’équipe, etc.) pour faire ses choix.
Quelles différences entre un Product Owner (PO) et un Chef de projet ?
Le Chef de projet fonctionne bien avec une vision ESN / SSII old school où il y a le chef de projet MOA (maître d’ouvrage) qui est côté client, un chef de projet MOE (maître d’oeuvre) qui est côté prestataire et un assistant à la maîtrise d’ouvrage (AMOA) qui va faire le lien entre le MOA et le MOE. Tout ce petit monde travaille souvent au forfait, sans méthode agile mais avec un bon vieux cahier des charges et de la planification à l’extrême.
Le PO n’est pas un MOA ni même un AMOA. Un PO a une interaction quotidienne avec l’équipe de dev alors que le AMOA non. Un PO a une vision globale du produit alors que le AMOA non. Un PO fonctionne en agile alors qu’un AMOA fonctionne avec un calendrier, un budget, un cahier des charges et des comités de pilotage. Enfin, un PO n’est pas un chef.
Quelles différences entre un Product Owner (PO) et un Proxy Product Owner (PPO) ?
Ce rôle de Proxy Product Owner n’est pas reconnu par les méthodes agile comme le Scrum. En théorie le Proxy Product Owner est l’assisant du Product Owner quand celui-ci est débordé et manque de disponibilité.
Souvent le Proxy Product Owner est un rôle qui n’existe que dans les grandes et anciennes entreprises qui mélangent leurs anciennes méthodes d’organisation et des nouvelles comme Scrum. Car dans ce type d’organisation le PO est côté métier et en dehors de l’équipe de dev (équipe scrum), il faut donc un PPO dans l’équipe pour combler cette problématique.
Quelles différences entre un Product Owner (PO) et un Product Manager (PM) ?
On dit que le Product Owner est dans le quotidien opérationnel alors que le Product Manager est dans la stratégie à long terme.
Le Product Owner est dans l’équipe et il est orienté produit, c’est le responsable du backlog et du delivery. Le Product Manager est lui orienté utilisateur, il identifie les besoins et valide la vision du produit. Le Product Owner est donc en charge du delivery alors le Product Manager est en charge du discovery. Dans certaines organisation le Product Manager à aussi un rôle de management et est donc le n+1 des Product Owners. Tout comme le PPO, ce rôle n’est pas reconnu par les méthodes agiles.
Le PM n’a de sens que si le produit et l’entreprise sont trop lourd pour être gérer tout seul par l’équipe Scrum.
Quelles différences entre un Product Owner (PO) et un Chief Product Owner (CPO) ?
Quand un produit devient gros voire obèse, ou alors quand plusieurs produits sont développés dans une entreprise, il faut adopter une nouvelle stratégie d’organisation car une seule équipe Scrum ne peut plus tout gérer. Dans ce contexte, on passe à l’echelle. Une des stratégies est d’avoir un PM comme nous l’avons vu dans le paragraphe précédent. Une autre est d’avoir un CPO. Le CPO signifie souvent la même chose que Head of Product.
Dans un environnement multi-équipes, celles-ci doivent se coordonner et par conséquent les PO doivent synchroniser leurs backlogs afin d’assurer la cohérence globale. Dans ce contexte, les Product Owners gardent la main sur leur produit alors que le Chief Product Owner possède une vue d’ensemble et fait les arbitrages nécessaires en fonction des utilisateurs, investisseurs, etc.
