| 💡 Cet article fait partie de notre dossier complet sur le métier de Product Ops à découvrir ici 💡 |
Notre dossier consacré à la profession de Product Ops dans l’écosystème nous amène aujourd’hui à Sébastien Levaillant. Le VP produit de Payfit a en effet contribué à la mise en place de cette fonction au sein de la solution de paie et de RH. Il nous explique pourquoi.
Salut Sébastien. Tu es arrivé en juin 2019 chez Payfit et, avec la VP design et le VP engineering, vous vous êtes tout de suite attelés à la réorganisation de l’équipe produit. Est-ce que tu peux nous raconter comment est venue l’idée de la création d’une fonction de product ops ?
Sébastien Levaillant : En fait, je dirais que ce choix a plus été dicté par le contexte que par la connaissance préalable de ce métier.
Je m’explique. Avec la croissance de Payfit, on savait qu’on allait connaître une diversification des lignes de produit et une augmentation importante de l’équipe produit. On a donc réfléchi à une organisation qui devait répondre à un double enjeu :
1) Rendre les équipes autonomes mais alignés sur des objectifs
2) S’assurer que la structure n’allait pas s’effondrer sur elle-même
Colonne vertébrale était un mot qui revenait en effet souvent dans nos discussions à ce moment.
Quand on a conçu l’orga, on s’est retrouvé avec un ensemble de sphères opérationnelles sur le papier. Mais on s’est vite aperçu que le danger n’allait pas venir de ce qui allait se passer à l’intérieur de ces dernières… mais plutôt de tous les espaces vides autour !
« Pour moi, la bonne combinaison en termes de compétence de product ops, c’est 1) avoir un côté analytique et rationnel et 2) savoir mettre son ego de côté »
Quels sont les enjeux que vous voyiez ici ?
S.L. : Il y en avait plusieurs pour s’assurer que la structure soit cohérente et plastique :
- Les process. Autrement dit, le système d’exploitation opérationnel qui va faire que les tribes vont bien fonctionner ensemble
- La culture
- Les compétences
On a réglé ce dernier enjeu en positionnant à la tête des tribes des directrices et directeurs produit qui ont pour responsabilité la création et le bon fonctionnement des équipes. Mais le système en entier ne pouvait pas reposer sur cette seule fonction.
Sachant que les enjeux de process et de culture ne pouvaient pas être incarnés que par le CPO et les VP fonctionnels. Sinon, cela deviendrait rapidement problématique car ce n’est pas au cœur de notre activité. Il fallait une fonction plus proche du terrain. Une sorte de product manager de l’organisation.
OK, on commence à voir poindre à l’horizon le product ops. Est-ce que vous vous êtes inspirés d’autres boîtes pour la définition de son rôle ?
S.L. : Chez Payfit, nous avons notre propre langage informatique, le JetLang et il existait déjà un rôle de JetLang Ops en interne, qui faisait le lien entre les équipes locales et globales.
On a aussi vu ce titre de product ops émerger en regardant ce que faisaient d’autres scale-ups. Toutefois, je me rappelle d’un échange que j’ai eu avec une personne de chez Stripe, la solution de paiement américaine. Leur conception du product ops était très différente. Chez eux, c’était très lié aux données, au marketing et au go-to-market. Tandis que, pour nous, l’objectif était plus d’orchestrer, de définir et d’entretenir le système d’exploitation organisationnel, voire aller jusqu’à l’accompagnement des équipes.
Donc en fait, on est vraiment parti du besoin qu’on subodorait de notre côté. A savoir que la structure qu’on allait mettre en place à l’instant T allait naturellement évoluer et qu’il fallait que ces changements reposent sur une fonction dédiée. On l’a identifié avec le nom de product ops, qui est un terme un peu fourre-tout, et qui ne correspond pas forcément à ce qui existait dans les boîtes américaines. Mais on va s’en rapprocher progressivement.
D’ailleurs, au début, quand j’en parlais autour de moi, je parlais de PM de l’orga. Je ne savais pas comment l’exprimer autrement qu’en parlant de l’intention.
Quelles sont les premières missions qui ont été attribuées au product ops chez Payfit ? Marie Gaumont, la directrice product ops chez vous, parlait de pompier dans cette conférence sur le sujet.
S.L. : Dans les faits, il y avait peut-être ce côté pompier. Mais, un des premiers enjeux, pour nous, concernait les processus d’alignement des équipes. Autrement dit : le product ops était responsable de la création et de l’entretien du cadre fonctionnel.
Très concrètement, nous sommes intervenus auprès des directrices et directeurs produit pour leur interdire de promouvoir à l’échelle de l’orga des process qui n’auraient pas été validés par l’équipe product ops.
Au sein des équipes, pas de problème pour tester des méthodes ou des outils. Mais pour l’étendre, cela devait passer par product ops. Ok, c’était bête et méchant. Mais c’était une façon de bien faire comprendre que c’était la chasse gardée du product ops.
Cela va faire maintenant près de 2 ans maintenant que cette profession existe chez Payfit. Qu’est-ce qui a évolué dans le temps ?
S.L. : Déjà, on est passé à un positionnement moins défensif par rapport à ce que j’expliquais juste avant. Très vite, on s’est dit que le spectre ne pouvait pas se limiter aux process. Et qu’il fallait aussi aider les équipes produit à monter en puissance, pour atteindre les objectifs ambitieux que l’on se fixe. C’est-à-dire s’assurer du niveau d’engagement et de bien-être des équipes, tout en accompagnant les décrochages. Un peu comme Médecins sans frontière : on doit être capable de diagnostiquer et soigner un problème d’évolution.
Petit à petit, on s’est donc rapproché de la thématique des plans de carrière. On a aussi agrémenté la partie données d’usage. Dans le but d’avoir des personnes capables de faire de la consolidation de données pour bâtir des tableaux d’usage pour les équipes. Sans oublier le volet recrutement et accompagnement sur le budget 2022. Le rôle a clairement mûri.
Comment s’est faite l’acceptation par les équipes ? On imagine qu’aux yeux de certains ou certaines, les product ops peuvent un peu passer pour les relous des process parfois, non ?
S.L. : Pas chez nous j’ai l’impression. Vous savez, quand tu es dans une scale-up, le mythe du PM omniscient tombe très vite. Il faut choisir ses batailles et celle de la structure, c’est très clair que tu ne peux pas la mener seul.
On était 200 quand je suis arrivé. On est aujourd’hui 700 et on sera 1 000 l’année prochaine. L’équipe produit va passer de 200 personnes à 400. Si tu réinventes la roue à chaque fois sous prétexte que t’es un PM, t’es mort.
Pour moi, la bonne combinaison en termes de compétence de product ops, c’est 1) avoir un côté analytique et rationnel et 2) savoir mettre son ego de côté.
En conclusion, à qui recommanderais-tu la création de cette fonction product ops ?
S.L. : Dès que tu passes le cap des 50 à 100 personnes, cela peut se justifier. Après, tout dépend du niveau de croissance. En mode ronron, tu peux t’en passer. Mais si tu es dans une boîte où tu as du chaos, là, oui. Dans le sens où tu sais que ça va bouger tout le temps et que tu vas avoir besoin de structure.
Pour moi, les process ne sont pas un gros mot. Ils sont positifs à une certaine taille et permettent de te libérer du temps de créativité, comme on le voit dans le modèle Toyota. La question que doivent se poser les personnes qui s’en plaignent, c’est : est-ce que vous êtes adaptées à cette taille de structure ? Car tu n’as pas le choix d’avoir un système d’organisation en place. Le temps consacré à l’alignement doit en effet se faire by design.
Retrouve l’ensemble de nos articles sur la fonction Product Ops ici. Notamment :
Comment ?! Vous n’êtes pas abonné(e) au Ticket ?
Corrigeons tout de suite cela 👇
