Product Owner : de la start-up au grand groupe
Quelle est la limite entre le rôle du PO et les différents rôles de l’équipe ? Comment doivent-ils travailler ensemble ? Ce sont deux questions que je me pose souvent quand je discute de mon métier avec d’autres PO. Voici ce que j’ai appris à ce sujet en passant d’une startup à un grand groupe.
Il y a presque trois ans, lorsque j’ai cherché mon premier poste de Product Owner, j’ai interrogé plusieurs Product Managers et Product Owners pour avoir leurs conseils. Une question revenait : “Est-ce mieux de commencer en start-up ou dans un grand groupe pour apprendre ce métier ?” Les avis étaient partagés. En start-up, j’allais toucher à tout, avoir un périmètre plus large et prendre rapidement plus de responsabilités. La contrepartie ? On attendrait de moi un niveau d’autonomie peut-être trop difficile pour un junior. Dans un grand groupe, au contraire, je pourrais m’appuyer sur mes collègues et managers du produit pour apprendre le métier. Le revers de la médaille ? J’aurais moins de responsabilités qu’en start-up et serais davantage cloisonnée.
En start-up, mon rôle de PO “couteau suisse”
C’est finalement le hasard des opportunités qui a décidé pour moi. Ma première expérience de PO serait en start-up. Là, j’y ai appris toute l’étendue du métier et toutes les dimensions que je pouvais lui donner. Mon rôle n’avait que les limites que je voulais lui mettre. On attendait de moi que je les repousse et joue différents rôles, notamment celui d’UX designer ou de testeur.
En grand groupe, l’apprentissage de mon métier… au contact des autres métiers
Il y a un an, je suis devenue consultante et mon premier projet a été dans un grand groupe. J’ai dû apprendre à lâcher prise sur différentes tâches hors de mon périmètre (tests, facilitation, UX….). Ce qui faisait partie de mon métier en start-up n’avait plus de sens dans un grand groupe, où il y a des experts, voire des équipes entières dédiées pour chacune de ses tâches.
Dans cet article, je me concentrerai sur les métiers avec lesquels j’étais en contact au sein même de l’équipe Scrum, même s’ il y aurait aussi beaucoup à dire sur les équipes externes avec lesquelles j’ai appris à travailler (UX, UI, Analytics, Optimisation…)
Travailler avec un testeur
Prenons l’exemple des tests, sur lesquels je passais de longues heures en start-up. Au départ, être libérée de ce rôle a créé un vide dans mon emploi du temps et dans ma relation avec le produit. Néanmoins, j’ai eu tendance à garder un œil dessus pour connaître mon produit et peut-être pour garder une impression de contrôle. Puis j’ai dû apprendre à travailler avec une testeuse : c’était inédit pour moi. Je me suis interrogée sur son rôle. Que devait-elle tester et quand ? Qui devait écrire les tests ? Sur quel environnement ? Qui donnait le Go final pour la mise en production ?
Pour vous donner un peu de contexte, nous avons deux phases de test : l’une sur un environnement de travail, l’autre sur un environnement de recette. Ma testeuse devait-elle tester sur l’un, l’autre, les deux ?
Au début, elle testait uniquement sur le premier environnement, et j’étais responsable des tests sur notre environnement de recette. C’est rapidement apparu peu pertinent puisque c’est elle la garante de la qualité.
Progressivement, elle s’est donc chargée de tous les tests en préprod. De mon côté, je suis responsable de donner le feu vert pour la prod, en prenant en compte le bilan des tests mais aussi d’autres facteurs (les dépendances avec les autres équipes, le contexte business…).
Travailler avec un Scrum Master
Autre exemple avec la facilitation : contrairement à ma précédente expérience en start-up, j’ai maintenant un Scrum Master dans mon équipe. Comme avec la testeuse, j’ai dû retrouver un équilibre, comprendre son rôle pour connaître la limite avec le mien.
Quand je ne facilite pas, je peux me concentrer sur le partage de la vision produit à l’équipe, tout en ayant quelqu’un qui me challenge et pose les bonnes questions pour faciliter la communication. C’est aussi mon Scrum Master qui permet de lever les points de blocage dans l’équipe : la synchronisation nécessaire avec une autre équipe, les soucis de communication ou l’amélioration de notre board… Autant de points qui déchargent ma charge mentale et mon emploi du temps.
Le syndrôme du Problem Owner, déclencheur du changement
Ce changement ne s’est pas fait du jour au lendemain. En arrivant sur le produit, j’avais envie de gagner la confiance de l’équipe, de me sentir utile et compétente. J’adorais donc aider sur les tests, la facilitation, les wireframes… C’était problématique car en sortant de mon rôle, j’empêchais les membres de l’équipe d’être dans le leur.
Sans parler de la propre charge mentale du PO, parfois surnommé “Problem Owner” car il a tendance à porter tous les problèmes du produit sur ses épaules. Le PO peut vite se retrouver noyé. Suite à une semaine où les anomalies se sont enchaînées, en discutant avec mes pairs, je me suis rendu compte qu’il est important de lâcher prise. En effet, la responsabilité du Produit est l’affaire de tous, pas seulement du Product Owner.
Nous avons alors mené à bien des ateliers Qualité avec l’équipe. Cela a mis en évidence que la qualité du produit n’était pas la responsabilité individuelle du PO mais une responsabilité d’équipe.
Créer du vide… et mettre un cadre
En travaillant davantage en équipe, j’ai appris à lâcher prise sur certaines tâches et donc à faire confiance à l’équipe et améliorer son autonomie. Mes premières vacances ont été un bon test pour “créer du vide” et voir comment l’équipe fonctionnait en mon absence. Comment faisait-elle face aux imprévus et prenait-elle des décisions ?
Ce lâcher-prise, un peu violent, a permis de faire prendre conscience à l’équipe de l’importance de l’autonomie (mais créer le vide n’est pas forcément une solution à long terme car on ne peut pas tout déléguer et couper toute communication !).
A mon retour, plusieurs membres de l’équipe ont émis le besoin de clarifier les rôles : qu’avaient-ils le “droit” de décider en mon absence ? Nous avons mené un atelier pour clarifier et officialiser les responsabilités de chacun. Cela a permis de mettre en place un système de backup, notamment pour la validation des mises en production.
De plus, le cadre agile et notamment les rétrospectives nous ont permis d’expérimenter et d’affiner ces rôles. Il ne s’agissait pas de déléguer en bloc mais de savoir quel niveau de délégation avoir, trouver un équilibre entre faire, déléguer, et tous les entre-deux (faire ensemble, déléguer puis valider, demander conseil….). De nouvelles instances ont alors été nécessaires pour bien communiquer. Nous avons ainsi mis en place un nouveau rituel lors des phases de recette pour faciliter la communication entre la testeuse, le Scrum Master et moi.
Monter en compétences
Et alors, ce temps et cette énergie que je consacrais aux tests, aux wireframes ou à la facilitation, qu’est-ce que j’en fais à présent ?
Eh bien, je monte en compétences sur mon cœur de métier : le Produit. J’ai le temps d’analyser la performance du produit, pour en tirer les enseignements et ajuster le tir dans la roadmap.
J’ai également plus de temps pour la phase Discovery, avec des ateliers regroupant interlocuteurs business, développeurs et designers.
Enfin, j’ai le temps de prendre du recul, en demandant du feedback et en partageant mes expériences avec la communauté Produit chez BENEXT.
Ce que j’en retire aujourd’hui
En arrivant dans une organisation de plus grande taille, mon rôle était plus défini, et donc de prime abord plus réduit qu’en start-up. Pourtant, je n’ai pas arrêté d’apprendre. Bien au contraire ! Au lieu de faire certaines tâches seule, j’ai appris à interagir avec mon organisation et à travailler en équipe, ce qui est clé dans mon métier. Finalement, j’apprends à mieux faire mon métier et j’ai donc plus de valeur ajoutée pour mon équipe et mon organisation.
Ce que j’écris est lié à mon expérience personnelle et propre aux entreprises dans lesquelles j’ai travaillé.
Et vous, qu’avez-vous appris en changeant d’organisation ?
