Le product owner est l’une des trois responsabilités définies par le cadre Scrum : il répond de la valeur du produit issu du travail de l’équipe et gère le carnet de produit qui ordonne ce qu’elle doit réaliser.
Le guide de référence de Scrum, dans sa version de novembre 2020, précise le contenu de cette responsabilité. Le product owner formule et communique l’objectif de produit, c’est-à-dire l’état futur visé. Il crée et explicite les éléments du carnet de produit, les ordonne et veille à ce que ce carnet reste transparent et compris de tous. Il peut déléguer ce travail, mais il en reste responsable. Ses décisions doivent être respectées par l’ensemble de l’organisation. Elles se lisent dans le contenu et l’ordre du carnet, puis dans l’incrément présenté lors de la revue de sprint.
Le même guide insiste sur un point : le product owner est une personne, non un comité. Il peut représenter les besoins de nombreuses parties prenantes, mais quiconque souhaite modifier le carnet doit l’en convaincre. L’équipe Scrum comprend aussi un Scrum Master et des développeurs, et compte en général dix personnes au plus.
Le product owner se distingue du product manager, intitulé de métier sans définition normative, dont le périmètre s’étend à la stratégie du produit, au marché et au lancement. Il se distingue aussi du chef de projet, qui s’engage sur un périmètre, un délai et un budget fixés à l’avance. Le product owner, lui, réordonne en continu ce qui apporte le plus de valeur. Hors du développement logiciel, le rôle apparaît dans des équipes marketing ou digitales qui adoptent un fonctionnement agile.
La dérive la plus courante est connue : un product owner désigné sans pouvoir de décision. Il recueille les demandes, les reformule en tickets et les transmet. Les vrais arbitrages se font ailleurs, en comité ou dans le bureau d’un directeur. L’équipe attend alors des décisions qui ne viennent pas, et le carnet devient une liste de souhaits. Le guide de Scrum demande pourtant que les décisions du product owner soient respectées par toute l’organisation. Nous recommandons d’écrire ce mandat noir sur blanc avant de nommer quelqu’un : périmètre du produit, budget de développement concerné, sujets réservés à la direction.
Un carnet de plusieurs centaines d’éléments n’aide personne. À notre sens, seuls les éléments des prochains sprints méritent d’être détaillés. Le reste peut rester à l’état d’intentions, regroupées par problème à résoudre. Chaque élément du haut du carnet devrait préciser le besoin de l’utilisateur, le résultat attendu et les critères qui permettront de dire qu’il est atteint.
La vélocité d’une équipe mesure un rythme de travail, estimé par l’équipe elle-même. Elle ne dit rien de la valeur produite et se compare mal d’une équipe à l’autre. Les indicateurs utiles au product owner portent sur les effets : progression vers l’objectif de produit, usage réel des fonctions livrées, satisfaction des utilisateurs, délai entre l’expression d’un besoin et sa mise à disposition. Un test A/B permet, lorsque le volume d’utilisateurs le permet, d’isoler l’effet d’une livraison. Chaque indicateur clé de performance retenu doit être relié à l’objectif de produit, faute de quoi il finit par piloter l’équipe à sa place.
Le rôle trouve sa place hors du logiciel dès qu’un dispositif évolue en continu : site, espace client, programme de marketing automation, application. Le product owner y arbitre entre les demandes des équipes de communication, des ventes et du service client. Il travaille avec les développeurs et les designers chargés de l’expérience utilisateur. Pour une campagne ponctuelle au périmètre figé, en revanche, la gestion de projet classique reste plus simple.
En assistance à maîtrise d’ouvrage, Advalians analyse vos pratiques et vos dispositifs, puis pilote le projet avec vos équipes et vos prestataires.
Advalians, cabinet de conseil indépendant en marketing et communication, vous aide à clarifier vos choix et à décider.
Le chef de projet tient un engagement fixé à l’avance : un périmètre, un délai, un budget. Il mesure sa réussite à leur respect. Le product owner dispose d’un cadre de temps et d’équipe, mais réordonne le contenu à chaque sprint selon la valeur attendue. Il mesure sa réussite aux effets sur les utilisateurs.
Critère pratique : si le résultat attendu peut être décrit entièrement au départ et ne changera pas, un chef de projet suffit. Si le besoin se précisera en cours de route, au contact des utilisateurs, nommez un product owner.
Ordonnez les éléments selon la valeur attendue rapportée à l’effort, puis corrigez selon le risque et les dépendances.
Revoyez l’ordre avant chaque planification de sprint, et motivez les changements auprès des demandeurs.
Regardez les effets des livraisons, pas le nombre de tickets traités. Trois questions suffisent à une revue trimestrielle. L’équipe progresse-t-elle vers l’objectif de produit écrit au départ ? Les fonctions livrées sont-elles utilisées par les utilisateurs visés ? Les développeurs obtiennent-ils rapidement une réponse quand ils ont une question ?
Complétez par un signal simple : la part des éléments du haut du carnet qui portent un critère de réussite mesurable. Une part faible indique un carnet tenu comme une liste de demandes, sans arbitrage réel.
Non, pas dans le cadre Scrum : son guide de référence précise que le product owner est une personne, non un comité. Un comité dilue la responsabilité et ralentit les arbitrages, car chaque membre défend ses propres demandes.
Les parties prenantes gardent leur place. Réunissez-les à la revue de sprint pour qu’elles voient le résultat et donnent leur avis. Organisez un point régulier où chacune présente ses besoins. Mais laissez au product owner la décision finale sur l’ordre du carnet, et rendez cette règle publique pour éviter les contournements.
Oui lorsque le projet est un dispositif qui évoluera après sa mise en ligne : site, espace client, scénarios d’e-mails automatisés, application. Les demandes y arrivent en continu et quelqu’un doit les ordonner.
Non pour une opération ponctuelle au contenu figé, comme une campagne saisonnière ou un événement : un chef de projet et un rétroplanning suffisent. Critère de choix : si vous prévoyez plus de deux ou trois cycles d’amélioration après le lancement, désignez un product owner disposant d’au moins une partie significative de son temps sur ce dispositif. Ce seuil est un repère, non une norme.
