Un peu d’histoire
Avant de nous lancer à corps perdu dans notre sujet, il est essentiel de rappeler d'où viennent le rôle de Product Owner et celui du Product Management. Le Product Owner est issu du framework SCRUM, incarnant un rôle avec des responsabilités bien définies. Quant au Product Manager, il s'agit d'un métier à part entière, conjuguant hard skills et soft skills. La présence simultanée de ces deux rôles dans une organisation peut, par méconnaissance des principes fondamentaux de l'organisation, induire un biais et mener à une dérive organisationnelle.
Pourquoi a-t-on des PO et des PM dans une même organisation ?
La présence des rôles distincts PO et PM dans une organisation s'explique simplement par la recherche d'équilibre entre efficacité de livraison et surcharge de travail. Initialement, le rôle de PO, dans un contexte de "feature factory", englobait un large éventail de responsabilités : spécification des fonctionnalités, communication externe, leadership d'équipe, gestion des bugs, suivi des mises en production (MEP), études de faisabilité...
Face à cette multitude de tâches, l'approche du "héros" se révélait insoutenable, conduisant à un redéfinition des rôles. Ainsi, le PO s'est vu attribuer la gestion du backlog, la réalisation des nouvelles fonctionnalités et des corrections de bugs, tandis que le PM se concentre sur la définition de la roadmap, les interactions avec les parties prenantes, et l'anticipation des besoins à travers diverses études. Ce découpage visant à créer un cycle harmonieux entre étude, anticipation et exécution.
Une fausse bonne idée : un binôme qui nous éloigne d’une organisation produit.
L'adoption du modèle PO/PM vise à accroître l'efficacité des livraisons, mais cette démarche révèle un effet pervers : elle engendre une course effrénée à la nouveauté. Ce système s’en trouve nourri par la concurrence, l'expertise interne et les désirs variés alimentent un cycle incessant de production de fonctionnalités. Dans cet élan, le succès est souvent réduit à la mise en production et à l'inauguration de nouvelles fonctionnalités.
Malheureusement, les résultats peinent à répondre aux attentes. A la manière d'un marshmallow challenge, où le véritable défi apparaît à la fin, les utilisateurs, noyés sous un flot constant de nouveautés, peinent à trouver leur chemin ou à percevoir la valeur ajoutée de ces innovations. Le sens même de chaque fonctionnalité se brouille; l'équipe ne sait plus pourquoi elle travaille sur tel ou tel développement.
Dans cette quête effrénée de la nouveauté, l'essence même de ce qui fait la force d'un produit – sa capacité à résoudre de manière simple et efficace les problèmes des utilisateurs – se perd. Les équipes, prises dans le tourbillon de la production, risquent de négliger l'importance de l'alignement sur les besoins réels des utilisateurs et de l'expérience globale qu'offre le produit.
Pourquoi c’est un antipattern ?
L'objectif principal d'une organisation produit est de concevoir, développer et gérer des produits afin de maximiser la valeur offerte aux clients, tout en atteignant les objectifs commerciaux de l'entreprise. Cette mission s'appuie sur l'innovation et l'amélioration continue, ancrées dans une compréhension approfondie des besoins des utilisateurs, et repose sur l'emploi de méthodes agiles ainsi que sur la promotion d'une collaboration étroite entre équipes multidisciplinaires pour générer un impact significatif sur l'utilisateur.
Cependant, la distinction entre les rôles de Product Owner (PO) et de Product Manager (PM) dans certaines organisations peut mener à une optimisation excessive du processus de livraison, au détriment de la création de valeur pour l'utilisateur. Cela devient un antipattern : au lieu de se concentrer sur la résolution efficace des problèmes utilisateurs par des solutions pertinentes, l'organisation privilégie l'accroissement de sa capacité de livraison, perdant ainsi de vue l'impact utilisateur, élément qui devrait être central dans toute décision relative au produit.
La focalisation du PM sur le discovery, même lorsqu'elle est effective, ne peut remplacer une démarche itérative et empirique intégrée au sein de l'équipe, essentielle pour l'optimisation continue du produit en réponse aux validations d'hypothèses. La séparation des rôles conduit à un cloisonnement des responsabilités et oriente l'équipe vers une logique de livraison plutôt que vers une logique d'impact et de valeur pour l'utilisateur, détournant ainsi l'organisation de son but premier.
La solution : manager l’incertitude en s’appuyant sur des équipes autonomes
Pour maximiser l'impact de nos solutions auprès des utilisateurs, réorienter l'organisation vers un modèle privilégiant compréhension et adaptabilité sur certitude et livraison est crucial. Cela nécessite d'accepter l'incertitude et de reconnaître que la solution idéale n'est pas toujours immédiate. Plutôt que de nous fier à des préjugés, il s'agit de s'appuyer sur l'établissement d'hypothèses et une méthode empirique pour tester, apprendre et ajuster nos actions en fonction des feedbacks et des données récoltées.
Ce réajustement nous conduit à revisiter les principes fondamentaux du framework Scrum : la constitution d'équipes autonomes, orientées utilisateur, qui itèrent pour répondre efficacement à ses problématiques. Une telle équipe autonome a le pouvoir de prendre des décisions clés concernant le produit, allant de l'identification des problèmes des utilisateurs à la conception et mise en œuvre de solutions. Cette démarche itérative encourage une exploration soutenue des besoins utilisateurs et une réactivité face aux changements, optimisant l'impact des solutions proposées.
L'autonomie des équipes cultive une culture de responsabilité et d'engagement, où chaque membre se sent pleinement investi dans la mission de générer de la valeur pour l'utilisateur. Promouvoir un cadre propice à la collaboration, à l'expérimentation et à l'apprentissage permet non seulement d'enrichir l'impact de nos produits mais également de favoriser l'innovation et l'excellence en matière de développement de produit.
Le modèle empirique, géré collectivement par l'équipe, suit un cheminement clair : identifier les problématiques utilisateurs, formuler des hypothèses, concevoir des solutions, évaluer l'intérêt, puis itérer. Il est primordial que la recherche de solutions et la définition de la méthode de validation des hypothèses soient co-conçues par toutes les parties prenantes : équipes produit, technique, design, etc.
Modèle empirique qui doit être manager par l’ensemble de l’équipe
Découvrir les pb utilisateurs -> imaginer des hypothèses -> imaginer des solutions -> tester l'appétence -> itérer
PM/EM : un modèle possible basé sur les responsabilités
Dans ce nouveau modèle organisationnel où l'on cherche à équilibrer innovation, compréhension des besoins utilisateurs, et efficacité de livraison, la question de la responsabilité du delivery se pose avec acuité. En effet, si les Product Managers (PM) concentrent leurs efforts sur la tactique et la discovery, l'exploration des besoins utilisateurs, et la planification à long terme, qui alors prend en charge l'aspect crucial de la livraison au quotidien ?
Une solution potentielle à cette question réside dans l'introduction d'un rôle complémentaire : l'Engineering Manager (EM). Ce dernier devient le garant de l'efficacité opérationnelle de l'équipe de développement, s'assurant que les projets avancent de manière fluide et que les obstacles techniques et organisationnels sont levés au fur et à mesure. L'EM joue un rôle crucial dans la coordination de l'équipe de réalisation, qu'elle soit auto-organisée ou non, en veillant à ce que les pratiques agiles soient bien appliquées et que la qualité du code reste élevée.
Cette répartition des rôles favorise l'émergence d'un modèle de collaboration entre tech et produit, où le binôme PM/EM remplace avantageusement la paire PM/PO. Ce modèle a plusieurs avantages notables. D'abord, il responsabilise davantage l'équipe de réalisation, chaque membre ayant un rôle clair et des responsabilités bien définies. Ensuite, il libère du temps pour le PM pour se consacrer pleinement aux activités de discovery et de delivery, assurant ainsi une meilleure compréhension des besoins utilisateurs et une planification produit plus tactique.
De plus, l'implication accrue de l'équipe technique dès les phases d'études préliminaires renforce la cohésion et la collaboration entre les membres de l'équipe. La présence de l'EM assure que les perspectives techniques sont prises en compte dès le début, facilitant ainsi l'identification des solutions les plus adaptées et innovantes. Ce modèle de collaboration PM/EM stimule non seulement l'efficacité et l'innovation au sein des équipes de réalisation mais favorise également une approche plus intégrée et cohérente du développement produit, où les décisions sont prises en considération des enjeux à la fois techniques et utilisateurs.
Il est important de distinguer clairement le rôle de l'Engineering Manager (EM) de celui du Delivery Manager. Tandis que le Delivery Manager se concentre principalement sur la supervision de la réalisation des fonctionnalités, l'EM couvre un éventail de responsabilités plus étendu, avec notamment la mission de structurer une équipe de réalisation apte à itérer rapidement. L'EM ne se limite pas à la gestion des tâches et des délais; il joue un rôle crucial dans le développement des compétences au sein de son équipe, l'instauration d'une culture agile et la garantie d'un environnement propice à l'innovation continue et à l'adaptabilité.
Orga as a product : formaliser et adapter
Il est clair que ces transformations organisationnelles ne sont pertinentes que lorsqu'elles sont mises en œuvre de manière adaptative et progressive. À l'image d'un produit de qualité, l'organisation elle-même doit être gérée de façon empirique, sous une supervision attentive.
Lien vers article “orga as a product”.