Pourquoi le binôme PO/PM est une fausse bonne idée

Un peu d’histoire

Avant de plonger dans le cœur du sujet, rappelons les origines des rôles de Product Owner (PO) et de Product Manager (PM). Le PO émerge du framework Scrum, où il incarne un rôle précis avec des responsabilités bien définies, comme la gestion du backlog et la priorisation des fonctionnalités. Le PM, en revanche, est un métier plus large, combinant hard skills (analyse, stratégie) et soft skills (leadership, communication). La coexistence de ces deux rôles dans une même organisation peut, par manque de compréhension des principes agiles fondamentaux, créer des biais et mener à des dérives organisationnelles.

Pourquoi avoir des PO et des PM dans une même organisation ?

Cette dualité s’explique souvent par la quête d’un équilibre entre efficacité de livraison et surcharge de travail. À l’origine, dans un contexte de "feature factory" (usine à fonctionnalités), le PO assumait un spectre large de tâches : spécification des fonctionnalités, communication externe, leadership d’équipe, gestion des bugs, suivi des mises en production (MEP), études de faisabilité, etc.

Face à cette overload, l’approche du "héros" s’est révélée insoutenable, menant à une redéfinition des rôles :

• Le PO se concentre sur la gestion du backlog, les nouvelles fonctionnalités et les corrections de bugs.
• Le PM gère la roadmap, les interactions avec les parties prenantes, et l’anticipation des besoins via des études.

Ce découpage vise à créer un cycle harmonieux entre étude, anticipation et exécution. Pourtant, bien que présenté comme un modèle collaboratif efficace, il dissimule des écueils lorsque le PO est débordé et que le PM prend le relais sur la discovery.

Une fausse bonne idée : un binôme qui nous éloigne d’une organisation Produit

L’adoption du modèle PO/PM semble accroître l’efficacité des livraisons, mais elle engendre un effet pervers : une course à la nouveauté alimentée par la concurrence, l’expertise interne et les désirs variés. Le succès se mesure alors à la mise en production et à l’inauguration de fonctionnalités, sans toujours évaluer l’impact réel.

À l’image du "marshmallow challenge" – où le vrai test survient à la fin –, les utilisateurs se noient sous un flot de nouveautés, peinant à percevoir la valeur ajoutée. Le sens des fonctionnalités se brouille, et les équipes perdent de vue le "pourquoi" de leur travail. L’essence d’un produit – résoudre simplement et efficacement les problèmes utilisateurs – s’efface au profit d’une production effrénée, négligeant l’alignement sur les besoins réels et l’expérience globale.

Les dérives du modèle PO/PM

• Le PO, Responsable du Backlog et du Delivery :
  • Se limite à la gestion du backlog, sans implication plus large.
  • Devient responsable de la vélocité de l’équipe, au lieu de la valeur délivrée.
  • L’équipe de réalisation perd en responsabilité sur l’impact utilisateur.
• Éloignement des Besoins Utilisateurs :
  • Le PO, absent de la discovery, ne peut plus émettre d’hypothèses valides.
  • Le PM, loin du terrain, risque de perdre le contact direct avec l’utilisateur final.
  • Augmentation du risque de prioriser sur des hypothèses erronées.
• Éloignement du PM de l’Équipe de Réalisation :
  • Le PM développe des attentes irréalistes, déconnectées de la réalité technique.
  • La stratégie produit s’éloigne de la capacité réelle de l’équipe.
  • Apparition de débats improductifs sur la vélocité.

Clarifier les rôles peut aider – par exemple, le PM définit l’impact attendu (outcome) post-discovery, tandis que le PO définit la solution (output) avec l’équipe. Mais cela reste théorique : la frontière est fragile, et les dérives persistent.

Pourquoi c’est un anti-pattern ?

L’objectif d’une organisation produit est de maximiser la valeur pour les clients tout en atteignant les buts commerciaux, via l’innovation, l’amélioration continue et une compréhension approfondie des besoins utilisateurs. Cela repose sur des méthodes agiles et une collaboration multidisciplinaire pour un impact significatif.

Cependant, la séparation PO/PM optimise excessivement la livraison au détriment de la valeur utilisateur. Au lieu de résoudre efficacement les problèmes via des solutions pertinentes, l’organisation priorise la capacité de production, perdant de vue l’impact – élément central de toute décision produit.

La focalisation du PM sur la discovery ne remplace pas une démarche itérative et empirique intégrée à l’équipe, essentielle pour valider les hypothèses et optimiser le produit. Cette cloisonnement oriente vers une logique de livraison plutôt que d’impact, détournant l’organisation de son essence.

La solution : manager l’incertitude avec des équipes autonomes

Pour maximiser l’impact, réorientez vers un modèle privilégiant compréhension et adaptabilité sur certitude et livraison. Acceptez l’incertitude : la solution idéale n’est pas immédiate. Appuyez-vous sur des hypothèses, une méthode empirique pour tester, apprendre et ajuster via feedbacks et données.

Revenez aux principes Scrum : équipes autonomes, orientées utilisateur, qui itèrent pour résoudre les problématiques. Ces équipes décident du produit, de l’identification des problèmes à la mise en œuvre. Cela encourage l’exploration des besoins, la réactivité aux changements, et cultive responsabilité et engagement.

Modèle empirique géré par l’ensemble de l’équipe

Découvrir les problèmes utilisateurs → Imaginer des hypothèses → Imaginer des solutions → Tester l’appétence → Itérer.

Cette co-conception implique produit, tech, design, etc., pour valider les hypothèses collectivement.

PM/EM : un modèle basé sur les responsabilités

Dans ce cadre, qui gère le delivery quotidien si le PM se concentre sur la tactique et la discovery ? Introduisez l’Engineering Manager (EM) comme garant de l’efficacité opérationnelle : coordination, levée d’obstacles techniques, application des pratiques agiles, qualité du code.

Ce binôme PM/EM remplace avantageusement PO/PM :

• Rôle Produit (PM) :
  • Définit les priorités tactiques, conduit la discovery, communique l’impact recherché et les mesures associées.
  • Maintient une relation étroite avec utilisateurs et équipe de réalisation.
• Rôle Tech (EM) :
  • Anticipe et valide la faisabilité des initiatives en cadrage.
  • Organise et optimise le delivery, en responsabilisant techniquement l’équipe.
  • Structure une équipe apte à itérer rapidement, développe les compétences, instaure une culture agile.
• Ensemble :
  • Pilotent une démarche de Product Delivery alignant attentes produit et excellence technique.

Avantages : responsabilisation accrue, libération de temps pour le PM, implication technique dès les études, cohésion accrue. Distinguez l’EM du Delivery Manager : l’EM va au-delà de la supervision des tâches, en favorisant innovation et adaptabilité.

"Orga as a Product" : formaliser et adapter

Ces transformations doivent être empiriques et progressives, comme la gestion d’un produit. Supervisez attentivement pour adapter au contexte. Résultat : une organisation orientée impact et autonomie, avec meilleure prise de décision, responsabilisation des équipes, et alignement entre vision, stratégie, tactique, terrain et besoins utilisateurs.

Si vos équipes peinent malgré ce modèle, discutons-en pour un regard extérieur !