Merci à tous et à toutes d'être là ce soir, donc ce sera le dernier meetup de la communauté French Produits Bordeaux pour la saison 2022 et on vous prévoit forcément d'autres meetups l'année prochaine. En tout cas, merci à tous et à toutes d'être si nombreux ce soir. Un petit rappel sur la communauté, historiquement ça s'appelait La Product Comp et on est devenu French Produits depuis cet été, donc vous pouvez nous rejoindre sur le slack French Produits pour ceux qui ne sont pas encore abonnés. L'objectif c'est de rassembler tous les product lovers de France, que vous soyez product designer, product manager, product content, etc. Donc n'hésitez pas à vous inscrire sur le slack. Ce qui est important de noter, c'est que c'est une communauté qui est gratuite, donc vous pouvez venir au meetup, y assister. On organise aussi des drinks, il y aura un drink de fin d'année, on va vous faire un petit teaser. La communauté French Produits est disponible dans beaucoup de régions en France, nous on représente la communauté sud-ouest à Bordeaux et il y a un bout de chapter qui est en train de s'ouvrir à Toulouse, donc il y aura également des événements qui arriveront à Toulouse dans les prochains mois. Je vais vous présenter rapidement l'équipe, donc on a Chloé qui est ici présente, Florian qui malheureusement ne peut pas être là ce soir, Arnaud, moi-même bien sûr, Margot et Camille qui sont également présentes et Margot qui travaille chez Betflix, donc certains d'entre vous connaissent. Maintenant on va faire un petit rapide mot sur les sponsors, donc on a trois sponsors aujourd'hui nationaux qui financent l'association French Produits. On a Euva et Zuri que vous devez connaître qui est un cabinet de conseil, qui a notamment comme client Decathlon et Leroy Marlin, donc qui est une référence dans le monde du produit. On remercie également Standing Blue qui est une boîte qui nous permet de faire du marketing digital, qui est basée à Paris et qui a des bureaux un peu partout dans le monde, merci de nous aider. Et enfin on a également un autre cabinet de conseil, Exalt, qui a des bureaux un peu partout en France, donc en l'occurrence à Nantes, à Bordeaux, à Lille, etc. Et c'est également un cabinet qui peut vous accompagner quand vous avez une entreprise qui souhaite se structurer en produit, donc n'hésitez pas à faire appel à eux. On remercie également forcément notre autre de ce soir, Baitclic. Baitclic, qu'est-ce qu'ils font ? Ils créent l'expérience de Paris Sportif de demain. Si vous avez plus de questions sur Baitclic, à la fin de la présentation on proposera, il y a des postes à pourvoir, donc n'hésitez pas à poser des questions, à profiter du moment de networking. Et donc on les remercie. Et on a également la bonne nouvelle qui est que Baitclic va devenir un sponsor de la communauté French Produits. Donc voilà, on l'annonce ce soir, on est très content. Et donc ils vont vous permettre et nous permettre de continuer à organiser des meet-ups l'année prochaine et de financer également les apéros. Donc au programme ce soir, Product Ops, c'est quoi, pourquoi, comment ? Donc j'ai le plaisir ce soir d'accueillir Clément Stallon, qui est Product Ops chez Baitclic. Alexandre Thierry, qui est Lead Product Ops chez ManoMano. Et Frédéric Tan, qui est Product Director chez Malte. Donc on est déjà un petit peu en retard, on va accélérer. Donc l'objectif c'est on a 45 minutes de talk, 15 minutes à 30 minutes de questions. Et ensuite on pourra aborder l'apéro avec quelques petits teasings avant l'apéro. Donc voilà. Je vais vous demander du coup de me rejoindre. Pardon, allez-y. Donc le Product Ops, pourquoi est-ce qu'on a décidé d'organiser cet événement avant de vous présenter ? En fait, on s'est rendu compte que c'est un sujet qui émerge déjà depuis quelques mois dans l'écosystème. Il y a beaucoup de meet-ups qui s'organisent autour du Product Ops. Je pense qu'on est le premier à le faire à Bordeaux. Il y en a à Paris, un petit peu partout. Donc si vous allez sur YouTube, vous allez trouver beaucoup de sujets. Et on avait de super speakers, donc c'était une super occasion d'organiser également ce meet-up. Le Product Ops, il faut savoir qu'on en fait tous, tous les jours, en tant que Product Manager, Product Designer ou autre. Donc là, l'intérêt ce soir, c'est de vous montrer comment est-ce qu'on en fait en fonction de la boîte dans laquelle on est, en fonction de sa taille. Pourquoi est-ce qu'on fait du Product Ops ? Comment on le fait ? Et derrière, l'objectif, c'est que vous ayez des key learnings et que vous puissiez appliquer quelques méthodes pour créer votre fonction Product Ops dans votre boîte, en fonction de vos besoins. Donc on va commencer par le quoi. Et avant de faire ça, je vais les laisser, chacun se présenter. Clémence, tu veux bien commencer ? Oui, bien sûr. Je présente BetClik aussi en même temps ? Oui, vas-y, avec plaisir. Je vais commencer par ma boîte parce que je suis très corporate. Donc BetClik, même si vous connaissez sans doute déjà tous, je vais quand même redonner quelques infos. Donc BetClik, c'est l'un des leaders européens sur les paris et les jeux en ligne. Paris, c'est Paris sportif, bien sûr, mais aussi Paris Épique. Et quand on dit jeux en ligne, c'est toute la partie casinos et poker. Aujourd'hui, BetClik, d'un point de vue produit, c'est deux apps natives, donc iOS et Android. C'est un site web et une version web mobile. C'est aussi 11 millions de joueurs inscrits, qui sont amateurs et passionnés de sport. Et après, d'un point de vue un peu plus corporate, on va dire, BetClik, aujourd'hui, c'est près de 900 collaborateurs. Il y a 38 nationalités, c'est 5 bureaux en Europe et une moyenne d'âge de 33 ans. Et me concernant, du coup, j'ai été Product Manager pendant 8 ans, aussi bien en France qu'en Belgique. Et j'ai rejoint BetClik en mai, comme Product Ops. Et pour la partie vraiment en détail, je pense qu'on y rentrera. Merci beaucoup, Clémence. A ton tour, Alexandre. C'est à moi. Donc, moi, je vais commencer aussi par ManoMano. Donc, ManoMano, je pense que vous le connaissez à peu près tous, si vous faites du bricolage, si vous faites des scènes de bricolage ou de jardinage. Donc, c'est le leader européen. C'est une marketplace qui a été créée en 2013. C'est le leader européen sur les secteurs du bricolage, jardinage, de l'amélioration de la maison. On a un catalogue d'environ 16 millions de produits. Donc, ça vous montre un peu l'ensemble du catalogue qu'on a. On avait 10 millions il y a un an et demi après. Donc, ça vous montre aussi la croissance qu'on a sur ce sujet-là. On est présent dans 6 pays, donc les grands pays européens, Allemagne, Italie, Espagne, Belgique, Angleterre. Et en termes de taille, on a à peu près environ 1000 personnes. Donc, on a passé le cap des 1000 il y a 2 mois environ. Et on est dans 3 locaux. Donc, un à Paris, un à Bordeaux et un à Barcelone. Donc, voilà, c'est un peu pour ManoMano. Pour ma part, moi, ça fait un an et demi, un petit peu moins que chez ManoMano. J'ai commencé comme Senior Product Manager sur la partie search, donc les séances de recherche pour nos clients qui utilisent le site B2C, c'est-à-dire qu'on a aussi un site B2B. Et depuis 15 jours maintenant, j'ai changé de poste et je suis passé sur le côté product opération. Donc, c'est tout nouveau et on en parlera, je pense, un petit peu plus en détail. Merci beaucoup, Alexandre. Frédéric ? Oui. Bonjour à tous. Moi, c'est Frédéric. Je suis directeur produit chez Malte. Malte, qu'est-ce que c'est ? C'est la plateforme référence en Europe de la mise en relation entre les entreprises et les freelances. On a une commisse aujourd'hui de 300 000 freelances qui sont réparties sur différents pays, donc la France, l'Allemagne, Belgique, Netherlands et UK, et en Espagne aussi. En termes de taille, on est environ 600 collaborateurs. Et au niveau de l'équipe produit, donc produit et design, on devrait être 40 à peu près. Voilà pour Malte, pour mon parcours. Donc moi, ça fait à peu près un an que je suis chez Malte. Avant ça, j'ai fait un saut chez ManoMano en tant que Senior Lead Product Manager. Super. Merci beaucoup, Frédéric. On va commencer avec toi, Alexandre, et ensuite, vous allez voir vous compléter. Je pense que l'important, c'est de commencer toujours avec le basique. Qu'est-ce qu'un Product Ops ? Est-ce que tu peux commencer par nous expliquer pour toi qu'est-ce que c'est ? Et peut-être d'abord, commencer par qu'est-ce que ça n'est pas pour mieux mettre en valeur quel est le job d'un Product Ops ? Carrément. Déjà, je voulais savoir, dans la science, combien de personnes s'intéressent à ce sujet ou de produits ? Combien de personnes, dans ce cas-ci, s'intéressent à ce sujet ou de près, de loin, l'envisagent dans leur entreprise, pour voir un petit peu ? Il y a quand même une bonne partie. Et une autre question, combien ne savaient pas que ça existait il y a un an à peu près ? C'est intéressant. C'est vraiment quelque chose qui a pris et qui commence à se faire connaître. Et effectivement, quand on lit de la littérature, quand on lit des articles, quand on s'intéresse un petit peu au sujet, on a beaucoup de définitions du Product Ops, on a beaucoup de mises en place aussi. Ça va dépendre vraiment de la boîte. Et il y a aussi des grandes différences, entre ce que vous pouvez lire sur des boîtes qui sont plus américaines, qui vont plutôt le considérer comme quelque chose qui est très proche de la délivrerie, très proche de la production, puisqu'on est très proche d'un DevOps. Il y a certains articles qui qualifient ce poste de process people. Donc, ce n'est pas forcément très sexy. En France, on est plus sur des exemples de gens qui sont assez holistiques, en fait, sur toute la partie produit, ce qu'on peut amener à l'équipe et comment on peut améliorer l'efficacité. Une fois qu'on a dit ça, je pense que pour moi, la meilleure manière de résumer tout ça, c'est en fait un poste de PM pour les PM. Et il y a une analogie qui est très simple, c'est qu'aujourd'hui, les PM s'occupent de leurs utilisateurs, ils essaient de comprendre leurs problèmes. Les utilisateurs utilisent un produit, ils ont des frictions, des frustrations. On essaie de les comprendre, de les solutionner. Et aujourd'hui, en Product Ops, il faut comprendre que les PM sont aussi utilisateurs d'un produit, une organisation, un process, un framework, des outils. Et ils ont aussi des problèmes, des frictions. Et il faut aussi comprendre tout ça. Donc, c'est pour ça que l'analogie entre être un PM pour les PM se fait assez facilement. Et pour moi, c'est la décision la plus simple qu'on peut donner à ce poste-là. OK. Merci beaucoup, Alexandre. Est-ce que toi, Clémence, tu vois… Comment est-ce que tu définirais Product Ops, par exemple, par rapport à un Scrum Master ou les cadres d'Agile ? Comme tu le disais, Alexandre, ça peut être intéressant de rebondir pour montrer la différence entre un coach Agile et un Product Ops. Oui. Alors…
Moi, la partie, pour le coup, Product Ops, je vais juste la redéfinir aussi. Ça marche. Pour moi, le Product Ops, c'est quelqu'un qui va vraiment orchestrer l'organisation des équipes produits. Et tu parlais des PM, nous, pour le coup, on l'élargit déjà un peu plus, c'est ce que j'appelle les Product People. Donc, ça inclut, bien sûr, les PM, mais aussi les PO, les Product Designers, et ensuite, tous les grades de personnes qui vont travailler sur le produit, que ce soit des Head of Product, des Directors Produits, etc. Déjà, je pense que le scope est un poil plus vaste que juste PM. Après, la différence avec des postes, justement, de Scrum, etc., je pense que tout va dépendre aussi du rôle que l'entreprise va souhaiter donner au Product Ops. En l'occurrence, il y a toute une partie stratégie qui va consister à vraiment aider les Product People à mettre en place, à prendre les bonnes décisions pour que l'entreprise puisse atteindre ses objectifs. Ça, c'est vraiment, pour moi, le rôle central. Et ça, on va le retrouver chez tous les Product Ops. En l'occurrence, ça s'éloigne un petit peu, ça, pour le coup, de ce que peut faire un DevOps ou un Design Ops. En fait, un Product Ops va rassembler, finalement, toute la partie transversale que peuvent avoir ces métiers-là, mais à aucun moment, je pense qu'on se marche sur les pieds. Alors, toi, tu vas peut-être, justement, pas me contredire, mais penser de façon un peu différente, sachant qu'il n'y a pas de Product Ops chez Malte. En l'occurrence, nous, chez Betclick, on part vraiment du principe que le rôle de Product Ops est là, vraiment, en transverse, pour aider, encore une fois, les équipes produits, non seulement à monter en compétences, mais aussi à s'organiser au quotidien. Je ne sais pas si je réponds encore aussi subitement à ta question, mais c'est vrai que c'est une question qui est quand même assez vaste. Attends, je suis désolée, je garde la parole un petit peu. C'est vrai qu'on a tendance à dire, c'est quoi le Product Ops ? Mais effectivement, tu l'as dit aussi, qu'est-ce que ne fait pas un Product Ops, finalement ? C'est peut-être aussi comme ça qu'on peut définir... Un Product Ops, c'est aussi un facilitateur. C'est un mot qui revient assez souvent, finalement, quand on parle de la profession. Pour autant, on n'est pas là pour faire les basses tâches, par exemple, du Product Management. Ce n'est pas non plus ça. C'est pour ça que j'aime bien aussi la façon dont tu me présentes aussi, à savoir qu'un Product Ops, finalement, fait du Product Management, mais pour les équipes produits, finalement. Les équipes produits sont sons produits. Est-ce que toi, Frédéric, tu partages complètement de ça ? Toi, tu l'as vécu chez Doctolib avec la structuration du métier de Product Ops et chez Malte, il n'y a pas de Product Ops. Comment est-ce que tu vois ça, toi, de ton point de vue ? Moi, je vais avoir un point de vue assez intéressant et je vais toujours un peu être le poil à gratter de la discussion. Moi, j'ai vécu dans deux environnements. Un, où il y avait effectivement une équipe Product Ops qui s'est structurée. Et chez Malte, tout pour le coup, si on décompose toutes les fonctions que peut avoir un Product Ops qui ont été présentées par mes camarades, eux, ils sont répartis dans les différents rôles qui constituent l'équipe Product Manager. Pour répondre à la question que tu posais initialement, moi, je définirais aussi le Product Ops par ses objectifs. Moi, je vois l'équipe Product Ops comme un coefficient de multiplicateur ou un levier d'accélération de l'équipe produit à trois niveaux. Le premier, c'est sur l'impact. Ce qui crée les conditions pour que chaque Product Manager ait encore un peu plus d'impact au quotidien. Au niveau de l'efficacité aussi, c'est que cet impact, il le fasse avec le moins en moins de temps. Et enfin, sur l'épanouissement et la satisfaction, je pense que le but, c'est aussi en débloquant les deux premiers leviers qu'un PM se sente, non pas, je pense qu'on l'a tous vécu en tant que PM, mais bloqué dans son quotidien, dans sa roue à tourner, tourner, tourner. Mais le but, c'est aussi de desserger toute une part de charge mentale qu'il peut avoir et qui peut parfois dégénérer. Et le fait de se concentrer sur son métier premier. Et là, du coup, je vais répondre à la question, qu'est-ce que ne fait pas un Product Ops ? C'est justement pour moi ce qui est le métier premier d'un Product Manager. Tout le cycle produit de développement, donc c'est vision, stratégie, discovery, delivery. Tous ces trucs-là, pour moi, c'est la chasse gardée du PM. Et il ne s'agit pas du Product Ops de rentrer sur ce domaine-là, mais de travailler sur le méta, sur tout ce qu'il y a autour pour justement faire en sorte que la colonne vertébrale du rôle de PM se fasse d'autant plus vite, d'autant plus impactante et d'une manière beaucoup plus satisfaisante pour le Product Manager. Donc, si on veut rassurer l'audience, un Product Ops n'a pas sa main sur les décisions produites ? Non. OK, très bien. C'est important de le noter, je pense. Clémence, pour compléter, je sais que dans ta fiche de poste de t'émission, il y a beaucoup de choses et pas seulement du process. On a beaucoup parlé du Product Ops autour du process. Est-ce que tu peux nous donner des exemples de missions ? Oui. Merci. Alors, du coup, chez BetClick, c'est vrai qu'on a tendance à découper le Product Ops en quatre grands piliers. Donc, le premier, c'est le pilier stratégie. Donc, ça rejoint ce qu'on disait, toute la partie process, etc. Donc, ça, on va le mettre pour l'instant de côté, même si c'est un pilier hyper important. Les trois autres piliers, il y a la partie vraiment culture. Donc là, l'idée, ça va vraiment être d'aider la communauté produit à monter, à acquérir finalement une culture produit. Et ça aussi, on peut le faire chez BetClick parce que ça fait partie de la stratégie d'entreprise, finalement, d'avoir le produit au cœur de tout. Donc, dans les prérogatives qui sont liées justement à la partie culture, typiquement, on a mis en place une communauté produit, la Product Community, et on organise de façon assez régulière, tous les mois, des événements où on va vraiment inciter les Product People, finalement, à échanger, communiquer. L'idée, c'est vraiment de favoriser les échanges. Chez BetClick, on a 19 équipes produits, ça fait beaucoup de monde. C'est hyper important d'être sûr que les gens communiquent entre eux et qu'ils ne restent pas dans leurs équipes, qu'ils vont vraiment pouvoir parler un petit peu à tout le monde. Donc, ça, c'est vraiment le pilier culture. Après, il y a un pilier, je pense, qu'on retrouve aussi, qui, pour le coup, est un pilier sans doute un peu plus générique. C'est ce que j'appelle, moi, le pilier démocratisation. Donc là, ça concerne vraiment les outils. Aujourd'hui, les outils des Product People, c'est la data, c'est la user research, c'est le design system. Ça va être aussi toute la partie vraiment outils, logiciels. Bon, ça fait partie aussi des prérogatives du ProductOps, s'assurer que tous les Product People ont à dispo les bons outils, qu'ils vont pouvoir monter en compétence sur ces outils, etc. Et le dernier pilier, c'est le pilier que j'appelle excellence. Là, c'est comment on fait monter en compétence les Product People, comment on s'assure qu'ils vont gagner en maturité, en autonomie et aussi comment on va les fidéliser, puisque c'est bien d'avoir des Product People, mais il faut aussi les garder. Donc, ça va passer et c'est là, je pense, où tu voulais en venir. On travaille pas mal, en tout cas chez Betlic, avec les ressources humaines pour tout ce qui va concerner les formations, le recrutement et avenir. Ça fait partie des projets qu'on va mettre en place, aussi les chemins de carrière, les carrières des Product People pour s'assurer aussi qu'ils vont pouvoir s'épanouir pleinement dans l'entreprise. Voilà. Merci. Est-ce que tu voudrais ajouter quelque chose, Alexandre ? Peut-être dans tes missions qui sont peut-être un peu différentes ou des choses qui se recouplent. Alors, le métier commence chez ManoMano, donc c'est vrai qu'on doit définir encore ce qu'on va vouloir faire, les sujets sur lesquels on va pouvoir avancer. Après, effectivement, ce qui est vrai pour une entreprise n'est pas forcément vrai pour une autre. C'est un métier qui va vraiment évoluer et prend sa racine et son sens par rapport aux problèmes, à l'insanté d'une entreprise. Donc, ce que tu dis, toi, Clémence, maintenant, peut-être ne s'appliquera pas du tout à ManoMano, parce qu'on a une autre manière de fonctionner, on a d'autres gens qui agissent aussi sur la delivery, donc tu parles des agilistes et des scrum masters, on en a beaucoup aussi, qui font des choses qui déchargent un petit peu ou qui permettent de faire différemment par rapport à ce qu'on pourrait faire nous. Mais voilà, donc il y a vraiment quelque chose à trouver, à créer et à savoir sur quoi on peut agir, sur quoi on a des leviers d'action et de l'impact dans une entreprise. En revanche, on a commencé ce sujet de Product Operations à commencer il y a à peu près un an, dans le sens où on a créé, au début, une communauté produit de volontaires au sein de ManoMano. Donc, en fait, ces sujets d'amélioration PM, d'optimisation de l'équipe, sont déjà les choses sur lesquelles on travaille et on agit sur des éléments comme améliorer la culture de discovery, améliorer l'usage de la data. On a travaillé aussi sur l'onboarding des PM. Voilà, c'est effectivement, je rejoins parce que c'est des choses qui sont très holistiques, qui prennent tout le life cycle d'un PM, de l'acquisition d'un PM, si on reprend encore l'analogie produit jusqu'à sa rétention, disons. Et donc, du coup, on a tous ces éléments sur lesquels on travaille. Donc, c'est vraiment assez vaste. Et en revanche, pour mon rôle à mois à venir, il va falloir plus rationaliser et plus prioriser les éléments qui font sens, justement, par rapport à l'instant T. OK, très clair. Puisqu'il y a une question sur laquelle on était beaucoup revenus quand on a préparé le Meetup, c'est votre utilisateur principal, c'est le PM ou un Peer Designer ou autre. Et on en a discuté avec Frédéric. Il y a une question qui me tenait à cœur, c'est est-ce qu'on doit faire du produit ? Est-ce qu'on doit en avoir fait pour devenir Product Ops ? Oui, c'est une super question, avec des avis qui peuvent diverger. Moi, j'ai une opinion assez forte là-dessus. En tant que personne qui va venir, quelque part, distiller les bonnes pratiques, s'assurer qu'elles soient bien remplies, choisir les bons outils pour que, quelque part, l'organisation produit scale, je pense qu'il faut, au minimum, avoir une sensibilité au produit. Et ce, pour deux raisons. Je pense que la première raison, c'est que, encore une fois, vos utilisateurs, ça va être les PM, en tant que Product Ops. Il y a cette notion de confiance à venir créer, et c'est d'autant plus facile d'adopter des recommandations qui sont faites si la personne qui les a faites a une forme de légitimité à les fournir. Ça, c'est un. Et deux, il faut aussi s'assurer que ces recommandations, on a du recul par rapport à ce qu'on recommande, parce que le risque, sinon, c'est qu'on vienne dégrader, quelque part, la qualité de toute l'équipe produit en proposant des process, des outils, des bonnes pratiques.
qui sont juste mauvaises et qui viennent ralentir tout le monde. Donc, le levier d'amélioration comme le levier de dégradation du rôle de Product Ops, il est juste monstrueux. Et donc, il faut de gens qui soient du coup compétents, ça c'est sûr, mais qui ont une forme d'empathie et d'expertise sur ce qu'elle va venir recommander. Est-ce que vous... Oui, une expérience en tant que PM, c'est sûr, c'est préférable. Après, on disait peut-être plus généralement, avoir travaillé de près ou de loin dans le produit. Je pense qu'il y a aussi derrière des compétences humaines à avoir. Et je pense que par exemple, on ne peut pas être un bon Product Ops si on n'est pas à l'écoute, si on n'aime pas parler aux gens, parce qu'on peut être un très bon PM et peut-être ne pas aimer... C'est important, je pense quand même, ça fait partie des qualités en tout cas, d'aller parler aux gens, sinon... Après tout, vu que les Product People de son entreprise, ce sont pas le produit, mais en tout cas les utilisateurs, il faut absolument les rencontrer. Donc c'est sûr que ça va être un gros fin si vous n'aimez pas parler aux gens. Donc on peut dire que vous êtes de bons Product Ops parce que vous venez parler à une audience qui est telle pour la communauté. En vrai, si je peux mettre un petit... Je pense que c'est très vrai quand on va débuter, vraiment, je pense. Parce qu'effectivement, il faut avoir de l'empathie, il faut comprendre, il faut effectivement mettre des choses en place. Ça passe par la crédibilité qu'on a eue, je pense que c'est très vrai. Après, ça peut dépendre de la... Comment on grossit l'équipe aussi. Parce qu'à un moment donné, on va aussi mettre des choses en place. Et donc on va peut-être moins agir sur un profil de produit, mais peut-être plus sur quelqu'un qui est capable d'agir sur du project management, tout genre de choses. Ou alors plus spécialisé dans une thématique qui est la data, qui est le design en fonction de la manière dont l'équipe se montre. Encore une fois, c'est une question de contexte. C'est pas la vérité d'une boîte qui n'est pas forcément celle d'une autre. Donc ça va vraiment dépendre de comment vous évoluez, de comment ce rôle et de comment cette équipe évolue. Mais effectivement, au début, je pense que c'est très vrai. Il faut avoir cette... Et je rajouterais un truc sur le fait que c'est important d'avoir une expérience en produit, une sensibilité ou une proximité avec le produit, parce que, comme vous le disiez avant, c'est du product management de PM. Donc quelque part, en fait, il y a beaucoup de similarités dans la méthodologie qui est appliquée au Product Ops, à savoir que tu vas passer du temps à identifier quels sont les problèmes de tes utilisateurs, etc. Et même dans l'aspect itératif de la chose. C'est pas juste j'ai identifié un problème, je le délivre et je sors. Il faut derrière suivre l'impact qu'on va venir créer et itérer par-dessus ça. Donc je pense que même dans les méthodologies, il y a beaucoup de similarités à créer avec le Product Management. Maintenant, il faut aussi relativiser avec le fait qu'on ne parle pas tout à fait de la même chose et que dans le passé, j'ai pu voir aussi des Product Ops qui venaient du consulting avec cet aspect très... J'ai une organisation, j'ai un regard extérieur et j'arrive à identifier des failles. Et une des choses sur lesquelles on peut être moins bon en PM pur, c'est sur la gestion du changement. C'est-à-dire, là, j'ai de la matière qui est un peu plus organique, on va dire, c'est l'humain, et donc d'arriver à appliquer ce changement-là à une organisation, c'est aussi des skills que nous, on peut ne pas avoir en tant que PM et qui peuvent se retrouver dans d'autres compétences, d'autres disciplines qui peuvent être par ailleurs. C'est pas 100%, mais il y a des similarités. Alexandre, tu évoquais tout à l'heure la communauté qui existait chez ManoMano. À partir de quel moment vous avez eu besoin, vous avez ressenti le besoin, en tout cas, de construire cette fonction Product Ops et ensuite de la faire grandir. Maintenant, tu es le lead Product Ops. Est-ce qu'il y a des facteurs clés qui l'ont fait ? Est-ce que tu as des exemples de challenges auxquels vous faisiez face à l'époque chez ManoMano ? Déjà, il y a un truc que je n'ai pas dit, c'est qu'on est 60 PM, à peu près, chez ManoMano. Donc, c'est quand même une grosse équipe de produits. Quand je suis arrivé, on était 45, donc il y a un an et demi. Donc, il y a quand même aussi une grosse ambition et une grosse croissance de l'équipe. Je pense déjà que c'est un élément qui est clé. Et en plus de ça, ManoMano était dans un contexte d'hyper croissance. Il y a un an et demi, quand je suis arrivé, il y avait une grosse levée de fonds, la plus grosse de ManoMano. Il y a beaucoup de projets qui sont arrivés, qu'on a voulu faire. Il y a une grosse organisation de la manière dont on travaillait, avec une mise en place, un nouveau framework, etc. Beaucoup de choses qui se sont mises en place, beaucoup de PM qui sont arrivées, beaucoup de PM avec différentes expériences, différentes séniorités, différents usages d'outils. Beaucoup de complexité, au final, à gérer. Et à cette complexité, il faut arriver à la comprendre, à la gérer et à essayer d'y répondre. Parce que sinon, au final, si on la laisse comme ça, ça crée de la frustration, ça crée beaucoup de friction. Et au final, vous perdez de la valeur, puisque des PM vont partir ou des PM vont être résilients, mais ne vont pas avoir les bons moyens d'évoluer. Donc, en fait, ce constat-là, cette situation-là a fait naître cette volonté de créer quelque chose qui va s'attacher à ces problèmes-là. Donc, c'est la communauté produit qu'on avait créée à ManoMano. Et au fur et à mesure, donc, ça fait à peu près un an et demi, un petit peu moins, un an maintenant qu'elle existe. Et on s'est très vite confrontés à des problématiques de temps. Parce que tous les PM qui partaient de ce comité sont volontaires. Donc, quand on est volontaire, on a une heure à dédier par-ci, une heure à dédier par-là, c'est très compliqué d'aller sur des sujets, sauf s'ils sont très tactiques. Et on s'est très vite confrontés avec ces problématiques de temps, ces problématiques de manque d'énergie, disons. Et c'est là qu'on a fait naître ce poste-là, on l'a évangélisé, on l'a créé comme ça, au final, on l'a pitché comme ça. Et on est arrivé à dire, OK, effectivement, on a des problèmes à résoudre, il faut qu'on les résolve pour que l'équipe produit fonctionne bien. Mais en fait, dans le système actuel, ça ne fonctionne pas. Donc, il faut qu'on crée quelque chose de beaucoup plus solide dans l'organisation pour que, voilà, on ait la légitimité, on ait l'autonomie, la liberté de faire ce genre de choses. C'est comme ça qu'est née, c'est un peu la genèse et l'histoire de ce poste-là à ManoMano. OK, très bien. Et toi, je crois que Clémence, ça s'est passé un peu différemment et la fonction, il y avait déjà eu un peu de Product Ops avant que tu arrives, il y avait déjà eu un travail sur les process que tu peux expliquer, peut-être, chez Betflix ? Je regarde Delphine, ma collègue qui est ici dans l'Assemblée. Effectivement, le poste de Product Ops a été mis en place quelques mois avant que j'arrive, début d'année, je crois. Et donc, Delphine, en fait, qui travaille en freelance pour nous, c'est elle qui, avec Thomas, ils se sont chargés tous les deux de mettre en place toute la partie process. En tout cas, chez Betflix, c'est lié aussi, je pense que le contexte est quand même assez souvent le même, c'est qu'il y a eu une croissance des effectifs hyper importante en très peu de temps. Et c'est vraiment dans ces moments-là qu'on a besoin de recadrer, de recentrer. Quand on grandit très vite, c'est très chouette pour l'entreprise, mais c'est sûr que derrière, si tout n'est pas un minimum cadré, ça peut vite se transformer en cauchemar en termes de délivery. Oui. Et Frédéric, toi, chez Doctolib, t'as encore l'expérience différente. Je crois que ça s'est structuré encore différemment, c'est même devenu un département à part entière qui est quand même assez important. Comment est-ce que tu l'as vu, toi, de l'intérieur ? Est-ce qu'il y avait... Quelles raisons t'identifiais ? Est-ce que c'était des raisons partagées ? J'imagine qu'il y avait l'hyper croissance, forcément, on le retrouve, mais est-ce qu'il y avait d'autres choses en plus ? Alors, il y a... Tout commence effectivement par l'hyper croissance qui, du coup, en conséquence, génère pas mal de failles dû par le fait que ça va très, très, très vite. Trop vite, oui. Je suis arrivé, on était une douzaine de PM, et je suis parti, il y a 50 personnes, et c'est dans l'espace de deux ans et demi. Et donc, avec l'hyper croissance, ça ajoute un certain nombre de... Et la croissance des organisations ajoute petit à petit des frictions dans l'organisation, les dépendances, le besoin d'aligner quelque part les bonnes pratiques, parce que c'est pas possible d'avoir une équipe qui fait ci, ou une équipe qui fait ça. Il y a besoin aussi de communiquer à l'échelle pour dire que l'équipe produit, au bout d'un moment, elle fait ça, ça, ça. Il y a besoin d'aller le dire à beaucoup plus de monde. En fait, on arrive à un moment où le fonctionnement classique en mode startup ne fonctionne pas, à savoir que tu te lèves, tu tapes sur l'épaule de ton voisin et tu lui dis juste, est-ce qu'on peut se parler deux secondes ? Ça, ça ne marche plus, ça ne grossit plus. Et en fait, le symptôme de ça, c'est quand 100% du temps de PM se retrouve à 50% à faire autre chose que du travail vrai de PM. Et donc, en fait, ça veut dire que, grosso modo, l'impact de ton organisation, la vélocité de ton organisation s'en retrouve petit à petit à avoir des rendements qui sont progressivement diminués. Et donc, après, on n'y est pas allé, on n'a pas eu un big bang. On a eu d'abord une personne qui est arrivée, qui était directement sous le CPO, dont le rôle était Product Management Strategist, qui ne voulait absolument rien dire. Il y avait cette idée de stratégiser sur l'organisation Product Management, déjà, avec plein de leviers qui étaient encore une fois méta Product Management, qui étaient l'onboarding, distribution du knowledge, internationaliser le produit, création des process, bla, bla, bla. Et en fait, petit à petit, on a vu que ça a pris. On a vu que ça avait de l'écho auprès des PM. Et c'est quelque chose qui s'est finalement professionnalisé avec l'arrivée d'une vraie directrice de Product Ops, qui a ensuite structuré l'équipe en fonction des différents leviers qu'il pourrait y avoir dans l'équipe Product Ops. Donc, c'est vraiment ça qui a été quelque part le déclencheur. Comprendre que la charge mentale du PM était trop forte et les tâches autres que directement liées à l'impact qu'ils génèrent étaient plus importantes que juste le fait de générer de l'impact. Et si on essaie de prendre le contre-pied, parce qu'on parle beaucoup d'Edicor et des boîtes en hypercroissance, mais si on parle à un public, parmi vous, il y a des gens qui travaillent dans des plus petites boîtes, des boîtes de 800 personnes, 1000 personnes, à partir de quand, pour vous, est-ce que ça devient intéressant de faire du Product Ops, pas forcément de dédier une fonction, mais de commencer à en faire et ensuite de travailler sur une fonction ? Est-ce qu'il y a des facteurs pour vous qui sont, même sans avoir scalé autant son organisation, est-ce qu'il y a des choses comme ça, des petits warnings qu'on peut avoir en tête et observer ? Comme disait Frédéric, je pense qu'à partir du moment où les PM ne font plus que leur job de PM, c'est qu'il y a un besoin, en fait. Ce n'est pas une question de nombre de personnes ou de nombre de PM. À partir du moment où ton quotidien de PM, au-delà que tu commences à devoir mettre en place toi-même des process, c'est que peut-être, oui, il y a un besoin. C'est un truc, ce n'est pas effectivement une notion de nombre uniquement, mais il y a aussi quelque chose qui a pas mal bouleversé les moyens dont on travaille, donc le COVID. Beaucoup de monde en remote, donc ce n'est pas forcément pour le faire.
Ce qu'on est beaucoup, c'est aussi parce que les gens peuvent être beaucoup plus éclatés. Après, quand même à nos monnaies, on a des bureaux à Paris, à Bordeaux, à Barcelone, on est éclatés de base, donc c'est compliqué d'aller lier les gens. Mais quand vous avez aussi, en plus de ça, des PM qui sont en full remote, c'est compliqué d'aller les voir et de taper sur l'épaule de son voisin, dire on va parler d'un truc, on va faire quelque chose. Donc c'est là où vous avez aussi une perte d'énergie sur la communication, sur la cohésion, sur l'adhérence à des sujets. Rien que voir des PM passer du temps en Zoom, essayer de mettre des solutions en place, les workshops par Zoom, c'est compliqué, c'est de l'énergie. Ce n'est pas réellement quantifiable, donc je ne sais pas si on peut définir un warning, mais c'est aussi une situation à prendre en compte également. Ce n'est pas forcément, effectivement, je te rejoins, une question de time, mais aussi une question de contexte, de comment on travaille. OK, c'est clair. Et quand on organise justement cette fonction ou ce département, est-ce que d'après vous, il y a plusieurs pratiques différentes selon les boîtes, mais finalement, on peut se poser la question à un moment à qui rattacher le Product Ops ? Est-ce qu'on doit rattacher une équipe produit ? Est-ce qu'on doit la rattacher à des équipes opération ? Par exemple, il y a des DevOps, des Sales Ops, etc. C'est quoi un peu votre point de vue là-dessus ? J'imagine qu'il y a autant de points de vue que de possibilités, mais… Nous, chez BaitClick, en tout cas, la partie Product Ops, elle est rattachée à une équipe qui elle-même est déjà transverse, l'équipe Customer Experience, qui du coup s'assure au départ que l'expérience pour un joueur est uniforme finalement sur toute l'app. Donc, c'est un département dans lequel on retrouve tous les Product Designers, et étant donné que c'est une équipe qui est déjà très transverse et que le rôle de Product Ops est un rôle transverse par définition, ça semblait assez naturel finalement que le Product Ops soit rattaché à cette équipe. Mais bon, c'est propre à notre structure. Je pense que ça, encore une fois, comme tu l'as dit, il y a autant de cas de figure que d'organisation d'entreprise. L'expérience de chez L'Octolibre qu'on a vue, c'est que l'équipe Product Ops, elle a été directement rattachée au CQO. Pourquoi ? Parce que c'est un job qui paraît censé transverse en fait. Il ne peut pas être rattaché à des tribes ou des domaines, peu importe comment on appelle ça dans les équipes, mais ça a ce rôle quasiment matriciel qui fait qu'on ne peut pas le rattacher à une tribe. Et c'est important que ce soit directement sous le CQO parce que je pense que ça va dans les deux sens. Un, c'est quelque part le bras armé du leadership produit sur le fait de faire redescendre des bonnes pratiques produits ou d'aller précisément travailler sur des failles qu'il a pu identifier. Mais je pense que ça va aussi dans les deux sens. Je pense que le leadership produit, de manière générale, peut avoir des angles morts sur ce qui se passe très concrètement dans les équipes. Et c'est aussi un rôle qui va jouer en bottom-up, d'aller être proche des équipes produits, comprendre quel est leur quotidien, quels sont les problèmes qu'ils peuvent avoir dans leur travail et remonter ça aussi au leadership pour prendre conscience quelque part de l'ampleur des problèmes qu'il peut y avoir. Je pense que cet aspect transverse, il est vraiment important à avoir dans ces équipes ProductOps. Et si je peux compléter, il y a aussi une chose qui est hyper importante dans le rôle de ProductOps, c'est qu'il n'y a aucun lien de hiérarchie avec justement les Product People. Et ça, c'est aussi une des forces de ce rôle, c'est qu'on est à la fois très proche des gens et pour autant, il n'y a pas de lien de hiérarchie, donc c'est aussi beaucoup plus simple. Alors, ça peut être plus compliqué quand on cherche à mettre en place justement des process, mais au quotidien, ça facilite aussi quand même grandement la communication. Ça fait partie justement des challenges. Justement, sur ce que tu dis, il y a aussi un truc qui est important, c'est la légitimité que ce rôle peut avoir. Parce qu'effectivement, vous allez parler au PM, vous allez les enquêtiner des fois, parce que vous avez besoin de comprendre leurs problèmes, de savoir comment est-ce que vous allez leur proposer des nouvelles choses, peut-être leur faire tester des trucs. Et vous avez besoin de cette légitimité, de cette crédibilité et qui vient forcément du leadership produit. On a un poste qui va faire ça. Il est dans l'organisation, il est là pour vous aider. C'est un message qui est fort et c'est un message que les PM doivent comprendre. On n'est pas là pour vous rajouter des trucs en plus, on est là pour vous aider. Le fait que ce soit rattaché au leadership produit et en haut de la chaîne de commande-produit, donne aussi cette capacité à avoir de l'autonomie, de la liberté et cette légitimité. Je pense que c'est aussi un aspect qui est vachement important et qui justifie le fait que ça soit rattaché à quelqu'un. Un truc que je voulais rajouter, parce que je n'ai pas parlé de maths très concrètement, mais comment est-ce que le ProductOps peut s'opérer chez maths. Il n'y a pas de poste à proprement parler de ProductOps. La manière dont on l'a abordé, on a pu voir qu'il y avait certains problèmes, certaines frictions dans l'organisation produit qui méritaient d'y mettre une personne dédiée. On a créé des postes qui ne sont pas encore, peut-être que jamais, appelés ProductOps, mais qui sont par exemple sur le knowledge. Il y avait un vrai besoin d'aller documenter tout ce que les équipes produits créaient et pour venir le dissimuler ensuite dans l'organisation. On a un modèle en B2B qui fait qu'on a besoin d'avoir des sales people qui sont ultra, qui ont le produit chevillé au corps et qui puissent du coup se transmettre à nos clients. Donc, on a créé ce poste de Product Knowledge Manager qui dans une autre organisation pourrait être un des leviers que les ProductOps pourraient gérer, mais on a décidé que ça, c'était important. On a créé un poste. On n'a pas encore de fonction ombrelle qui s'appelle ProductOps. Un autre poste qu'on a pu créer, c'est l'internationalisation. On a voulu internationaliser, et on a une Product Localization Manager qui nous aide à remonter les besoins des pays et nous aider à venir versionner quelque part ce grand tronc commun qui est notre produit On a créé un poste. En revanche, il y a d'autres choses sur lesquelles on a voulu garder la mainmise en centre du Product Management. Et ça, je pense que ça dépend quelque part de l'appétence de ton organisation. On a quelqu'un, par exemple, comme Tristan Charvillat qui vient d'arriver et qui a écrit un bouquin qui s'appelle Discovery Discipline et qui a des idées extrêmement claires sur quelles sont les bonnes pratiques et comment est-ce qu'on doit les suivre. Et quelque part, il n'y avait pas besoin de créer une couche de traduction entre ce que pouvait penser Tristan et ce qu'on pouvait faire. Et du coup, toute la partie bonne pratique, création des process, comment est-ce qu'on transmet aux équipes parce qu'on a un leadership qui est extrêmement mature là-dessus et qui a vécu d'autres vies qui font qu'ils ont les idées très arrêtées là-dessus. On n'a pas eu besoin de créer ce produit-là. Donc, en fait, ça peut être aussi à la carte. Il y a des postes sur lesquels vous pouvez créer parce qu'il n'y a personne qui peut les gérer et qu'il n'y a personne qui a une opinion extrêmement forte là-dessus. À l'inverse, il y a des choses que vous pouvez continuer à internaliser au sein du produit parce qu'il y a une appétence, parce qu'il y a du temps, parce qu'il y a cette idée qu'on va venir scaler par le leadership et pas nécessairement par un poste ou par des process. Et une fois qu'on a réussi à avoir cette légitimité auprès de ses sponsors, comment est-ce qu'on développe la connivence et peut-être la confiance qu'on peut avoir avec les équipes produits ou même avec d'autres équipes avec lesquelles on interagit ? Comment est-ce que vous ouvrez ça ? Est-ce qu'il y a des choses qui ont mieux fonctionné d'autres ? Je pense qu'un premier levier qui va être intéressant, c'est d'être transparent, d'être clair avec ses équipes, avec les PM ou avec les Product People, avec lesquels on travaille. Le poste, à quoi est-ce qu'il correspond ? Quel est le scope ? Évangéliser ça. Je ne sais pas si beaucoup de personnes au sein des entreprises et compagnies savent ce que c'est et savent à peu près quel est le rôle, quelle est la substance de ce nouveau poste. Donc ça, je pense que c'est la première chose. Et après, comme un PM, au final, la crédibilité se gagne par l'impact, par la délivrée. Et donc tout l'enjeu et tout l'équilibre et tout justement la connivence qu'on peut créer et la légitimité qu'on peut créer avec les équipes du bas, pour le coup, ça va être de savoir est-ce qu'on délivre des choses ? Qu'est-ce qu'on propose ? Qu'est-ce qu'on va délivrer ? Et qu'est-ce qu'on va délivrer des choses très, sur le fond, très compliquées ? Quels sont les premiers wins ? Sur quels éléments tactiques est-ce qu'on peut partir ? Donc c'est vraiment créer un peu cet équilibre entre il y a des choses qu'on va devoir changer dans l'organisation, des choses de fou, mais aussi il y a des choses très tactiques, très quick wins qu'il va falloir qu'on sorte pour justement montrer qu'on est là, ça ne reste pas un rôle sur papier, on arrive à délivrer quelque chose, avoir un impact assez rapidement, tout en travaillant aussi sur des choses beaucoup plus profondes pour l'équipe au global. C'est vrai que les postes de Product Ops sont assez récents, Dan pour le coup, toi un peu moins du coup, mais tous les deux ça ne fait quand même pas si longtemps que ça qu'on est en poste, donc est-ce que pour l'instant on est légitime ? L'avenir nous le dira. En revanche, en tant que PM finalement, en quelque sorte, on s'assure quand même de suivre, de voir si nos actions sont bénéfiques ou pas. Et donc après, comme un PM va avoir ses KPIs, en fait nous on va suivre aussi un peu la satisfaction de nos Product People, donc par exemple, alors ce n'est qu'une partie du travail, mais quand on organise par exemple un événement au cours duquel on va communiquer sur la roadmap, etc., par exemple chez Bellclic, toutes les saisons, c'est-à-dire tous les trimestres, on organise une grande messe avec toutes les équipes produits au cours de laquelle on va présenter la roadmap, ce qui va être développé. Ça permet aussi de s'assurer que les équipes, d'une part, sont au courant, mais de tacler les éventuelles interdépendances entre équipes, etc. Typiquement, après ce genre d'événement, on va envoyer systématiquement un questionnaire de satisfaction pour s'assurer que le message est passé, que les équipes, ça leur convient. Ça va nous permettre aussi de savoir quels sont justement les points qui plaisent moins ou non. Et ça, on va essayer de le mettre en place systématiquement. Encore une fois, on est avant tout dans Product Ops Manager, il y a Product Manager. Et donc, c'est aussi à nous de nous assurer que derrière, nos clients sont satisfaits en quelque sorte. Après, il va falloir du temps, c'est certain, puisqu'encore une fois, on a des scopes tous qui sont extrêmement variés. Donc, ça ne se fait pas juste sur un projet. C'est une multitude de projets qu'on va mettre en place. Mais si déjà, au quotidien, en communiquant avec les gens, puisqu'encore une fois, je pense que c'est la clé, on se rend compte qu'on fait, qu'on apporte, qu'on fait des choses, en tout cas qu'on met en place, qui sont bénéfiques et que nos Product People en tirent en tout cas un petit peu de satisfaction ou de chargement d'un moment, comme tu pouvais l'évoquer tout à l'heure. Je pense que oui, on est déjà sur la bonne voie. Donc, ça signifie que finalement…
il y a un product manager souvent on lui demande d'impacter des métriques et de définir les objectifs, un productops aussi il a des objectifs, il a des métriques à suivre. Juste pour ajouter sur la partie d'évangélisation et légitimité, il y a un truc qui marche un peu plus, qui a marché chez Doctrip, qui a marché aussi chez Malte, c'est de s'appuyer sur les product managers. Le but ce n'est pas de paraître comme une fonction hors sol et de sortir les choses du chapeau, c'est vraiment de s'appuyer sur les product managers les plus seniors pour sortir des bonnes pratiques qui sont finalement déjà implémentées et qu'il s'agisse quelque part de mettre à l'échelle. Et donc nous systématiquement chez Doctrip, à la fois dans l'identification des problèmes et à la fois dans la mise en place, il y avait systématiquement du coup un partenariat, une collaboration avec les lead product managers, ça c'est un. Et même ensuite dans le rollout, il s'agissait d'abord de le faire sur une petite partie et ça quand on est product manager c'est quelque chose qui est assez naturel, c'est de tester sur une petite partie, comprendre quels sont les impacts, itérer à petite échelle et une fois qu'on est à peu près sûr que le truc va marcher, de le passer ensuite à l'échelle avec du coup un business case qui est beaucoup plus fort pour dire voilà ce que ça a pu changer, voilà les gains que tu vas pouvoir avoir. Et ça se fait ensuite dans le temps, c'est-à-dire qu'il va y avoir des gens qui vont être des champions de ce nouveau changement et qui vont être super accueillants dans le fait de pouvoir mieux travailler, comme il y a des gens qui vont dire pourquoi tu me fais chier avec ce nouveau truc, moi ça marche extrêmement bien et qui vont du coup être un peu rétifs. Donc c'est toujours important d'avoir à la fois l'appui des gens qui travaillent en tant que PM, avoir l'appui du leadership à la fois une forme de légitimité en tant que Product Ops, juste pour s'assurer que le process il va effectivement être utilisé au bout d'un moment par tout le monde, quitte à être un peu bâton dans l'approche et même un peu destruction au bout d'un moment, j'ai jamais arrivé à me faire taper sur les doigts parce que je n'avais pas, et mon manager aussi, donc il faut aussi s'appuyer vraiment sur tout ce qui constitue l'organisation aujourd'hui pour s'assurer du succès du Product Ops. Comment toi Alexandre, pour continuer là-dessus, comment est-ce que tu as réussi à trouver des champions, peut-être à identifier dans des équipes des personnes avec lesquelles tu as travaillé et derrière à réussir à les garder motivés parce qu'on peut faire du Product Ops pendant six mois et finalement si ça se passe mal, les personnes se démotivent ou alors elles ont plein d'autres choses à faire, comment est-ce que tu fais en sorte de les incentiver, de les garder motivés et de pouvoir continuer à travailler avec elles ? Alors c'est une question sur laquelle on essaie de travailler actuellement. En vrai donc on a cette communauté de produits, de volontaires encore une fois et ça s'est fait assez organiquement. L'idée c'était qu'on a envoyé un message à tous les PM en disant voilà, on a cette initiative, on veut améliorer la vie des PM qui veulent nous suivre. Et assez rapidement en vrai, on a eu 6 à 7 personnes qui sont venues de manière organique, c'était plutôt bien. On a commencé à créer notre roadmap, notre organisation au sein de cette petite communauté, l'application leadership, on a eu leur accord et après on a refait une communication auprès des PM. Et là on a doublé la taille de l'effectif. Donc en vrai ce qui s'est passé c'est qu'il y a vraiment une accroche, les PM savent qu'il y a des problèmes, veulent y aller et donc adhèrent à ce message-là. Donc ça c'est vraiment déjà l'activation des PM au sein de cette communauté. Après sur la partie dynamique et motivation, je pense qu'effectivement comme je disais tout à l'heure, ça passe par être reconnu et la reconnaissance passe par l'impact qu'on peut avoir et donc la délivrerie de sujets qui soient au final très tactiques vu le temps qu'on a passé. Donc ça je pense que ça a pas mal joué aussi parce qu'on a quand même réussi à délivrer des choses, on a montré à la communauté entière des PM qu'on existait, qu'on arrivait à délivrer des choses, qu'on avait le support du leadership. Et donc ça je pense ça a joué sur la motivation globale et sur le fait qu'on ait pu garder des gens, motiver des gens et une dynamique certaine au sein de ce groupe-là. C'est vrai qu'il y a des moments où on a passé un peu, on était un peu dans le creux de la vague et donc il y a eu des moments qui étaient compliqués, dans des réunions on était à 4-5, on s'est sent un peu le vide. Et là effectivement c'est des questions qu'on se pose après un an, comment est-ce qu'on arrive à continuellement avoir ça. Donc on se pose la question de l'incentive effectivement, on se pose la question de la valorisation du temps et voilà comment est-ce qu'on arrive à remettre de la dynamique là-dedans. Et surtout ce qui est intéressant c'est que les messages restent aussi positifs dans le sens où grâce à cette communauté on a créé ce poste-là. Donc ça la met aussi dans une autre dimension, dans une dynamique, ça la fait monter donc ça nous donne encore plus de poids et beaucoup plus de visibilité. Donc ça participe aussi à cet engouement. Mais on a aussi cette notion de temps, les PM sont volontaires encore une fois et on en arrive à se demander comment est-ce qu'on fait. Réellement là on n'a pas de… Tu as peut-être un exemple de projet qui a bien réussi pour toi et que tu peux partager à l'audience. Il y en a quelques-uns. Donc on a mis en place un système de buddy pour les PM qui arrivaient chez ManoMano. Donc ça voilà, dès qu'il y a un PM qui arrive chez ManoMano, il y avait quelqu'un qui était son buddy, donc ça permettait d'avoir des échanges, ça permettait d'arriver chez ManoMano et de connaître un petit peu les différentes personnes, etc. On a mis en place le framework de BED, donc je ne sais pas si vous connaissez, c'est un framework pour mieux communiquer et décrire des initiatives produits. Donc c'est quelque chose qui a été évangélisé par John Cutler d'Amplitude. Donc c'est quelque chose qu'on a testé à petite échelle. Donc on l'a testé à petite échelle sur une ou deux tribes et ensuite on est en train de l'implémenter sur tout le produit. Donc c'est des choses qui sont assez grosses au final, mais qu'on a réussi à délivrer. Et ce qui est intéressant, c'est que sur ce genre de projet, quand après vous parlez aux gens qui sont à l'intérieur de cette communauté, ils nous disent « En vrai, moi je suis content d'être là parce que j'apprends quelque chose, parce que je discute avec d'autres personnes ». Donc on a cette motivation aussi par là. Donc il faut la garder à un niveau assez haut, ce qui est compliqué. Donc c'est pour ça qu'on essaie de trouver d'autres relais, mais on a quand même des choses qui ont fonctionné, on a quand même réussi à avoir une bonne dynamique. Vous avez des exemples que vous partagez peut-être ? Des tips concrets ? Alors nous, l'exemple concret, c'est qu'historiquement, chez Betflik, on a une grosse machine de guerre sur la partie délivery. Sur la Discovery, on en faisait moins, on va dire. Donc on a décidé de mettre en place, vraiment d'implémenter la Discovery chez Betflik. Et du coup, ça ne se fait pas non plus comme ça du jour au lendemain. Et donc on a fait un peu comme tu l'expliquais, c'est-à-dire qu'on a d'abord imaginé un process. Ensuite, on l'a testé auprès de certaines équipes parce que justement, tu l'as dit toi-même, il y a certaines personnes qui sont plus réceptives, qui ont plus envie, qui sont parfois plus touche-à-tout, etc. Et ces personnes-là, en fait, après il faut vraiment s'appuyer sur elles. Donc on leur a fait prouver justement les premiers process. On a fait des meetings avec eux et qu'est-ce que t'en penses et comment t'as amélioré, etc. Enfin, comme on ferait finalement sur un produit avec des clients qu'on aurait bien identifiés. Et ensuite, on a pu déployer justement ce process à l'échelle de l'entreprise. Donc après, en toute modestie, pour l'instant, la Discovery, c'est la première saison qu'on la met en place. Donc c'est encore tout frais et on a encore beaucoup de choses à faire. Mais on a fait déjà quand même, c'est déjà une belle première étape. On l'a mise en place. Aujourd'hui, il y a un process qui roule. Derrière, on a recruté les product managers justement pour avancer sur ce sujet-là. Et voilà, maintenant, on va pouvoir suivre ça dans les prochains mois. Mais voilà, je pense que oui, effectivement, compter sur des sponsors en interne, c'est clé pour ce genre de projet. Frédéric, toi, est-ce qu'il y a eu un process ou une action qui a eu plus d'écho pour toi chez Doctolib ou chez Malte, quelque chose qui a vraiment fait la différence pour toi, un bon exemple ? Chez Malte, il y a eu l'arrivée de Tristan et le fait qu'on a commencé à utiliser Discovery Discipline. Je pense que ça, ça a été extrêmement important. Pourquoi ? Parce qu'on vient d'un monde, chez Malte, où la gestion des équipes produits est extrêmement décentralisée. Il y a vraiment cette logique d'une squad est une unité autonome des autres squads. Et donc, quelque part, les bonnes pratiques étaient extrêmement disséminées. Et on voyait bien, quelque part, la limite de cette approche où ça évite... Les bonnes pratiques n'étaient pas partagées. C'était difficile de parler le même langage que son voisin. Et donc, l'implémentation d'une bonne pratique à l'échelle était pour nous extrêmement important, justement pour que tout le monde apprenne et tire dans le même sens. Et pour le coup, le tip que je pourrais vous partager là-dessus, c'est que ça ne se fait pas du jour au lendemain, vraiment. Et même avec Tristan qui est arrivé avec des idées extrêmement claires sur comment implémenter le bouquin qu'il a écrit. Parce qu'en plus, il est légitime, pas dans le sens où il a écrit un livre. Il avait toutes les conditions pour que ça se passe du jour au lendemain. Et même avec ça, on s'est rendu compte qu'un process, il faut qu'il soit compris. Il faut qu'il soit compris dans la durée. Donc, il y a une forme d'accompagnement derrière pour comprendre toute la pleine mesure de ce que ça veut dire que de faire la discovery selon Discovery Discipline. Ensuite, les projets sont très différents. Donc, il y a une forme d'adaptabilité d'un projet à un autre. Et donc, on est encore dedans. On est encore en train de transitionner vers l'utilisation dans sa pleine mesure de Discovery Discipline. Donc, pour abonder dans ce que vont dire mes copains, ce n'est pas quelque chose qui se fait du jour au lendemain. Il faut vraiment persévérer. Et quelque part, comme dans tout process, c'est l'adoption qui va juger du succès aussi de ce process-là. Et donc, c'est vraiment important d'avoir un oeil là-dessus. Merci beaucoup Félix. On arrive à la fin de la partie talk. Avant de passer aux questions, on aura une demi-heure de questions, ensuite à peu près une heure d'apéro. La marque de fabrique du Fresh Produce est de donner des tips à chaque fois. Est-ce que vous aurez chacun un tips à partager avec l'audience ? Être résilient. Non, mais en vrai, être résilient vraiment, je pense que c'est important. Et il y a des moments où ça peut être frustrant. Je pense qu'il faut tourner cette frustration en énergie pour continuer à faire avancer les choses. Moi, je dirais être modeste dans le sens où rien n'est jamais acquis et on travaille avec de l'humain. Et donc, je pense qu'il faut être patient. C'est un mélange, on va dire, de qualité en tout cas humaine, je dirais. Donc, être à l'écoute, être patient, être modeste, ça paraît être des bonnes qualités en tout cas pour travailler en Product Ops. Et être organisé quand même. Effectivement. Moi, j'ai envie de dire, il faut travailler le go-to-market. C'est un truc très produit, mais tout bon process n'est que bon si jamais il est effectivement compris et adopté. Donc, on peut passer énormément de temps à ficeler le truc de manière extrêmement structurée et organisée.
Encore une fois, si derrière, ce n'est pas suffisant, ça n'aura zéro impact. Et donc, ça mélange un peu ce que vous dites. C'est être résilient, ça prend du temps, être modeste, ne pas essayer de voir trop gros, essayer de voir toujours tout à l'échelle en un instant T, c'est d'y aller progressivement et c'est comme ça que ça va prendre du temps. Merci beaucoup. On peut aborder la participation. On va être à l'écoute, justement, donc n'hésitez pas. Sous-titrage ST' 501