Le Product Owner est un acteur clé dans le développement de produits, garant de la valeur et de l’alignement stratégique. Il ne se limite pas à gérer un backlog (voir cet article pour plus de détails), mais jongle avec plusieurs rôles cruciaux : décisionnaire, visionnaire, influenceur, et surtout, collaborateur. Cette dernière casquette est souvent négligée, pourtant elle est fondamentale pour réussir à créer de la valeur et à innover.
Le Product Owner, un collaborateur avant tout
Bien que son rôle de décideur soit souvent mis en avant, celui de collaborateur est tout aussi essentiel. Le Product Owner ne peut pas réussir seul : la création de valeur et l’innovation reposent sur une dynamique collective. Un Product Owner efficace travaille main dans la main avec les développeurs, designers, testeurs, et toutes les parties prenantes. C’est cette coopération qui transforme une vision en un produit concret et impactant.
Un Product Owner qui impose ses solutions et ses choix est souvent caricaturé comme un Product Owner Commander :
Cette posture est un piège qui nuit à la collaboration et freine l’innovation. La traduction littérale de Product Owner en Chef de Produit accentue encore cette confusion, alors qu’un chef a souvent un pouvoir total sur son équipe, ce qui n’est pas le cas ici.
Le véritable enjeu du Product Owner est de faciliter les échanges, de poser les bonnes questions et de s’assurer que chacun contribue avec son expertise. C’est en cultivant cette collaboration qu’il parvient à transformer une vision en un produit concret et impactant.
Quelques exemples de difficultés de collaboration courantes
Avec l’expérience, j’ai souvent observé des tensions entre Product Owners et leurs équipes. Voici quelques exemples concrets.
PO vs Développeurs
Dans une entreprise que j’ai accompagnée, j’ai observé un PO très compétent techniquement, mais qui s’immisçait constamment dans les détails techniques : choix de la base de données, de l’architecture, des frameworks… Résultat : les développeurs se sentaient dépossédés de leur expertise, ce qui créait des frustrations.
PO vs UI/UX Designers
Toujours dans cette entreprise, le responsable UX/UI se plaignait des PO qui imposaient leurs choix : placement des boutons, couleurs, widgets, parcours utilisateur… plutôt que de laisser les designers faire leur travail. Résultat ? Des tensions et une créativité bridée.
De même, lors de la création d’une solution de mobile money dans une autre entreprise, j’ai travaillé avec un designer UX/UI très compétent. Celui-ci était capable de venir avec des solutions innovantes, en lui exposant clairement le problème à resoudre. J’ai compris avec lui que mon rôle n’était pas de lui dire fait ceci, fais cela, design moi tel parcours, ou telle fonctionnalité. Encore moins de lui imposer les choix de designs. À chaque fois, il me suffisait de revenir à la base: quel problème du client on essaie de résoudre? et de le laisser proposer des idées adaptées.
PO vs Parties Prenantes
Dans une autre mission, j’ai vu une PO en difficulté face à un Business Representative, ancien responsable d’équipe de développement. Ce dernier avait du mal à lâcher prise et dictait aux équipes ce qu’il fallait faire, contrôlait leur travail en plein sprint et demandait des status reports incessants. Frustrée, la PO a fini par adopter un comportement de PO Commander, qui in fine décidait de tout, tant avec ce Business Rep qu'avec son équipe. ce qui a empiré la situation. Le conflit était tel que le top management a dû nous faire intervenir pour apaiser les tensions et renouer le lien de collaboration.
La fameuse règle du 100-50-0 pour redistribuer le ownership et laisser place à la collaboration et à l'innovation
C'est la qu'intervient la fameuse règle que j'ai appelé : la Règle du 100-50-0.
Elle vise à mieux équiper les Product Owners pour faciliter la collaboration au sein des équipes. Elle permet de tirer parti de l’intelligence collective, encourageant chacun à apporter sa valeur et à co-construire les meilleures solutions face aux problématiques identifiées.
Que veulent dire ces chiffres?
• 100% sur le Why - Le Problème : Le Product Owner doit posséder pleinement le ‘Pourquoi’ de son produit, de ses fonctionnalités. Il s’agit de s'approprier le problème de l'utilisateur à résoudre, le besoin à satisfaire, la valeur à lui apporter.
• 50% sur le What - La Solution : Ici, le Product Owner collabore avec l’équipe pour définir ‘Quoi’ faire, la solution à implémenter. Plutôt que d’imposer ses solutions, il pose des questions, encourageant ainsi la co-construction.
• 0% sur le How - L'Implémentation : Le ‘Comment’ de l'implémentation technique doit être laissé aux experts. Le Product Owner fait confiance à l’équipe pour trouver les meilleures solutions techniques et créatives.
PROBLÈME => SOLUTIONS => IMPLÉMENTATIONS
Application concrète
Dans un projet de solution de finance technologique, nous avons appliqué la règle du 100-50-0 pour faciliter la collaboration et maximiser l’intelligence collective. Voici comment cela s’est concrètement traduit :
💡 100% sur le Why : Posséder la vision et la problématique
Le défi principal était d’instaurer la confiance des utilisateurs envers la solution, un enjeu majeur particulièrement pour cette plateforme financière.
En tant que Product Owner, j’ai travaillé en amont pour bien définir le Pourquoi. Nous avons analysé les retours utilisateurs concernant ce point, et définit un objectif clair : rassurer les utilisateurs avec un système de reconnaissance de la fiabilité des comptes.
En résumé : J’étais 100% responsable du Why, en alignant toutes les parties sur le problème à résoudre et l’impact attendu.
🤝 50% sur le What : Co-construire la solution avec l’équipe
Une fois le problème défini, il fallait identifier quelle solution pouvait le mieux répondre à ce besoin. Initialement, nous avions dans notre backlog produit des fonctionnalités pour évaluer les utilisateurs, et déterminer ultérieurement des scores de confiance.
Plutôt que d’imposer cette solution, je l'ai co-construite avec notre expert UX/UI. Il a finalement allégé notre solution initiale, et améliorer le parcours pour l'utilisateur. Il a proposé un système de badges plus facile à comprendre qui peut rassurer les utilisateurs.
🎯 0% sur le How : Laisser l’équipe choisir l’implémentation
Une fois la solution définie, mon rôle était de laisser l’équipe technique et UX prendre le relais. Les UX/UI designers ont proposé un affichage intuitif et testé différentes itérations avec des utilisateurs. J’ai suivi leurs avancées et apporté des clarifications, féliciter et encourager sur les initiatives prises, mais sans jamais imposer de choix techniques ou de design.
En somme, je leur ai fait 100% confiance sur le How, ce qui a permis d'aboutir à une meilleure solution.
À la fin, un simple interview avec de potentiels utilisateurs nous a donné des signaux assez positifs pour son adoption ultérieure.
Pour les plus curieux - lien avec la pyramide de Gary Hamel
Cette règle s’inscrit parfaitement dans la logique de la pyramide de Gary Hamel, qui vise à maximiser l’engagement et la créativité des équipes en leur accordant plus d’autonomie et en leur laissant la liberté d’agir et de proposer des solutions.
C'est la fin
Voilà, c'était tout. Dites moi ce que vous en pensez dans les commentaires.
A bientôt pour d'autres contenus ;)