Quand le Product Owner oublie le “pourquoi”… et compile le “comment”

Quand le Product Owner technique veut piloter le business à coups de commits, le produit devient parfait sur le papier… mais sans direction ni pourquoi.

Le syndrome du “PO-tech tout-puissant”

Il arrive en Daily Stand-up avec un laptop et des yeux qui brillent : “J’ai refacto le microservice, c’est plus scalable !” Problème : personne ne sait pourquoi il l’a fait. Le PO issu de la technique a une arme redoutable : la maîtrise du “comment”, mais une faiblesse fatale : l’oubli du “pourquoi”. Et quand il commence à influencer le business, c’est souvent le début d’une douce anarchie organisée.

Le drame du Product Owner venu du code

1. Quand le “comment” dévore le “pourquoi”

Dans sa tête, le code est plus noble que la vision. Chaque user story devient une “feature technique prioritaire”, et le backlog se transforme en journal d’expérimentations DevOps. Le PO-tech préfère “rendre le produit robuste” plutôt que “rendre l’utilisateur heureux”. Exemple classique : au lieu d’ajouter une simple option de paiement demandée par le marché, il reconçoit toute l’architecture “pour anticiper la V3 qui viendra un jour, peut-être”.

2. Le business challengé… à coups de pipelines

Quand un PO technique s’invite dans les discussions business, les slides PowerPoint tremblent. Il explique que “le client n’a pas besoin de dashboards, il a besoin de résilience applicative”. Il remplace les personas par des logs, et les discussions de valeur par des débats sur la latence des API. Résultat : une roadmap orientée infrastructure plutôt qu’impact marché.

3. Le backlog comme laboratoire technique

Sa vision produit ? Maintenir un écosystème pur, sans dette technique ni compromis. Un rêve noble, mais dangereux. Dans son monde, la priorité n’est plus dictée par la valeur business, mais par la beauté du code. Le backlog devient un musée du “clean code”, un endroit sacré où chaque ticket est traité comme un manifeste d’optimisation. Pendant ce temps, les utilisateurs attendent une fonctionnalité simple qui réglerait un vrai problème.

La grande illusion du contrôle

Ce PO pense maîtriser le produit parce qu’il maîtrise le système. Mais en réalité, il pilote un avion sans destination. Chaque décision technique prend la place d’une décision de vision. Et dans cette confusion, le produit risque de devenir une vitrine technologique sans pertinence business.

Comment rééquilibrer la donne

Commencer chaque story par un “pourquoi” avant de parler du “comment”.
Impliquer de vrais retours clients avant chaque pivot technologique.
Co-créer la vision avec le business, pas au-dessus de lui.
Se rappeler que le code n’est qu’un moyen de livrer de la valeur, pas une fin artistique.

Le vrai pouvoir du PO

Un Product Owner venu de la technique peut être un atout extraordinaire s’il garde les yeux sur le client et le business. Mais s’il cherche la perfection technique plutôt que la pertinence stratégique, le produit sera beau… et inutile. Un bon PO n’arbitre pas entre code et business : il les relie.