“En tant que Product Ops, nos utilisateurs à nous, ce sont des Product Managers” (Doctolib)

💡 Cet article fait partie de notre dossier complet sur le métier de Product Ops à découvrir ici💡

Dans le cadre de notre dossier sur le métier de product ops, on interroge Charlotte de Beauregard, directrice Product Operations de Doctolib. Arrivée en 2020 au sein de la licorne de prise de RDV médicaux en provenance de New-York, où elle était product director chez Dailymotion, elle a monté l’équipe, aujourd’hui composée de 5 personnes. Voyons sa vision de cette profession émergente. 

Pour commencer, peux-tu nous rappeler le contexte qui explique la création de la fonction de Product Ops chez Doctolib ?

Charlotte de Beauregard : A mon arrivée, en 2020, Doctolib comptait 1 200 personnes et une vingtaine de feature teams. On avait des fondations solides mais on anticipait l’hypercroissance à venir. On est d’ailleurs aujourd’hui 1 800 avec 40 feature teams et 50 Product Managers (PM). Sans compter la complexification du portefeuille de produits, le lancement de nouveaux pays et l’augmentation des parties prenantes.

Il y avait donc un besoin d’équipes transverses qui allaient pouvoir supporter cette croissance et aider à outiller les équipes afin qu’elles puissent se consacrer pleinement à leur métier et au business.

Tu connaissais, toi, ce métier de product ops avant de rejoindre Docto ?

C.d.B. : (Elle hoche la tête) Non, je n’en avais pas entendu parler. Même aux Etats-Unis où je travaillais auparavant. Mais le défi de participer à la naissance de ce métier m’intéressait justement !

Après, j’ai pu me faire une meilleure idée d’une part en lisant le livre “The Rise of Product Ops” de l’entreprise Pendo. Et, d’autre part, il y avait un “product management strategist” chez Doctolib qui était un peu l’ancêtre du product ops et qui travaillait déjà sur des projets concrets.

Justement, peux-tu nous raconter tes premières semaines dans ce rôle qui était à définir ?

C.d.B. : Déjà, j’ai récupéré une partie des chantiers en cours de la personne dont je parlais à l’instant. Concrètement :

1) La refonte de l’onboarding des PM. Autrement dit, créer une expérience d’apprentissage produit pour expliquer comment on travaille chez Doctolib pour les nouveaux PM recrutés. Ce qu’on appelle aujourd’hui le Product Camp.

2) Aussi, en lien, la création du programme d’associate product manager. C’est-à-dire la formation et l’accompagnement de salariés de Doctolib qui veulent s’orienter vers le produit.

3) Enfin, le lancement d’un outil de knowledge management (= de gestion des connaissances), en l’occurrence Confluence. En gros, je suis arrivée, on m’a dit : “On a pris des licences sur Confluence. Maintenant, il faut documenter toute la tech et le produit dessus”. Il fallait donc voir comment organiser l’info.

En parallèle de cela, j’ai aussi mené une phase de discovery. J’ai rencontré tous les product directors pour comprendre comment ils travaillaient et les gros enjeux auxquels ils étaient confrontés. J’ai fait de même avec la tech, le design et la data, afin d’avoir une bonne vision des défis opérationnels. 

As-tu un exemple concret de projet sur lequel tu as travaillé, pour bien saisir le rôle de product ops dans une organisation ?

C.d.B. : Oui, je pense à un des premiers projets quand je suis arrivée. On avait un enjeu de communication auprès des parties-prenantes “terrain”, sales ou customer support notamment. D’un côté, ces derniers n’étaient pas au courant de la sortie de nouvelles fonctionnalités. De l’autre, les PM comprenaient bien l’enjeu mais ne savaient pas qui précisément mettre dans la boucle…

On a donc adopté une approche très produit en allant interroger des personnes des deux côtés. Et, au final, on a abouti à la création d’un rôle de “Product Champion”, qui est une personne représentante du terrain auprès des équipes produit. On en a aujourd’hui 22 et elles aident autant les PM à valider l’impact de leur fonctionnalité que le reste des équipes terrain à avoir de la visibilité sur ce qui est en cours de conception. 

Cet exemple illustre bien le moment où tu commences à avoir besoin de product ops dans ton orga : quand tu ne peux plus simplement appeler un.e de tes collègues dès que tu as un souci et qu’il y a un besoin de structuration plus globale. 

J’ajoute que, tous les 6 mois, on fait une retro pour vérifier si ce processus est toujours utilisé et qu’il ne prend pas trop de bande passante pour ces product champions. 

Vous mesurez l’impact de toutes vos actions ?

C.d.B. : Le problème, c’est qu’on peut vite être vu comme des gens qui mettent en place des process mais qui ne regardent pas forcément l’impact que cela a sur le quotidien des PM. C’est un sujet sur lequel on travaille justement ce trimestre. Chacune de nos initiatives contient aujourd’hui une baseline et un résultat clé. Afin de mesurer concrètement la valeur de ce que l’on fait. 

En effet, on imagine que, parfois, votre intervention peut provoquer de la frustration chez des PM pas très fan de process. Voire que cela tombe dans le flicage à des moments, non ? 

C.d.B. : Oui, c’est un sujet. Surtout quand on parle de centralisation de l’info pour la rendre accessible au plus grand nombre. Il y a des PM qui n’apprécient pas ou qui n’ont pas l’habitude de le faire. A nous de bien les sensibiliser et leur expliquer le pourquoi de telle ou telle action. 

C’est pour cela que l’enjeu est d’arriver à impliquer au maximum les PM dans les process que l’on va mettre en place, pour que cela soit vraiment applicable et appliqué. C’est comme pour un produit classique : l’objectif quand on lance quelque chose, c’est d’avoir de l’adoption à la fin. Sauf que nos utilisateurs à nous, ce sont des PM !

Doctolib compte aujourd’hui une équipe de 5 personnes en product ops. Comment êtes-vous organisés ?

C.d.B. : Nous avons aujourd’hui 4 grands champs d’action, que nous avons défini au fur et à mesure :

• La mesure de l’impact. En soi, l’accompagnement des équipes produit pour maximiser leur impact sur le business. Ce qui va de l’aide à la définition de KPI (= indicateurs clés de succès), l’identification de leviers à la centralisation de cette info.
• Les process et les outils. Il s agit ici d’optimiser les process et outils utilisés et de supporter leur adoption entre le produit et la tech. Par exemple, la clarification du process de QA, la definition d’une timeline projet, l’hygiène Jira, comment travailler avec la data etc.
• La connaissance produit. C’est-à-dire : comment on organise l’information produit au sein des équipes mais aussi envers les parties prenantes
• Les talents et l’orga. Sous-entendu, les thématiques autour du recrutement et du bien-être des équipes. 

Un dernier mot sur le recrutement. Que regardes-tu quand tu souhaites embaucher une personne en product ops ?

C.d.B. : Tout d’abord, l’appétence pour le produit. Pas forcément une expérience en tant que PM. D’ailleurs, à part moi, aucune personne de l’équipe actuellement n’était PM auparavant. On va aussi prêter attention aux compétences en gestion de projets car on travaille beaucoup par projet. Enfin, on cherche des personnes analytiques. En face de nous, on a une population qui est drivée par ça et, comme je le disais, c’est important de toujours montrer l’impact que l’on peut avoir.

Product Ops : Qui sont ces Product Managers de l’organisation ?

---

Retrouve l’ensemble de nos interviews sur la fonction Product Ops ici :

---