La vraie vie, sur le terrain, d’un Product Owner

Rôle du Product Owner

Avec le développement de la méthodologie Scrum et plus généralement des méthodes « Agile », le rôle de Product Owner ou PO est de plus en plus présent dans les organisations.

Si les littératures théoriques sont nombreuses sur le rôle du PO, il existe dans la pratique encore beaucoup de mythes et de freins au sein des entreprises.  Entre attentes et responsabilités réelles, à quoi faire attention pour que le Product Owner apporte sa vraie valeur ?

Nous accueillons dans cette interview Claire, consultante projets et organisation pour partager et débattre du rôle du Product Owner au travers de ses expériences en tant que PO.

Comment définirais-tu le rôle de Product Owner en quelques mots ?

Le Product Owner porte la responsabilité et la vision du produit. Ce n’est pas qu’un chef d’orchestre. Il doit s’imprégner du produit ! Etre sensible à l’environnement et au contexte dans lequel le produit sera utilisé apporte un coup d’avance sur le “comment le faire vivre” dans le temps. S’il associe en phase RUN l’équipe de développement, il a toujours en tête la valeur finale du produit apportée aux utilisateurs. Cela demande une certaine prise de hauteur par rapport au produit.

Qu’est-ce que n’est pas le Product Owner ?

Je suis convaincue que le Product Owner n’est pas un exécutant car il doit porter la vision du produit et être persuadé de sa valeur. Si les développeurs ne peuvent pas se rattacher au PO quand ils ont une incompréhension, des doutes, c’est la catastrophe ! Le PO sait de quoi il parle, il sait l’expliquer. Il sait aussi dire non au client car il peut donner du sens à sa vision du produit !

J’ai l’exemple d’un projet autour d’outils mobiles. Il ne fallait donc délivrer que des fonctions qui avaient du sens pour la mobilité ! Seulement, l’un des PO ne savait pas dire non et intégrait certaines fonctionnalités inutiles. Il ne gardait pas en tête l’objectif du produit et ne savait donc pas arbitrer auprès du client.

Le Product Owner n’est pas non plus un théoricien de l’agilité. Il ne suffit pas d’avoir une très bonne connaissance des rituels et de la méthodologie : les savoir-faire et les savoir-être sont essentiels pour endosser ce rôle.

Être garant du produit, c’est aussi mettre son nez dedans, y compris dans les aspects techniques et savoir challenger les équipes de développement.

Je peux partager un autre retour d’expérience. Au sein d’un retailer, le PO s’est aperçu que l’impression de balisage ne fonctionnait plus en mobilité. Le sprint suivant commençant deux jours plus tard, il s’est dit qu’il le mettrait en priorité et que cela attendrait. Dans la réalité terrain, les prix changent tous les jours et en conséquence ce sont les magasins qui ont supporté les différences de tarifs. Le PO est passé à côté du concept d’agilité. Un Product Owner doit être capable en cours de sprint d’arbitrer, d’identifier les effets de bord et savoir remettre en cause les priorités.

Selon toi, qu’est-ce qui est à l’origine de cet engouement pour le profil de PO ?

J’ai participé à plusieurs projets en cycle en V, avec une organisation traditionnelle : chef de projet, MOE, AMOA et MOA. Une raison de l’échec de certains projets, c’est l’effet tunnel. On ne délivre pas régulièrement, et cela entraîne des écarts entre la vision client et le résultat. Les projets ont aussi plus souvent tendance à s’embourber. Avec les cycles de développement plus courts des méthodes agiles, on a la capacité à délivrer au fil de l’eau et d’éviter certains de ces écueils.

Cette bascule fait aussi évoluer les rôles et les responsabilités. Elle a l’avantage de rapprocher les équipes métiers et les équipes de développement, ce qui est toujours bénéfique pour la valeur finale apportée au client. Tout le monde se sent embarqué et partage des objectifs communs. Les périodes de delivery plus courtes impliquent que les équipes fêtent plus souvent des victoires. La dynamique projet reste positive !

C’est aussi se tromper plus vite, pour rebondir plus tôt !

Mais ces arguments sont connus ! Au-delà, mon sentiment, c’est que la transformation digitale a entraîné un sentiment d’urgence. Il faut arriver les premiers sur le marché, être plus réactifs et donc revoir en conséquence les manières de procéder.

J’ai en particulier l’exemple d’une enseigne de grande distribution où la bascule vers le travail en mode agile était liée à la transition du multicanal à l’omnicanal. L’état d’esprit avait changé : il fallait délivrer vite et donner des résultats visibles pour les équipes mais aussi pour les actionnaires.

Quels sont les points d’attention pour que l’intégration d’un Product Owner soit une réussite ?

Comme dans toute transformation, il existe des décalages entre perceptions, attentes et responsabilités réelles accordées. Malheureusement, encore beaucoup d’entreprises veulent intégrer une facette de l’agilité, très souvent la livraison au fil de l’eau, sans se remettre en cause et faire évoluer leur organisation. Le cas où on met juste un titre de Product Owner sur des fonctions “traditionnelles” de chef de projet est loin d’être isolé !

J’ai l’exemple d’un projet où le Product Owner avait la responsabilité du planning, sans avoir la capacité à porter les arbitrages sur le produit. Comme autre illustration, certaines entreprises positionnent un responsable métier à côté du PO. Inévitablement, le PO ne va pas avoir le même pouvoir de décision…

Là où le bât blesse, c’est lorsqu’on attend du Product Owner des résultats pour lesquels on ne lui donne pas les responsabilités. Définir et répartir clairement les rôles et les responsabilités est primordial ! Pour des équipes qui connaissent peu l’approche agile, il ne faut pas hésiter à passer par une étape théorique pour faire tomber les mythes.

Pour apporter sa vraie valeur à l’entreprise, le Product Owner ne doit pas être un passe-plat entre métier et technique ! Les entreprises recherchent l’agilité, mais il faut aussi avoir la volonté de changer les organisations.

Un autre point d’attention porte sur le dimensionnement de l’équipe. Au début des démarches agiles, on avait tendance à penser que le PO était seul responsable de la qualité de ce qui était délivré. Ce qui sous-entend qu’il était aussi testeur ! Dans la réalité, même si le PO a un rôle très important, il faut aussi dimensionner son équipe.

Tout le monde ne peut pas être PO. Historiquement, j’étais 100% côté fonctionnel, et j’ai dû faire un pas important vers la technique. Cependant, je considérais cette aventure comme le prolongement de mon expertise métier. C’est cette dualité qui fait la richesse et la valeur du rôle de PO. Si le PO vient du métier, il ne doit pas avoir peur d’animer une équipe de développeurs. S’il vient de la technique, il doit vraiment appréhender l’angle de vue du client et la valeur que le produit doit lui apporter. Personnellement, j’ai eu la chance de pouvoir m’appuyer sur des leaders techniques solides avec qui nous formions de très bons binômes.

Souvent, ce sont des chefs de projets qui basculent vers des rôles de PO. Parfois, ils gardent comme objectif principal de délivrer dans le temps imparti. J’ai l’exemple d’un profil de PO très technique qui trouvait sa zone de confort dans l’animation de l’équipe de développement mais délivrait de manière très théorique, au détriment de la satisfaction du client.

On ne peut pas juste changer le titre de quelqu’un en lui disant « Tu n’es plus chef de projet, tu es Product Owner ! ».

Cependant, les exemples où le rôle de Product Owner est un succès sont aussi nombreux ! J’ai l’expérience d’un grand retailer qui avait approfondi la démarche et s’était fait accompagner par un cabinet de consultants externes. Au-delà de la théorie et du poste du PO, cette entreprise avait la volonté de se remettre en question, et d’aller vers une mise pratique réelle.

Derrière le rôle de Product Owner et les méthodes agiles, il y a donc un vrai sujet de change management!

Comment accompagner les équipes pour s’approprier le rôle de PO ?

Avant de lancer un projet en mode agile, il faut une démarche de conduite du changement, sans qu’elle soit nécessairement chronophage. Le plus important c’est de prendre du recul, et de porter un diagnostic : qui va être concerné ? Quelle est la volumétrie de personnes impactées ? A quelle hauteur dois-je les accompagner ? Ensuite, il sera facile de dérouler un accompagnement adapté. Le vrai problème c’est que les entreprises ont tendance à mener la conduite du changement en même temps que le projet !

S’auto-réorganiser est très difficile. Si une entreprise veut se lancer dans une approche agile, elle gagnera toujours à se faire accompagner par des consultants extérieurs qui peuvent mettre à profit leurs retours d’expérience. C’est un tremplin !

Il ne faut pas négliger que cette bascule vers une approche agile n’est pas toujours liée à un échec sur des projets. Pour beaucoup d’entreprises, il s’agit d’aller plus loin, d’être plus réactif. Accompagner l’évolution des rôles est alors d’autant plus nécessaire. Les chefs de projets vont à juste titre se demander « Notre méthodologie actuelle fonctionne, je livre dans les délais, pourquoi je changerai ? ».

Pour conclure, quelles seraient tes recommandations à une entreprise qui souhaite mettre en place un rôle de Product Owner ?

Avant tout chose, il ne faut pas faire de l’agile et définir un rôle de Product Owner simplement car tout le monde le fait !

Si l’entreprise veut mettre en place un rôle de Product Owner, c’est qu’elle s’intéresse à l’agilité. Elle a alors tout intérêt à prendre du recul sur ses attentes et débuter par un diagnostic. Un Product Owner ce n’est pas juste un titre.

Ensuite, dans le choix du profil, il faut quelqu’un de très organisé mais aussi très bon communicant.

Être convaincu du produit n’est pas suffisant, il faut aussi convaincre les équipes internes et les clients de sa vision. La polyvalence est indispensable : le PO est un couteau suisse.

Si l’entreprise propose le rôle à un chef de projet, cela doit être associé à une remise en question : va-t-il savoir sortir de sa zone de confort ? Faire le pont entre les deux mondes ?

Projexion est un collectif de consultants au service de vos projets de transformation  qui regroupe des profils variés et des expériences dans des contextes métiers diversifiés : chefs de projets, Product Owners, consultants en organisation ou en architecture d’entreprise, formateurs…

Vous cherchez une clé d’entrée pour vous familiariser avec le rôle de Product Owner ? Découvrez notre formation agile et gestion de produit .

Vous souhaitez être accompagné et mettre à profit les expériences de PO de nos consultants ? Partageons autour de vos problématiques ! 

Soyez averti(e) de nos prochains évènements et publications via LinkedIn !