Product-leader

Product Owner, Product Leader, Product Manager, Scrum Master… de nombreux rôles autour du « produit » sont apparus ces dernières années avec l’avènement de l’agilité. Ils ont pris une place centrale dans l’organisation et les processus des entreprises. Cependant, les périmètres et les interactions de chacun ne sont pas toujours très clairs !

Nous accueillons pour cette interview Clémentine, consultante et Product Leader pour nous partager ses convictions sur le rôle de PL et sa place dans l’organisation.

Le rôle du Product Owner est maintenant globalement bien intégré, mais on parle moins de celui du Product Leader. Tu peux nous donner ton point de vue sur son rôle ?

Je suis d’accord ! D’un écosystème à l’autre, on ne met pas les mêmes sujets derrière. J’ai vécu des situations où en arrivant en mission, les responsables d’applications étaient majoritairement des anciens développeurs qui sont montés dans la hiérarchie et ont gagné un pouvoir d’arbitrage. Dans la plupart des cas, ils conservaient une forte dimension technique, mais rencontraient des difficultés à prendre du recul sur la facette de Product Owner ou de Product Leader.

Je vais vous partager un retour d’expérience d’un client où la DSI souhaitait se transformer et mettre en place des postes de Product Owners et Product Leaders. Les postes de Product Owner étaient rattachés aux équipes métiers et garants du contenu fonctionnel de l’application. Ce ne sont pas des informaticiens : ils vont gérer et prioriser la backlog mais n’ont pas de rôle technique. Ils connaissent avant tout les process, leurs utilisateurs, les besoins et vont les traduire en s’arrêtant assez tôt sur la frontière technique. 

Le Product Leader agit en parallèle. Il est responsable de tout ce qui est autour. Pour ma part, j’interviens par exemple sur les outils liés à la logistique et je suis responsable en quelque sorte de la « coquille de l’application » comme la base de données, les flux avec les autres applications… Le travail est aussi important dans l’outil qu’en-dehors ! Par exemple, autour du WMS, il y a plus de 60 flux à gérer, et des intégrations critiques avec le web ou le TMS. Je dois conserver la cohérence, la vision de la road map technique du produit et de tous les projets qui peuvent l’impacter. Disposer d’une vision de l’architecture du SI et de l’entreprise aide à trouver des solutions simples et harmonieuses.

PO, PL, on peut résumer cela à une coloration du profil plutôt technique ou plutôt fonctionnelle !

Le Product Leader ne va pas intervenir sur le contenu du Produit. PO et PL, ce sont ainsi des rôles différents. Ils n’agissent pas sur une chaîne descendante, c’est-à-dire l’un à la suite de l’autre, mais bien en parallèle, et sans lien hiérarchique

Dans mon expérience, une différence importante qui touche l’organisation, c’est que c’est le Product Leader qui pilote le budget. En tant que PL, je dispose à l’année d’un budget limité pour les évolutions techniques, et en cas de modifications importantes, c’est à moi de défendre le budget en fonction du projet en lien !

 Il y a donc aussi une facette de pilotage qui ne doit pas être négligée : il ne faut pas avoir consommé 90% de son budget RUN à la fin du premier trimestre…

Avec qui interagit le Product Leader ? Quelle dimension prend la communication dans ce rôle perçu parfois comme technique ? 

Bien sûr avec les développeurs, mais pas uniquement !

Nos interactions sont très liées aux flux du Système d’Information et à la transversalité. Tous les Product Leaders naviguent dans les bus applicatifs. Dans mon cas, c’est par exemple sur l’ETL développé en spécifique. Nous interagissons beaucoup entre Product Leaders pour se synchroniser sur les données et les flux transmis entre nos applications. Si nos produits se parlent, nous aussi ! 

Les échanges s’organisent également avec les équipes métiers pour répondre aux demandes et conseiller. Par exemple, le responsable transport souhaite une modification importante sur l’application. Le Product Leader remonte que l’outil va être décommissionné dans 6 mois et qu’il serait préférable d’attendre la nouvelle application. Les échanges sont principalement portés par les projets en RUN !

Le Product Leader peut aussi animer une équipe. Je travaille pour ma part avec un junior comme mon périmètre grandissait, mais certains PL ont des équipes bien plus vastes incluant des développeurs, des responsables technico-fonctionnels…

Et cela ne s’arrête pas là ! J’échange aussi avec les administrateurs systèmes pour monitorer les flux, mettre en place les tuyaux pour mes application Cloud

Si j’ai une conviction, c’est que le PL doit savoir communiquer avec tous les interlocuteurs et adapter la granularité des informations à chacun. 

D’après tes expériences, il y a-t-il des évolutions dans le positionnement du Product Leader au sein des organisations ? 

Sujet difficile !  J’ai eu un parcours en zig zag. J’ai été Product Owner, puis à la fois PO et PL et enfin PL. J’ai ainsi vécu des situations où le rôle du Product Leader était intégré à celui de Product Owner.

Mon opinion, c’est qu’on ne peut être juge et parti. Le rôle de Product Owner se focalise sur la valeur pour le métier. Les enjeux de sécurité, d’architecture… ne sont pas prioritaires pour lui et c’est normal. Avec les deux rôles, il risque de délaisser la facette sur laquelle il est moins attendu.

A l’opposé, le Product Leader n’a pas à jouer le rôle d’arbitre avec le métier et je trouve personnellement que c’est appréciable. Je vais conseiller sur les implications techniques sans trancher sur la dimension fonctionnelle. Avoir un arbitre sur le fonctionnel et un autre sur la technique permet de répartir clairement les rôles et de prendre des décisions éclairées. Des exceptions existent, comme pour des applications qui arrivent en fin de vie, ou qui évoluent très peu, pour lesquelles avoir un PL qui déborde sur le rôle de PO reste pertinent en s’appuyant sur les Key users. 

Bien sûr, si je suis convaincue qu’il faut séparer les deux postes, la synergie entre PO et PL est tout autant essentielle. C’est un binôme !

Ainsi, élargir le rôle de PL ne doit pas se faire en termes de chaîne verticale, mais sur le périmètre applicatif. Un Product Leader peut ainsi disposer d’un périmètre métier cohérent, comme dans mon cas avec une vue consolidée des applications liées à la logistique. On gagne ainsi en maîtrise des flux et des implications et donc en valeur apportée.

Qu’est ce que tu apprécies dans le rôle de Product Leader ? Quelles sont, pour toi, les compétences attendues ?


J’ai eu un parcours sur le terrain en entrepôt, intégrée à une équipe organisation et méthodes, puis sur des sujets très techniques… J’ai navigué entre métier et IT et j’ai toujours eu la volonté d’être entre les deux. C’est ce que j’aime dans le métier de Product Leader. J’apprécie la dimension d’échanges et d’intégration dans l’organisation du Product Leader, sans être pour autant déconnectée des enjeux IT !

De mon point de vue, les Product Leaders sont des personnes qui aiment toucher à tout, comprendre, sans pour autant être des hypers spécialistes. Il faut avoir une vision d’ensemble et une capacité de pilotage et d’analyse plutôt qu’un souhait de tout maîtriser dans le détail.

C’est aussi pour cette raison que je vois évoluer les profils au sein des clients que j’accompagne. Ils se renouvellent, avec une recherche de sang neuf, plus aligné avec les démarches d’agilité. C’est-à-dire des personnes qui ont la volonté de remettre en cause le fonctionnement et les processus ainsi que de s’intéresser à la « root cause » des problèmes.

Dans les processus de recrutement de PL que j’ai vécus, les décideurs ne recherchaient pas la personne qui avait le plus d’expérience sur le logiciel ou sur le développement. Ils souhaitaient avant tout des personnalités qui portent les valeurs d’agilité, qui apportent une communication honnête et réaliste et qui prônent des objectifs SMART !

Je vis le rôle de Product Leader en ayant toujours les antennes allumées. Je provoque des points avec les autres Product Leaders sans besoin immédiat, car j’identifie des potentiels futurs. Le succès, c’est aussi connaître les autres et se faire connaître. Ainsi, si un sujet peut impacter tes produits, les gens vont penser à toi ! Dans les grosses structures, créer ce lien est essentiel pour le PL.

Tous ces termes agilité, PO, PL… : c’est normal que leurs significations ne soient pas identiques d’une organisation à l’autre. C’est la preuve que l’entreprise se les est appropriées. Sinon, c’est du « Zombie Scrum » et cela ne fonctionne pas ! »

Projexion est un collectif de consultants avec des expériences dans des contextes métiers complémentaires : Product Leaders, Product Owners, consultants en organisation, chefs de projets, formateurs, architecte SI…

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