Son premier bouquin, Escaping the Build Trap, une référence dans le produit, a été un carton (+ 75 000 exemplaires vendus). Melissa Perri, la consultante et conférencière en product management de renommée internationale, vient dans Le Ticket parler de son nouveau livre, co-écrit avec la Product Leader Denise Tilles : Product Operations. Un nouveau guide essentiel pour celles et ceux qui s’interrogent sur la fonction Product Ops.

8 min de lecture 

 ✉️ Article issu du Ticket n°072

C’est quoi le Product Ops ?
Leur mission : aider les Product Managers à se concentrer sur leur cœur de métier. Leur produit ? L’orga. Leurs utilisateurs ? Les équipes en interne. Mi produit mi projet, ce sont des mutants. Des tortues Ninja ? Non… Des Product Ops !

Voici la définition que l’on donnait de cette profession naissante dans notre article sur le sujet en novembre 2021. Celle de Melissa est moins fleurie mais sûrement plus précise : 

“Le Product Operations (Ops) est une discipline qui consiste à aider les équipes produit à bien passer à l’échelle. Leur job n’est pas de dire ce qu’il faut concevoir. Ce sont en quelque sorte des PM de PM”.

Bonjour Melissa. D’où vient l’idée de ce nouveau livre et cette volonté d’explorer ce thème du Product Ops ?

Melissa Perri : Tout simplement de l’expansion grandissante de la fonction Product Ops au sein des entreprises. Devant l’ampleur du phénomène, Denise et moi avons décidé d’écrire un livre sur le sujet afin de dissiper certaines idées reçues sur cette nouvelle profession et d’expliquer son utilité, au regard de ce que nous avons concrètement constaté au cours de nos expériences récentes.

Comment expliquer cet essor des Product Ops ?

M. P. : Le développement de ce rôle est intimement lié à la multiplication du nombre de Product Managers. Et au fait que, souvent, ces derniers ne sont pas en mesure de bien faire leur travail, car ils effectuent beaucoup de tâches qui ne constituent pas le cœur de leur activité.

Au lieu de s’intéresser aux problèmes des clients, de prendre des décisions produit ou de collaborer avec les dev’ et les différentes parties prenantes, la plupart doivent par exemple galérer toute la journée sur des bases de données afin d’obtenir des informations correctes. Sauf que cela n’est pas de leur responsabilité ! Le Product Ops est ainsi là pour les aider à se concentrer pleinement sur leur travail.

“Les Product Ops ne remplacent pas les Product Managers mais les aident à mieux faire leur travail”

Si notre mémoire est bonne, il y avait déjà un passage sur le Product Ops dans votre premier livre, Escaping the Build Trap…

M. P. : Oui, j’avais écrit un bref passage sur le sujet. J’étais justement chez Athena Health, l’entreprise dans laquelle je travaillais en 2017 et où j’ai découvert de manière opérationnelle le Product Ops, quand j’ai fini d’écrire Escaping the Build Trap. Et les questions qu’on me posait à la suite de ce premier livre m’ont convaincu qu’il fallait y vraiment réfléchir afin d’apporter un cadre à cette nouvelle discipline.

C’est précisément ce que vous avez fait en créant notamment le modèle des 3 piliers du Product Ops, l’un des enseignements majeurs du livre à nos yeux. Comment les avez-vous définis ?

M. P. : À la suite de ce que j’avais vu chez Athena Health, nous nous sommes questionnées avec Denise sur les éléments dont une organisation a besoin pour fonctionner efficacement, en dehors des compétences des équipes. Je précise d’ailleurs ici que les Product Ops ne remplacent pas les Product Managers mais les aident à mieux faire leur travail. 

C’est en cherchant les obstacles majeurs dans le quotidien des PM qu’on a trouvé ces trois piliers : Data & Insights, Customer & Market et Process & Governance (traduction : les données et connaissances, les consommateurs & le marché et les processus & la gouvernance).

Commençons par l’explication du premier, Data & Insights.

M. P. : Il s’agit ici d’aider les Product Managers à obtenir facilement des bonnes données afin de pouvoir prendre leurs décisions. “Il faut que je demande aux Data Analysts ces données car je n’arrive pas à y avoir accès” : je ne compte plus le nombre de fois où j’ai entendu cette phrase dans ma carrière !

De plus, en traitant cet enjeu, notamment dans les entreprises en phase de forte croissance, on débloque souvent tout le monde. Autant les leaders produit qui peuvent baser leur stratégie sur des faits concrets, que les Product Managers qui peuvent mesurer leur succès.

Le constat est-il le même pour le 2e pilier, Customer & Market ?

M. P. : Oui. Là encore, c’est en constatant, lors de nos accompagnements avec différentes entreprises, que celles qui ne faisaient pas de recherche utilisateur n’avaient pas un problème de volonté mais de capacité. 

Les Product Managers se plaignaient toujours des mêmes choses : je n’arrive pas à entrer en contact avec les utilisateurs, cela me prend trop de temps, j’interroge toujours les mêmes clients (généralement, ceux qui m’ont déjà dit oui par le passé…).

En cherchant à voir comment certaines organisations résolvent ce problème, nous nous sommes rendus compte que, la plupart du temps, elles travaillent en étroite collaboration avec le business et les équipes commerciales. Je pense par exemple à Pendo qui a commencé par remonter les données des ventes directement au produit. Puis, réciproquement, qui a instauré une communication ouverte du produit vers les Sales.

C’est le cœur de ce deuxième pilier : s’assurer que la connaissance des clients est accessible aux personnes qui en ont besoin et faciliter la recherche utilisateur.

Source : site de Melissa Perri

Est-ce que cela ne chevauche pas la fonction de Research Ops ?

M. P. : Tout à fait ! Soyons clair : si vous avez une excellente équipe Research Ops, ne cherchez pas à la remplacer par des Product Ops. Ces derniers sont utiles quand il n’y a personne ou peu de monde qui s’occupent de la recherche utilisateur. 

Encore une fois, l’objectif est de faire en sorte que les PM, les Product Designers ou les développeurs puissent accéder aisément à la recherche utilisateurs.

Et enfin le 3e pilier, Process & Governance…

M. P. : Celui-ci repose sur une question que se posent beaucoup de leaders, que cela soit dans des scale-ups ou des grandes entreprises : sur quoi travaillent concrètement toutes mes équipes ?

On s’entend que fouiller dans Jira pour le savoir n’est pas le bon niveau d’informations. La plupart demandent plutôt des présentations de roadmap de la part des différentes squads. Sauf que, bien souvent, les formats ne sont pas uniformisés et les enseignements rapidement obsolètes. 

L’enjeu ici, c’est d’avoir une structure afin de savoir comment prendre des décisions, comment les communiquer et comment maintenir les informations à jour.

“L’équipe Product Ops doit rester aussi petite que possible”

Comment y arriver concrètement ?

M. P. : Parler de gouvernance et de processus, cela veut dire standardiser des modèles de documents, organiser des bonnes réunions et définir une cadence dans les instances de décision afin de garder l’information fraîche et de déterminer la façon dont nous travaillons ensemble. Entre équipes produit mais aussi au-delà. Autrement dit, éviter la boîte noire du produit où l’on vous demande constamment sur quoi vous êtes en train de travailler.

L’idée est de ne pas arriver au mois de novembre et de paniquer subitement car il faut vite faire sa roadmap et son budget pour l’année prochaine ! Le système opérationnel doit être conçu de manière à ce que la stratégie produit soit un processus continu tout au long de l’année. 

L’enjeu est large : il est question de documentation, de communication, de collaboration avec le reste de l’organisation… C’est pourquoi le piège est d’en faire trop et de vouloir modéliser chaque petite chose. Alors qu’il ne convient que de s’assurer de ces points essentiels : 

  • comment prendre des décisions sur la base d’informations fiables
  • comment faire savoir aux personnes ce qui a été décidé
  • comment réexaminer ces décisions stratégiques
  • comment les communiquer et s’assurer que tout le monde est sur la même longueur d’onde.

Comment faut-il comprendre ces trois piliers ? Est-ce un tout à appliquer dans sa globalité ou peut-on raisonner pilier par pilier en fonction de son contexte ?

M. P. : Trois piliers aussi vastes, cela peut en effet paraître décourageant. Nous ne recommandons évidemment pas de mener tous ces chantiers à la fois. Il faut plutôt commencer par diagnostiquer son plus gros problème et commencer par là.

Si vous ne savez pas si votre stratégie produit fonctionne car vous n’êtes pas bien instrumenté, il faut commencer par les données. Si vous avez du mal à accéder à vos utilisateurs et que les informations qualitatives ne circulent pas, il faut s’attaquer d’abord au 2e pilier. Si, en tant que dirigeant, vous constatez qu’il existe beaucoup de frictions et que le travail de vos équipes reste opaque, la gouvernance est la meilleure porte d’entrée.

En fait, je dirais qu’il faut commencer par un enjeu… mais il ne faut jamais s’y arrêter. Une fois qu’il est résolu, il faut continuer à améliorer son système opérationnel.

Une dernière chose sur ce point : comme dans tous les livres, nos trois piliers sont un modèle. Ce qui veut dire que chacun doit l’adapter en fonction de sa réalité, de la façon dont ses équipes fonctionnent, des responsabilités et rôles déjà existants etc.

Est-ce que, selon vous, les Product Ops vont devenir une nouvelle norme dans les équipes produit à l’avenir ?

M. P. : Je le pense, oui… mais j’apporterai une nuance toutefois. Beaucoup de commentaires négatifs émis sur cette profession concernent leur coût et leur ampleur potentiel au sein d’une organisation.

D’une part, rappelons que les Product Ops ne sont utiles qu’à un certain niveau de développement d’entreprise. Si vous êtes une vingtaine dans votre startup, vous n’avez pas besoin de Product Ops. C’est une aide pour passer à l’échelle quand les équipes commencent à grandir.

Par ailleurs, ce que nous expliquons dans le livre, c’est que cette équipe doit rester aussi petite que possible. Il est évidemment démesuré d’envisager un rapport de un Product Ops pour un Product Manager.

C’est en effet une critique que l’on entend à propos des Product Ops : si une boîte en a besoin, c’est qu’elle n’a pas réussi à automatiser son système d’exploitation opérationnel.

M. P. : C’est vrai. Personnellement, je suis convaincue que l’objectif, c’est de réussir à automatiser au maximum sa structure afin de pouvoir passer à l’échelle sainement. 

Malgré tout, faisons le parallèle avec une démarche produit. Au début, tu as besoin de faire le travail manuellement pour le comprendre et pouvoir le codifier. En expérimentant, en menant des itérations, en construisant un Minimum Viable Product (MVP)… Avant de le “productiser”, c’est-à-dire de pouvoir le rendre actionnable de manière répétée sans beaucoup d’interventions manuelles. En fait, cette petite équipe de Product Ops doit construire une infrastructure qui sera progressivement mise en mode pilotage automatique. 

Pour résumer, je pense que la plupart des entreprises qui font du produit à grande échelle doivent avoir au moins une personne en Product Ops. La taille de cette équipe dépendra de celle de l’organisation et de sa capacité à automatiser sa structure.

“Du Product Ops avec des juniors ? Pourquoi confier la façon dont le product management fonctionne dans une organisation à une personne qui n’en a jamais fait auparavant et pour qui c’est peut-être le premier emploi ?” 

Que pensez-vous de l’article de Marty Cagan qui désigne les Product Ops comme des “process people”, à savoir des personnes qui alourdissent une structure ?

M. P. : Je ne doute pas de ce qu’écrit Marty. Il y a sûrement des gens qui ont en effet mal compris la signification du Product Ops. Cela me fait penser à l’émergence de l’agilité qui a provoqué l’arrivée d’une horde de coach agiles venus mettre en place des process pour le plaisir du process. Si tes Product Ops ne sont là que pour empiler des process, il faut les licencier immédiatement ! 

Ce n’est toutefois pas ma conception du métier. Les bons Product Ops que l’on a rencontrés ne sont pas là pour mettre en place des process contrôlant mais plutôt pour atteindre des résultats. C’est la fameuse distinction entre outputs et outcomes (livrables vs résultats).

L’objectif du Product Ops, c’est d’améliorer la vie des Product Managers. Il s’agit de rendre leur travail plus efficace en contribuant à créer un environnement de travail agréable.

Quelles sont les erreurs fréquemment commises que vous avez pu voir lors de la création d’une équipe Product Ops ?

M. P. : Je pense à une erreur en particulier qui fait référence à un commentaire que j’ai reçu l’autre jour sur Linkedin. La personne me disait : “Mais en fait, les Product Ops ne s’occupent-ils pas de ce que font habituellement les Product Managers junior (Associate Product Manager) ?” Ma réponse : non, pas du tout !

Pourquoi confier la façon dont le product management fonctionne dans une organisation à une personne qui n’en a jamais fait auparavant et pour qui c’est peut-être le premier emploi ? Vous n’obtiendrez aucune plus-value de cette manière. D’autant que, comme on l’a vu avec les trois piliers, les zones d’intervention sont amenées à fluctuer rapidement.

Si l’on cherche des points de comparaison, la fonction se rapproche plus de Chief of Staff (NDLR : chef de cabinet en français) de Chief Product Officer, avec des responsabilités aussi bien stratégiques que de mise en œuvre opérationnelle.

Comment voyez-vous l’évolution du Product Ops à l’avenir ?

M. P. : Pour réaliser le livre, nous avons parlé à une cinquantaine de Product Ops ou de pros du Product Management au sein d’entreprises de différentes tailles. Je dois dire que ces discussions ont changé ma perspective sur ce rôle. 

Depuis, mon point de vue change continuellement et je pense que dans cinq ans par exemple, j’aurais probablement une opinion encore différente sur ce que doit être un ou une Product Ops. Toutefois, je pense que je serais toujours d’avis de dire que cette fonction est nécessaire !

Pour aller plus loin :