| 💡 Cet article fait partie de notre dossier complet sur le métier de Product Ops à découvrir ici 💡 |
C’est une des références sur le métier de Product Ops en France. Marie Gaumont occupe cette fonction (naissante) depuis 2 ans chez Payfit et dirige aujourd’hui une équipe d’une dizaine de personnes. Profitons de son recul pour mieux comprendre cette profession.
Salut Marie. Sébastien Levaillant, le VP Produit de Payfit, nous a raconté dans cette interview la genèse de la création de la fonction Product Ops dans la boîte. De ton côté, comment es-tu arrivée à occuper ce poste ?
Marie Gaumont : Auparavant, j’étais chef de projets numériques dans des grands groupes. J’ai démissionné et pendant mes 3 mois de préavis, j’ai pris des cafés avec plein de gens car je ne savais pas ce que je voulais faire. J’en étais arrivée à quelques convictions : je ne voulais plus faire de conseil pour des clients externes mais travailler dans des environnements tech et avoir de l’impact sur la façon dont les équipes collaborent entre elles.
Lors du pot de départ d’un ami, qui était product director chez Payfit (NDLR : lui), je lui explique cela, en mode bullet points, mais que je ne sais pas à quel métier cela correspond. Il me répond : “C’est exactement ce que fait Inès-Ambre Salhi chez nous… et elle va commencer à recruter !”
J’ai discuté avec elle et, en effet, ça cochait toutes les cases. J’ai donc postulé et c’est comme ça, en janvier 2020 que l’aventure a commencé !
« On a un rôle de catalyseur. On est là pour accélérer les choses en enlevant des charges aux équipes. Mais sans faire à leur place. On ne travaille pas pour eux mais avec eux. »
Dans cette conférence, tu expliques qu’au début, tu occupes un peu un rôle de pompier opérationnel. C’est-à-dire ?
M.G. : Au début, on avait en effet un peu l’impression d’absorber les urgences sans avoir forcément de cadre clair. Quand je suis arrivée, mon onboarding a duré 3 jours… avant qu’on me file une patate chaude dans les mains !
Petite précision : le poste existait déjà au sein de l’équipe France depuis 2018 même s’il n’était pas vraiment formalisé. Et nous étions 3 Product Ops quand j’ai commencé, pour une dizaine de feature teams.
Sur quoi as-tu commencé à travailler concrètement ?
M.G. : La 1ère chose, c’était le process trimestriel d’alignement produit. On avait beaucoup de dépendances entre les équipes chez Payfit et on avait du mal à les anticiper. Ce qui pouvait provoquer le ralentissement voire l’abandon de certains sujets.
A l’époque, on avait déjà ce qu’on appelle des Product Initiative Briefing. Une page qui synthétise toutes les infos nécessaires d’un sujet (le problème que l’on souhaite résoudre, sa source, sa taille et l’intention que l’on a pour le résoudre) pour que chacun puisse avoir une compréhension globale des enjeux du moment. Sauf que seulement ⅓ des équipes produit l’utilisait.
J’ai donc repris ce modèle et je l’ai déployé à l’échelle en mettant en place le process et les outils associés. Ainsi, aujourd’hui, en milieu de trimestre, les équipes font des ébauches de briefing pour le trimestre suivant, en pointant les dépendances. S’ensuivent alors des semaines d’alignement et, la dernière semaine du trimestre, on a une présentation finale où chaque équipe présente leurs initiatives validées. Le rôle du Product Ops ici, c’est de créer et de mettre en place tout ce process.
Pour résumer, ton métier, c’est de mettre de l’huile dans les rouages ?
M.G. : En quelque sorte. Sauf que, parfois, on crée les rouages. On peut aussi parler de système d’exploitation ou de colonne vertébrale du département. C’est en effet un équilibre entre alignement et autonomie : qu’est-ce qu’on standardise pour fonctionner tous ensemble et qu’est-ce qu’on laisse à la libre discrétion des Tribes ?
Et en quoi vous ne marchez pas sur les pieds du leadership produit ?
M.G. : Pour reprendre l’image de la colonne vertébrale : on relie les vertèbres au cerveau. On est un peu le bras armé du leadership. Ce sont eux qui vont penser la stratégie et la structure organisationnelle. Et nous, on va créer les conditions qui vont permettre de l’exécuter.
Je précise d’ailleurs que chez Payfit, les Product Ops ont un périmètre plus large que juste les product managers. On s’occupe de l’ensemble du département, ce qui inclut les PM mais aussi les designers, les ingénieurs ou les product builders. Soit près de 200 personnes dont une vingtaine de PM. On va ainsi gérer les process de maintenance ou la diffusion de la culture design, ce qui n’a pas grand chose à voir avec le product management.
Vous fonctionnez avec une méthodo plutôt produit ou projet ?
M.G. : Je dirais que c’est un peu hybride, du fait de notre proximité avec les équipes produit, contrairement aux autres équipes Ops (Sales Ops, Customer Service Ops, Finance Ops, HR Ops… oui, on aime beaucoup les Ops chez Payfit !) qui sont plus en mode projet.
On commence toujours nos sujets par une discovery. Sachant que notre produit à nous, c’est l’organisation. Et nos utilisateurs, ce sont les salariés en interne. On va avoir cette même logique d’aller définir le problème avant de penser à la solution.
Le Product Ops n’est-il pas plus un état d’esprit à avoir qu’un métier ? Autrement dit, est-ce que l’arrivée de cette fonction ne provoque pas une déresponsabilisation des PM ?
M.G. : Ca peut arriver, mais c’est évidemment l’écueil à éviter. Moi, je ne viens pas du produit. Je n’ai pas d’expertise sur ce métier donc j’ai besoin de travailler avec les PM pour concevoir des choses qui vont vraiment les aider. Notre objectif, c’est d’avoir de l’adoption à tous les niveaux.
C’est pour cela qu’on commence par une discovery. On ne prétend pas mieux connaître le problème que ce que vivent les équipes. Et que l’on fait des développements progressifs pour itérer sur ce qui est mis en place. On veut les impliquer un maximum et développer les solutions en co-construction. Pour que cela soit aussi bien notre solution que la leur.
Je dirais qu’on a un rôle de catalyseur. On est là pour accélérer les choses en enlevant des charges aux équipes. Mais sans faire à leur place. On ne travaille pas pour eux mais avec eux.
D’ailleurs, je suis convaincue que mon département pourrait ne pas exister. Rien ne doit en effet reposer sur nous. Nous ne devons pas être un maillon de la chaîne. Cela doit s’autoporter. Nous, on ne fait qu’absorber les sujets et catalyser les efforts pour, au final, le redonner à l’orga.
On imagine toutefois que les PM n’ont pas tous et toutes la même réaction et qu’il peut y avoir quelques réticences face à l’arrivée de Product Ops et donc de process supplémentaires, non ?
M.G. : Oui, c’est un aspect négatif qui peut facilement arriver. En mode: “C’est la police qui nous oblige à faire ça et qui nous court après sinon”. Personne n’a envie de faire ce métier. Certaines personnes Product Ops ont très mal vécu parfois ce type de situations.
Je dirais qu’il faut rapidement démontrer notre légitimité et prouver que l’on apporte de la valeur sur des sujets critiques. Ne pas être sur la défensive mais, au contraire, que les équipes soient heureuses quand on prend à bras le corps un sujet qui les concerne.
Après, dans un groupe, il y a toujours différents profils. Les promoteurs : tu leur expliques la valeur que tu veux apporter et ils vont y aller spontanément. Les suiveurs : il faut les accompagner, leur montrer une première fois et après, ça déroule tout seul. Et enfin les renégats. une minorité de mauvais élèves.
Ce n’est toutefois pas à nous d’imposer les choses. On fait beaucoup de sensibilisation auprès des directeurs et directrices produit pour leur passer le relais. C’est à eux et elles de maintenir les choses, de coacher les équipes voire d’user du bâton envers les récalcitrants.
As-tu une roadmap au sein de ton équipe ?
M.G. : J’ai essayé une fois d’avoir une roadmap annuelle… et franchement ça ne marche pas ! On est obligé de s’adapter aux besoins du moment de l’orga. Quand je vois les projets sur lesquels on travaille aujourd’hui, c’est sûr que je n’aurais pas pu les anticiper il y a 6 mois.
Par exemple, là, on aide l’incident manager à retravailler tout le process de gestion des incidents. On ne l’avait pas envisagé en début d’année mais, après quelques incidents survenus au printemps, il est devenu prioritaire d’améliorer cette partie.
On est tout de même sur des projets trimestriels pour fonctionner au même rythme qu’au produit. Généralement, un mois avant la fin du trimestre, on fait un brainstorming ensemble pour voir les différents sujets. Notre source, ce sont essentiellement les retours terrain mais aussi des axes poussés par le CPO ou les VP voire d’autres équipes Ops.
J’envoie ce tableau de projets à tous les directeurs de la triforce (Produit, design et Engineering) et on a alors ce qu’on appelle le mercato : ils vont voter en donnant une note de 1 à 3. Ce qui nous donne un classement et on va alors se répartir les sujets prioritaires entre nous.
Comment mesurez-vous le succès de vos actions ?
M.G. : On a des OKR (= Objectives Key Results) tous les trimestres, qui correspondent à des impacts et non des livrables.
On regarde aussi des KPI (= Key Performance Indicator) à l’échelle de l’orga. Par exemple, tous les trimestres, il y a chez Payfit une étude avec une cinquantaine de questions sur son quotidien au travail. Certaines réponses sont super pertinentes pour nous : Suis-je bien dans mon travail ? Ai-je les bons outils pour faire mon métier ? Ai-je le bon socle de connaissances pour progresser ?
A quel moment estimes-tu qu’il convient de se doter d’une équipe Product Ops ?
M.G. : Ça devient pertinent quand le mode très oral, où tout le monde se connaît, commence à ne plus fonctionner. Autrement dit, quand tu dois passer sur de la transmission d’informations asynchrone et créer des systèmes pour t’aligner et standardiser ta communication.
Concrètement, cela va dépendre des profils de ton équipe. Certaines personnes adorent ce volet orga donc tu pourras pousser plus longtemps. Mais aussi de la vitesse du passage à l’échelle. Plus ton scale est rapide, plus la pertinence d’une fonction ops est claire.
Un dernier mot sur le métier de Product Ops en soi. N’est-ce pas un peu frustrant si l’on vient du product management et que l’on aime parler à des utilisateurs finaux par exemple ?
M.G. : Nous, dans notre équipe Product Ops, on n’a en effet aucun ancien PM. Et c’est vrai que j’ai déjà vécu cette situation auprès d’une personne qui voulait être PM et qui voyait le Product Ops comme une porte d’entrée. Ce qui est vrai… Mais assez rapidement, elle s’est retrouvée frustrée de ne pas vraiment parler avec des clients ou de travailler avec des dev’ ou des designers.
Elle a trouvé un poste de PM en interne donc tout s’est bien fini. Mais c’est sûr que c’est un avertissement pour moi en entretien désormais. Des personnes qui savent déjà qu’elles veulent être PM, pour moi, c’est un no go. Le Product Ops est une porte d’entrée pour découvrir le monde du produit quand on ne l’a pas connu. Mais si on sait fermement qu’on veut être PM, ça va générer de la frustration.
