Le PO n'est pas un designer (et autres vérités bonnes à dire sur l'agilité)

Le problème n'est pas la user story. C'est ce qu'on y met.

La structure "En tant que… je veux… afin de" n'est pas mauvaise en elle-même. Elle pousse à articuler un besoin depuis le point de vue d'un utilisateur, ce qui est déjà une bonne habitude. Le glissement commence quand la partie "je veux" devient une spécification déguisée.

"Je veux un bouton rouge en haut à droite qui ouvre une modale avec un formulaire à trois champs." Ce n'est plus une user story. C'est un brief créatif mal rédigé. Le PO a décidé à la place du designer comment la solution devrait se présenter, et à la place des développeurs comment elle devrait être construite. L'équipe peut exécuter, mais elle n'a plus grand chose à apporter.

Ce que le PO est vraiment là pour faire

Le product owner porte une responsabilité qui est souvent sous-estimée parce qu'elle est invisible : comprendre le pourquoi derrière une demande, et le traduire de façon exploitable pour l'équipe. Pas la solution. Le problème.

Ça veut dire aller chercher ce que les parties prenantes expriment, et ce qu'elles n'expriment pas. Une direction métier qui demande "un tableau de bord avec des KPIs" ne demande pas vraiment un tableau de bord. Elle demande à pouvoir prendre de meilleures décisions, plus vite, avec moins d'incertitude. Ce n'est pas la même chose, et la différence change tout à ce que l'équipe va produire.

"People don't want to buy a quarter-inch drill. They want a quarter-inch hole."

Cette phrase, attribuée à Theodore Levitt et reprise dans les travaux de Clayton Christensen sur le Jobs to Be Done, dit quelque chose de fondamental sur la nature des besoins. Les gens n'achètent pas un produit pour ce qu'il est. Ils l'engagent pour ce qu'il leur permet d'accomplir. La perceuse n'est qu'un intermédiaire vers le trou. Et le trou lui-même est peut-être un intermédiaire vers le tableau qu'on veut accrocher, l'appartement qu'on veut rendre plus vivable, la fierté d'avoir fait quelque chose de ses mains.

Un détour par le Job to Be Done

Le framework Jobs to Be Done part de cette idée : pour comprendre ce dont quelqu'un a besoin, il faut comprendre quel travail il essaie de faire dans sa vie, pas seulement ce qu'il dit vouloir. Ce "job" peut être fonctionnel (accomplir une tâche concrète), émotionnel (se sentir compétent, serein, en contrôle) ou social (être perçu d'une certaine façon par son entourage).

Appliqué au travail du PO, cette approche change la nature des questions qu'il pose. Plutôt que "qu'est-ce que tu veux comme fonctionnalité ?", on cherche à comprendre : dans quel contexte ce besoin émerge-t-il ? Qu'est-ce qui se passe aujourd'hui quand ce besoin n'est pas satisfait ? Qu'est-ce qui ferait qu'une solution serait vraiment bonne, pas juste acceptable ?

C'est ce travail-là qui permet ensuite de sortir du quoi et du comment, pour mieux y revenir, mais avec l'équipe entière, et pas depuis les décisions solitaires d'une seule personne.

Ce qu'on fait quand le PO décide à la place du designer

Si le PO spécifie la solution dans sa user story, le designer se retrouve dans une position étrange : valider une décision déjà prise, et en habiller l'exécution. Ce n'est pas du design. C'est de la mise en forme. Le travail réel du designer, questionner les hypothèses, explorer des alternatives, valider avec de vrais utilisateurs, arbitrer entre lisibilité et densité d'information, n'a plus vraiment de place.

Ce n'est pas une critique de la bonne volonté des POs concernés. C'est souvent une question de culture d'équipe, ou de pression sur les délais. Quand on doit livrer vite, il est tentant de "pré-mâcher" le travail pour gagner du temps. Sauf que ça produit l'inverse : des allers-retours, des maquettes jetées, des développements à refaire.

Et ce qu'on fait quand le PO décide à la place des développeurs

L'autre dérive, peut-être moins discutée, c'est quand la user story embarque des contraintes techniques implicites. "Je veux que ça se charge en moins d'une seconde avec une animation fluide, depuis n'importe quel appareil, en mode hors-ligne." Ce ne sont plus des besoins utilisateurs. Ce sont des choix d'implémentation qui appartiennent à l'équipe de développement.

Les développeurs ne sont pas là pour exécuter mécaniquement ce qui leur est dicté. Ils sont là pour trouver la meilleure façon de résoudre un problème, avec leurs connaissances des contraintes techniques, de la dette existante, des compromis possibles. Si tout est déjà décidé dans la story, on se prive de leur expertise là où elle serait la plus utile.

Designer et développeurs : une seule équipe, pas deux silos

Ce qui rend cette organisation efficace, c'est quand le designer et les développeurs travaillent ensemble, pas séquentiellement. Le designer ne produit pas des maquettes finies que les développeurs reçoivent en entrée. Les développeurs ne reçoivent pas des specs figées à implémenter sans discussion. Ce dialogue en continu, c'est là que les meilleures solutions émergent : quand les contraintes techniques orientent les choix de design, et quand les choix de design challengent les habitudes techniques.

Le PO, dans ce modèle, n'est pas l'architecte de la solution. Il est le gardien du problème. Il s'assure que l'équipe comprend bien ce qu'elle essaie de résoudre, et pour qui. C'est déjà un rôle exigeant. Pas besoin d'en faire aussi le designer en chef.

Et l'IA dans tout ça ?

Il y a quelque chose d'intéressant à observer dans la façon dont les équipes intègrent des outils d'IA générative dans leur processus. Utilisée sans réflexion, l'IA a un comportement qui ressemble étrangement au "mauvais PO" décrit plus haut : elle propose, elle oriente, elle remplit les cases vides. Elle sort du lorem ipsum, mais pas du pourquoi.

Demandez à un outil d'IA de concevoir une interface, il va en générer une. Elle sera cohérente, bien formée, acceptable. Mais il ne vous aura pas demandé quel problème vous essayez vraiment de résoudre, pour qui, dans quel contexte, avec quelles contraintes réelles. Il aura orienté vers une solution sans avoir creusé le besoin.

Ce n'est pas un défaut de l'outil. C'est une limite à comprendre. L'IA peut amplifier un bon processus. Elle ne le remplace pas. Et si ce processus n'inclut pas un vrai travail sur le pourquoi, porté par un PO qui fait son métier, questionné par des designers et des développeurs qui font le leur, l'IA produira vite quelque chose qui ressemble à une solution, sans être sûre d'en être une.

Ce que cet article ne dit pas

Il ne dit pas que les POs ne devraient jamais avoir d'intuitions sur la solution. Il ne dit pas que le design doit être hermétiquement séparé du produit. Il ne dit pas que la user story est un format à jeter. Et il ne dit surtout pas que 99 % des POs rêvent secrètement d'être designers, même si parfois, honnêtement, ça se voit.

Ce qu'il essaie de dire, c'est qu'il y a une vraie valeur à clarifier les rôles, non pas pour créer des frontières rigides, mais pour que chacun puisse faire son travail correctement. Un PO qui porte le problème laisse la place au designer de faire du design. Il laisse la place aux développeurs de faire de l'ingénierie. Et il se retrouve lui-même à faire quelque chose de plus difficile et de plus utile : comprendre les vrais besoins, les articuler clairement, et les défendre dans la durée.

C'est une vision, pas un mode d'emploi. Elle ne sera pas parfaite dans votre contexte. Mais si elle vous donne envie de relire vos prochaines stories en vous demandant "est-ce que là je parle d'un besoin ou d'une solution ?", elle aura déjà fait quelque chose d'utile.