5 techniques pour un Product Owner qui priorise mieux

En bref. Un Product Owner tranche toute la journée : quoi construire, dans quel ordre, pourquoi. Cinq techniques de Business Analyse l'aident à décider avec méthode plutôt qu'au feeling : tenir un backlog produit sain, ordonner sur le bon axe, écrire des user stories claires, poser des critères d'acceptation observables et savoir qui pèse sur le produit dans la durée. Ensemble, elles rendent chaque priorisation défendable.

Si tu es Product Owner (PO) — la personne qui porte la valeur d'un produit et décide de son ordre de construction —, tu vis sous une pression constante : tout le monde veut sa fonctionnalité en premier. Sans méthode, tu décides au plus fort ; avec, tu décides au plus utile. Chez Edelw'ice, le glacier artisanal lausannois fondé par Heidi en 1983, c'est Lexie — celle qui va voir sur le terrain — qui a montré à l'équipe produit comment défendre un choix sans hausser le ton.

Pourquoi « décider au feeling » finit-il par se retourner contre le PO ?

Parce qu'une priorité qu'on ne sait pas expliquer se conteste sans fin. Si l'ordre du backlog repose sur la seule intuition du PO, chaque partie prenante — chaque personne que le produit touche ou qui peut l'influencer — pousse la sienne, et le PO passe ses journées à négocier au lieu de livrer. Une méthode partagée déplace le débat : on ne discute plus qui a raison, mais le critère.

Cinq techniques pour ordonner, écrire et défendre

1. Tenir un backlog produit sain. Le backlog produit, c'est la liste unique et ordonnée de tout ce qui reste à construire sur un produit. Il vit au-delà d'un projet, il est porté par le Product Owner, et il est ordonné par valeur. Un backlog sain se reconnaît à sa forme : le haut affiné et prêt à partir, le bas volontairement grossier, et un nettoyage régulier de ce que plus personne ne défend. → la fiche dédiée.

2. Ordonner sur le bon axe. C'est ici que le PO gagne le plus, et la question n'est pas technique : elle est de savoir qui arbitre. Le PO arbitre côté métier — il compare des fonctionnalités, et il les compare en impact × urgence : ce que ça rapporte, et ce que coûte l'attente. L'effort, lui, appartient à l'équipe qui construira : elle arbitre ses tâches en impact × effort. Le métier ne chiffre pas l'effort — il le fait chiffrer, puis il s'en sert. Un PO peut donc en tenir compte, mais il ordonne d'abord sur la valeur : c'est le seul argument qui lui appartienne. MoSCoW (Must, Should, Could, Won't — « doit / devrait / pourrait / ne sera pas ») rend le même service en version grossière, quand il s'agit surtout de séparer l'indispensable du confort. → prioriser quand tout est urgent.

3. Écrire des user stories claires. Exprimer chaque besoin en une phrase — « en tant que…, je veux…, afin de… » — dont la dernière partie porte un bénéfice réel, pas une reformulation de la première. → écrire des user stories.

4. Poser des critères d'acceptation. La condition observable qui dit quand une story est réussie : une phrase qu'on peut vérifier sans débattre. Écrite avant le développement, elle évite les livraisons « presque bonnes » qui repartent en correction et mangent la capacité du sprint suivant — le sprint étant, dans les méthodes agiles, la courte période de travail (une à quatre semaines) au bout de laquelle l'équipe livre quelque chose d'utilisable.

5. Cartographier les parties prenantes du produit. Un projet se termine, un produit continue : le flux de demandes ne s'arrête jamais. Situer qui pèse sur le produit et qui s'y intéresse sert moins à constituer un comité qu'à savoir qui consulter avant d'ordonner — et à qui on doit un « non » argumenté plutôt qu'un silence. → la fiche dédiée.

Le réflexe de Lexie. « Une priorité qui s'explique se défend toute seule. » Elle attache toujours un pourquoi à l'ordre du backlog.

La même logique, hors du produit

Gérer une liste de demandes clients, un planning d'équipe, un budget associatif : partout, un critère explicite vaut mieux qu'un arbitrage à la tête du client. Ces techniques servent tout rôle qui doit dire non à de bonnes idées pour livrer les meilleures.

Un chef de projet s'appuie sur plusieurs des mêmes techniques, mais pour cadrer un engagement qui a une fin. Le comparatif est dans 5 techniques d'analyse pour tout chef de projet.

Par où commencer

1. Assainis ton backlog produit : une seule liste, le haut affiné, le bas grossier.
2. Nomme l'arbitre avant l'axe, puis réordonne tout le haut du backlog en impact × urgence.
3. Réécris trois demandes floues en user stories, avec un bénéfice et un critère d'acceptation observable.

Trois gestes, et ta prochaine revue de backlog se défend sans monter d'un ton.

Ces cinq techniques, et les 45 autres du guide central du BABOK, sont sur les cartes du deck BADASS : la vue d'ensemble, et le moyen de se rappeler laquelle sortir le jour venu. Le déroulé complet d'une technique sur un cas réel — pas à pas, arbitrages, chiffres — c'est l'eBook qui lui est consacré.

Articles liés : Gérer son backlog sans se noyer · Écrire des user stories claires · 5 techniques d'analyse pour tout chef de projet