Product Ops : mesurer la maintenance pour libérer la roadmap

1. Le Product Ops : le liant entre des équipes qui n'ont aucune raison naturelle de se parler

Ce qui m'a frappé dès le début de l'échange, c'est la façon dont Morane pose le rôle avant de parler de méthode.

Pour elle, le Product Ops est la personne qui fait exister un pont entre les équipes business (sales, CS) et les équipes produit et tech. Ce pont ne se crée pas naturellement. Il exige quelqu'un qui comprend le langage des uns et des autres, qui sait aller chercher les signaux faibles sur le terrain, et qui traduit ce qu'il y trouve en solutions applicables par tous.

Chez Payfit, ce rôle se déclinait dans un contexte particulier : une équipe de product builders, profils hybrides combinant les responsabilités de PM (Product Manager, chef de produit), designer et développeur via un langage low-code interne appelé Jetlang, dédiée à l'implémentation des règles de paye française. Quinze product builders à l'arrivée de Morane, une quarantaine au départ.

2. La maintenance non mesurée : la bombe à retardement silencieuse

C'est le premier chantier sur lequel Inès, sa manager, l'a positionnée dès son arrivée. Et c'est celui qui m'a semblé le plus sous-estimé dans les organisations que je connais.

Dans les équipes de développement, la règle est généralement de consacrer environ 20% du temps à la maintenance contre 80% à la construction de nouvelles fonctionnalités. Chez Payfit, les product builders n'avaient pas de système pour mesurer ce ratio. Le premier problème était qu'on ne pouvait pas distinguer les vrais bugs des tickets mal qualifiés remontés par le CS. Le second : personne ne trackait le temps passé sur la maintenance, alors que les développeurs classiques le faisaient systématiquement.

"La maintenance, il faut la surveiller comme le lait sur le feu."— Morane Shemtov

Résultat : des équipes en souffrance, un risque de turnover réel, et une direction incapable de chiffrer si le problème venait d'une plateforme buggée ou d'un défaut de qualification des remontées. Morane est arrivée dans une équipe qui souffrait sans avoir les données pour se faire entendre.

3. Qualifier les tickets avant qu'ils remontent : méthode en trois temps

C'est l'idée la plus concrète de l'épisode, et celle que j'ai trouvée la plus directement transférable quelle que soit la taille de la structure.

Morane décrit une méthode construite sur plusieurs mois de travail.

Étape 1 : discovery qualitative et quantitative. Interroger toutes les parties prenantes (product builders, CS, CSM, experts paye, équipes tech) pour comprendre comment les tickets remontaient, pourquoi certains n'auraient pas dû remonter, et quel était le coût humain de l'ambiguïté.

Étape 2 : construction d'une grille de qualification. Définir des critères précis pour qu'un ticket soit légitime à remonter jusqu'à l'équipe produit. Pour chaque critère, une preuve doit accompagner le ticket. Cette grille est testée sur un échantillon de tickets existants, avec les product builders et les CS en parallèle.

Étape 3 : déploiement progressif et ajustement. Partir en live avec le nouveau système, accompagner les équipes CS dans l'adoption, et mesurer régulièrement. Pour certaines squads, la diminution des tickets entrants a été visible en quelques semaines.

4. Le time tracking : la donnée que les product builders n'avaient pas

Ce point m'a semblé être la leçon la plus simple à formuler et la plus difficile à appliquer.

Les développeurs classiques trackent le temps passé sur chaque tâche, y compris la maintenance. Cette pratique n'avait pas été étendue aux product builders chez Payfit, ce qui rendait impossible toute mesure objective du ratio maintenance versus nouvelles fonctionnalités.

Morane a mis en place ce tracking et y a ajouté une lecture par percentiles : à chaque trimestre, elle regardait en combien de temps 70% des tickets étaient résolus. Une amélioration progressive de ce chiffre de quarter en quarter montrait une progression tangible, présentable à la direction et aux équipes. Cette approche permettait aussi d'identifier les squads en difficulté, celles qui absorbaient un volume de tickets disproportionné par rapport à leur taille, et d'agir avant que la situation ne devienne critique.

5. La feedback loop : relier les signaux terrain à la roadmap produit

Le deuxième grand projet de Morane en Product Ops a été le déploiement de Productboard, un outil de gestion des remontées produit, pour environ 800 personnes chez Payfit.

Ce projet illustre ce que "casser les silos" veut réellement dire en pratique. Il ne s'agit pas d'abord d'un déploiement d'outil. Il s'agit de construire une arborescence du produit partagée et stable, à laquelle chaque équipe peut rattacher ses remontées, sans avoir à connaître l'organisation interne des squads produit. Chez Payfit, cela a demandé des semaines de travail : passer en revue toutes les squads, arbitrer les zones de recouvrement, trouver une organisation lisible pour les CS qui font remonter les feedbacks.

La formation a été volontairement immersive, avec des ateliers par équipe pour 300 personnes côté sales et CS, et non une simple vidéo envoyée sur Slack.

"Pour moi, c'est ça, les Ops : j'ai toujours travaillé pour détecter les signaux faibles des équipes. Et à travers ce qu'ils me disaient, trouver des solutions."— Morane Shemtov

6. Chief of Staff et Ops : deux noms pour souvent la même fonction

La fin de l'épisode m'a semblé particulièrement utile à entendre pour quiconque structure une première fonction transverse dans une petite organisation.

Morane est aujourd'hui Chief of Staff chez Riverse. Ce qu'elle décrit concrètement ressemble beaucoup à du RevOps (Revenue Operations) ou du Business Ops : analyser les verticales, comprendre ce que font les équipes terrain, identifier les priorités, aider à la décision.

La différence avec un CRO (Chief Revenue Officer, directeur des revenus) ou un Head of Sales tient selon elle à la neutralité. Le Chief of Staff n'a pas d'agenda sectoriel, ce qui lui permet de piloter des projets transverses comme un changement de pricing sans être perçu comme le représentant d'une fonction particulière. Dans une boîte de quinze personnes, ces deux fonctions font souvent la même chose avec des noms différents, selon qui recrute et comment l'organisation est structurée.