Transcription de l'épisode : "Marie Gaumont, Comprendre le rôle de Product Ops"
Terry : Salut Marie.
Marie : Salut Terry.
Terry : Merci du coup de prendre du temps aujourd'hui. Donc aujourd'hui on va parler de Product Ops et notamment basé sur ton retour d'expérience de ce que tu as pu faire et apprendre chez Payfit même si aujourd'hui tu travailles dans une autre boîte. Donc je te propose tout d'abord de te présenter succinctement.
Marie : Marie, je suis ingénieure de formation, j'ai un diplôme de l'école centrale Paris et de l'université de São Paulo, j'ai fait un double diplôme au Brésil. J'ai commencé d'abord en conseiller en stratégie avec un stage de fin d'études chez Stratégiennes, c'est la partie conseiller en strat de PwC. Et ensuite IKEMS, c'est un cabinet plus petit en France spécialisé industrie de matières premières. J'ai fait du coup les deux combinés ça pendant un peu moins de deux ans, avant de me rendre compte que j'étais un peu frustrée du fait de pas avoir d'impact concrètement parlant, c'est-à-dire que tu fais des analyses, tu donnes des recommandations à tes clients. Et après, ça part dans les cercles décisionnaires des boîtes pour lesquelles tu as travaillé, et puis tu ne sais pas s'ils ont implémenté ce qu'on a recommandé ou pas, et s'il y a eu les retours qu'on a pu espérer ou pas. Donc j'ai transitionné vers une entreprise qui s'appelle Reveval, qui accompagne des grands groupes dans le passage, on va dire, au cloud. D'abord au cloud bureautique, donc c'est des intégrateurs Office 365 et Google. Mais moi je travaillais sur une no-code plateforme qu'ils ont développée en interne qui s'appelle AODOX, qui est un peu une surcouche à Drive qui permet de créer des applications de gestion documentaire. Et donc j'intervenais auprès des clients quand ils voulaient utiliser cette no-code plateforme pour faire des applications de gestion documentaire un peu avancées, donc des intégrations avec d'autres systèmes, des ERP, des CRM. où ils avaient des normes documentaires un peu poussées. J'ai beaucoup travaillé avec la filière pharmaceutique d'Air Liquide par exemple, où dans la pharma, sur la documentation, t'as beaucoup de contraintes. Et donc j'ai fait ça pendant deux ans et demi, et puis au bout de deux ans et demi, Les projets ont commencé à un peu se ressembler, du coup j'avais envie d'autre chose, mais je savais pas quoi. Et j'ai discuté avec beaucoup de monde pour essayer de savoir qu'est-ce qu'ils me parlaient dans mon travail, qu'est-ce que j'avais envie de faire. J'en suis arrivée avec des bullet points de j'ai envie de continuer à travailler avec des techs parce que j'aimais bien la proximité avec ce type de profil. Mais j'avais envie de continuer à avoir ce travail de... J'aide les gens à être plus efficaces ou à trouver des solutions pour rendre leur quotidien plus facile, ce que je faisais avec mes clients via de la digitalisation et des applications. Mais je voulais plus faire du conseil, je voulais vraiment participer à une aventure d'entreprise, de boîte. Et je savais pas trop comment combiner tout ça, donc j'ai rencontré pas mal de gens pendant 2-3 mois. Et un ami m'a dirigé vers Payfit en me disant « Ce que tu me décris, c'est une équipe qui est en train de se construire chez Payfit et ça s'appelle Productops. Ça se trouve, ça t'intéressera. » À ce moment-là, je me souviens, ma première réaction, ça a été de lui dire « Non, Payfit, c'est trop gros déjà. Moi, je veux aller dans une boîte plus petite. » Parce qu'ils étaient déjà 500. Et j'ai petit déjeuné avec celle qui montait l'équipe et quand elle m'a décrit l'émission, le quotidien, je me suis dit ok, ça coche toutes les cases donc ça vaut le coup d'y aller et d'essayer. Et donc j'ai passé un peu plus de trois ans chez Payfit à finalement monter l'équipe Productops parce que la personne qui m'avait recrutée a bougé en interne au bout de six mois et donc j'ai pris sa place. Et au début, on était vraiment un peu en mode, on tâtonnait sur ce métier-là, ça veut dire quoi, qu'est-ce qu'on fait, c'est quoi nos missions. On faisait un peu pompier opérationnel et puis il a fallu mettre, on va dire, un cadre à ce métier-là et lui apporter un peu plus de structure et monter une équipe derrière. Et pour la dernière étape, j'ai quitté Payfit du coup en mars. Et aujourd'hui, je suis chef de la transformation chez Gladi. Donc, je gère une équipe opération. Donc, il y a quand même un lien avec le ProductOps. Il y a toute la partie travaillée sur l'escalabilité à l'échelle, comment on fait en sorte que la manière dont on fonctionne soit un minimum industrialisée pour que l'entreprise continue à grandir et qu'on puisse remplir les objectifs avec des équipes qui grandissent en fait et qui accueillent des nouvelles personnes et qui forment des nouveaux groupes ou des nouvelles équipes. Donc il y a ces parts-là qui sont similaires, après il y a des sujets de fond qui sont différents.
Terry : Ok. Présentation très claire. Donc on leur passe un coucou à tes nouveaux collègues. Même si, comme on avait discuté cet épisode, on va se concentrer principalement sur les exemples peut-être que tu as pu voir sur les trois ans d'XP passés chez Payfit. Mais n'hésite pas à faire les liens si tu en vois l'intérêt par moment avec ton expérience actuelle. Du coup, pour rentrer dans la problématique Product Ops, comme tu dis, c'est un métier en plus qui est récent. Toi quand t'es arrivé, quand on avait changé avant cet épisode, tu m'as dit que t'avais pas énormément de ressources francophones aussi pour savoir un peu du coup, essayer de s'inspirer de ce qu'on fait, d'autres boîtes et autres. Donc pour expliquer déjà un peu, sans même mettre le terme ProductOps, quelles étaient un peu les missions qu'on t'a demandé de faire au-delà de la partie... optimiser et aider les gens à mieux travailler mais de manière très concrète. Quel cas d'usage tu pourrais avoir en exemple dans ce que vous faisiez chez Payfit et d'ailleurs aussi si tu peux rappeler ce que fait Payfit ou le coeur de métier ?
Marie : Alors Payfit c'est une entreprise qui développe un logiciel de gestion de paie et de gestion RH pour petites et moyennes entreprises. Donc l'idée c'est de donner aux petites et moyennes entreprises un outil qui va gérer la paie de manière entièrement automatisée. Donc sans avoir besoin d'être un expert de la paie ou de faire appel à des experts de la paie, Payfit permet vraiment aux boîtes de 1 à 100 employés de gérer leur paie de manière autonome sans avoir besoin de vraiment aller creuser toutes les spécificités de la paie.
Terry : Ok, très clair. Donc par rapport à leur mission, c'est une plateforme SaaS, quels étaient les premiers enjeux, les premières problématiques auxquelles tu as pu être confronté dans le rôle de ProductOps ? Qu'est-ce que tu devais faire ? Moi, je te parle d'un regard extérieur à leur organisation. Donc ils étaient déjà 500 à peu près, tu disais, donc pas une petite boîte quoi, c'était plutôt une scale-up. Donc tu rentres, ils sont déjà 500, il y a des choses qui tournent, donc tu as déjà des product managers qui vont avoir leur roadmap, qui vont avoir un peu des objectifs d'outcome, qui vont avoir des choses à livrer. Du coup, j'imagine des product designers aussi en interne, la panoplie complète en fait de l'équipe produit avec les techs. Complètement. Les techs qui aussi ont une partie d'automatisation de ce qu'ils font, la partie de tout ce qu'on appelle le DevOps avec leur intégration continue, etc. Là-dedans, entre le product manager, product designer, les techs, les UX qui viennent de temps en temps, quel était le besoin d'avoir une équipe du coup ProductOps pour comprendre un peu les points bloquants, les problématiques que tu as dû résoudre derrière en fait ?
Marie : — Les premiers besoins, les missions, elles venaient plus par urgence. On va être honnête, c'était vraiment... On regardait l'organisation. Et avec les VIP, on regardait là où il y avait des feux et comment Productos pouvait venir en catalyseur, c'est-à-dire prendre le sujet, le porter, mettre les bonnes personnes dans la même pièce. Et puis... définir une solution et la dérouler. Et ça avait un côté très pompier opérationnel. On était plutôt sur des sujets transverses à l'organisation, mais sur lesquels tes métiers, donc tes produits managers, tes produits designers, tes techs, ne pouvaient pas forcément dédier du temps. Et même tes directeurs ou les différents managers ne pouvaient pas forcément dédier du temps parce qu'eux se concentrent justement sur la croissance des équipes. C'est-à-dire recrutement d'abord, ensuite accueillir les bonnes personnes, les onboarder, et puis aussi former leurs équipes. On arrivait à cette taille-là chez Payfit, un peu critique, où on savait que l'équipe produit, donc c'était à peu près 150 personnes à ce moment-là, allait continuer à grandir rapidement. Et du coup, les managers ont besoin de travailler à définir les nouveaux paramètres qu'on va devoir créer, recruter ces nouveaux profils. et n'ont pas forcément du temps pour structurer comment le département fonctionne de bout en bout. Le premier sujet que moi j'ai porté en arrivant chez Payfit c'était comment on gère l'alignement entre les équipes pour en fait gérer la dépendance surtout. Donc comment on se donne de la visibilité, donc là c'était à la cadence trimestrielle, pour que chaque équipe dise en fait moi tous les projets sur lesquels j'aimerais avancer c'est ceux-là, tous mes projets où j'ai des dépendances avec des équipes c'est ceux-là et ces telles équipes. et du coup créer des espaces de discussion et d'échange où chacun se met d'accord sur, bah oui effectivement on peut avancer sur ce sujet là, cette dépendance là, bah non on va la porter, on va la prendre en compte etc. Et inversement, bah non là clairement ça passe pas dans notre planning et ça passe pas avec notre charge donc ce projet là on peut pas l'avancer.
Terry : Ok, donc très clair, première pose sur ce sujet des dépendances, donc pour comprendre, donc tu parles des dépendances des équipes produits, donc comment elles étaient organisées en fait ces équipes produits déjà, est-ce que c'était un format un peu type ce qu'on peut voir chez Spotify, des squads, quelles étaient un peu les équipes qui elles étaient plus ou moins autonomes sur leur périmètre, et du coup pour comprendre ensuite en quoi elles pouvaient avoir des dépendances l'une envers l'autre en fait.
Marie : Oui, on avait en gros un modèle très inspiré de Spotify, donc avec des tribes et des squads. Une squad, c'était toujours un product manager, un product designer, un engineering manager et un ensemble de développeurs. Donc tu as toujours une Triforce dans une squad. C'est un point très important pour le coucher payfit, la notion de Triforce et d'avoir toujours un représentant produit design et tech. Et ces squads-là étaient regroupés par tribes. Donc t'avais des tribes plateforme et des tribes qui étaient plutôt sur des verticales d'expérience, on va dire. Et à la tête d'une tribe, t'as toujours un product director, un design director et un engineering director. et t'avais principalement des dépendances entre les équipes qu'on appelait un peu solutions, donc les tribes solutions qui étaient vraiment sur des expériences de bout en bout, et les tribes plus plateformes, qui du coup travaillaient sur des mécanismes qui allaient toucher à plusieurs expériences du type authentification, notification, la gestion des droits, ce genre de choses.
Terry : Donc pareil, juste pour faire une première pause là, pour être sûr de bien comprendre, les tribes solutions, c'est ceux qui vont avoir l'expérience de bout en bout, enfin qui vont être responsables de l'expérience de bout en bout en termes d'utilisateur final, c'est-à-dire que je parle pour ma paye par exemple, je veux comprendre Je ne sais pas, même en tant qu'utilisateur, je veux comprendre comment les congés sont payés ou pas, enfin les congés qui me restent. Moi, en tant qu'utilisateur, je vais me connecter à la plateforme, je vais ensuite aller sur, cliquer sur tel dashboard et voir et avoir le résultat. Ça, c'est une expérience complète. Ça, c'est les trap solutions du coup qui étaient responsables de ça. Mais pour faire ces étapes, je vais passer d'abord par la phase de login, ensuite par la phase de cliquer sur le dashboard principal, et ça, ça va être les tribes, du coup j'ai déjà oublié le nom.
Marie : — Plateforme.
Terry : — Plateforme, merci. C'est bien ça ?
Marie : — Oui, elles vont développer un peu les mécaniques que tu vas retrouver à plusieurs endroits. Par exemple, quand tu demandes tes congés, le manager qui doit valider, il reçoit une notification avec une validation, et donc ces mécanismes de notification et de validation, chez PayFit, ils sont portés par des équipes plateforme. C'est pas chaque équipe en charge d'un parcours qui va développer son propre mécanisme de notification, son propre mécanisme de validation, ce genre de choses. Et après, il y a une petite spécificité chez PayFit, qui n'est pas si petite que ça, c'est que tu as une équipe plateforme qui s'appelle le JetLang Platform. En gros, le JetLang, c'est une loca de plateforme qui a été créée, qui va venir, on va dire, abstraire les logiques de paye pour aider à l'internationalisation. Et en gros, après, tout ce qui est calcul de la fiche de paye, ça va être développé en JetLang dans chaque pays, puisque dans chaque pays, la manière dont est structurée ta paye et dont la manière dont est calculée ta paye est strictement différente d'un pays à un autre. Donc on avait aussi des équipes un peu particulières qu'on appelle des équipes de Product Builder. Donc t'en as une par pays. Donc c'est aussi des équipes solutions, puisqu'elles sont en charge de tout ce qui est calcul de la paye. et gestion de la paye, et eux vont travailler uniquement dans un environnement JetLang, donc c'est des product builders qui travaillent principalement avec des outils low-code de la JetLang Platform, et donc eux pour le coup ont énormément de dépendance avec la tribe. plateforme qui développe le JetLang, puisque parfois il y a des fonctionnalités qui n'existent pas dans la JetLang plateforme, qu'il faut que du coup la tribe en question développe pour permettre ensuite aux équipes qu'on appelait locales, solutions locales, de pouvoir ensuite eux développer ce qu'ils souhaitaient derrière.
Terry : Ok, très clair et c'est vrai que c'est bien de le rappeler parce que ce langage de programmation qui est assez haut niveau effectivement c'est ce qui fait aussi la force de Payfit. Donc j'imagine que ces équipes solutions locales c'était quand même un peu les clients principaux de la tribe. Complètement. Très clair, donc en gros, si j'ai bien compris ce que tu m'as dit, un exemple de problématique que tu pouvais avoir à résoudre sur des bloqués des points de friction quand il y avait deux priorités divergentes entre deux équipes qui n'avaient pas... qui avait besoin de travailler ensemble, je vais prendre un exemple par exemple la partie demande de congé, donc il va y avoir une tribe donc plateforme par exemple qui va être sur la partie purement réception de la demande de congé et une tribe solution qui elle est sur le parcours complet de je me connecte jusqu'à je demande et j'ai la réponse oui ou non. Et cette tribe qui est en support de la partie purement je reçois la notification auprès du manager, elle a aussi d'autres choses à gérer. et potentiellement sur sa roadmap en fait elle n'a pas cette priorité d'améliorer je sais pas quelle spécificité que la tribe solution qui est sur ce parcours là unique elle a besoin exactement par exemple.
Marie : Si ça pourrait être le cas si on veut mettre en place quand un manager est en congé du coup il a quelqu'un qui reçoit la notification à sa place ça c'est forcément quelque chose qu'on va développer dans le mécanisme de notification cette notion de je suis remplacée par quelqu'un et c'est pas l'équipe en charge du parcours de gestion des congés qui va le développer et donc là pour le coup c'est à eux de pousser les besoins parce que c'est eux qui ont envie de le mettre en place parce qu'ils ont fait les recherches qui montrent que c'est pertinent de faire de développer une telle fonctionnalité etc pour autant après doit y avoir des discussions avec l'équipe plateforme pour savoir si eux, avec les priorités qu'ils ont, ils peuvent insérer ça dans la roadmap.
Terry : Et du coup, donc comment concrètement t'as pu gérer les premières problématiques ? Quelles sont les choses que t'as mis en place et comment t'as approché ces problèmes ? Parce que ça c'est des problématiques qui sont assez... Dans des boîtes plus grosses où t'as des silos souvent, enfin t'as des départements qui sont dédiés, même des départements purement IT qui vont être détachés dans des boîtes qui sont moins digital native on va dire. Comment toi t'as géré ces premières... Quelles sont un peu les clés que t'as essayé de mettre en place pour débloquer des situations comme ça ?
Marie : — Le premier truc, et quand j'ai pris le sujet, ils avaient déjà un peu lancé ce chantier-là, mais c'est... Il faut qu'on ait, on va dire, un standard d'information sur les projets qui permette la discussion. T'es obligé de partager à peu près le même niveau d'information sur tous les projets pour justement pouvoir savoir un de quoi tu parles et puis ensuite savoir arbitrer donc ça passe alors il y a beaucoup de noms pour ce genre de choses dans le monde du produit nous on l'appelait chez payfit le product initiative briefing donc en gros c'est un template avec des grosses sections qui expliquent quel est le projet, à quel problème on veut répondre, quel est le besoin derrière, quel est l'impact aujourd'hui à ne pas le faire. Qu'est-ce que ça nous apporterait ? Est-ce que ça nous apporte du revenu ? Est-ce que ça nous apporte de la satisfaction ? Est-ce que ça nous apporte faciliter tout ce qui est activité back-office aussi ? Ça peut être ça l'incentive, on va dire. et d'écrire un peu la solution qu'on souhaite mettre en place, d'écrire un peu les dépendances. Donc il y avait déjà ce travail sur comment on standardise l'information pour que chacun parle à peu près le même langage et qu'on puisse le faire aussi de manière un peu industrialisée, un peu asynchrone. Donc il a fallu former toutes les équipes à faire ça, les accompagner à s'approprier les modèles, à les respecter aussi. Et avec ça, du coup, t'as aussi les rituels que tu mets en place, comment tu les partages, ces informations que t'as standardisées. Donc nous, ce qu'on avait fait sur la première version, parce qu'on a eu plein d'itérations de ce process-là, c'était en milieu de trimestre, les équipes commençaient à partager, on va dire, leur briefing en mode brouillon pour le trimestre suivant. Donc ils faisaient des premières ébauches de briefing où ils mettaient les premiers niveaux d'information et ils remplissaient bien les dépendances qu'ils voyaient avec les différentes équipes. Ensuite, on leur demandait de raffiner un peu ça. Parfois, t'avais des équipes qui, déjà, eux, faisaient un peu de l'écrimage à leur niveau. Parce qu'en fait, tout ce qu'ils avaient en brouillon, ils savaient qu'ils allaient pas pouvoir avancer sur tout au niveau du trimestre. Ensuite, on demandait aux équipes... Là, c'était pas forcément formalisé, mais vraiment sur l'indépendance. Enfin, chaque personne qui portait un projet avec une dépendance devait aller voir l'autre équipe et devait avoir validation. et on avait un dernier rituel un peu final l'avant-dernière semaine du trimestre où chaque équipe passait et du coup présentait succinctement tous les projets sur lesquels elle allait travailler le trimestre suivant avec les dépendances validées.
Terry : Ok ouais, donc ça fait pas mal de points de synchro. Ce que je trouve assez intéressant, tu l'as mentionné en fait en trame de fond, c'est la partie asynchrone et du coup le fait de pouvoir... et la partie aussi, je sais pas à quel point chez Payfit c'était transparent, mais la logique de transparence radicale qu'on peut retrouver dans d'autres boîtes qui permet effectivement de faciliter les problématiques d'alignement, parce que derrière il y a aussi ça qui vient en jeu en fait, quand tu dois allouer plus de temps à quelque chose, versus une autre c'est une question aussi de par rapport au business global sur lequel tout le monde doit s'aligner qu'est ce qui est le plus plus important donc est ce qu'il y avait ça derrière au delà de l'aspect de montrer et de permettre aux gens de bien voir toutes les dépendances et d'en être conscient avec les métriques qui permettait ensuite de vérifier les succès ou non des différentes fonctionnalités est ce qu'il y avait aussi cette logique d'essayer d'être un peu plus transparent et pour aligner tout le monde sur les objectifs globaux de la boîte où c'était — Pas dans un premier temps.
Marie : Après, ce process-là, en 3 ans, on l'a pas mal retravaillé. Donc il y a eu pas mal d'évolutions. Dans la première version, la logique, c'était vraiment juste tout le monde est au courant de tout. Et il y a plus... En fait, on avait vraiment... Avant que j'arrive, on avait vraiment des stats pas ouf sur ce qu'on appelait le delivery on time des projets. Et c'était souvent dû à des sujets de dépendance. des dépendances pas anticipées, des dépendances pas communiquées, des dépendances sur lesquelles on ne s'était pas aligné. Donc sur cette toute première version, il y avait vraiment un enjeu assez simple de dire qu'en fait, il n'y a plus de dépendances qui ne sont pas sues et il n'y a plus de dépendances qui ne sont pas discutées.
Terry : — Ok, très clair.
Marie : Après, effectivement, surtout cette première version-là, on l'a bricolé avec les outils qu'on avait sur la main. Une fois que tout le monde l'avait un peu adopté, au bout d'un an, etc., on a commencé à chercher un outil adapté. Et c'est vrai que quand on a, on va dire, upgradé ça sur un vrai outil pour porter tout ça, on a commencé à intégrer des notions Docker. Et donc effectivement à mettre en place aussi la priorisation on va dire un peu plus calculée. On n'est pas sur du racisme et c'était quelque chose comme ça avec une logique de on mesure l'effort et on mesure les niveaux de dépendance donc ça ça fait un peu tombe dénominateur. et ensuite on voit à quel point ça vient impacter les aucaires de la tribe et du département, ou alors si c'est un enjeu critique de sécurité, etc. pour laisser un peu bypasser certains sujets qui sont essentiels.
Terry : Très clair, et c'est vrai que tu fais bien du coup de bien préciser au départ que la problématique n'était pas sur l'alignement, mais plutôt sur le fait que tout le monde soit au courant de tout, ce qui peut surprendre des auditeurs qui ne seraient pas du milieu scale-up, c'est juste que quand tu parles de 500 personnes, c'est en l'espace de très peu de temps, et donc effectivement, c'est pour ça que tu parlais de pompiers, c'est parce que c'est littéralement comme ça, enfin c'était comme ça en interne, et donc des choses qui peuvent paraître un peu triviales en fait ne le sont pas quand tu passes Je ne sais pas combien de salariés, de personnes il recrutait tous les mois, mais ça devait se compter en 10 ans.
Marie : Moi quand je suis arrivée, début 2020.
Terry : Il y avait 50 personnes dans ma promo. Ok ouais, voilà. A peu près. Donc ça fait des onboardings assez... Assez conséquents. Donc très clair, après ce premier sujet que tu as taclé, quelle a été un peu la suite pour toi au niveau Productops ?
Marie : Du coup j'ai fait 6 mois où j'étais vraiment juste les mains dans le cambouis, donc il y a eu ces sujets-là, il y avait aussi pas mal de sujets sur tout ce qui est gestion de la maintenance, parce qu'en fait on avait beaucoup d'équipes qui prenaient l'hôte, donc en fait les autres sujets pour, on va dire la route cause c'est un peu toujours la même, pourquoi on n'arrivait pas à délivrer, ben en fait c'est que t'as énormément énormément de maintenance, Et c'était pas forcément de la maintenance... C'était plus la gestion qui était ablamée que le taux de maintenance initial. C'est-à-dire que la maintenance allait pas au bon endroit, on la monitorait pas, donc on savait pas en fait quelle équipe était sous l'eau pendant très longtemps ou pas. Et donc du coup, on enclenchait pas forcément, on va dire, les sujets un peu de... Ok, bah là, en fait, cette équipe-là, elle va tacler la dette technique pendant trois mois parce que, clairement, en fait, elle est pas capable de délivrer, elle fait que de la maintenance pendant... Il y avait beaucoup de sujets autour de comment on gère la maintenance et comment on redirige l'étiquette vers les bonnes personnes. Beaucoup de choses sur tout ce qui est routing et triage. Et ensuite comment on monite tout ça, comment on fait pour avoir des chiffres et du coup quelles conséquences ça a derrière. On avait aussi pas mal de choses sur les pays, comment ils se géraient, comment on créait aussi une communauté. Même si c'était des product builders qui travaillaient finalement sur des produits différents, parce que chaque pays sur la partie pay a finalement un payfit différent. Mais ils font le même métier, donc comment tu crées une communauté qui partage les bases de connaissances, etc. Ça, c'était un peu les premiers enjeux. Et après, du coup, j'ai pris la tête de l'équipe. On était quatre à ce moment-là. Et on a continué un peu ce côté très pompier opérationnel, à prendre les sujets qui popaient, les feux rouges. Enfin, on s'est retrouvés parfois à, on va dire, faire du management de transition sur certaines équipes, qu'il n'y avait pas les bons managers et qu'il allait arriver. Enfin, c'était vraiment un peu pour tout. Et à la fin de la première année, en gros, l'équipe a pas mal remonté le point que même si au quotidien ils voyaient très bien qu'ils avaient de l'impact et qu'ils étaient contents d'aider les équipes et tout, ils avaient du mal à voir comment tout ce qu'ils faisaient s'agençait dans une logique unique. Et aussi, concrètement parlant, ils apprenaient quoi au quotidien ? Comment ça s'inscrivait dans leur carrière ? Parce qu'en fait, on n'avait pas de... Product Up, c'était un peu... C'était un peu, ouais, les pompiers qui prennent un peu tout, quoi. Donc il n'y avait pas de cadre à ce métier-là. Et la fin de la première année, j'ai passé pas mal de temps à, justement, chercher comment je pouvais... donner un corps à ce métier là. C'était quoi nos missions ? C'était quoi notre périmètre ? C'était quoi notre rôle dans l'organisation ? Ça s'inscrivait dans quoi ? Et surtout à partir d'un moment qu'on puisse commencer à sortir un peu de ce rôle un peu pompier opérationnel et qu'on arrive à balancer une partie de projet où effectivement on est plus proche de la gestion de crise, à des choses où on commence à penser plus loin, où on commence à penser Scalabilité, long terme, mise à l'échelle. Mais pour ça, il y a besoin de clarifier le rôle et l'émission. Et aussi, c'était hyper important d'engager l'équipe dans une vision du rôle et de leur permettre de savoir, OK, en fait, moi, mon rôle, c'est ça. J'apprends ça, je développe telles compétences et mes perspectives d'avenir, c'est ça, ça, ça, ça, ça.
Terry : C'est vrai que ce que tu expliques, c'est que sur la première partie, le rôle était très opérationnel, pas tant de product que ça. Après cette première année d'apprentissage, c'est aussi intéressant, j'imagine, avec le recul, Ce que je vois de l'extérieur, c'est que quand tu fais ça, quand t'es très les mains dedans, tu vas aider plein de gens différents, quand ensuite tu structures un peu plus ton équipe, bah t'as quand même une certaine reconnaissance auprès des différentes équipes que t'as pu aider par le passé, et ça aide sur ta légitimité à pousser derrière.
Marie : Complètement. Complètement. La légitimité, c'était... Je pense qu'on n'en aurait pas eu une aussi forte avec ça, malgré qu'on avait un gros gros soutien du CPO et des VP. Si on n'avait pas travaillé sur vraiment les plus grosses douleurs des équipes, sur les trucs qui étaient vraiment criants dans l'organisation, on n'aurait pas eu aussi rapidement la légitimité qu'on a eue. Alors il y a eu le revers de la médaille aussi où tout le monde... au bout d'un moment, ne savaient plus rien faire par eux-mêmes, donc tout est allé chez Productops. Mais effectivement, et si c'était à refaire, je le referais comme ça, sans hésiter, justement pour ces notions de légitimité et d'après plus avoir à se battre sur le fait que quand t'apportes quelque chose sur la table, c'est que c'est un minimum réfléchi et qu'on remet pas en cause ta capacité à toucher certains sujets.
Terry : Ouais et ça je pense c'est un message hyper important même aussi côté plus product management quand on veut toucher à des sujets bien au-delà de la pure delivery, ben en fait la première chose à faire quand même c'est de montrer qu'on peut délivrer et ensuite on peut aller demander aussi à voir plus grand. Donc je pense que c'est toujours bon de le rappeler. Du coup quand tu es allé ensuite sur cette deuxième année, comment ça a structuré tout ça ? De quoi tu t'es inspiré ? Comment tu as mené les choses avec ton équipe ?
Marie : — J'ai d'abord essayé de lire pas mal de littérature sur le sujet. Et puis là, je me suis rendue compte qu'il n'y en avait pas beaucoup. Surtout, il n'y en avait pas du tout en Europe. Les quelques articles... Donc là, on était fin 2020. Les quelques articles, les quelques commentaires... Il n'y avait pas de bouquin sur le ProductOps. Voilà, il n'y avait pas grand chose. Donc j'ai essayé de me nourrir un peu de ça. J'ai essayé aussi d'en rencontrer un peu à droite à gauche. En France, à l'époque, il n'y avait quasiment que Spendès et Doctolib qui avaient des productops. Il n'y en avait nulle part ailleurs. Il y en avait un peu plus au UK, donc j'ai rencontré quelques personnes au UK. Et après, le truc qui m'a quand même pas mal apporté, c'est que j'ai fait une journée de bootcamp avec Products Labs. C'est l'institution de formation de Ménisa Péry. et il faisait des journées un peu d'introduction à ProductOps pour accompagner les équipes à comment introduire le ProductOps dans votre entreprise et tout. Sur les sujets de fond, c'était pas assez développé pour moi parce qu'on avait déjà un an de ProductOps derrière, j'avais pas besoin, c'était très tourné comment se faire l'avocat pour avoir une équipe ProductOps dans ton organisation produit. Donc tout ça, c'était des choses que moi j'avais, on va dire, pas besoin d'affronter à ce moment-là. Mais c'était hyper intéressant, surtout de discuter avec les gens qui participaient à cette journée-là. Parce que pour le coup, j'étais pas la seule à pas être à ce stade-là. Il y avait un peu des gens comme moi qui étaient dans une équipe ProductUps avec quelques personnes. Et donc finalement, ce qui m'a le plus intéressée, c'est le chat. où vraiment les gens parlaient de tout, de tout ce qui nous intéressait, comment tu récupères le feedback de tes sales et de tes services supports, comment tu fais pour l'amener au produit, comment tu fais pour faire en sorte que les discoveries prennent pas trop longtemps, comment tu fais pour gérer dépendance, comment tu fais pour monitorer le delivery, la maintenance, comment tu fais pour aligner les équipes... Comment tu fais pour diffuser les bonnes pratiques ? Comment tu fais pour former les gens sur des outils que t'introduis ? Enfin, tous les sujets qu'on rencontrait, ces personnes-là, elles en parlaient. Donc là, j'ai eu 2-3 contacts après avec des personnes qui avaient des équipes un peu plus conséquentes que la mienne et qui me semblaient être à un stade après. Il y en avait étonnamment quelques-unes en Allemagne. Donc c'était beaucoup US et en Allemagne. Typiquement, Delivery Hero, ils étaient bien avancés là-dessus. Et tout ça combiné a fait... En fait j'ai fait un peu ma propre discovery quoi. J'ai pris aussi en interne tous les besoins. Donc j'ai demandé à tout le monde, j'ai fait je sais pas une quarantaine d'entretiens avec les directeurs, les VP en mode, pour vous Productop c'est quoi ? Et vous nous attendez sur quoi ? Et donc combiné les entretiens en interne, les entretiens à l'externe, et ce que j'avais pu lire, on a formalisé avec l'équipe un peu notre rôle et nos missions. Du coup ProductOps chez Payfit c'est vraiment... On est là pour orchestrer le département produits et tech afin de maximiser l'efficacité, l'impact et l'épanouissement de chacun. Je parle bien du département dans son ensemble parce que nous on travaillait aussi bien avec les product managers, les designers que les développeurs. Là où je sais qu'il y a des équipes productops qui travaillent qu'avec les product managers et que sur les pratiques produits. Mais on va dire la structure organisationnelle de Paycheek et surtout le concept de Triforce faisait que c'était difficile de décorréler les métiers et de ne pas aborder tous les sujets. Et dans l'émission, on en a défini quatre principales. La première, c'est une mission plus de stratégie. C'est comment tu garantis l'alignement au sein du département ? Comment tu garantis que tout le monde ait conscience de la direction dans laquelle on veut aller et de comment il s'inscrit dans cette direction-là ? Donc t'as des projets derrière du type, comment on construit et on fait cascader les OKR dans l'organisation. T'avais aussi, on a commencé à développer au bout d'un moment, plutôt la troisième année, de la gestion de programme. Quand t'as un sujet qui est fondamentalement transverse, qui touche une grosse majorité des tribes, comment tu fais pour le cadrer, pour aligner tout le monde et pour t'assurer une certaine efficacité, aussi bien dans l'avancement que dans la communication ? Ensuite, il y avait une mission d'intelligence, c'est comment on fait en sorte que les équipes produits et tech aient à disposition les insights pour prendre les meilleures décisions. À ne pas confondre avec les products analystes, parce que nous, on n'était pas générateur d'insights. C'était juste, on te donne les moyens d'avoir accès à l'insights. Donc c'est plus par exemple comment on fait pour capter les feedbacks des sales et du support ou des accounts managers et comment on fait pour que à l'échelle ça retombe chez les bons PM et que les PM n'aient pas besoin de lire genre des centaines de feedbacks. qui ne leur sont pas forcément destinés. C'était aussi former tous les PM à Looker, qui est l'outil de BI chez Payfit, pour qu'ensuite, quand les équipes produits et data product mettent à disposition des bases de données, ils soient en mesure de faire des analyses lors de leur discovery en autonomie. C'était aussi comment on gouverne un outil type amplitude sur tout ce qui est product analytics pour pas te retrouver avec un milliard de trackers partout que personne ne regarde et avec des trucs obsolètes et du coup tu payes l'outil une blinde et un peu tous ces sujets-là. Ensuite il y a une mission d'enablement, c'est comment on fait en sorte que chacun travaille dans les meilleures conditions. Donc là on va beaucoup toucher à des sujets de process et à des sujets d'outils. Donc tu avais beaucoup de mise en place et d'amélioration de process comme ce qu'on discutait au départ sur les gestions des dépendances, donc ça on l'a beaucoup fait évoluer avec le temps. Et sur des outils, c'était par exemple comment on met en place Pendo pour tout ce qui est, on va dire, pop-up pour aider les utilisateurs, ou sondage dans l'appli, comment on fait pour gouverner, etc. pour ne pas se retrouver avec un milliard de pop-up et que du coup les utilisateurs se retrouvent à fermer des pop-up en permanence. On a mis en place aussi... J'ai oublié le nom de l'outil, ça c'est incroyable.
Terry : — Ça reviendra après.
Marie : — Ça reviendra plus tard, sûrement. Pour tout ce qui est gestion produit et planification produit, on a mis en place un outil pareil. Et la dernière mission, c'est... — Product board, non ?
Terry : C'est pas product board ?
Marie : — Product board, oui. Exactement. Ouais, j'ai oublié en ce temps. Et il y avait une dernière mission, une mission d'excellence, c'est comment on peut faire... on peut aider à faire diffuser les bonnes pratiques et à les faire, du coup, adopter au mieux par les équipes. Et donc là, ça passait plus par de la création, par exemple, de toolbox avec pas mal de templates, avec des séries de formation sur certains sujets, avec un peu des standards de qualité qu'on mettait en place. donc pas mal de sujets autour des best practices.
Terry : Ouais, hyper vaste en fait, hyper large comme périmètre. Vous étiez du coup toi plus quatre personnes ?
Marie : — Alors bon, ça a augmenté au fur et à mesure des années. À la fin de ma période chez Payfit, on était 9.
Terry : — D'accord.
Marie : — Donc j'avais un pôle, on va dire, très classique, produitable sur toutes ces missions-là. Donc où ils touchaient un peu à tout. Parmi ces missions-là, ils étaient 5. Donc une lead et 4 personnes. Et après, j'avais trois profils un peu plus particuliers. Une personne sur tout ce qui était gestion de la connaissance, et qui aidait aussi sur des sujets un peu du X-Writing, de documentation technique, donc vraiment tout ce qui touche à l'écrit. Ensuite, j'avais une personne qui était que sur la gestion de programme, puisque Payfit ayant beaucoup grandi, les équipes ayant... À la fin, il y avait 350 personnes au produit à la tech.
Terry : Au.
Marie : Moment où je suis partie. Et donc du coup, il fallait parfois piloter des projets un peu de manière transverse, les projets stratégiques. Et j'avais une troisième personne qui était sur tout ce qui était formation et learning plan. Donc comment on peut permettre à tous ces profils-là et à tous ces talents-là de grandir dans leur métier en construisant quelque chose qui est à l'échelle.
Terry : Hyper intéressant, donc il y a vraiment beaucoup de choses dans tout ce que tu viens de partager, donc on va pas rentrer dans chacune d'entre elles. En revanche, ce que je pense qui peut être intéressant pour d'autres boîtes qui seraient à des étapes similaires ou qui vont passer par ces étapes-là, c'est déjà, là t'as donné un cadre de ce que vous, vous aviez mis en place en tout cas et comment vous aviez défini l'émission. mais c'est toi qu'elles ont été les plus gros apprentissages en fait, une fois que vous aviez posé ça, que vous aviez défini ces missions et que du coup vous êtes passé plutôt en mode run de réaliser ces missions, qu'est-ce qu'aujourd'hui t'en retires comme choses qui ont vraiment bien fonctionné, choses peut-être qui ont moins bien fonctionné mais sur lesquelles t'as vraiment appris et que tu ferais peut-être différemment ? Donc on disait au tout début, avant que tu mettes ce cadre, il y avait le fait d'aller les mains dans le cambouis, puis comme ça faire comprendre aux gens que tu étais là pour les aider, ce qui permettait d'asseoir la légitimité, mais ça c'était avant de tout structurer. Une fois que tu as tout structuré, qu'est-ce que tu retiens aujourd'hui ?
Marie : Ce que je retiens, c'est qu'il y a quelque chose d'important dans le métier de product top, ce qu'on peut négliger, c'est qu'on doit toujours redonner l'ownership à l'organisation. Il y a vraiment ce rôle-là, on est là en tant que catalyseur, c'est-à-dire qu'on prend un sujet qui ne va pas bien, qui est une douleur à l'instant T, qui nous est remontée aussi bien par le terrain que par le top management. Du coup, on n'est pas à sa chambre. sur le sujet. Parfois un petit peu plus, mais parfois pas du tout. Donc il faut faire de la co-construction, ça c'est hyper important. La démarche initiale d'un sujet productops pour moi elle est très produit. C'est beaucoup faire de la discovery pour comprendre les besoins. Donc faire des entretiens en interne, faire de l'analyse de données si c'est possible, aller voir à l'extérieur aussi, parce que j'ai toujours dit à l'équipe si quelqu'un va craquer le sujet en fait on copie, on va pas s'embêter. Et faire beaucoup de co-construction dans les solutions que ça vienne pas tout simplement de notre tête. Ça c'est vraiment très important, mais aussi ce truc-là de penser quelque chose qui s'auto-porte dans l'organisation. Parce que si en fait ProductOps devient un maillon de la chaîne sur tout ce qu'on touche, c'est pas scalable en fait. On perd un peu cette notion de... construire un peu la colonne vertébrale de l'organisation pour que l'être vivant et l'organisation grandissent. Mais si on doit être un peu partout, ça ne marche pas. J'avais un peu cet objectif que le round de l'équipe soit le strict minimum. et que tout projet avait une phase à la fin de redonner l'ownership aux membres de l'organisation. On n'a pas vocation à remplacer des directeurs ou des managers, ça marche pas comme ça. Je pense que... Ce qui est difficile, c'est que quand tu grandis très vite, il y a un moment, même en étant sur des sujets de mise à l'échelle, d'escalabilité, ça joue quand même contre toi. Et je vois bien la dernière année, ce qui a moins bien marché, c'est que du coup j'avais une plus grosse équipe, donc on traitait à peu près on va dire 25 projets par trimestre, donc ça fait beaucoup de projets, donc tu fais quand même de la co-construction, mais tu fais de la co-construction avec quelques personnes de l'organisation produit, et du coup tu commences à avoir un peu ce sentiment de tout le monde qu'on leur imposait beaucoup de choses, alors qu'en fait c'était quand même co-construit, Mais en fait, sur ce projet-là, c'est ces deux squads-là avec qui on co-construit. Puis sur ce projet-là, c'est avec ces deux squads-là. Et on avait vraiment du mal la dernière année à... Les gens avaient l'impression qu'on avait changé. Et que du coup, on imposait les choses maintenant et qu'on co-construisait plus avec eux. Mais juste par manque de visibilité et... En fait, oui, on ne co-construit pas avec toi sur ce sujet-là parce qu'on ne va pas te solliciter cinq fois dans le trimestre. Donc on essayait de découper un peu quelle squad on sollicitait pour quel sujet. Mais du coup, il y avait une vraie difficulté à montrer que tout ce qu'on créait restait dans une logique de co-construction, de travailler avec le terrain. Et ce n'était pas imposé par l'équipe ProductOps. Ça j'avoue que je l'ai pas forcément craqué cette partie-là et on atteint un certain niveau de taille d'équipe où en fait tu peux pas tenir tout le monde tout le temps au courant quoi.
Terry : Est-ce que ça serait pas juste doubler l'équipe ProductOps ou la faire grossir pour permettre de maintenir la proximité mais après tu rajoutes peut-être de la dépendance là où comme tu le disais tu dois te mettre au bout d'un moment en retrait pour.
Marie : Je pense que pour le coup là j'étais arrivé une taille et c'est pour ça qu'on avait développé des expertises. Pour moi ça aurait été un échec de me dire il faut que mon équipe elle double parce que ça veut dire qu'on revient en permanence sur les mêmes sujets alors que l'objectif c'est bah non on tacle des choses. et c'est pérenne dans le temps et c'est escalable et donc on n'a pas besoin d'y revenir avant d'avoir passé à une vraie haute échelle, une vraie haute dimension. Et c'est pour ça qu'on va dire les profils ProductUps, ils ont jamais vraiment été plus de 4 ou 5 vraiment pendant tout le temps où j'étais là. Après, les personnes qui venaient enrichir mon équipe, c'était sur des expertises où là t'as besoin d'avoir une expertise particulière pour aller creuser les sujets. Je ne sais pas si c'était forcément la doublée. Je pense qu'il y a un moment où on ne s'est pas rendu compte qu'il fallait adapter notre communication, que peut-être il fallait qu'on soit plus visible. Autant les directeurs étaient assez au courant de ce qu'on faisait, mais on n'avait pas forcément de roadmap visible, on ne faisait pas forcément des briefings comme les équipes produits. Et du coup, je pense que pour eux, en insynchrone, c'était plus difficile d'avoir conscience de tout ce qui était en cours. et qui participait à quoi. Donc plus que faire grandir l'équipe, je pense que c'était vraiment des enjeux de communication qu'on n'avait pas encore réussi à craquer.
Terry : Hyper clair, hyper intéressant comme retour d'expérience, donc j'espère que ça peut aider d'autres personnes qui sont dans ces situations-là. Du coup, avant d'aller vers la fin des questions classiques sur chacun de mes épisodes, est-ce qu'il y a un sujet en particulier ou un point que tu voudrais accentuer par rapport à la thématique d'aujourd'hui qui est le Product Ops ?
Marie : Je pense que c'est peut-être quelque chose que les gens essayent de craquer en ce moment, c'est de mettre une définition et un label à ce métier-là. Chose avec laquelle je ne suis pas toujours très à l'aise parce que je pense qu'il y a autant d'équipes Productops qu'il y a d'organisations Produit Tech. Une équipe ProductOps qui marche bien, c'est une équipe qui est complémentaire avec l'organisation auquel elle est rattachée. Donc c'est normal qu'il y ait des équipes qui ne soient que sur le product management, c'est normal que d'autres soient sur toutes les dimensions, c'est normal que certaines traitent des sujets que d'autres ne traitent pas. Par exemple, j'ai rencontré des équipes ProductOps qui travaillaient beaucoup à l'enablement des équipes support ou sales. Donc en gros, il travaillait beaucoup avec les product managers à comment on forme les sales aux nouvelles fonctionnalités, comment on forme le support, chose qu'on faisait absolument pas chez moi. Mais pourquoi ? Parce que dans les équipes sales, t'avais des gens d'enablement qui étaient... Donc t'es forcément, on va dire, ton périmètre, il est forcément en complémentarité de l'organisation dans laquelle t'es. Et je trouve que c'est difficile de vraiment dire que Product Hub, c'est ça. Et l'émission, c'est ça. Et moi je pense qu'il y a des enjeux communs que tu retrouves un peu dans chaque organisation, l'alignement, la productivité, l'excellence, ce genre de choses, oui. Après, je suis pas toujours à l'aise avec le fait qu'on essaye de trouver absolument une définition à c'est quoi le product top. Et de pouvoir le décrire comme on le fait plus facilement avec d'autres métiers du produit, Product Manager ou PO, c'est déjà plus simple à définir. Là où l'ops est toujours un peu... Mais même d'autres métiers d'ops, il y a autant de définition de SalesOps qu'il y a d'organisation de SalesOps aussi. Je pense que c'est un point important pour le coup où on m'a beaucoup posé la question et moi j'ai toujours dit la définition que je donne du product hubs c'est la définition qui allait bien chez Payfit.
Terry : Tu fais bien de le rappeler, je pense que c'est souvent des torts qu'on peut avoir quand on sait pas trop où aller, on veut se rattacher à un cadre pour se dire c'est comme ça qu'il faut faire, mais faut pas oublier qu'en fait il faut faire quelque chose qui sert l'organisation dans laquelle t'es et pas l'inverse, pas essayer de faire rentrer des carrés dans des ronds. Ce que je retiens aussi de ce que tu viens de partager en termes de comment tu vois le rôle, bon la partie Ops comme tu viens très bien de le dire, ça dépend de chaque organisation, donc t'as autant de Ops différents que tu vas avoir d'organisation, mais la partie product peut-être si je devais moi tel que je le comprends y mettre un cadre ou tout du moins une sorte pas une définition mais une façon de faire c'est de se dire qu'on est là en support au produit et donc cet aspect très on vient pour aider un moment sur un sujet mais ensuite notre but c'est pas de remplacer c'est au contraire de de vous donner les clés pour qu'ensuite vous vous débrouillez tout seul et ça je trouve que c'est quand même assez intéressant de le voir de cette façon parce que ça rappelle aussi le rôle de base qui est là d'être pour débloquer des situations mais pas de devenir ensuite comme tu le disais un maillon de la chaîne ou plutôt même un point derrière un goulet d'étranglement là où en fait t'es censé juste débloquer des situations.
Marie : À la rigueur, la meilleure définition qui redonne un peu ça, c'est... Moi, Product Hub, c'est les PM de l'organisation. L'organisation produit et tech, c'est ton produit, en fait. Alors, on n'est pas sur des fonctionnalités, on n'est plus sur des groupements d'humains, on va dire. Mais il faut que ça arrive à fonctionner, il faut que ce soit fluide, il faut que ce soit cohérent, il faut que ça aille dans la même direction, globalement. Et donc il faut voir ça en mode, c'est là où moi je me suis beaucoup inspirée des méthodologies produits, c'est être dans la discovery un peu continue, être beaucoup dans le feedback, être beaucoup dans le test and learn, parce qu'en fait tu développes un operating system de l'organisation, et l'approche produit je trouve que ça s'approprie assez bien quand tu vas sur ce genre de sujet.
Terry : Top, je trouve ça très bien comme résumé, donc cool, parce qu'effectivement, de la même manière que les PM, tu vas avoir différentes façons de faire du product management dans différentes boîtes, PM de l'orga, c'est bien parce que ça peut s'adapter du coup à chaque orga. Donc pour aller vers les deux questions maintenant de fin d'échange, la première, c'est du coup, est-ce que tu aurais une position assez forte sur laquelle, en général, quand tu en parles avec tes pairs, tu es en désaccord ou tout du moins qui génère de la discussion ?
Marie : Ça va être lié à ce que j'ai dit auparavant, mais j'ai beaucoup de mal avec les grands noms du monde du produit qui parlent du Productops. Marty Kagan, Melissa Perry, et surtout c'est très tendance en ce moment. Melissa Perry va sortir son livre sur le Productops. J'ai beaucoup de mal parce que je trouve que c'est un métier, si tu ne l'as pas pratiqué, théorisé, ça ne sert pas à grand chose. Je suis beaucoup plus dans la prise d'expérience. On a monté une communauté ProductOps avec quelques autres en France, donc il y a déjà quasiment 70 personnes. Et pour le coup, pour l'instant, c'est une communauté qu'on garde uniquement aux gens qui pratiquent ce métier-là. et pas aux curieux et pas à ceux qui veulent philosopher sur ce métier-là. Et moi j'apprécie davantage les échanges, on va dire, plus représentatifs où t'as vraiment des personnes qui vont partager leur quotidien, ce que eux ont construit, comment ils l'ont fait, etc. que des grandes théories organisationnelles produits où il faut absolument mettre le product top dans une case, ça s'inscrit où, est-ce que ça sert à quelque chose, est-ce que ça sert à rien. Moi je me souviens qu'on m'avait... Tout le monde m'envoyait l'article de Marty Gegan qui disait que product top ça servait à rien, je l'ai jamais lu en vrai. J'avoue que je n'ai pas forcément beaucoup d'intérêt à savoir ce que Marty Gagan dit là-dessus, étant donné qu'il n'a jamais pratiqué ce métier-là, ça ne m'intéresse pas beaucoup pour être honnête.
Terry : Hyper intéressant et c'est vrai que moi mon avis là-dessus c'est que plusieurs fois le sujet théorie versus pratique dans les différents échanges que j'ai pu faire sur le podcast ça revient souvent. Moi la position que j'ai par rapport à ça c'est que faut pas oublier que là où t'es aujourd'hui et du coup les problèmes que t'as c'est ça qui doit te guider. mais la théorie peut permettre parfois, je trouve, juste de se poser et juste de prendre du recul en fait sur ce que tu es en train de faire. Et c'est là où je trouve que la théorie est intéressante, même si tu ne vas pas réussir à appliquer ce que tu as pu lire dans un bouquin, c'est juste que le fait de faire la démarche, de dire attends je vais voir ce que les autres font, je vais essayer de voir ce que la théorie dit, ça te permet toi d'engager une réflexion en fait, et après avec tes pairs, avec les autres qui font les choses, pour derrière trouver ce qui toi va marcher pour toi. Et c'est là où je trouve que les théories sont intéressantes, mais après totalement alignées sur le fait qu'il ne faut pas les prendre... Il faut savoir se les approprier quoi. Ouais, exactement. Et du coup, pour aller vers les ressources ou en tout cas les choses qui toi t'inspirent d'un point de vue pro, qu'est-ce que tu pourrais donner comme article, podcast ou autre lecture ? Et ça peut être des sujets qui n'ont rien à voir avec le produit mais qui toi te nourrissent professionnellement.
Marie : Moi j'avoue je suis plutôt dans l'humain donc c'est plutôt des échanges. J'échange avec beaucoup de personnes. Parfois c'est des gens qui viennent à moi, parfois c'est moi qui vais les chercher. Sur tous les sujets que je lance, généralement je vais toujours Essayer d'aller voir s'il n'y a pas des gens qui ont parlé de ça dans la presse ou sur LinkedIn. Et je rajoute les gens sur LinkedIn et je leur envoie des messages. Parce que je préfère parler avec quelqu'un et avoir des retours d'expérience pour le coup. Donc je n'ai pas de grosses références en termes de podcast ou en termes de lecture, etc. Moi je suis plus... Je vais chercher sur un thème, je vais regarder qui a écrit les articles. Je lis généralement les articles en diagonale et j'envoie des messages aux gens sur Edean. Alors bon, la moitié du temps, ça ne marche pas et la moitié du temps, ça marche. Mais j'ai eu des conversations très intéressantes comme ça.
Terry : C'est de très bons tips, je trouve. Et j'espère qu'en tout cas, le partage d'expérience que tu as partagé sur le podcast aidera d'autres qui se trouvent dans des situations similaires. Et puis, je te dis à bientôt Marie.
Marie : Merci beaucoup, à bientôt.
