Julie Chalumeau, Comment structurer la pratique produit dans une scale-up

Transcription de l'épisode : "Julie Chalumeau, Comment structurer la pratique produit dans une scale-up"

Terry : Salut Julie, merci de prendre du temps aujourd'hui pour parler de produits et en particulier de comment tu structures la pratique produit dans un environnement scale-up puisque tu as vécu à la fois la partie avant en start-up et aujourd'hui tu vis qu'est-ce que c'est que de faire du produit dans une scale-up et structurer un peu tout ça. Donc avant de rentrer dans le vif du sujet, je te propose de te présenter puis de nous dire ce que tu fais aujourd'hui.

Julie : Ok, merci Terry pour l'invitation, je suis ravie de partager mon expérience avec toi et tes auditeurs. Donc pour me présenter, j'ai commencé à bosser en 2011, de mémoire, toujours dans la tech puisque j'avais fait mon apprentissage chez Microsoft et ensuite j'ai évolué plutôt chez des éditeurs de logiciels. Et ensuite, je suis arrivée en fintech, je dirais en 2015, dans une fintech d'une soixantaine de personnes, une fintech parisienne qui s'appelle SlimP, et qui fait du prélèvement bancaire. Expérience super enrichissante, et après trois ans, là-bas, je suis arrivée chez Checkout, mon entreprise actuelle, donc je suis arrivée juste avant le confinement, donc début 2020. Et en fait, quand j'ai joint Checkout, c'était une boîte de 500 personnes. Donc c'était déjà une boîte assez scale-up, tu vois. Mais vu qu'on fait du paiement en ligne, on a profité du boom du Covid. Il y a eu des gagnants et des perdants dans la période Covid et le e-commerce a vraiment énormément grossi, et donc nous avec, et du coup on s'est retrouvé, on est passé de 500 à 2000 en peut-être un an, un an et demi, grand max. On est encore de mémoire 2000 aujourd'hui, on s'est un peu plus stabilisé, on nous recrute quand même un petit peu moins que pendant la période Covid. C'est une fintech qui a été créée en 2012 et moi j'ai rejoint en 2020 pour créer une nouvelle ligne de produits. Donc huit ans après le produit coeur de Checkout, une nouvelle équipe a été créée entre Paris et Londres pour créer une deuxième ligne de produits et depuis on essaye de se diversifier. L'idée de Checkout c'est vraiment d'avoir plein de diversifier vraiment le portefeuille.

Terry : Et du coup le produit coeur à la base c'était quoi ? Et celui sur lequel par exemple là tu travailles ?

Julie : Ouais, alors c'est une bonne question. Le producteur c'est ce qu'on appelle de l'acquisition. Donc c'est tout simplement quand toi tu vas sur un site de e-commerce et que tu payes, c'est la partie brique de paiement d'un site e-commerce, pour la faire courte. Ou donc du coup on signe avec des marchands qui vont acquérir des fonds. Et nous on a créé la ligne qui est un petit peu le spectre d'en face, qui est ce qu'on appelle la partie émission. C'est émettre des moyens de paiement à des entreprises. Donc une carte de fidélité avec laquelle tu peux payer, une carte ticket resto, une carte d'expense, une carte d'une banque en ligne, ce genre de choses. Donc nous on est vraiment sur cette partie émission qu'on a créée donc en 2020 et là on est encore en bêta. Donc tu vois ça fait... On a commencé il y a quatre ans, on est encore en bêta et on n'est vraiment pas encore au niveau de maturité du produit Coeur qui a été créé en 2012.

Terry : Ok, très clair. Du coup, pour bien poser le décor sur l'équipe que tu as aujourd'hui, un peu la taille que ça représente au niveau produit, tech, un peu quels sont, enfin voilà, si tu décrivais un peu l'orgasme produit dans lequel tu t'inscris aujourd'hui, entre ton rôle, les différentes personnes vers qui tu reportes, vers qui tu as en dessous de toi, c'est quoi à peu près en termes de chiffres ?

Julie : Ok.

Terry : À la louche, c'est pas la peine d'être très précis.

Julie : Ouais, non, j'ai pas les chiffres en tête malheureusement. Donc nous, on fait partie de ce qu'on appelle un pilar qui s'appelle Emerging Product. Donc on est le gros emerging product de la compagnie. Donc je reporte un VP product. Et donc moi, dans mon rôle de product lead, je gère 3 squads, 3 PM. Et en tout, je pense qu'on est une quarantaine.

Terry : Ok, très très clair. Donc première chose qui me vient en tête et sur laquelle on avait un petit peu échangé en off, c'est pour toi entre la première grosse différence que tu as eue sur l'environnement startup versus ton arrivée donc dans un environnement scale-up clairement, qu'est-ce qui t'a vraiment frappé et ce sur quoi aujourd'hui tu as travaillé, tu travailles encore en fait en termes d'adaptation et de mise en place d'organisation de produits plus structurés.

Julie : Quand j'étais chez SlimP, on n'était pas très structuré et surtout on avait un CEO qui venait plutôt des sales. Et si tu veux, on n'avait pas de méthode produit, donc on n'avait pas de gestion de nos KPI du tout, on n'avait pas d'OKR, on ne savait pas vraiment ce qu'on traquait, on ne mesurait pas l'adoption de nos features, donc on lançait des features, on ne savait pas si elles étaient utilisées par deux ou quatre personnes. On signe des deals, on a besoin de features, on est réactif, on délivre les features qui ont été demandées par les sales, pour la faire un petit peu courte. une pratique que beaucoup de PM d'ailleurs décrit, dans le sens, on est dans une entreprise sales driven, on ne fait pas de stratégie produit, etc. Et c'est dommage. Je suis assez d'accord, mais dans une startup qui n'est pas encore rentable et qui doit atteindre un certain niveau de, dans notre cas, de volume de paiement, en fait, ça se tient. Et donc, moi, je suis Selon la maturité de l'entreprise, ça ne me dérange pas du tout de travailler dans ce cadre-là. En arrivant chez Checkout, j'ai quand même retrouvé un petit peu des similitudes, parce qu'encore une fois on était la petite boîte à l'intérieur de la grosse boîte, donc on faisait un peu ce qu'on voulait. Ça c'était les deux premières années. Donc la stratégie on n'en avait pas, la vision c'était le CEO qui disait ben en fait pendant 8 ans on a fait telle partie du paiement, maintenant je veux lancer telle partie parce que ça va nous permettre d'être sur tout le spectre de paiement, on a plein de compétiteurs qu'on peut aller chatouiller avec cette offre, ça s'arrêtait là un petit peu et donc nous on nous a dit ben tu crées un MVP en un an. Et quand je dis un an ça peut paraître très long mais en fait vu qu'on est régulé un an c'est pas long en fait.

Terry : Ouais c'est ça pour aussi bien imposer le cadre pour que tout le monde comprenne sur les enjeux dans tout ce qui touche aux finances en fait tu peux enfin MVP ça veut dire un produit qui est utilisable là vraiment on n'est pas sur un sur un POC ou quelque chose que tu peux... Pas du tout ouais. Le MVP dans le monde du secteur financier, qu'est-ce que ça veut dire en fait ? Est-ce que déjà tu peux faire des POC dans ce type d'environnement où en fait t'es obligé directement de passer à l'étape MVP ? Et ensuite, qu'est-ce que ça veut dire que faire un MVP en termes d'étapes au-delà de la partie purement product, mais pour bien que nos éditeurs comprennent ce que c'est que ce monde-là, pour ceux qui viendraient parler.

Julie : C'est une bonne question. Alors, des POCs, oui, on peut en faire. Et je dirais même que c'est assez simple de faire un POC, parce que nous, vu qu'on fait du paiement, on peut faire des AB tests, par exemple. Donc, tu vois, tu vas dire 99% du trafic, il va vers A, 1% il va vers B, je monitore. B marche mieux, ok, c'est un petit POC et on a validé nos hypothèses et on y va. Ça, on peut le faire sur des mini-features. Par contre, nous, notre objectif de base, c'était de devenir ce qu'on appelle un émetteur, un issuer en anglais. Et pour devenir un émetteur, en fait, il faut avoir une licence auprès soit de Visa, soit de Mastercard, soit des deux. Donc nous, on a choisi un seul network pour le début, donc c'était Mastercard. Et en fait, eux, ils t'envoient des specs, donc on parle de dizaines de PDF de 1000 pages chacun, des champs ISO à analyser, enfin bref, un truc vraiment assez costaud. Et en fait, le seul but qu'on a, c'est de... Enfin, le seul. Très complexe, très méticuleux, très long, etc. Donc je ne suis pas en train de dire que c'était simple. Mais dans le sens où on n'a pas eu beaucoup de stratégie à faire, c'est on applique des specs avec tous les use case et à la fin, Mastercard, il te donne un environnement de test. Tu dois faire des paiements dans la vraie vie. Il moniteure si tes paiements dans la vraie vie ont bien marché, qu'il n'y a pas eu de fraude. Et puis à la fin, il te délivre. OK, c'est bon, vous êtes certifié. Donc tu peux pas faire un POC avec ça. Donc ton MVP c'est cet certif. Et pour avoir cet certif, il faut que tu gères le paiement de A à Z, et dans les règles de l'art bien évidemment, en étant conforme puisqu'il y a beaucoup de régulations, il y a du vrai mouvement d'argent, etc. Donc nous ce qu'on a fait pour notre MVP, c'est qu'on a créé des cartes check-out. Donc on s'est dit, à l'époque, on était peut-être 700 dans l'entreprise. On s'est dit, OK, on va émettre des cartes à quelques employés, pas aux 700, mais à une centaine. On a créé des cartes check-out avec un logo, check-out, etc. On a mis 5 euros dessus, 5 GBP, et on a dit aux gens, allez vous acheter un café, un croissant, etc. Et c'est comme ça qu'on a fait notre MVP, et c'est ça qui a été certifié.

Terry : D'accord donc le but du MVP sur cette première année c'était de pouvoir faire certifier en fait ?

Julie : Exactement, c'était notre seul objectif. On avait zéro milestone. C'est là où aujourd'hui je pense que je le ferais complètement différemment. On avait le milestone certification dans un an mais on n'avait pas d'étape à chaque mois, chaque quarter etc. On n'avait pas d'OKR, on n'avait pas de Metrix, on n'avait pas de... Voilà, c'était vraiment juste, il faut qu'on soit certifié et donc qu'on gère tous les test case de Mastercard.

Terry : Du coup, toujours pour rester sur ce sujet du MVP d'un an, je trouve ça assez intéressant dans ces contextes là où en fait tu dois répondre à des specs qui sont très très clairs. Ça me fait penser à une expérience que j'ai pu vivre de travailler sur un produit comme ça dans le secteur du maritime qui était très très régulé, normé, sur lequel en fait il y avait des specs internationales à suivre pour pouvoir répondre derrière avec ce logiciel. Donc c'était pour du tracking de navires. Et du coup la question que je me pose dans ces contextes là c'est quelle est en fait la latitude que tu as d'un point de vue produit pour justement essayer d'innover en restant dans le cadre que tu dois suivre. C'est à dire que quand tu dis au final on n'avait pas de milestone intermédiaire parce que le but c'était clair c'était d'obtenir l'assertif donc voilà fallait répondre à cette spec. Mais tu disais, si je devais le refaire différemment, peut-être que je ne ferais pas tout à fait comme ça. Qu'est-ce que tu entends par là ? Quelles voix tu verrais comme... Enfin, quels éléments tu verrais comme point de... je ne sais pas, d'intermédiaire pour justement tester des choses tout en restant dans ce cadre assez régulé ?

Julie : Alors, je pense que dans ce contexte-là, la créativité produit est assez limitée. Elle l'est beaucoup plus aujourd'hui, mais au début, elle était quand même assez limitée. On n'est pas très créatif quand on applique des specs dans Mastercard ou dans Visa. Je pense que ce qu'on a manqué, c'est peut-être un peu de tactique et de priorisation. Je pense qu'on aurait pu se dire que certains use cases allaient être beaucoup plus utilisés et qu'il fallait les gérer mieux que d'autres. Je te prends un exemple. ce qu'on appelle un purchase, donc c'est un paiement lambda, bon ben ça c'est le gros de notre business. Par contre, le type de paiement récurrent, c'était peut-être pas le premier truc à faire, tu vois. Et puis après t'en as plein, t'as retirer du cash à un ATM, c'est aussi un type de paiement. Bref, il y a des types de paiements, il y en a des vingtaines et des vingtaines. et je pense qu'en fait nous on a pris le test case et on a un peu fait à la suite alors qu'en vrai on aurait pu se dire non mais attends en termes d'adoption commençons par ça, finissons par ça et ça je pense qu'on l'a un petit peu manqué.

Terry : Ouais donc si je rephrase et tu m'arrêtes si c'est pas ce que tu voulais dire mais ce que je comprends c'est que tu es arrivé donc avec une spec en gros bah on te dit voilà c'est ça qu'il faut livrer dans un an et plutôt que de le prendre tel quel là où tu pouvais apporter une vision produit un peu plus intéressante c'était de se dire bah dans la logique produit un des trucs les plus importants c'est de s'assurer des problèmes auxquels on répond et de leurs priorités surtout et donc là ça aurait été juste un ordonnancement des priorités même si à la fin tu les as tous fait de commencer par peut-être des choses qui sont plus impactantes pour pouvoir plus les tester et avoir plus de temps pour les ajuster.

Julie : Et en fait, je pense aussi que si on ne l'a pas fait, c'est parce que c'était compliqué à faire. Vu que tu lis des milliers de pages, tu n'as pas la vue exhaustive des mille pages. Donc en fait, tu apprends des choses au fur et à mesure que tu les implémentes. Et je pense qu'avec le recul, ce que j'aurais aimé faire, c'est, OK, quarter 1, on sait gérer les paiements sur une carte physique. Quarter 2, on sait gérer les paiements sur une carte virtuelle à usage unique. Quarter d'après à usage multiple. Bref, je pense qu'on aurait pu faire un truc comme ça, sauf qu'en fait, vu que tu découvres les specs au fur et à mesure, je ne sais pas si ça aurait été vraiment faisable et réaliste de le faire comme ça.

Terry : Oui, sauf si dans ce genre de contexte, il y a des personnes très métiers. C'est là aussi où, dans certains milieux produits, la connaissance métier, c'est des convictions que chacun a. Moi, je pense que dans certains sujets, tu n'as pas spécialement besoin de l'avoir à partir du moment où tu es capable de l'approprier. Mais dans d'autres secteurs où c'est très régulé et normé, ça peut être un facteur différenciant dans ce genre d'implémentation, d'avoir une connaissance métier en amont pour derrière déjà pouvoir prioriser.

Julie : Exactement.

Terry : Hyper clair sur cette première phase. Donc là, comme tu l'expliquais, donc au final, cette année de MVP, c'était un peu un mode comme tu pouvais le vivre avant en mode start-up, en fait, au sein de la scale-up, mais un peu de manière autonome. Ensuite, la suite, du coup, c'était quoi l'étape 2 après ça et les enjeux qu'il y a derrière ?

Julie : Donc en fait, juste chez Checkout, moi, j'ai vécu deux ères, on va dire. Donc l'ère 2020-2021, où c'était encore la scale-up, on est entre 500 et 1000, on a un comité de direction qui sont, on va dire, des personnes historiques de checkout. Et voilà. Et ensuite, il y a eu une petite transformation. Il faut savoir qu'aussi pendant le Covid et donc pendant ce boom du e-commerce, on a levé beaucoup d'argent, on est devenu la scale-up la plus valorisée d'Europe, on est monté jusqu'à 40 milliards. C'était à l'époque de la folie. Là, on n'est plus à 40 milliards de valorisation. Mais ça c'était vraiment fin 2020, début 2021 je pense, et à ce moment là il y a eu un shift du comité de direction et on a commencé à recruter, enfin le CEO et le board, on commençait à recruter des C-level qui viennent de boîtes énormes. Donc on avait le CTO qui venait de Twilio, le CPO qui vient de Meta, et c'est un peu la même chose pour le COO, le CFO, etc. Et c'est vrai que du coup, eux, ils ont commencé à mettre en place beaucoup plus de structures, et donc nous, on a commencé à adopter les process qu'ils ont commencé à mettre en place, donc on a eu les product ops qui sont arrivés, des PMO pour gérer, on va dire, plus la gestion de projet pour les gros sujets cross-fonctionnels entre équipes, etc. Et donc du coup, on a commencé à shifter vers déjà une roadmap basée sur une vraie stratégie produit et non pas juste trois lignes de devient un compétiteur de telle compagnie. Donc on a fait une stratégie produit qui a été éprouvée. On nous a demandé beaucoup de data, elle a été amendée, etc. Donc à la fin, tu te retrouves avec quelque chose qui est clair. Quel segment de marché je veux adresser ? Quel pays ? C'est quoi mes KPIs, c'est quoi ma North Star Metric, c'est quoi les use case que je vais aborder en premier, blablabla. Et ensuite, ok, dans le go-to market, je commence par où ? Il faut savoir que nous on a une licence au UK et une licence en France qui nous permet d'opérer en gros en Europe. C'est ce qu'on appelle le EEA, bon bref c'est un espace européen des paiements, on va dire ça comme ça. Donc on a vraiment travaillé sur notre go-to-market-stratégie, etc. Et ensuite, en termes de gouvernance, on a mis en place des OKR. Donc ça, c'est relativement classique. OKR semestriel. Et ensuite, on utilise ces OKR pour piloter l'activité. Donc toutes les deux semaines, on a ce qu'on appelle un OKR check-in. Chacun met ses updates en asynchrone et pendant une demi-heure, on voit ce qui résulte, on ne va pas y arriver, ok, qu'est-ce qu'on peut mettre en place pour essayer d'y arriver, etc. Donc on a commencé à mettre ça en place, et surtout mettre de la data. Nous, avant, on avait de la data dans Datadog, ça s'est arrêté là, donc c'était des metrics relativement techniques. Ensuite, on a commencé à tout injecter dans Snowflake, qui ensuite rend tout dans Looker. On a commencé à mettre en place une stratégie de, c'est quoi déjà notre métrix principal en tant qu'issuing group ? Et ensuite, chaque squad va devoir travailler sur sa North Star Metrics, ses Tracking Metrics. Il faut que dans chaque spec, tu te poses la question de quelle metric je suis en train de faire bouger ou quelle metric je veux faire bouger et pourquoi. Donc vraiment, on se pose quand même beaucoup plus de questions et on mesure beaucoup plus l'impact de nos features. Donc ouais, on a commencé à mettre ça en place et ensuite avec ces nouveaux leaders qui sont arrivés, ils ont mis en place notre gouvernance où, outre les OKR, on a commencé à avoir ce qu'on appelle des QBR, donc Quarterly Business Review, où en fait, c'est une review du quarter écoulé. Et en fait, on a deux types. Là, tu vois, il y a les HBR de H1 et on est le 23 janvier. Donc en fait tu as la business review du quarter écoulé, donc c'est un peu la rétro du quarter écoulé, et un mois après tu fais la même chose mais pour le quarter ou le semestre qui arrive, qu'est-ce que je veux faire, pour quelles raisons, qu'est-ce que je mets en place, est-ce que j'ai des problèmes de ressources, de capacités, de dépendance, un bloqueur dans l'entreprise qu'on aimerait bien que le leadership nous aide à débloquer, ce genre de choses. Du coup, on a commencé à devoir shifter. Au début, quand on parlait de notre MVP, on était en cambans. Ne serait-ce qu'un sprint, planifier un sprint et avoir un sprint goal, c'était déjà trop. C'était vraiment au jour le jour. Et là, on devient une product team qui a une stratégie à plusieurs années, des OKR semestrielles, on doit faire des business reviews vers le passé et vers le futur. On a des KPI à faire bouger, enfin bref. Donc c'est tout ça qui a changé en fait.

Terry : Donc clairement un passage quand même assez net d'un mode un peu freestyle ou en tout cas un peu au fil de l'eau versus quelque chose de beaucoup plus structuré comme tu l'expliques.

Julie : Exactement.

Terry : Donc la première question, quand on pense Surtout sur une rupture assez... Alors évidemment j'imagine qu'il y a quand même eu une phase de transition, mais ça reste assez rapide dans l'échelle de temps dont tu parles. Et quand on pense souvent à ce passage-là, on se dit qu'on passe d'une boîte qui est capable de bouger facilement, d'être agile dans le sens propre comme figuré, versus de quelque chose qui peut derrière avoir plus d'inertie, où ça va être plus complexe de créer de l'innovation, de pouvoir lancer des initiatives ou ce genre de choses. Donc je suis curieux de savoir par rapport à ça, qu'est-ce que t'as appris comme bonne pratique de mise en place justement de ces process tout en gardant en maintenant cet aspect très start-up que t'as pu connaître avant et même au sein de Checkout du coup ? et comment t'as travaillé tout ça à ton niveau, au niveau product, pour en faire vraiment une force et pas que tu tombes dans des travers justement de se retrouver après à juste devoir faire des slides et devoir à chaque fois faire remonter ON plus 25 pour faire valider juste le fait que tu changes la couleur d'un bouton.

Julie : Oui, donc en fait c'est une bonne question. Alors je t'avoue qu'aujourd'hui j'ai un peu plus de recul et on a quand même beaucoup avancé dans notre mutation on va dire. Mais c'est vrai qu'au début c'est pas venu sans frustration parce que tu vois on nous demandait par exemple une roadmap annuelle. Alors bien évidemment tu avais le quarter plus 1 c'était high confidence et le quarter plus 4 c'était low confidence. Mais quand même moi je disais mais en fait à notre niveau de développement ça n'a aucun sens de faire une roadmap à un an, je ne comprends pas pourquoi on nous demande ça. Donc tu vois j'étais un peu frustrée de devoir parfois me conformer à certaines instances qui étaient mises en place et je le faisais avec assez peu de conviction. Aujourd'hui ce que je comprends, et ça c'est un learning, c'est que Une roadmap long terme, une stratégie long terme, même si à la fin t'auras exécuté peut-être que 40% de ce que t'as dit, ça donne un outil d'alignement, de visibilité, de storytelling. Et quand tu grossis, nous sur le storytelling on n'était pas terrible avant et on n'est pas beaucoup mieux aujourd'hui, sur ça je l'avoue, J'ai des pairs chez Checkout qui sont arrivés et qui, pendant six mois, n'ont fait que ça. Rassembler les gens autour d'eux, faire de la recherche utilisateur avec une armada de user researchers, embarquer le product marketing dès le début, faire stratégie long terme, des workshops pendant des semaines et des semaines, etc. Et dans ma tête, ils sont en train de brasser du vent. Et en fait, un an après, tu te rends compte qu'ils ont peut-être moins exécuté que nous au sens purement feature, use case débloqué, problèmes résolus pour les clients, etc. Mais en fait, tout le monde sait ce qu'ils font, tout le monde les priorise dans leur roadmap parce que nous, on est quand même très interdépendants des autres équipes. Tout le monde les priorise, tout le monde sait ce qu'ils font, ils sont ultra alignés et en fait, ils sont plus rapides que nous. sur certains aspects et donc là tu vois tu commences à te remettre en question en te disant ok donc en fait il brassait pas du vent sur le moment tu dis bon c'est peut-être pas utile d'en faire autant et en fait à la fin tu comprends le Tu comprends le truc quoi. Désolée, du coup j'ai perdu un peu la question.

Terry : Déjà pour rebondir là-dessus, ce que je trouve c'est hyper pertinent sur ce que tu viens de dire, c'est l'aspect, quand tu as des gros changements d'organisation comme ça, souvent justement dans les boîtes, tech même, tu fais intervenir des fois des coachs agi, tu vas mettre en place pour les boîtes qui fonctionnent en mode Scrum, des fois Scrum à l'échelle, donc Safe qui a pris une place hyper importante dans certaines entreprises. Et du coup autour de ces cadres de travail là tu vas avoir plein de rendez-vous qui vont être présents pour que des gens viennent, que les autres présentent ce qu'ils font et toi parfois quand t'es plus un profil très très exécutant qui veut vite voir du concret tu te dis on brasse encore du vent pour réexpliquer la même chose mais en réalité et encore plus quand tu fais du produit ton rôle c'est de répéter répéter répéter pour que ça rentre et donc je trouve ça hyper intéressant ce retour d'expérience que tu partages c'est à dire de dire bah en fait ouais t'avais ce sentiment là comme beaucoup au début et tu te rends compte à postériori que c'est ces équipes-là qui aujourd'hui ont le plus derrière, enfin qui ont la capacité plus facilement à faire faire des choses à d'autres parce qu'ils sont connus grâce aussi à ce travail d'évangélisation.

Julie : Oui, exactement. Et je pense aussi que, alors encore une fois ça va dépendre un peu du domaine dans lequel tu évolues en tant que PM, mais nous on fait quand même des sujets relativement complexes. Donc moi parfois je me le dis encore, je me dis putain mais ils comprennent rien ou quoi ? mais quand je parle à une autre équipe, mais en fait c'est pas qu'ils comprennent rien, c'est qu'il faut qu'on leur explique et que ce qu'on fait, moi je suis dedans depuis quatre ans, c'est ultra difficile, c'est le produit le plus difficile sur lequel j'ai jamais bossé, et encore je pense que tu vois je connais pas 100% du tout du truc, c'est un puissant fond le truc, et en fait il faut prendre du temps pour évangéliser et éduquer, mais ce travail là il est colossal, Et donc du coup malheureusement, avec le recul je pense qu'on a eu pas mal de... tu vois s'il y avait des trucs à refaire je ferais un peu plus d'évangélisation et d'éducation auprès de mes pères pour justement les embarquer et pour qu'ils, entre guillemets, travaillent pour moi dans le contexte de nos dépendances. Mais après, du coup, nous on n'a pas fait ce choix-là parce qu'il fallait quand même qu'on ait une roadmap à délivrer, des features à sortir, et on a complètement raté cette partie évangélisation. Et là, tu vois, on a eu un challenge. Nous, en fait, on gère tout le parc de cartes, donc les cartes physiques, virtuelles, etc. Bref, on a un PM qui est dédié aux cartes et aux cardholders. Donc les cardholders, c'est toi, le porteur de cartes, le titulaire de la carte. Et souvent en fait, je ne sais pas si tu as une carte Lydia, Revolut ou quoi que ce soit, tu as ce qu'on appelle un système de vérification en ligne. Où on te demande de faire un selfie, d'uploader ton passeport, de parler, enfin bref. Et donc c'est ce qu'on appelle un IKYC. Et donc on a une équipe qui fait ça. Donc on s'est dit super, on va faire une synergie, il faut que vous alliez vérifier nos cardholders. Et pour moi c'était assez simple en fait. Vous avez la stack technique, vous savez le faire, nous on a des cartes. En tant que consommateur tu as déjà subi, enfin subi, pas subi, mais tu es déjà passé par un parcours de KYC. ça devrait être facile, tu fais une réunion, deux heures, un workshop et démerdez-vous, grosso modo. Bon ben en fait non, c'est pas comme ça que ça se passe, parce qu'en fait, avant ça aurait pu se passer comme ça. Aujourd'hui, on est un peu dispatché entre Lille-Maurice, Tallinn, Londres, Berlin, Paris, New York, etc. Donc déjà, on a un peu plus la barrière de la langue, on a la barrière de... Enfin tu vois, un workshop à distance, c'est quand même pas très très efficace par rapport en présentiel. Et maintenant tu as l'égal qui est dans la boucle, conformité qui est dans la boucle, l'équipe risque et en fait tu te dis ok pour ce sujet là si je devais le refaire je passerais en mode projet.

Terry : Oui, pour être sûr de ne pas oublier d'interlocuteurs et de pouvoir tous les mettre et mesurer les points de contact nécessaires avec tous ces différents interlocuteurs, au-delà de la partie purement de production du service de vérification.

Julie : Et je pense qu'il aurait fallu mettre les bonnes personnes autour de la table, et encore une fois c'est des PM, des EM, mais aussi le risque-officeur, le legal manager, des gens qui n'ont rien à voir avec... Tu leur dis le mot use case, ils ne savent pas ce que c'est. Et je pense qu'on aurait dû passer une grosse étape d'évangélisation, de visualisation aussi de tous les use cases, et ensuite on aurait dû passer en mode, voilà, c'est qui l'équipe projet, c'est qui est responsable, tu vois, à faire un RACI, qui est responsable, le countable, informe, etc. Et le faire en mode vraiment, ouais, comité de pilotage.

Terry : Hyper intéressant ces différents retours d'expérience, que ça redonne un peu aussi de poids sur des méthodos qu'on pourrait se dire qui sont d'un autre temps, alors qu'en réalité tout ça c'est complémentaire en fait. Maintenant pour revenir peut-être plus sur la partie produit, en tout cas voir ce que toi t'as mis en place en termes d'orgas, de méthodes aujourd'hui au niveau product, qu'est-ce que t'as mis en place ou en tout cas qu'est-ce qui est en place, qui fonctionne, qui se rapprocherait plus un peu des pratiques produits qu'on peut voir aujourd'hui. et comment ça cohabite aussi avec des pratiques moins product, mais qui sont malgré tout nécessaires, notamment dans une taille telle que la vôtre.

Julie : Donc en fait, nous, on s'est rendu compte d'un truc, c'est qu'on avait nos roadmaps, donc la fameuse roadmap annuelle avec une confidence assez faible sur les quarters éloignés et une confidence forte sur le quarter, tu vois, en décembre, on avait notre Q1 qui était prêt. Sauf qu'en fait, quand Q1 commence, on se rend compte que parfois on doit dérouter certains sujets, on a des bugs assez critiques qui vont nous prendre du temps à fixer, etc. Et en fait, on est rarement à 100% de délivery sur la roadmap sur laquelle on s'est engagé le mois précédent, le début du trimestre. Et donc en fait ce qu'on a mis en place c'est ce qu'on appelle un continuous discovery process, bon je pense que le terme n'est peut-être pas le plus adapté, mais en fait aujourd'hui ce qu'on se dit c'est que donc tu vois un petit peu ce que c'est la méthode du double diamant où t'as vraiment la partie stratégie et la partie exécution, et donc du coup nous les PM on est un peu plus basé sur la partie stratégie, on va dire ça comme ça.

Terry : Peut-être que tu peux la redétailler pour les plus tech et les moins produits de mes auditeurs mais effectivement tu as une première partie sur laquelle tu vas diverger autour. La façon dont tu présentes c'est la stratégie du problème et ensuite tu vas donc brainstormer pour diverger sur le problème, donc première montée du diamant, ensuite tu vas refermer pour converger sur quel est le problème, de la même manière tu vas diverger sur comment résoudre ce problème, donc tu remontes un deuxième diamant et tu refermes en disant on va converger sur comment on va résoudre le problème.

Julie : Exactement et donc du coup moi, dans cette visualisation d'un double losange collé en fait, t'as ce que j'appelle la partie stratégie, où tu vas diverger, tu vas faire de la recherche, collecter des feedbacks, essayer de comprendre le pourquoi, la vraie root cause de pourquoi je fais ça etc. Et ensuite, une fois que le problème il est fixé, qu'il est clair, que je sais quel est mon problème et pourquoi je veux le résoudre, parce qu'il y a peut-être des problèmes qui ne valent pas le coup d'être résolus parce que ça va impacter un utilisateur, voilà. Et ensuite, on va plutôt passer dans la partie exécution, plutôt de délivrerie, et donc là on va passer dans la partie qui est plutôt l'idée chez nous en tout cas par les EM, par les ingénieurs pardon. Et donc du coup, ce qu'on a mis en place dans notre process de continue discovery, c'est qu'on a la première étape qui est récupérer les insights, marché, clients, etc. Donc nous aujourd'hui, ce qu'on fait, c'est qu'on a une équipe de user researchers, qu'on peut booker, entre guillemets, alors peut-être pas, si on veut les booker tous les jours, ça peut être compliqué, mais tu vois, on peut les booker pour une interview par semaine, deux interviews par semaine, etc. Et donc du coup, on leur dit qu'est-ce que je veux comprendre, qu'est-ce que je veux apprendre, quels problèmes je veux creuser, et donc on va avoir un researcher avec lequel on va créer une interview. et récupérer donc du feedback des interviewés et on charge tout dans Dovetail. C'est l'outil qu'on utilise, c'est un enregistrement Zoom que tu charges dans Dovetail et il y a Dovetail qui te digère le truc. Donc on a cette étape-là qu'on essaye de faire avec recherche PM-PMM, Product Marketing pardon. Ensuite, on va avoir aussi ce que j'ai appelé le intake process, donc c'est récupérer les feedbacks du terrain. Donc ce que j'appelle terrain, c'est force de vente, les implementation managers, les success managers, le support, etc. C'est vraiment toutes les personnes qui sont en lien avec le client. Certains sont très techniques, certains très commerciaux, etc. Donc eux, j'ai mis un process en place où ils ont un Google Form à remplir, avec de mémoire une dizaine de questions. Et en fait, ce Google Form, j'ai fait un truc avec Zapier qui fait qu'il est directement injecté dans Jira Product Discovery, donc qui est la partie Discovery de Jira. Et donc du coup, j'ai un board où j'ai tous les Google Forms qui deviennent des tickets, des tickets Jira tout simplement. Et là, tu vas leur assigner Squad 1, Squad 2, PM1, PM2. Et puis après, bien sûr, tu as toute la section commentaires qui te permet d'interagir avec les gens qui ont soumis le feedback. Donc ça, c'est pareil, on a ce qu'on appelle un Product Insight Meeting mensuel, où en fait, on va rassembler tous les gens qui ont soumis des feedbacks, des feedbacks récents. Donc chaque mois, tu en as quelques-uns, mais on n'en a pas 400 aujourd'hui. Et on va regarder ça avec tous les PM, qu'est-ce qui vaut le coup, qu'est-ce qui vaut pas le coup, qu'est-ce qui est prioritaire, qu'est-ce qui est pas prioritaire, etc. Et donc ça, ça va aussi nourrir la partie, on va dire plutôt, quels problèmes on aimerait résoudre prochainement. Ensuite, on va bien évidemment, tout ça est couplé bien évidemment avec la définition semestrielle des OKR en lien avec la stratégie, etc. Et ensuite, une fois qu'on a tout ça, on est censé être capable de pondre ce qu'on appelle des Candidates. Donc les Candidates, c'est pas forcément ce qu'on veut faire en Q1. c'est des candidats que j'aimerais faire en Q1 et j'aimerais en discuter avec l'équipe produit. Donc en gros, c'est les EM et les PM. Et chaque mois, on a ce qu'on appelle un Candidate Review où chaque PM va venir avec un candidate ou deux en disant voilà, j'aimerais proposer tel problème à résoudre. Donc concrètement, c'est quoi ? C'est un One Pager sur Confluence, peut-être deux pages. Et là, on se concentre beaucoup sur le pourquoi. Le pourquoi, l'EQPA que je veux faire bouger, etc. On n'est pas du tout dans la spec de... Ouais, on n'est pas dans la liste des Requirements Produits. Et donc là, en fait, dans cette audience-là, on réfléchit, est-ce que c'est important de le faire en Q1 ? Oui, pourquoi ? Parce que ça va impacter tel client qui fait 50% de notre volume, etc. Et donc, vu qu'on a ces Candidates Discovery chaque mois, Si chaque PM soumet deux candidats par mois, à la fin, il a ses six candidats. Sur les six candidats, on en a priorisé quatre. Et en fait, il a sa roadmap qui est prête de façon assez naturelle. Et tout ça, encore une fois, nourrit par la recherche qu'on a faite juste avant, les feedbacks utilisateurs qu'on récupère du terrain avec les Google Forms, etc.

Terry : Tu voulais enchaîner ou déjà première poste sur ce que tu as en tête sur cette première partie là donc hyper clair sur la structuration de cette cette phase de discovery du coup derrière d'aller enfin de création de roadmap court terme. Tu as mentionné du coup les EMS c'est les Engineering Managers si je dis pas de bêtises. C'est un rôle que j'ai vu apparaître dans différentes boîtes mais qui n'est pas omniprésent et du coup je suis un peu curieux de comprendre vous chez vous qu'est-ce que c'est que les engineering managers et comment ils travaillent avec les PM parce que de ce que tu viens de me dire j'imagine qu'il n'y a pas trop de problématiques côté produits d'alignement une fois que ces problèmes et cette roadmap est définie de par tout ce process que tu viens de dérouler. En revanche, plus côté après delivery, est-ce qu'il y a des sujets parfois de questions du pourquoi, justement de challenge auprès de vous, équipe produit, de pourquoi est-ce qu'il faut qu'on délivre ça ou est-ce que globalement le process fait qu'en fait ça fonctionne ? Mais du coup, par rapport à ça, vraiment pour moi, le rôle central, j'imagine, c'est aussi l'engineering manager et je suis un peu curieux de comprendre qu'est-ce qu'il fait chez vous, c'est quoi un peu les profils de ces EM ?

Julie : Alors chez nous, déjà l'équivalent du PM, c'est l'EM. Donc on essaye typiquement, tu vois, pour avoir des squads cohérents, on essaye d'avoir un EM et un PM. Par contre, si on a un SPM, Senior PM, ça serait bien d'avoir un Senior EM. Enfin bref, tu vois, on essaye d'avoir, c'est comme le VP Product qui va avoir en face le VP Engineering. sinon ça crée des décalages et je trouve que c'est assez toxique et néfaste pour le bien-être de tout le monde. Donc l'EM, sa fonction principale c'est gestion du delivery et gestion d'équipe. Donc c'est un manager, c'est un people manager qui fait des performances review, ce genre de choses quoi. Par contre, selon les équipes, parce qu'on a des squads quand même qui font 12 ou 15 personnes, on va aussi avoir des staff engineers qui eux vont peut-être plus avoir le rôle de tech lead sur des projets complexes, des projets transverses. Ça va être des gens très techniques. Par contre, gérer les gens, gérer ce qu'ils font, gérer l'exécution, c'est pas trop leur force. Donc on a un petit peu ce duo-là. Juste pour une aparté sur ça, moi je me suis beaucoup battue pour qu'on essaye de sortir de plus en plus du delivery. Alors ça peut être soumis à débat. Dans la mesure où aujourd'hui on est dans une boîte qui grossit, où on doit parler en tant que PM à beaucoup de gens dans l'entreprise, Je tiens à ce qu'on parle à des clients très régulièrement, etc. Et qu'aussi, comme je disais en préambule, on nous demande quand même de faire des business reviews, des choses qui prennent quand même beaucoup de temps. J'essaye que les PM soient de moins en moins dans le delivery, c'est-à-dire qu'une fois que les candidates Discovery sont faits et donc que chaque... Tu vois là par exemple on a un Candidate Discovery qui a eu lieu le 15 janvier. C'est le premier de l'année, tout le monde revient de vacances. Bon bah le 15 janvier t'as au moins un ou deux sujets à présenter pour Q2. Et ça nous force aussi à éviter un peu le last-minus que parfois on a où on close la roadmap du quarter deux jours avant un peu en urgence tu vois. Donc ça nous met aussi une cadence un peu plus régulière. Et donc du coup une fois qu'à la fin, le 15 mars par exemple, tu dis ok donc j'ai présenté 6, 8 candidates, il y en a 2 qui n'ont pas trop d'intérêt, enfin où on m'a challengé et je vais les dropper, ok donc il m'en reste 6. Les 6 ok je les priorise selon mon... en tant que PM ce que je pense. Et là le M après il prend le lead. il va bien évidemment estimer, etc. Mais c'est lui ensuite qui va faire vraiment toutes les faisabilités, tic et gira, acceptance criteria, test case avec le QA, etc. Le PM est assez peu involved là-dessus.

Terry : Donc pour faire le parallèle, donc pas métier mais rôle, et j'insiste sur la distinction en tout cas de mon point de vue, il prend ce rôle dans, si c'est du scrum derrière, de product owner sur la partie vraiment délivrée.

Julie : Exactement. On a des PM qui vont en daily stand-up, d'autres qui ne vont pas. Je n'ai pas de grande conviction sur ça. Après, on demande beaucoup à nos EM, c'est-à-dire qu'ils doivent comprendre le métier. Déjà, ils sont experts, alors peut-être pas comme nous en termes, dès qu'on parle de compliance légale, etc., ils sont perdus. Mais sur le produit pur, ils connaissent très bien. Et c'est eux qui délivrent en fait, donc il faut qu'ils comprennent au maximum et on n'est pas du tout dans la feature, enfin en tout cas moi je ne veux pas qu'on soit dans la feature factory de j'ai créé des tickets Jira, tu les exécutes, tu comprends la moitié, ben tant pis pour toi, voilà. Et ils savent pas vraiment pourquoi ils font les trucs. Et c'est pour ça que souvent j'essaye de les inviter dans les interviews clients. ils parlent jamais, assez rarement, quelques-uns parlent mais sinon ils sont quand même très observateurs, mais ils sont toujours très contents d'aller voir des clients et ça c'est super important pour moi. Et donc on essaye de changer, d'avoir ce shift-là où on évite de « spoon feed » les ingénieurs et de leur donner vraiment, ok voilà, c'est le truc que tu dois faire. Et ça c'est pas que moi, c'est « check out » au global et moi je pousse aussi beaucoup sur ça.

Terry : Mais du coup, vous le faites, enfin, de ce que je comprends, pour être sûr de bien comprendre, là, vous le faites déjà grâce aux engineering managers, ça, en fait. C'est-à-dire que l'engineering manager, il a ce rôle-là, justement, d'éviter aux product managers de devoir se retrouver à écrire tous les tickets...

Julie : Exactement.

Terry : ...Avec les acceptances carrières. Donc, quand tu dis on évite un peu de leur donner à manger directement aux ingés, tu veux dire aussi vous faites venir dans les interviews parfois les devs qui sont, eux, en charge de.

Julie : La delivery, c'est ça que tu veux dire ?

Terry : Exactement.

Julie : Et tu vois, c'est aussi, on est passé de specs où tu vois, on avait, je sais pas, dans Confluence, un product specification de feature A qui pouvait faire 15 pages. à aujourd'hui on fait deux pages, peut-être trois max tu vois. Et ensuite c'est eux, bien évidemment il y a des questions, bien évidemment t'es là pour les accompagner, mais le travail de petite souris, du PM souvent junior qui prend des specs de 30 pages, on l'a fait pour notre fameux MVP, mais on le fait plus aujourd'hui.

Terry : Ce rôle qui prend le nom d'engineering manager que j'ai déjà vu autre part, il y a d'autres boîtes qui appellent ça technical, product owner, mais vraiment ce travail de petite souris comme tu dis et aussi de manager la productivité de l'équipe. C'est vrai que je trouve ça hyper intéressant. Après, on rappelle bien le contexte, on est dans un contexte de scale-up, vous êtes plus de 2000 du coup. Après, dans un environnement, comme tu le disais avant, quand tu es startup, tu fais un peu tout, il faut délivrer parce que de toute façon, il faut soit trouver ton marché, soit réussir à faire entrer du cash. Mais dans cet environnement scale-up, le rôle du PM, il est beaucoup plus sur la partie strat, sur la partie compréhension business. Et donc par rapport à ce vers quoi tu veux pousser aujourd'hui les PM à aller, c'est quoi un peu les process qui sont en cours de mise en place, les choses qui fonctionnent déjà pour aller chercher plus cet aspect plus business, l'aspect plus stratégie d'un point de vue rôle de PM chez vous ?

Julie : Alors ça c'est intéressant comme question. Juste avant je vais quand même, si tu me permets, un peu élaborer sur la deuxième partie du double diamant qu'on a assez peu abordé. Donc une fois qu'on a fait nos candidates discovery, que nos problèmes sont clairs, qu'on a collecté le feedback, etc. ça passe en ce que j'appelle l'exécution. Et là bon il y a le classique backlog refinement, etc. et on fait, tu vois, un delivery plan review, où en fait, on a les roadmaps de tout le monde, les roadmaps, on va dire, de delivery de tout le monde qui sont sur un Gantt chart, et on voit que tel sujet prend deux semaines de plus, du coup, telle dépendance prend deux semaines de plus, etc. Donc ça, on fait quand même un check-in de delivery. Moi, typiquement, j'y vais pas. J'attends à ce que, si à la fin du quarter, on a délivré que 40%, je sois au courant. Mais tu vois, j'essaie de ne pas trop m'impliquer dans cette partie delivery pur. Et ensuite, on a le classique démo, etc. Bon, après, les démos dans notre contexte, ce n'est jamais très fancy, ce n'est jamais une mobile app avec des boutons, etc. Mais c'est quand même très utile de le faire. Et donc, juste pour revenir sur ce que tu disais, rappelle-moi ta question, je suis désolée.

Terry : Non, après moi, là, j'ouvrais sur le sujet, tu disais que pour toi, les PM, il faut qu'ils aillent plus vers les sujets Strat, Business, et donc moins, enfin qu'ils soient moins pris par la delivery, ce qui est déjà le cas, mais c'est de continuer à pousser vers ça, et donc ma question, c'était autour des process que tu as déjà mis en place, que vous avez en place, et ceux sur lesquels vous travaillez pour permettre aux PM, du coup, de vraiment aller encore plus vers ces axes Business et compréhension utilisateur. Et tu voulais avant d'aller sur cet axe là, vraiment finaliser le sujet de la deuxième partie du diamant, donc la partie delivery.

Julie : Oui, qui là du coup est suffisamment, je pense, à part si tu as.

Terry : Des questions... Non, non, pour moi c'est très clair. Pour aller vers ce sujet là, les PM plus orientés... qui se détachent le plus possible de la délivrer. Moi ce que je retiens dans ce que tu disais c'est grâce à ces logiques de roadmap très court terme et du coup derrière de pages confluences qui vont être assez macros qui vont permettre ensuite à l'engineering manager d'aller faire ce travail beaucoup plus détaillé et d'en sortir des user stories avec les critères d'acceptance etc. modulo des interactions évidemment, ça c'est un premier point donc de pouvoir se reposer au max sur l'engineering manager grâce au process de continuous discovery que tu viens de décrire. Est-ce qu'il y a d'autres axes comme ça sur lesquels aujourd'hui vous avez des points particuliers en fait sur votre façon de travailler au niveau produit ?

Julie : Alors on a mis des choses en place, après je suis assez convaincue que chaque bon PM a un trait principal, une appétence principale, un type de profil ou de sous-profil on va dire. C'est une zone de génie. Exactement. Et le problème, c'est que c'est difficile pour la personne, justement la petite souris qui, il y a 4 ans, digérait des milliers de pages de specs extrêmement complexes et qui les exécutait parfaitement bien. Pour moi, c'était le sujet le plus complexe qu'on ait eu à gérer depuis 4 ans, tu vois. Ce profil-là, mettre des gens autour de la table et animer un workshop cross-fonctionnel avec des équipes légales, du product marketing, etc. J'ai essayé de faire rentrer dans les cases, mais je me rends compte qu'il faut recruter aussi une diversité de profils. Parfois il faut recruter, selon ton niveau de maturité et ce que tu dois faire, il faut recruter un exécutant, parfois un évangéliste, parfois les deux, mais je pense qu'on a du mal à rentrer dans des cases. Donc nous ce qu'on a mis en place, c'est vraiment dans ce processus-là, sortir de la spec en fait. Moi aujourd'hui je veux plus de spec, j'aimerais qu'on tende au maximum à pourquoi on fait les choses et je résous quoi comme problème. Au début il n'y avait pas de problème à résoudre, c'était on fait pas d'issuing, on va faire issuing, on fait tu vois et on a un an pour le faire. Aujourd'hui, ça résout quoi ce que tu fais ? Si on le fait pas, quel est le problème ? Ah ben on va mal gérer tel truc. Ok ? Mais le tel truc qu'on va mal gérer, tu l'as quantifié ? Pas vraiment. Déjà quantifions-le et si en fait ta feature elle va résoudre 1% du volume, Bah on s'en fout, autre guillemet, je ne dis pas qu'on s'en fout mais ça va aller en fin de priorisation. Et donc on essaye vraiment plus de tendre vers comment tu priorises mieux et comment tu poses ton problème. Et donc d'ailleurs, j'en ai pas parlé mais on priorise avec Rice, on n'a pas réinventé la roue donc Reach, Impact, Confidence et Fort. Et vraiment le reach est très important parce que ah oui ça va être pour tel client, oui mais si tel client il fait 3% du volume, est-ce que c'est la priorité tu vois ? Parfois ça peut être la priorité parce que stratégiquement il ne fait que 3% du volume mais c'est le use case principal sur lequel on a décidé d'accélérer sur les six prochains mois. Donc stratégiquement il faut qu'on y aille. Mais j'essaye vraiment de challenger au plus les PM et certains n'ont pas du tout besoin d'être challengés sur ces sujets parce que Encore une fois, ils ont été recrutés sur un profil peut-être un peu plus stratégique, un peu plus business. Mais avec d'autres, c'est plus compliqué. Mais s'ils n'étaient pas là, en fait, on ne saurait pas faire de paiement.

Terry : Merci pour ce partage que je trouve hyper intéressant. C'est-à-dire que ce que je retiens, c'est là, dans cette stratégie de ramener les PM sur une partie plus business, en fait, au-delà de ça, c'est vraiment de les ramener sur le pourquoi avant même d'aller construire des solutions, c'est-à-dire vraiment le problème auquel on veut répondre et s'assurer que ce problème-là Comme tu viens de le dire, il y a un impact pertinent pour la boîte derrière, que ce soit en termes de reach, de business ou stratégie et autres. Et en même temps, tu as bien rappelé aussi qu'il y a des phases en fonction de là où tu es dans une boîte que des fois tu n'as pas tant besoin que ça de challenger. Pourquoi ? Il faut plus challenger comment on arrive à sortir les features parce qu'il faut la faire. Et donc la nécessité d'avoir ces deux profils et aussi d'avoir des profils en fonction des moments de l'entreprise, il y a différents profils nécessaires. Je trouve ça hyper intéressant parce que souvent on peut avoir tendance à caricaturer le rôle du product manager idéal qui est juste sur le focus, qui se concentre uniquement sur le pourquoi, sur le problème, qui va vers des rôles plus stratégiques. Mais des fois en fait quand tu es au tout début d'une boîte et qu'il faut déjà aller trouver, prouver ton marché ou même créer le produit que tu es en train de vendre, il va falloir juste te concentrer en fait sur des phases de livraison, de delivery et donc la complémentarité en fait des deux je trouve qu'elle est hyper intéressante et c'est bien de le rappeler aussi parce qu'on peut avoir tendance des fois à trop opposer les deux donc je trouve ça intéressant ce que tu viens d'expliquer par rapport à ça.

Julie : Et je pense aussi que le challenge c'est de comprendre Quel type de PM tu as besoin de recruter à l'instant T ? Je prends un exemple un peu classique de la start-up où en fait le fondeur, il a trouvé son market fit, il commence à avoir de l'attraction, c'est lui qui porte la vision, c'est lui qui porte le business, c'est lui qui porte la stratégie. Il n'a pas besoin de head of product, tu vois. Enfin, à mon sens, je ne sais pas, je n'ai jamais fondé de boîte, donc peut-être que je me trompe. à un certain niveau de maturité, tu as besoin d'un exécutant qui va exécuter ta vision, ta stratégie, qui va digérer les comptes rendus d'interview client que tu fais à longueur de journée. Il va avoir besoin de ça. Tu n'as pas besoin de recruter un head of product ou un VP product à ce moment-là. Et parfois, j'ai l'impression qu'il y a des start-up qui... Ah ok, on a levé 20 millions, bon ben on va recruter un codire. Si tu portes déjà le produit en tant que CEO, je pense que t'as pas besoin d'avoir ça. Et je connais pas mal de gens qui... Bah tiens, ça c'est un petit coup de gueule. Qui en fait, t'as facilement le titre dans les petites boîtes, je suis VP. Mais en fait, dans les faits, tu fais du ticket Gira, tu vois. Donc oui, le titre ça fait plaisir à ton ego. Est-ce que tu as un vrai salaire de VP ? C'est débattable. Et en fait, dans les faits, tu fais du ticket Gira et je trouve qu'il y a parfois une dissonance entre ce qu'on veut recruter et ce qu'ils font ensuite par la suite. Et en fait, ça crée juste des déceptions.

Terry : Ouais, ça parait hyper intéressant, parce que ce que tu touches du doigt aussi, là c'est un autre aspect qui revient de manière différente, mais assez régulièrement sur le podcast, c'est savoir s'approprier les choses, c'est-à-dire même quand on parle de méthodes, de bonnes pratiques, quand on partage, donc le but c'est de partager du retour d'expérience sur ce podcast aussi, mais il faut pas oublier qu'après, tous ces retours d'expérience, il faut se les approprier dans son contexte et voir ce qui marche pour soi, c'est-à-dire prendre, picorer à droite à gauche des choses, des bonnes idées, mais après se les réapproprier, et comme tu viens de le dire, en fonction de... des boîtes de la core team que tu vas avoir dans nos entreprises, ce n'est pas parce que tu es passé de ta série A à ta série B que par définition il faut que tu aies tel type d'organisation. Ça dépend vraiment de comment tu fonctionnes aussi en interne. Je trouve ça hyper intéressant. Avant d'aller sur mes questions de fin et même sur l'ouverture autour de l'évolution du rôle de PM chez Checkout, est-ce qu'il y a un point en particulier que tu voudrais accentuer, qu'on n'a pas traité ou est-ce que tu trouves qu'on a fait un tour assez complet ?

Julie : Non, je pense qu'on a fait un tour assez complet, je pense qu'en retour d'expérience un peu plus philosophique, je pense que c'est important quand on a l'opportunité de rester dans une boîte assez longtemps, moi ça fait quand même 4 ans que j'y suis et dans notre milieu c'est beaucoup, c'est intéressant de voir les différentes phases de l'entreprise. Et c'est aussi intéressant de voir sa personne, tu vois. Moi, il y a des phases, je ne m'en cache pas, où j'ai été quand même assez frustrée. Justement, quand on a eu ce shift-là, où on nous demandait de faire beaucoup de... Il y a des reviews dans tous les sens. Je me disais, putain, je fais des documents à longueur de journée, je ne fais que ça. Des slides, des Google Docs, des slides, des Google Docs. Et j'étais très frustrée de ça, et j'étais assez vocale, d'ailleurs, j'en parlais beaucoup. aux gens auxquels j'avais accès et en fait avec le recul tu t'apprends et tu dis ok en fait on n'a pas recruté des débiles a priori et en fait tout ça ça a un sens et même si ça se met en place ça met un an à se mettre en place au bout d'un an tu récoltes les fruits et tu vois pourquoi on en est passé par là on a fait des erreurs bien évidemment il ya plein de choses qui seraient Mais je trouve que c'est intéressant d'avoir l'opportunité de rester longtemps dans une boîte pour pouvoir avoir ce retour d'expérience-là, parce que je serais partie il y a un an et demi, je n'aurais pas ce discours-là.

Terry : C'est hyper intéressant aussi et je trouve que c'est un discours qui vient un peu aussi challenger le statu quo entre guillemets où ce qu'on peut voir c'est que dans le monde actuel on a tendance à vraiment aller picorer à droite à gauche et pas rester justement dans les entreprises. ce qui pose des problèmes derrière aussi, même pour les boîtes elles-mêmes, et puis toi en tant que personne, parce que du coup tu te détaches de plus en plus des fois du projet auquel tu viens, tu viens juste chercher pour toi, et je trouve ça intéressant ce que tu dis, c'est-à-dire qu'en restant, tu vas aussi apprendre beaucoup plus peut-être sur des choses, et ne pas te rester bloqué sur des convictions qui en fait étaient peut-être pas vraies, et que tu réalises a posteriori en restant qu'en fait tu t'étais trompé et t'apprends. Laissez le temps au temps. C'est un peu évident, mais je trouve que c'est bien de le rappeler. Donc merci pour ce retour-là, parce que je trouve que c'est assez rare, en tout cas dans notre écosystème, comme tu l'as dit. Donc 4 ans, c'est déjà bien. Et si j'ai eu en tête une personne de chez Agora Pulse que j'ai eue sur le podcast, Sébastien Gendron, qui lui, je crois que depuis 10 ans, il est chez eux ou quelque chose comme ça. et qui a grandi avec la boîte. Je l'ai en tête parce que c'est rare d'avoir des profils comme ça qui restent assez longtemps. Et pourtant, ça te permet derrière d'apprendre beaucoup de choses. Pour ouvrir sur l'évolution du rôle de PM chez vous, chez Checkout, avant d'aller sur mes deux questions de fin, qu'est-ce que c'est ? Comment tu construis ça ?

Julie : Alors, du coup, comme je le disais, au début, on a recruté des PM qui étaient très dans l'exécution, qu'on aurait pu appeler vraiment, tu vois, technical PM, product owner, voilà, et qui étaient là pour vraiment servir l'objectif long terme sur un an de être certifié et devenir un issuer, un émetteur certifié. Et donc, c'est ce que j'appelle, moi, un PM de délivery. et on en a dans l'équipe, et c'est les personnes... Je ne vais pas faire de ranking des profils, mais c'est les personnes qui sont les plus expertes. Et dans notre métier, l'expertise, c'est extrêmement important. Encore une fois, on parle de fraude, d'authentification des cardholders, de compliance, de régulation, bref, c'est très complexe. Et en fait, ces PM de delivery, leur skill set, c'est qu'ils vont être très méticuleux dans l'exécution des tâches et très experts. Il en faut. En tout cas chez nous, il en faut, c'est primordial. Ensuite, on va avoir des PM de... ce que j'appelle les PM de stratégie. Donc ça va être plutôt les PM qui vont plutôt avoir une appétence pour la recherche utilisateur, aller parler aux clients, savoir prioriser à long terme, savoir vraiment mesurer les impacts... savoir faire des paris, ok, on va faire un pari sur Q1, on va tenter ce truc-là, si ça ne marche pas. Enfin voilà, vraiment être dans les tactiques de product management. Et ensuite, on va avoir des PM cross-fonctionnelles. Et donc c'est les fameux sur lesquels je... Pardon, les fameux que je jugeais un petit peu il y a quelques années et que maintenant je revois ma position. Les PM cross-fonctionnels, leur skillset, c'est vraiment influencer sans autorité, savoir aligner les gens, les mettre autour de la table, faire de l'éducation, d'évangélisation, énormément de storytelling, et passer sa vie en workshop avec des employés de la boîte, etc. Et je pense qu'on a besoin des trois. Et le travers, c'est qu'il ne faut pas avoir que de l'un, que de l'autre ou que du troisième. Je pense qu'il faut vraiment savoir ce que tu as dans ton équipe et te dire ok, là je manque peut-être de la skills cross-fonctionnelles, je vais aller chercher ce type de profil-là parce que j'ai déjà les deux autres types entre guillemets. Et je pense qu'on a fait une petite erreur, je parle pas au niveau de issuing mais au global, à un moment donné on a recruté beaucoup de gens qui étaient très bons en cross fonctionnel et c'était la fameuse période où on passait notre vie en comité de pilotage. Et je pense que oui, c'est bien d'avoir ça, mais il ne faut quand même pas oublier qu'on fait quand même du produit, donc il faut quand même qu'on ait une vision, qu'on ait une stratégie, qu'on sache prioriser correctement, etc. Donc je pense que voilà. Pour ouvrir, je pense qu'il y a trois teintes, en tout cas chez Checkout, j'ai l'impression qu'il y a ces trois teintes-là, et qu'il faut un mix des trois pour faire la super équipe. Et juste, je sais qu'il y a Shreyas Doshi qui lui a son propre framework, à lui, et lui c'est le visionnaire, celui qui a la vision, mais par contre manager des gens il ne sait pas faire. Lui il a la vision, c'est un peu le fou fou, le savant fou. Le visionnaire, l'opérateur, donc l'opérateur c'est un peu le cross fonctionnel dont je parle, et le crafter. Et le crafter c'est celui qui va vraiment être fort en product management. créer des métriques, savoir prioriser, etc. Et puis après, donc ça c'est vraiment le crafter qui connaît très très bien la pratique Product Management. Le visionnaire, bon, il a la vision mais il a du mal à embarquer les gens derrière. Et l'opérateur qui va être plutôt là pour aligner les gens sur des sujets.

Terry : Cross-Fonctionnels, etc. hyper intéressant et je pense que ça va parler à pas mal d'autres personnes qui sont en tout cas dans ces environnements scale-up. Je rappelle bien sur le contexte de l'épisode, c'est aussi dans un environnement scale-up ce dont on parle, donc ce type de scission aussi, tu peux le mettre en place quand tu commences à atteindre je pense à une certaine taille critique. quand t'es une dizaine de personnes, ça va être compliqué d'avoir un peu ces trois silos, mais hyper pertinent et intéressant là-dessus. Du coup, pour aller vers mes deux questions de fin d'échange, la première, c'est si t'as une conviction forte avec laquelle tu te retrouves en général en désaccord avec tes pairs.

Julie : Je pense que tu vois, pour reboucler avec ma remise en question entre guillemets récente, Je pense que les PM on est souvent en désaccord avec le côté sales-driven d'une boîte, dans le sens je ne veux pas faire du produit dans une boîte sales-driven. Ça dépend ce qu'on veut dire par sales-driven, si c'est juste délivrer de la feature de façon réactive sans avoir même parlé au client, je suis d'accord que c'est vraiment pas pérenne. Par contre, on est là pour servir des clients, on est là pour diversifier notre portefeuille produit, diversifier nos use case, etc. Et on est là vraiment pour... Alors encore une fois, nous on fait du paiement, si demain il faut que je fasse une feature pour faire des carottes, bien évidemment, ça n'a aucun sens. Mais je trouve que dans un certain cadre, être sales driven, C'est pas mauvais. Et je dis ça en tant que PM et je l'entends pas souvent. Je pense que c'est important de... Si tu as un use case qui répond quand même à ton cœur de métier, ok, il y a peut-être 20% des features du RFP que tu ne fais pas aujourd'hui. Mais en fait, si ces features là, elles rentrent dans ton cœur de métier, et que ça peut servir un client qui, à la fin, va te rapporter du volume, parce qu'à la fin, il faut quand même qu'on... Enfin, c'est ça aussi notre succès, c'est faire rentrer de l'argent dans l'entreprise, on va pas se le cacher. Et ça, on a aussi, je trouve, assez... On n'en parle pas beaucoup, de la monétisation de nos produits, j'ai l'impression, et du fait qu'en fait, il faut qu'on apporte du business à la boîte. Et je pense qu'avant j'étais beaucoup en désaccord avec ce côté un peu feature factory parce que j'ai peut-être vécu un peu l'extrême où c'était vraiment en réactif, il faut faire tel report pour tel client et c'est du sur-mesure et donc du coup tu te retrouves avec que des reports sur-mesure et c'est Pascalable et c'est une usine à gaz. Mais quand c'est correctement fait ou en fait dès le début tu intègres dans ta stratégie d'avoir au maximum de modularité sur ta plateforme, d'éviter de faire justement du sur-mesure mais que donc du coup tu intègres dès le début que tes reports il faut qu'ils soient customisables par le client, Et ensuite, tu pars sur les bonnes bases et tu peux te permettre d'être un peu plus sales-driven. Donc ça c'est plutôt un désaccord. Je sais pas si je suis très claire dans ce que je dis.

Terry : C'est hyper clair et ça résonne. Je parlais tout à l'heure d'une personne qui est restée longtemps aussi, de Sébastien Gendron que j'ai eu sur le podcast, qui est chez Agorapulse. On a parlé de ce sujet-là, du sujet product-led versus sales-led, et en fait il n'y a pas vraiment de débat là-dessus. Tu as besoin de faire du business donc il faut vendre, et après c'est en fonction aussi des étapes de l'entreprise où tu vas avoir des modes d'organisation qui vont différer en fonction de là où tu en es. Et je rejoins ce que tu dis sur le fait de ne pas se dire parce qu'on fait du produit, il faudrait idéalement être product-led, c'est-à-dire on n'a pas besoin d'aller envoyer des commerciaux, le produit est tellement bon qu'en fait il va se vendre tout seul, encore moins en 2024 et encore moins dans les années à venir avec toutes les technos aujourd'hui qui sont à la disposition de tous pour créer des produits assez cool rapidement. Je pense qu'au contraire tu vas avoir de plus en plus besoin aussi d'aller te démarquer d'un point de vue marketing, d'un point de vue vente. Mais l'important c'est de réussir à mieux collaborer et à bien collaborer entre ces mondes-là, pure vente, versus ceux plus construction, strat, côté produit. Et cette collaboration passe par différents points de contact et des moments dont on parlait juste avant. Je pense qu'il ne faut pas faire d'opposition entre product-led et sales-led, je.

Julie : Ne.

Terry : Connais pas de boîte qui soit purement l'un ou l'autre. C'est comme souvent, c'est des cadres de travail qui permettent un peu de poser des bases et du vocabulaire commun. Mais après, quand tu les appropries et quand tu en discutes avec tes pairs, tu te rends compte que personne ne le fait tel quel, mais a pris des bouts à droite et à gauche. Et donc, on est toujours sur l'appropriation aussi de ces pratiques là. Donc très très clair et donc sur ma dernière question c'est un peu les ressources, les choses qui toi te nourrissent intellectuellement, dont tu t'inspires, qui te servent dans ton cadre pro mais qui sont pas nécessairement des choses, pas nécessairement des livres ou podcasts mais des choses qui te nourrissent intellectuellement.

Julie : Alors, moi j'écoute beaucoup de podcasts et pas que des podcasts. J'écoutais beaucoup de podcasts produits à l'époque, là un petit peu moins. Mais ouais, j'écoute beaucoup de podcasts sur lifestyle, santé mentale. Je fais aussi un petit peu de méditation, tu vois, et je pense que ça m'aide à... Tu vois, je pense que le lâcher prise, c'est quelque chose que de base, c'est pas vraiment du tout ma nature de lâcher prise. Et via la méditation, des podcasts de santé mentale, etc., j'apprends à lâcher prise de plus en plus dans ma vie perso et aussi dans ma vie pro. Et donc du coup, je pense que c'est aussi concomitant avec le moment où je me suis dit, en fait, je suis dans cette boîte, elle me plaît, il y a peut-être des sujets sur lesquels j'ai eu des sujets de frustration, mais en fait, est-ce que je les contrôle ? Bah non. Et d'ailleurs, c'était un... Désolée, je fais une petite aparté. C'était notre CEO justement pendant la récession post-Covid qui a commencé avec la guerre en Ukraine, etc. On a eu comme beaucoup de boîtes une petite baisse du chiffre d'affaires, etc. Et dans tous ses discours, il disait en fait il y a des choses qu'on peut contrôler, des choses qu'on ne peut pas contrôler. On peut contrôler quoi ? On peut contrôler la satisfaction client, on peut contrôler le nombre de paiements qui sont acceptés versus déclinés. On a plein de choses qu'on peut contrôler, par contre en fait le contexte économique on ne peut pas le contrôler, donc ça en fait il faut qu'on lâche prise dessus. Désolée, c'était un petit parallèle. Et donc du coup, je pense que je m'inspire pas mal de contenus un peu plus lifestyle et mental health, bien-être, etc. pour essayer de devenir une personne un petit peu plus calme et reposée et reposante du coup.

Terry : À la limite, tu me donneras les liens de tes podcasts préférés que je mettrai dans les ressources pour ceux qui seraient intéressés par ça. Je te remercie encore pour ton partage et pour ton temps, Julie.

Julie : Merci beaucoup, c'était un plaisir.