Le Product Owner porte le pourquoi. Il est responsable de maximiser la valeur du produit, et cette responsabilité tient dans une phrase : c'est lui qui décide de l'ordre.
Une seule personne, pas un comité
Le Product Owner est une personne, pas une instance. Cela n'interdit ni de consulter, ni de s'appuyer sur des experts métier, ni d'être challengé. Mais au moment de trancher l'ordre du backlog, une seule personne décide, et elle en répond.
Un comité de priorisation produit systématiquement le même résultat : un backlog où tout est prioritaire, c'est-à-dire un backlog sans priorité.
Quatre responsabilités
Porter la vision. Savoir dire à qui sert le produit, pour résoudre quel problème, et en quoi il se distingue. Une vision qui tient en trois phrases est une vision utilisable ; un document de vingt pages ne l'est pas.
Ordonner le backlog. Décider de ce qui passe avant. Ce n'est pas classer par importance déclarée : c'est arbitrer entre valeur, risque, coût et apprentissage attendu.
Rendre le besoin compréhensible. Expliquer, montrer, discuter, plutôt que spécifier. Une user story est une invitation à une conversation, pas un document à exécuter.
Décider de l'incrément. Accepter ou refuser ce qui a été produit au regard de l'objectif, et le dire clairement. Un incrément accepté par défaut n'apprend rien à personne.
La compétence centrale : dire non
C'est la part la plus difficile du rôle, et celle qu'aucune certification n'installe. Dire non à une partie prenante puissante suppose deux choses : un mandat clair, et la capacité d'expliquer l'arbitrage plutôt que de l'imposer.
La formulation qui fonctionne est rarement non. C'est oui, et voici ce qui passe après si nous le prenons. L'arbitrage devient alors une conversation sur le coût d'opportunité, pas un rapport de force.
Trois choses qu'il n'est pas
Ce n'est pas un rédacteur de spécifications. S'il passe ses journées à écrire des tickets détaillés, l'équipe a perdu la conversation qui donne du sens au besoin.
Ce n'est pas le chef de l'équipe. Il ne décide pas du comment, ne répartit pas les tâches et n'évalue pas les personnes.
Ce n'est pas un intermédiaire. Un Product Owner qui se contente de transmettre les demandes du métier n'exerce pas le rôle : il le mime, et c'est un des symptômes du théâtre agile.