La personnalité recherchée pour le rôle de Product Owner

Une nouvelle façon de présenter le portrait du PO idéal

La personnalité recherchée pour le rôle de Product Owner
Sommaire

C’est le 5 décembre 2006 que j’ai écrit le premier article de description du rôle de Product Owner. En ce moment, je réécris le chapitre qui lui est dédié pour l’édition 6 de mon livre. Il sortira en gros quinze après.

L’occasion de voir ce qui a évolué dans le rôle et dans la façon de le présenter.

Évolutions

Le nom

Mon article de 2006 a pour titre : Le rôle de directeur de produit. Eh oui, je ne disais pas Product Owner. J’utilisais directeur de produit depuis la lecture d’un excellent article de Brian Marick, dont je vous conseille la lecture (pdf), il est toujours très pertinent.

Malheureusement, c’est Product Owner qui est resté…

Le chapitre

En 2009, un chapitre s’appelait donc Product Owner et c’est d’ailleurs le premier que j’ai écrit. Il faut dire qu’à l’époque je tenais ce rôle pour iceScrum, ça me donnait de la confiance pour en parler.

Au fil des éditions, il a évolué tout en gardant la même structure. Dans l’édition 5, la trame a evolué avec 2 nouvelles rubriques :

  • la journée typique d’un PO,
  • les antipatterns.

L’article Tenir le rôle de Product Owner constitue le bonus de ce chapitre.

Nouvelle grille

La structure du chapitre va changer suite à la lecture de l’excellent livre de Luc de Brabandère :

Petite philosophie des arguments fallacieux

Dans son chapitre L’instant critique il décrit le penseur critique en termes d’attitude, de compétences, de capacités et d’exigences. Ça m’a donné envie d’utiliser cette grille pour le Scrum Master.

Après le Scrum Master, voici ce que ça donne pour le Product Owner.

Le portrait d’un Product Owner idéal (2021)

La carte heuristique associée à l’article donne la vue d’ensemble. Je suis parti de l’édition 5, plus précisément des traits présentés dans les § 4.2 à 4.4 que j’ai essayé de mettre au bon endroit (attitude, compétence, capacité ou exigence).

Attitude

Luc de Brabandère définit l’attitude comme l’état d’esprit. C’est une prédisposition mentale qui désigne une intention et n’est donc pas directement observable.

Pour moi, un Product Owner devrait avoir cet état d’esprit :

Envie de changer le monde

Ne serait-ce qu’un tout petit peu, comme dit Jeff Patton.

Ouvert au feedback des utilisateurs

Il pense — vraiment — que les retours des utilisateurs sont les bienvenus et il en tient compte>.

À l’écoute des idées de ses coéquipiers

Il est normal qu’un Product Owner ne connaisse pas aussi bien que ses coéquipiers les aspects techniques des solutions pour arriver à un résultat. Ceux-ci, en faisant, font émerger de nouvelles idées qui peuvent améliorer le produit. Il est important que le PO s’y intéresse et fasse confiance à ses coéquipiers.

Compétences

Une compétence est une connaissance approfondie, reconnue qui confère le droit de juger ou de décider.

On demande au Product Owner des compétences sur :

Son domaine métier

Bien sûr, c’est son Product. Il ne sait pas tout mais sait s’appuyer sur ceux qui savent.

Scrum et l’agilité

Un Product Owner doit connaitre Scrum et les techniques de définition de produit.

Dans l’édition actuelle du livre, je liste 7 compétences pour le Product Owner Avec cette grille de réflexion, je réduis à 2 ! Les autres sont devenues capacité, attitude ou exigence.

Capacités

Une capacité est une possibilité de réussite et de mise en oeuvre de compétences dans l’accomplissement d’une activité.

Voici quelques capacités utiles à un Product Owner :

Percevoir la valeur

Le Product Owner décide des priorités en s’efforçant de maximiser la valeur. Le travail du PO c’est décider ce qui doit être fait, ce qui ne sera pas fait et assumer la responsabilité de ses choix. Grâce à lui, du travail inutile sera évité.

Prendre les décisions concernant le résultat

Dans une équipe qui démarre, l’auto-organisation concerne le comment. Sur le quoi, le Product Owner décide. Cependant il sait expliquer ses décisions.

Détailler au bon moment

Le Product Owner pratique l’affinage du backlog. Il a la capacité de décomposer au bon moment, pas trop tôt ni trop tard.

Trier le feedback

Il y a toujours plus d’idées que de capacité à faire par l’équipe. Le Product Owner ne peut pas dire oui à tout.

Garder le cap

Si l’on ne demande pas à un Product Owner d’être un grand visionnaire comme Steve Jobs , il doit cependant avoir une bonne vision du produit et être capable de la communiquer. Tout le monde devrait partager cette vision, et c’est au PO de s’assurer que l’équipe garde le cap. Il ne faut pas comprendre l’ouverture au changement proposée par le Manifeste comme le droit de changer d’avis à tout moment. Un Product Owner garde le cap : la vision ne varie pas fondamentalement et, à court terme, c’est lui qui porte l’objectif du sprint. Bien qu’ouvert au changement, il n’est pas une girouette.

Exigences

Une exigence est une contrainte à laquelle une activité doit satisfaire ou un impératif que l’on s’impose à soi-même.

Voici 4 traits qui me paraissent être des exigences pour un Product Owner.

Donner de son temps à l’équipe

La disponibilité pour le rôle est une condition sine qua non. Par opposition à ce qui se passe pour un projet classique, où l’intervention du client (ou de son représentant) est importante au début et à la fin mais pas entre les deux, l’implication du PO est constante sur tous les sprints.

Pratiquer l’art de la conversation

Pour un Product Owner qui a l’habitude de l’écrit, il s’agit de passer à l’oral. Une story ça se raconte.

Dire non aux demandes en violation avec la mission de l’équipe

Un PO peut être soumis à des demandes spéciales venant du sponsor ou d’une partie prenante importante. Si la demande est en contradiction avec l’engagement qui a été pris par l’équipe lors de l’alignement du prélude, celle-ci se sentira trompée et vivra mal ce décalage. Dans sa capacité à dire non, le PO poussera à une discussion sur le sujet.

Défendre l’équipe auprès des parties prenantes

Il est dans l’équipe, il la soutient, même s’il aurait aimé avoir plus de valeur à la fin d’un sprint.

Voir aussi