Le Product Owner n'arbitre pas, il décide

Article

Introduction

Je vois passer deux caricatures du Product Owner en permanence. La première, le PO qui écoute et transmet. Direction donne une demande, il la met sur le backlog. Marketing demande une feature, elle entre en sprint. Métier crie urgent, il repriorise immédiatement. Il est un porte-voix sans filtre. La seconde, le PO qui pilote la livraison. Il fait des rétrospectives, il suit le burndown, il arbitre entre deux implémentations techniques, il gère le planning. Il est un mini chef de projet habillé en agile.

Les deux sont faux. Et les deux sont dangereux.

Le vrai rôle du PO, celui qui crée de la valeur durable, c'est de tenir ensemble trois axes : la vision du produit, la faisabilité technique et les urgences réelles du marché. Pas d'ordre de priorité. Pas de hiérarchie morale. Juste une tension permanente que le PO doit arbitrer, chaque semaine, sans tomber dans aucun des trois pièges.

C'est un rôle d'arbitre. Pas d'exécuteur.

Cette confusion vient d'une malédiction du rôle, le PO est au carrefour de tout. La direction, le métier, l'équipe technique, les clients, les partenaires. Chacun pense qu'il faut prioriser sa propre demande. Et le PO qui ne dit pas non devient vite un secrétaire dépassé qui gère des conflits à la place de l'organisation.

Le PO qui n'arbitre que sur la vision est un rêveur. Il fabrique des roadmaps magnifiques, inatteignables, et son équipe finit par l'ignorer. Le PO qui n'arbitre que sur la faisabilité technique est un ingénieur qui négocie sa propre complexité au lieu de servir un marché. Et le PO qui n'arbitre que sur l'urgence est un pompier qui brûle son produit au fil du temps.

Voici ce que j'ai appris en accompagnant des PO dans des trains SAFe sur quatre ans, la posture qui change tout, c'est celle du partenaire stratégique qui refuse, qui propose, qui impose quand c'est nécessaire, et qui tient ses comptes rendus de raison à la direction sans crainte. Ce PO-là n'est jamais populaire, mais il finit par être écouté. Parce que ses décisions fonctionnent.

Le PO n'est ni un porte-voix ni un mini chef de projet

La confusion entre ces deux rôles a un mérite, elle montre à quel point le PO fait peur à l'organisation. Trop puissant si on lui laisse de l'autonomie, trop faible s'il n'a que la parole de transmettre. Du coup, les organisations lui confient tout sauf ce qu'il faudrait.

Le PO porte-voix, c'est celui qui est devenu le canal entre la demande et l'exécution. "Voilà ce qu'on vous demande, faites-le." Il prend les ordres le lundi en comité produit avec le métier, il met le truc en backlog, il en fait un user story fluide, et voilà. Efficace en apparence. Catastrophique sur la durée. Pourquoi, parce qu'il n'y a personne pour dire non aux demandes contradictoires, personne pour refuser la 47e urgence du mois, personne pour poser la vraie question, est-ce que cette feature sert vraiment notre stratégie produit ou est-ce qu'on réagit à du bruit. La décision est outsourcée au hasard du lobbying organisationnel.

Le PO chef de projet, lui, devient le tuteur de l'équipe technique. Il suit les points, il arbitre entre l'API et le SDK, il optimise l'implémentation, il gère les dépendances. Là aussi, c'est efficace à court terme. À moyen terme, il n'a jamais parlé à un client réel, il n'a pas une vision du marché, il réduit tout à on livre en deux sprints. Les vraies questions d'arbitrage produit finissent par être traitées en dehors de lui, par la direction ou le marketing. Et son équipe perd confiance parce qu'elle sent bien que le PO n'est pas vraiment en charge.

Le vrai PO est un arbitre. Il dit oui et non. Il apporte des raisons. Il change d'avis quand le signal change. Il n'a pas d'agenda caché, il n'a qu'une vision et des limites, quels sont les vrais besoins du marché, qu'est-ce qu'on peut techniquement supporter, où on pose la limite avant de dépenser trop et de crever la vision.

Exemple concret. Un PO avait une vision claire sur l'architecture de son produit (une plateforme d'optimisation moteur). Il a eu une demande du département X, "on vous demande une intégration avec l'outil Y, c'est urgent, c'est stratégique pour nous". Légitime. Mais le PO a posé deux questions, est-ce que ça sert notre vision produit, oui un peu, est-ce que c'est techniquement simple ou ça va bloquer notre roadmap, ça va prendre 40 % de la capacité du train pendant deux trimestres. Conclusion, il a dit non, il a expliqué pourquoi, il a proposé une alternative (une intégration allégée six mois plus tard). Le département X a eu mal trois jours. Six mois après, il a dit merci parce que l'alternative suffisait et la plateforme avait tenu ses promesses.

Ce PO n'était pas populaire. Il avait raison.

Les trois axes d'arbitrage du PO

Le PO tient trois tensions ensemble. Les ignorer, c'est perdre un axe et dériver.

L'axe vision. Qui on sert, pourquoi ce produit existe, quel problème il résout réellement. Ce que je vois en continu, des organisations qui remplissent des templates de vision produit sans jamais l'utiliser comme outil d'arbitrage. La vision devient une affiche de corridor. Le vrai PO, lui, ramène tout à la vision. Une demande arrive, ça sert notre vision. Si la réponse est clairement non, le PO propose de laisser tomber ou de la traiter ailleurs. Si c'est un peu, il pose la question, on y consacre combien de capacité pour combien de valeur. La vision n'est pas un poème, c'est un filtre.

L'axe faisabilité. Qu'est-ce qu'on peut faire avec une équipe de N personnes, en tenant compte de la dette technique, des dépendances, de la courbe de vie du produit. Je vois des PO qui ignorent complètement la technique et se demandent pourquoi l'équipe les ignore. Je vois aussi des équipes techniques qui refusent tout changement de priorité au motif qu'il y a de la dette. Entre les deux, le PO vrai doit pouvoir dire, je comprends qu'il y a de la dette, j'ai aussi une deadline commerciale, voilà comment on arbitre, on dépense 30 % cette quarter sur la dette structurelle et on met 70 % sur la feature client. Pas de débat stérile. Un choix avec des raisons.

L'axe urgence. Les demandes arrivent sans respecter votre planning. Le marché bouge. Un concurrent fait quelque chose. Un client clé fait chier. Le PO qui n'arbitre que sur l'urgence finit en pompier. Il jure que c'est vraiment la dernière fois. Puis 48 heures après c'est encore la dernière fois. Mais le PO qui refuse d'écouter le signal marché finit hors de la réalité. L'arbitrage, c'est cette urgence est réelle, elle demande 3 sprints, ça va décaler la roadmap de deux mois, le jeu en vaut-il la chandelle. Parfois oui. Souvent non. Mais la question doit être posée, et la réponse doit être visible à l'organisation entière.

Tenir les trois. Le piège classique, le PO idéaliste qui dit d'abord la vision puis le reste finit avec une roadmap inutile. Le PO pragmatiste qui dit d'abord la faisabilité finit avec une équipe qui se connaît par cœur mais pas assez rapide. Le PO réactif qui dit d'abord l'urgence finit avec un produit qui part dans tous les sens.

Le bon arbitrage, c'est en quoi ça sert ma vision, de façon réaliste. Et non pas, c'est ma vision donc on doit le faire. C'est, techniquement c'est dur, est-ce que la valeur justifie l'effort. Et non pas, c'est dur donc on ne le fait pas. C'est, cette urgence est réelle, elle dure combien, et où on la cale. Et non pas, arrêtez tout.

Les trois axes ensemble, c'est la posture du PO qui dure. Isolément, c'est un rôle à court terme ou une abstraction.

Construire une vision produit qui résiste à la pression

La vision produit en grand groupe c'est un exercice politique. Pas seulement. Mais surtout.

Parce que la vision doit être assez claire pour arbitrer, assez flexible pour durer, assez crédible auprès du terrain pour ne pas être contredite d'emblée, assez ancrée au marché pour ne pas sembler déconnectée. C'est une formule difficile. Et la plupart des visions échouent sur l'un des quatre points.

Comment on la formule. Voici ce qui marche, un énoncé de 3 à 5 phrases qui dit qui on sert vraiment (pas "les entreprises" mais "les directeurs de fleet management des PME de 50 à 500 véhicules"), qu'est-ce qu'on leur résout (pas "améliorer le pilotage" mais "réduire les coûts d'essence de 8 à 12 % en six mois sans changer leur logiciel"), et comment on le fait différemment d'un concurrent (pas "avec des algorithmes propriétaires" mais "sans former personne, avec une API qui branche sur leur comptabilité existante").

Ça semble détaillé. C'est fait exprès. Une vision vague (devenir leader du marché) n'arbitre jamais. Une vision trop spécifique meurt au premier changement de contexte.

Ce qui résiste à la pression. La vision doit être ancrée à un ou deux cas clients réels, nommés (quand c'est permis) ou au moins suffisamment décrits. Pas "on sert les clients qui" mais "la DSI de TechCorp nous a dit que" ou "on travaille avec trois clients similaires qui". Parce que dès que quelqu'un au comité dit "ouais mais il y a aussi le marché allemand qui demande", vous pouvez répondre, oui, et l'allemand doit pouvoir être servi par le même produit avec cette philosophie, si ce n'est pas possible, c'est un nouveau produit ou un nouveau marché.

Les critères d'une bonne vision. Elle passe le test du non, vous la proposez, vous attendez une semaine, les gens reviennent avec des demandes qui ne la respectent pas. La vision était bonne. Elle passe le test du changement, contexte change, PDG change, stratégie évolue, la vision tient ou elle devient rapidement obsolète. Les meilleures visions durent 18 à 24 mois sans révision. Les autres meurent en six mois. Elle passe le test du oui, assez de clarté pour que l'équipe technique sache ce qu'elle construit et pourquoi, et assez de flexibilité pour qu'on n'arrive pas chaque sprint à justifier pourquoi on a changé d'avis. Et elle passe le test du marketing, elle inspire confiance auprès des clients sans être une promesse marketing creuse.

Travailler avec les parties prenantes sans devenir leur secrétaire

Le piège du PO c'est simple, vous êtes au carrefour, alors tout le monde vous demande quelque chose. Direction demande une feuille de route jusqu'à 2028. Marketing veut trois features d'ici le mois prochain. Métier veut que vous assistiez à cinq réunions par semaine. Technique gueule parce que la dette technique. Clients veulent être consultés.

Vous devenez un organisme de distribution de demandes et de refus. Vous ne décidez plus, vous managez du bruit.

La première limite, clarifier le périmètre du PO. Ce que j'ai vu fonctionner en train SAFe, le PO est responsable de la vision, du roadmap et de la priorisation. Le PO n'est pas responsable de la date exacte de livraison (c'est le SM plus l'équipe), ne dirige pas la technique (c'est le tech lead), ne peut pas promettre au client sans valider avec l'équipe (c'est une conversation, pas une décision du PO seul). Cette limite ressemble à pas grand-chose, mais elle évite au PO de devenir responsable de tout.

La deuxième limite, bâtir un système de demandes. Le PO qui dit oui à la première demande et non à la troisième parce qu'il était fatigué perd la crédibilité. Voici ce qui marche, un processus clair (les demandes arrivent par un formulaire, pas en réunion improvisée), une hiérarchie honnête (je vais répondre à votre demande en 48 heures et vous dire oui, non, ou c'est possible mais à quelle place dans la roadmap), et une traçabilité (voilà pourquoi on a dit non à telle feature, voilà ce qu'on en fait à la place).

La troisième limite, dire non en expliquant. Non sans raison crée du ressentiment. Non parce que la vision produit ne l'inclut pas, et on n'a pas la capacité technique même si c'était bon à faire respecte l'interlocuteur, même si la réponse est non. J'ai vu un PO dire non à un demandeur puissant (VP marketing), simplement avec, c'est légitime, c'est une bonne idée, mais si on la fait on vire trois autres trucs du roadmap, c'est le choix que tu veux. La VP a dit non, merci. Simple.

La quatrième limite, proposer une alternative. Le PO qui refuse tout est un bloqueur. Le PO qui propose une version allégée de la demande, ou un délai, ou une étape intermédiaire, devient un partenaire. Je ne peux pas faire le truc intégralement avant novembre, mais je peux faire la version alpha en juillet et on verra.

Un PO qui promet et tient finit par être écouté même quand il dit non. Un PO qui multiplie les promesses qui traînent se rend faible. Quand vous avez un backlog de promesses non tenues, vous avez perdu la confiance de l'organisation.

Les métriques qui disent vraiment quelque chose

Je suis fatigué d'entendre les PO parler de vélocité comme si c'était la santé du produit. La vélocité c'est combien de points de story vous traitez par sprint. Zéro signal sur la santé produit.

Voici ce qui compte vraiment.

Adoption et abandon. Taux de clients qui utilisent réellement la feature six mois après. Pourcentage de dépréciations (fonctionnalités qu'on a supprimées parce que personne ne les utilisait). Je vois des produits où 40 % du code n'est jamais exécuté. Ça, c'est un signal fort que le PO ne sert pas les vrais besoins ou qu'il fabrique du luxe au lieu du nécessaire.

Time to value. En combien de temps un client nouveau voit de la valeur. Une heure, un jour, une semaine. Plus ça prend, plus c'est douloureux. Beaucoup de produits B2B entassent des fonctionnalités mais un client reste confus pendant deux semaines après son arrivée. Le PO vrai mesure ça et en fait une priorité de produit, pas juste une question d'UX.

Satisfaction nuancée par segment. Ne pas faire un NPS global. Faire un NPS par type de client (startup vs grand compte, client nouveau vs client trois ans). Parce que votre produit peut ravir les startup (onboarding simple, prix bas) et énerver les grands comptes (manque de conformité, manque de SLA). Ça dit au PO sur quoi il doit construire.

Coût de change. Si un client change de produit facilement, vous êtes fragile. Si c'est coûteux, vous êtes dans la place. À mesurer. À monitorer.

Dépendances critiques et dette technique. Je l'ai dit, les bonnes équipes techniques ignorent le PO qui ignore la technique. Pas de combien de points de dette, mais combien de features on réclame par quarter qui butent sur une dépendance non résolue. Si c'est plus de trois, c'est un problème produit.

Ce qu'on ne mesure pas, story points, burndown, tickets fermés par sprint. Ça c'est de la plomberie. Utile pour l'équipe. Zéro signal sur la santé produit réelle.

En conclusion

Le rôle de Product Owner n'est pas compliqué à définir. C'est l'arbitre entre vision, faisabilité et urgence. C'est une simple phrase. Mais c'est un rôle qu'on n'apprend pas en trois jours de formation.

Je l'ai vu s'apprendre dans le fer. Dans les arbitrages refusés. Dans les sponsors puissants qui finissent par comprendre que le PO n'est pas un exécuteur de leurs demandes. Dans les équipes techniques qui découvrent qu'un PO qui maîtrise sa vision ne leur en demande pas plus, il leur en demande plus clair. Et dans les clients qui apprécient de ne pas être sur la liste de demandes en attente, mais d'être servis par un produit qui sait ce qu'il veut.

Voici ce qui change tout, le PO qui arrête de vouloir être aimé de tout le monde et qui choisit d'être cru. Qui refuse de distribuer des demandes et qui décide. Qui apprend à faire compétence (vision claire, marché connu), à écouter (sans faire de la transcription obéissante), et à tenir ses arbitrages dans le temps.

Ce PO existe. Je le vois dans chaque train SAFe qui dure. Il n'est jamais le plus populaire. Il n'est jamais le consultant qui parle le mieux. Mais six mois après son arrivée, les gens lui font confiance. Un an plus tard, personne ne le conteste.

C'est parce qu'il n'arbitre pas. Il décide. Et ça se voit.

Pour approfondir ce rôle, deux chemins. Le PSPO I couvre les fondamentaux, vision, backlog, stories, métriques. Le PSPO II creuse la posture, arbitrage en continu, gestion des parties prenantes, feedback loops, adaptation du produit. Si vous encadrez des PO en organisation SAFe, le SAFe POPM couvre les arbitrages à l'échelle du portefeuille. Et je propose aussi un accompagnement RTE/PO senior pour qui veut débloquer des arbitrages spécifiques dans sa transformation en cours.

Pour aller plus loin

Articles connexes à venir, placeholders à brancher en MDX :

Vision produit, formuler clairement ce qu'on sert.
Arbitrer avec l'équipe technique sans devenir un chef de projet agile.
Travailler avec le marketing et la vente sans casser le produit.
Roadmap produit, dire oui, non, et pourquoi.
SAFe PO, arbitrer au niveau du portefeuille.
Retour vers la pillar Agilité à l'échelle, le PO dans un train SAFe, qu'est-ce qui change.