Top 7 : Caractéristiques d’un « bon » Product Owner

Déubt juin, j’ai eu la chance de lancer le premier Meetup LPCxLille, avec l’aide de Xavier Koma.

« LPC », qu’est-ce que c’est ? 

L’ambition de La Product Conf est de contribuer à la diffusion et à l’adoption d’une culture, de pratiques et de valeurs liées à la création de produits numériques, à travers une conférence annuelle et des meetups mensuels.

Jusqu’ici, La Product Conf était très active à Paris et assez peu représentée dans les grandes villes françaises. C’est pourquoi nous avons lancé un premier événement le 18 juin dernier à Lille. Nos objectifs ? Donner rendez-vous aux amoureux de Product Management de la région, permettre aux personnes intéressées de venir partager un retour d’expérience, et d’échanger sur divers sujets au sein de la communauté Produit locale.

LPCxLille est donc un meetup est dédié aux Product Managers, VP Product, UX Designers, Product Owners, Design Thinkers. Tous ceux qui au quotidien travaillent dans des organisations produits. Ce meetup est le prolongement de la conférence annuelle « La Product Conf ».

Pour ce premier événement, Xavier et moi avons choisi d’ouvrir le bal en prenant la parole chacun notre tour. Il a démarré avec le sujet « Beaucoup de Product Owners, mais combien de Produits performants« .  A travers deux de ses retours d’expériences très bien illustrés, il est revenu sur l’importance de solliciter le « terrain » lors de la conception d’un produit numérique. Par la suite, je me suis lancé sur le thème « Être un bon Product Owner, est-ce mission impossible ? ». Pour encourager les échanges, nous avions choisi de limiter nos prises de paroles à 2 fois 20-30 minutes, et de laisser la place aux questions/réponses qui suivraient. Nous avons été très satisfaits des questions et échanges qui ont suivi entre les participants. Ils ont permis de lancer une réelle dynamique au cours de la soirée.

Voici ci-dessous un résumé de ma présentation.

Top 7 des caractéristiques d’un « bon » Product Owner

#1 – Mettre de côté l’approche « Projet »

Pour être un « bon » Product Owner, il est nécessaire d’avoir une idée claire de sa vision et de la raison d’être du Produit dont on a la responsabilité. Cela se concrétise (entre autres), par l’organisation de sprints qui répondent à des objectifs clairs ou qui permettent de tester des hypothèses de manière incrémentale.

A la différence d’une approche « projet », qui aurait pour finalité de livrer une solution en production, l’approche produit considère la mise en production comme le début d’une amélioration continue et incrémentale, au service des utilisateurs.

Selon moi, avoir une approche produit, c’est se demander continuellement en quoi une fonctionnalité va répondre à un réel besoin ou permettre d’atteindre un objectif business. Et surtout, comment on va mesurer le retour sur l’investissement mis en oeuvre pour la développer (taux d’utilisation, taux de clics, taux d’engagement, impact sur la conversion…).

Pour illustrer ce point, je me suis permise de partager 2 outils que je trouve vraiment utiles pour le Product Owner dans l’adoption d’une approche « Produit » : le « Lean Canvas » et l’outil présenté par Bruce McCarthy lors de LPC2019 à Paris, dans sa conférence : « Roadmaps are dead, long live roadmaps !« .

En utilisant ces templates, le PO peut se concentrer sur son objectif de maximiser la valeur produite par l’équipe de développement et arrêter de proposer des sprints qui correspondent à un fourre-tout de fonctionnalités dénué de sens.

#2 – Avoir un certain état d’esprit

Pour moi, il est essentiel que le Product Owner sache s’entourer et faire équipe. Il doit être en mesure de dire “je ne sais pas » et se remettre en question, notamment vis à vis de l’équipe de développement. Il doit faire preuve d’un leadership réel et ne pas donner un sentiment de hiérarchie. En bref : savoir jouer collectif.

Pour illustrer ce deuxième élément, j’ai partagé brièvement mon retour d’expérience chez Oui.sncf.
En 2014, j’ai eu la chance de jouer le rôle de PO dans la première Feature Team de l’organisation. Nous avions construit une équipe cross-fonctionnelle sur toute la chaîne, de la conception à la mise en production. Notre un produit était piloté par le taux de conversion et la Satisfaction Client, et visait des objectifs business ambitieux. J’avais alors peu d’expérience dans le rôle de Product Owner et j’ai découvert un esprit d’équipe hors du commun, où chacun peut s’entraider. Par exemple, en tant que Product Owner, je participais aux releases et à la configuration du produit en production. Les développeurs s’impliquaient dans l’UX et dans la collecte des feedbacks des utilisateurs. Nous étions tous tournés vers un objectif commun.

#3 – Être un couteau suisse

Le Product Owner est souvent confronté à une grande diversité d’interlocuteurs, d’outils, de sujets ou types de tâches, surtout dans les grandes organisations. Il est donc essentiel qu’il sache se « débrouiller » selon moi. Consulter l’équipe de développement et faire équipe est un atout, mais devoir faire le « passe-plat » à chaque fois que quelqu’un pose une question ou émet un besoin, ce n’est pas efficace. Le Product Owner doit être le premier utilisateur du Produit. Il doit savoir quelles sont ses qualités, ses défauts et savoir comment il est construit.
En tant que Product Owner, je me sens en apprentissage permanent, c’est aussi ce qui fait la richesse de mon rôle.

#4 – Avoir un coup d’avance

Le Product Owner doit avoir un coup d’avance, pour anticiper les besoins et avoir une vision sur la planification des développements, même si elle est amenée à évoluer au fur et à mesure, en fonction des apprentissages. Un « bon » Poduct Owner travaille plus dans la proactivité que dans la réactivité. Pour s’aider, il peut utiliser un outil proposé par Roman Pilcher : le Go Product Roadmap.

Ce template peut-être utilisé sur des jalons plus ou moins longs. Comme par exemple, la planification des prochains sprints, en les orientant toujours sur les objectifs et résultats attendus. Ou alors, le PO peut utiliser cet outil pour donner de la visibilité aux parties prenantes sur la tactique de développement à 3, 6, 9 mois (avec moins de détails sur les jalons « long terme »).

Lorsque je travaillais chez Oui.sncf, les Features Teams devaient présenter régulièrement leurs planifications et communiquer des bilans sur les performances en production des fonctionnalités développées. Un pilotage d’une roadmap par les résultats, en rendant clairs les objectifs à atteindre dès la conception.

Dans mon rôle de Product Owner actuel, l’anticipation sur les sprints à venir est un réel défi. J’ai la responsabilité de plusieurs produits (qui s’intègrent dans un même domaine, mais qui sont proposés à des cibles d’utilisateurs différentes). Mon équipe et moi avons donc adopté une approche qui s’apparente à Kanban, en l’adaptant à notre contexte.

#5 – Savoir dire « non » et oser demander « Pourquoi » ?

Un bon Product Owner doit être capable d’échanger avec tous types de profils : depuis les parties prenantes jusqu’aux utilisateurs finaux. En revanche, le PO n’est pas un exécutant. Si untel demande de réaliser telle feature, le PO doit toujours identifier le bénéfice recherché. Si on ne sait pas pourquoi on priorise telle fonctionnalité, comment cela peut-il faire du sens auprès de l’équipe de développement ? Et auprès des utilisateurs du produit ? Quelle est le manque à gagner si on ne le fait pas ?

En tant que Product Owner, si vous n’avez pas dit « non » au moins une fois cette semaine (ou sur une journée ?)… Votre démarche est-elle la bonne ? Il est impossible que toutes les demandes émanant des parties prenantes et des feedbacks utilisateurs fassent du sens dans la stratégie produit. Et s’il a un statut de consultant dans l’organisation, c’est une posture assez spéciale que le Product Owner doit savoir adopter selon moi.

#6 – Protéger l’équipe

En tant que Product Owner, vous voulez conserver une équipe efficace et motivée le plus longtemps possible, dans la durée. Alors c’est aussi votre rôle de la protéger. Un piège pour le Product Owner serait de vouloir influencer l’équipe sur la charge du Sprint Backlog, pour réaliser le plus de choses possible. Et à force de vouloir surcharger l’équipe ou d’intégrer des sujets dans le sprint en cours, il en résulte une démotivation de l’équipe et un manque de focus sur les objectifs visés. Ce sont les membre de l’équipe qui décident du sprint backlog et qui valident qu’un sujet est prêt. Il est donc dans le rôle du PO de temporiser les demandes de sponsors qui veulent « tout, tout de suite » afin de protéger l’équipe.

#7 – Prendre de la hauteur… et savoir aller dans le détail

Pour résumer, afin d’avoir une bonne maîtrise de son rôle, le PO doit savoir osciller entre stratégie et tactique. Pour plus de détails, je vous invite à lire un de mes articles précédents : « Un bon Product Owner doit savoir faire la roue ».

 

En conclusion, le rôle du Product Owner n’est pas une mission impossible, mais un rôle très riche et diversifié, qui demande de l’organisation et donne du fil à retordre. Et si vous avez toujours l’impression de bien exercer ce rôle, vous devez sans doute être en train d’oublier certains éléments ;-). … Alors, quels sont vos secrets pour être un bon Product Owner ? Quels sont vos difficultés actuelles et vos FAIL (First Attempt In Learning) ?

—

Si les sujets liés au Product Management vous intéressent, rejoignez la communauté LPCx sur Meetup ou Twitter.
Le prochain meetup LPCxLille aura lieu à la rentrée, restez à l’écoute !