Ce que fait vraiment un Product Owner

Mardi, 9h12 : trois demandes, un seul sprint

Ton sprint planning est dans deux jours. Ce matin, trois messages t'attendent. Le directeur commercial : "il me faut l'export PDF des trajets pour vendredi, c'est promis au client Sodexo". Le support : "30 % des tickets du mois concernent le calcul d'itinéraire qui se trompe de point de rendez-vous". Un développeur : "on repousse encore la migration de la base ? Elle nous coûte une demi-journée par semaine en contournements". L'équipe livre environ 30 points par sprint. Ces trois sujets, mis bout à bout, en pèsent 21. Il reste le reste du backlog.

Tu ne peux pas tout faire. Décider ce qui passe devant, et pouvoir expliquer pourquoi à chacun des trois sans perdre leur confiance : voilà le métier. Tout le reste du cours détaille comment prendre ce genre de décision autrement qu'au feeling ou à l'ancienneté du demandeur.

La définition officielle, et ce qu'elle cache

Le Scrum Guide tient en une phrase : le Product Owner est responsable de maximiser la valeur du produit issu du travail de l'équipe. C'est vrai, et c'est presque inutile tel quel. Dans la réalité d'une journée, le PO passe son temps à trancher : quelle est la prochaine chose la plus utile qu'on puisse livrer, et pourquoi celle-là plutôt qu'une autre.

Le piège numéro un du débutant, c'est de se vivre comme un guichet. Le commercial demande une fonctionnalité, elle entre dans le backlog. Le directeur veut un bouton rouge, il devient une story. Au bout de trois mois, le backlog compte 400 tickets, personne ne sait ce qui compte, et l'équipe livre beaucoup sans que rien ne bouge côté clients. J'ai repris un backlog dans cet état en arrivant sur un produit de paiement : 412 tickets, dont 260 jamais rouverts depuis plus de six mois. On en a fermé 300 en une après-midi, personne ne les a jamais réclamés. Un bon PO dit non plus souvent qu'il ne dit oui, et il sait expliquer chaque non.

Trois responsabilités qui ne se délèguent pas

Sur le fond, le métier tient sur trois piliers. D'abord la vision et la stratégie : où va le produit, pour qui, contre quoi il se bat. Ensuite la gestion du backlog : traduire cette direction en travail concret, ordonné, compréhensible par l'équipe de développement. Enfin l'arbitrage de valeur : décider en permanence des priorités face à des ressources limitées et des demandes contradictoires.

Ce qui n'est pas le métier : écrire les tests à la place des devs, imposer comment on code, jouer au chef de projet qui distribue les tâches. Le PO décide du *quoi* et du *pourquoi*. L'équipe décide du *comment*. Cette frontière est la source de la moitié des conflits que je vois chez les nouveaux POs.

À quoi ressemble une journée

Pour donner de la chair au poste, voici une journée assez représentative :

• 9h30 : daily de l'équipe, 15 minutes. Tu écoutes, tu notes deux questions produit à traiter après.
• 10h : entretien avec un utilisateur (30 minutes, en visio), le troisième de la semaine.
• 11h : refinement avec l'équipe, une heure. Deux stories clarifiées, une découpée en trois, une renvoyée en découverte.
• 14h : écriture des critères d'acceptation des deux prochaines stories, réponses aux questions posées le matin.
• 15h30 : point avec le directeur des opérations, qui finance le produit. Tu montres les chiffres du mois et tu défends l'ordre du backlog.
• 16h30 : tri des demandes entrantes de la semaine. Sur neuf, deux entrent au backlog, cinq sont refusées avec une réponse motivée, deux repartent en question de découverte.

Remarque ce qui n'y figure pas : aucune heure passée à "faire du Jira". L'outil, que ce soit Jira, Linear ou une base Notion, matérialise tes décisions ; il ne les prend pas. Un PO qui passe quatre heures par jour à ranger des tickets a un problème de fond, pas un problème d'outil.

Notre fil rouge : Covio

Tout le cours s'appuie sur un produit unique, Covio, une application de covoiturage domicile-travail. L'idée : mettre en relation des salariés qui font le même trajet chaque matin. Le marché existe (BlaBlaCar Daily et Karos opèrent dessus en France), le modèle est un marketplace à deux faces — il faut assez de conducteurs *et* de passagers pour que ça marche — et les problèmes produit y sont concrets : confiance, ponctualité, remboursement, masse critique locale.

Quelques ordres de grandeur qu'on retrouvera tout du long : 3 400 inscrits sur la zone pilote de Lyon-Est, 12 % d'actifs hebdomadaires, un taux d'annulation conducteur de 18 %, une équipe de cinq développeurs et une designer, des sprints de deux semaines, une vélocité moyenne de 30 points.

À retenir : le PO ne maximise pas le volume livré, il maximise la valeur livrée. Ce sont deux métiers différents, et le second est beaucoup plus difficile.

Garde Covio en tête. À chaque notion, on se demandera : concrètement, qu'est-ce que ça change pour la prochaine décision sur Covio ?