Et évidemment ça ne marche pas. On va commencer, les gens vont arriver je pense progressivement en ces journées de grève et de beau soleil. En tout cas merci à vous d'être venu quand même ce soir pour parler d'un sujet un peu atypique, qu'on n'a pas nécessairement l'habitude d'entendre parler. Et on est très content de le faire ici. Juste je vais vous resituer un peu l'asso French Produits, ce qu'on fait, etc, même si quelques personnes connaissent déjà. Donc en gros nous on est une communauté un peu indépendante qui regroupe toute la partie produits. Donc ça veut dire, ça va être des PM, des Product Designers, des Product Ops, Product Marketing, etc. Et l'idée en gros c'est de fédérer tout ça sur une communauté qui a plusieurs volets. Le flagship entre guillemets, c'est pourquoi les gens viennent souvent et tirent le plus de valeur, ça va être le Slack. Il y a beaucoup d'échanges, etc. Mais après derrière ce qui est aussi assez intéressant c'est que du coup on est un peu national dans le sens, je vous montre un peu après derrière, mais globalement on est un peu partout en France et assez actif. Et en fonction des pôles et des envies des gens, on ouvre de plus en plus de villes derrière pour évangéliser le produit et parler produit. Donc il y a la communauté produits, si jamais vous avez le QR code pour la rejoindre si vous n'y êtes pas et vous pouvez faire votre candidature. L'idée en gros c'est de, à l'intérieur de cette communauté, c'est plus de faire de l'échange. On n'est pas là pour faire de la vente, c'est gratuit. Et l'idée c'est qu'on s'accepte qu'entre produits, dans le sens où on va pas aller chercher nécessairement des commerciaux qui vont vendre leurs tools sur le Slack, on va pas aller chercher, on va pas accepter des talents recruteurs qui vont venir scraper la base du Slack pour aller mettre des messages à tout le monde, etc. Donc l'idée c'est qu'on est assez sélectif et on n'a pas une entrée libre comme ça. Juste pour situer l'équipe, il y a Anthony qui était dehors au portail et après on a quelques personnes qui sont en vacances. Donc voilà, mais bon globalement on est six et si jamais vous avez des idées de sujets, de choses que vous voudrez voir ou même discuter de manière générale, vous pouvez venir nous voir. Après qui dit gratuit et dit organisation, infrastructure, payer pour le matériel et le bénévolat des gens, dit en fait sponsor. Donc on en a trois dont deux qui sont là ce soir. Donc le premier vis-à-vis je vais le passer rapidement parce que du coup je vais laisser Benoît en même temps en dire quelques mois juste après. Donc on a Brevo pour lequel on accueille Mickaël. Globalement il l'expliquera 100 fois mieux que moi mais Brevo on va dire que c'est une solution de marketing digital un peu holistique. Donc ça va être de l'email marketing, des sms, etc. Donc tout ce qui se plug pour le transactionnel généralement pour la plateforme mais pas que. On a Exalt qui est une boîte de consulting aussi en product management et en gestion de projet qui est basée dans différentes villes et qui pareil a sponsorisé l'assaut. Et dernièrement on a Betclick qui sponsorise plus particulièrement la partie de Paris. Donc je pense que je ne les présente plus. C'est une boîte de Paris Sportif mais qui ont quand même de gros challenge produits. Ah mince je te remets ta slide. Je l'ai oublié de la déplacer à la fin. En tout cas merci à Upvizory de nous accueillir ce soir c'est très sympa. Avec grand plaisir alors juste pour introduire un petit peu cette session donc moi je m'appelle Benoît Rosier je suis un des trois fondateurs d'Upvizory. Pour ceux qui ne connaissent pas Upvizory c'est une agence conseil dédiée au product management et donc moi chez Upvizory j'ai le rôle de cofondateur et CPO. Donc voilà je suis très content aujourd'hui de vous accueillir pour ce très bel événement. C'est vrai qu'on a eu l'occasion de faire deux sessions à Lille mais on n'a pas encore eu l'occasion d'en faire une à Paris. Donc voilà j'espère que vous allez pouvoir profiter de nos locaux et j'espère de la terrasse après puisque on a de la chance aujourd'hui il fait beau. Et donc on est aussi juste pour dire un petit mot très content d'être d'être sponsor de cette très belle initiative qui est French Produit. On est content d'avoir été les sponsors pour cette première année comme dirait nos amis marseillais à jamais les premiers. Donc on aura été à jamais les premiers sponsors de French Produit qui est vraiment une très belle initiative. Donc voilà donc profitez bien de l'événement on espère que ça va vous plaire et encore une fois bienvenue chez nous, bienvenue dans nos locaux et puis on se retrouve juste après pour un petit apéro. Du coup voilà je réintroduis rapidement Mickaël mais en tout cas merci Mickaël d'être venu ce soir et puis on va parler un peu Product Ops et je laisse dérouler. Merci à vous bonsoir à tous. Merci à French Produit déjà de me laisser la parole ce soir pour vous présenter un peu mon métier chez Brevo. Merci à Viserie également pour l'accueil. Alors mon ambition ce soir ça va être un peu de vous parler de mon quotidien en tant que Product Ops chez Brevo. Je donne deux trois petits mots sur Brevo donc c'est une entreprise qui existe maintenant depuis 2007 on a changé de nom, on s'en plaît encore il y a quelques semaines Sending Blue. Donc on est comme l'a précisé Alex un outil à destination des petites moyennes entreprises qui souhaitent engager leur relation client donc à la fois du one to many c'est à dire lorsque vous faites des campagnes marketing email sms facebook ad whatsapp mais également du one to one au travers un outil de phoning, un outil de meeting, un outil de crm à destination des sales ou un outil de coïncidence. Voilà je vous expliquerai un peu tout ça en détail. Donc ce soir moi je vais vous présenter pas forcément de la théorie de ce que c'est le Product Ops mais qu'est ce que je fais au quotidien en tant que Product Ops et puis qu'est ce que ça signifie utiliser ce qui fait le Product Management ou du moins les forces du Product Management pour travailler sur mon produit qui est l'organisation de produits. Je vous donne une petite présentation également de mon parcours professionnel. J'ai commencé en 2012 dans le digital donc ça fait 11 ans j'étais chef de projet chez un éditeur de logiciels où du coup je m'occupais d'intégrer la solution chez le client donc un truc bien waterfall et puis en 2015 cette entreprise elle décide de changer un peu sa manière de concevoir du produit et va ouvrir en interne à candidature du coup un poste, un premier poste de Product Owner. Donc j'ai postulé, j'ai potassé tout l'été sur la terrasse d'un mobile home d'un camping en Bretagne pour être bien prêt à la rentrée pour cette candidature. J'ai lu Scrum Guide, j'ai lu Lean Startup et j'ai eu d'une certaine manière une épiphanie. En fait d'une certaine manière j'ai trouvé qu'il y avait quelque chose dans le Product Management qui était assez proche de la démarche scientifique à laquelle je suis très attaché. C'est à dire vous faites des hypothèses de solutions, des hypothèses de problèmes, vous expérimentez et vous mesurez donc le fameux test and learn. Donc j'ai ensuite une carrière de consultant chez Tiga pendant 4 ans où j'ai pu voir différents contextes du très peu mature au un peu plus mature du coup avant d'arriver chez Brevo en 2022. Cette expérience m'a permis de voir deux choses et de faire un premier constat c'est qu'il y a à mon sens deux types de PM. Vous avez les PM qui sont très focus sur leurs produits, qui ont envie de développer la meilleure solution qui soit, qui se concentrent véritablement sur cette tâche. Et puis à mon sens une deuxième catégorie de PM qui a conscience que faire du Product Management c'est travailler sur la résolution des problèmes des utilisateurs mais c'est également travailler au changement des approches, changer la culture au sein de l'organisation. Si je vous interroge je suis sûr qu'il y a à peu près des personnes dans cette salle qui ont eu l'occasion de batailler avec leur directeur produit pour le convaincre qu'il fallait faire de la discovery avant de faire du delivery ou vous avez déjà dû aussi avoir l'occasion d'expliquer à votre CEO que faire un release plan sur 18 mois c'était pas possible en fait. Voilà donc clairement
moi je suis assez convaincu que faire du produit convenablement, c'est déjà installer la culture produit au sein de l'organisation et ça, ça demande un effort. Et si vous n'avez pas une personne qui le fait ou qui travaille spécifiquement sur ça, c'est à votre rôle en tant que product manager, en tant que product de le faire. Le deuxième constat que je fais, j'ai remis ici la loi de Melvin Connery qui dit en substance que finalement votre produit c'est le reflet de votre organisation, de votre entreprise. Donc ce qui est intéressant aussi je trouve dans cette citation là, et c'est pourquoi je suis assez convaincu, c'est que finalement si vous n'avez pas une culture produit qui est suffisamment forte, ça va avoir un impact sur votre produit et donc sur votre business de votre entreprise. Vous allez créer des silos entre les équipes, vous allez avoir des frictions dans la communication, vous allez avoir finalement des problèmes d'alignement et tout ça forcément ça va avoir un impact sur la manière dont vous concevez votre produit et forcément sur votre produit et sur votre business. Donc clairement moi je suis assez convaincu que finalement si vous voulez faire un bon produit, il faut intégrer de la culture produit au sein de votre organisation et deuxièmement que votre culture produit, ça ne s'installe pas toute seule. Donc il faut clairement des gens qui travaillent et pour moi c'est un des rôles du Product Ops. L'instant définition, je vais passer rapidement sur la partie théorique, mais clairement j'ai retenu deux définitions qui me parlent assez bien, c'est celle de Mac Lauslin concernant du coup le fait que le Product Ops c'est le product manager de votre organisation de produits. Je la trouve intéressante parce qu'elle est simple à comprendre, elle est en phase aussi avec mes convictions sur ce qu'est le product management et puis c'est aussi ce que j'utilisais finalement comme citation lorsque j'ai fait mon onboarding au sein de l'organisation. Deuxièmement, j'ai choisi la citation de John Cutler, l'ancien product évangéliste d'Amplitude. Je l'ai trouvée intéressante pour deux niveaux. Le premier, c'est que finalement votre Product Ops, il est là pour résoudre les problèmes que les équipes, que les individus ne peuvent pas résoudre. Vraiment les problèmes structurels que vous rencontrez dans votre organisation qui sont des pains pour les PM, pour les équipes produits, c'est au rôle du Product Ops de les résoudre. Également, ce que j'aime bien, c'est la deuxième partie de la citation, c'est que vous avez ici un Product Ops dont la définition reste encore relativement fou. C'est un métier qui est encore relativement jeune et globalement vous allez avoir des contextes, des définitions qui sont différentes d'une organisation à une autre. Donc, pourquoi Brevo a fait appel à un Product Ops ? Globalement, pour vous donner un peu de contexte, Brevo a fait x2 en termes de salariés depuis début 2022 à peu près. Donc, on est maintenant 800 personnes dans huit pays différents, principalement en France, Berlin et en Inde. Et on a du coup 270 personnes qui travaillent à l'engineering et 50 personnes à l'équipe produit. L'engineering et le produit a connu finalement la augmentation un peu massive dans la même période. Côté produit, on est moitié PM, moitié Product Designer, plus une équipe qui s'occupe du Help Center, donc la documentation utilisateur, une équipe UX Researcher également. Donc, pourquoi Brevo a fait l'appel à un Product Ops ? Selon ce contexte, on était déjà passé à l'échelle de manière un peu massive. On a 20 tribes chez Brevo et finalement, il fallait structurer un peu. On se rendait compte finalement chez Brevo qu'avec ce passage à l'échelle, on générait de l'inertie, on avait des problèmes de communication, des problèmes finalement d'engagement des équipes et qu'il fallait essayer de restructurer un peu tout ça un peu mieux. Et puis la deuxième étape, c'est grandir sur le Product Management et développer du coup une meilleure culture produit. Développer la culture produit liée à l'impact, développer la culture produit qui est liée du coup au discovery, optimiser aussi notre pipeline de delivery. Donc concrètement, qu'est-ce que je fais chez Brevo dans une slide ? En fait, je travaille sur le Product Process. Donc le Product Process, ce sont toutes les étapes qui vont de votre signaux faible, de vos insights, de feedback que vous prenez des utilisateurs en passant par la discovery, le solutionning, le delivery jusqu'au Product Launch, comment on lance le produit, comment on communique sur le produit. Donc ça, c'est un peu finalement mon produit, le Product Process, et j'ai pu travailler depuis quelques mois déjà sur différents sujets. Faciliter la collecte des feedbacks pour l'équipe produit, optimiser l'approche itérative lorsqu'on développe notre produit, travailler sur la communication en interne de nos releases, optimiser finalement cette communication. Un niveau un peu plus supérieur, structurer les OKR produits, accompagner du coup les responsables de chacun des OKR de notre équipe, construire l'OKR review, et puis également travailler sur le changement de paradigme sur notre roadmap, passer d'une roadmap au quarter à une roadmap en continue, now, next, later. Donc vous voyez, les tâches, elles sont diverses et variées, mais finalement, elles sont tous identifiées sur une tâche du Product Process. Je ne l'ai pas précisé ici, mais je suis également manager d'un Product DataOps qui, lui, va s'occuper de structurer nos approches et les outils de mesure que l'on va utiliser à destination d'équipes produits. Comment je travaille ? Tout simplement, je définis ce que j'appelle un playbook. Alors, vous allez voir que par la suite, j'utilisais beaucoup le terme de process, mais le terme de process, je le trouve assez rigide finalement. Un process, c'est très, vous faites ça et vous ne faites pas autrement. Moi, je préfère parler de guidelines ou de playbook, c'est-à-dire on pose les fondations de comment on doit travailler ensemble et libre ensuite aux équipes de leur laisser suffisamment d'autonomie pour qu'elles puissent arriver à atteindre l'objectif souhaité. Je travaille forcément aussi sur le paramétrage des outils, la documentation, la manière dont les équipes vont utiliser le process et puis aussi une dimension un peu de coaching, un peu d'accompagnement. Quand les équipes produits ont des besoins qui sont liés finalement à leur activité, qui peuvent être très spécifiques, j'essaie de les accompagner au mieux, de leur communiquer un certain nombre de frameworks, de leur montrer comment on peut réaliser finalement un certain nombre de choses. Allez, je rentre un peu dans le concret et puis je vais vous expliquer un peu comment j'ai mené ma première mission chez Brevo concernant la collecte des feedbacks. Le pitch, c'est lequel ? On avait un besoin, c'est-à-dire mettre en place un outil pour collecter les feedbacks. Vous connaissez peut-être Productboard ou Harvester. Donc voilà, intégrer ce type d'outils au sein de l'organisation tout simplement pour stocker, collecter les feedbacks plus efficacement, les catégoriser afin de les intégrer dans notre roadmap. On a du coup, pour cette première intervention en ProductOps, comment j'ai travaillé ? J'ai fait une session de discovery d'à peu près deux semaines où j'ai rencontré les principales personnes concernées par ce produit, par ce besoin. Donc globalement, on a d'un côté les PM qui eux ont la responsabilité finalement de récupérer les feedbacks, de les catégoriser, de les intégrer dans la roadmap. Et puis ce qu'on appelle chez nous les Customer Experience Agents, donc un peu le support, qui eux sont en fronte avec les utilisateurs au quotidien et qui peuvent nous remonter du feedback. Et eux, ils ont un pain, c'est-à-dire on vous remonte parfois du feedback, on ne sait pas ce qu'ils deviennent ces feedbacks. Et ces feedbacks, on a l'impression qu'ils n'ont aucun impact dans la roadmap. Donc j'ai travaillé au discovery pendant deux semaines, j'ai fait des entretiens avec les personnes concernées, j'ai mis en place le workflow, j'ai mis des empathy maps tout simplement pour bien comprendre quels étaient les principaux points de friction du coup de mes utilisateurs. Une fois que j'ai fait ça, j'ai paramétré l'outil, donc j'ai défini trois versions finalement de trois lots de mon produit avec les use cases qui étaient prioritaires en premier et les sements prioritaires forcément dans un deuxième temps. La construction du process, donc ça se traduit par une documentation assez riche et fournie où là j'ai défini globalement sous format AOTU l'ensemble des use cases et comment les utilisateurs allaient pouvoir l'utiliser. Une présentation un peu magistrale auprès des PM où du coup je leur ai communiqué l'ensemble de la documentation, une petite démo de comment fonctionne l'outil pour leur montrer tout ça. Et puis le projet du coup était terminé, ça m'a pris à peu près un mois et demi. Bon vous vous doutez bien qu'il y a un loup quelque part et que ça a été un gros fail. Oui ça a été un énorme échec et je vais vous expliquer un peu globalement dans quel type de piège je suis tombé. Le premier c'est qu'au bout d'un mois j'avais deux tiers des PM qui n'avaient pas encore utilisé l'outil. Ces problématiques, d'autant plus que côté customer experience agent, eux ils jouaient le jeu. C'est à dire que globalement ils nous envoient à peu près entre 400 et 500 feedbacks par mois, ce qui est quand même pas mal. Et de l'autre côté vous avez les PM qui n'utilisent pas ces feedbacks et qui ne les intègrent pas à leur own map. Donc forcément vous arrivez avec des problèmes qui sont identifiés, vous proposez une solution et la solution ne fonctionne pas. Deuxièmement, je pense que le deuxième piège dans lequel je suis tombé, ce que j'ai appelé overkill, j'avais pas d'autres termes, je suis désolé. Mais je pense que j'ai mis beaucoup d'efforts sur certaines choses où je n'aurais pas dû mettre d'efforts. Premièrement la documentation, je pense que globalement j'ai refait le manuel d'utilisation de l'outil. Et après six mois d'intégration, j'ai regardé un peu les stats, on a 29 personnes qui ont consulté la documentation sur une centaine de personnes qui pourraient être concernées par l'outil.
Vous voyez que l'indicateur il n'est pas top. Pareil sur la phase de discovery, je vous ai parlé de la phase de discovery qui m'a pris deux semaines, c'est une phase de discovery un peu one shot. Vous avez fait votre grosse discovery au début, j'ai pu jamais rouvrir finalement ce document que j'avais pu faire. Le troisième piège finalement dans lequel je suis tombé, quand votre solution ne fonctionne pas, vous essayez de trouver des responsables. Et c'était intéressant finalement de constater qu'on se renvoyait un peu la balle avec les product directors donc les managers d'EPM qui étaient un peu la voix d'EPM qui considéraient que le produit qui avait été mis en place, la solution, ne répondait pas à leurs besoins tout simplement. Et puis moi j'avais un peu cette posture, je me dis ok ce sont les utilisateurs internes mais en même temps c'est les salariés qui répondent aux cadres que l'on leur donne quand ils travaillent. Et finalement la posture utilisateurs qui ont des problèmes, à un moment vous êtes aussi des salariés, vous devez suivre le process. J'étais clairement en tort sur cette réflexion. Donc clairement après ces premières semaines, on va dire que c'était pas forcément la joie sur l'approche que j'avais choisie. J'ai eu l'impression déjà de ne pas apporter de la valeur à l'organisation, à l'entreprise. On doute aussi je pense de ses capacités, de sa propre expertise sur le product management. Et puis l'image aussi que vous dégagez, vous êtes une espèce d'architecte qui fait des plans dans une tour d'ivoire au dessus de sa cathédrale de process. Vous n'avez aucune légitimité à l'organisation puisque vous n'apportez pas de valeur à l'organisation. Donc quand c'est comme ça, je pense qu'il faut être fidèle à ses convictions. Et mes convictions, rappelez-vous le camping de Bretagne, c'est finalement test, mesure, end-learn. Et ça tourne bien puisque à la même période chez Brevon, on commence à réfléchir à la manière de mieux communiquer sur notre product process. Et je vais me servir finalement de ce product process, que vous allez un peu s'affichier ici, pour m'appuyer sur deux chantiers que je vais mener. Le premier c'est comment mieux itérer lorsqu'on développe afin de ne pas provoquer un effet tunnel et essayer de trouver la bonne solution en moindre coût. Et puis la communication en interne sur les releases qu'effectue l'équipe produit. Et donc je vais vous présenter un peu la manière dont j'ai changé mon fusil d'épaule pour adopter une vraie approche Product Management sur mon métier de Product Ops. Premièrement sur le discovery, j'ai laissé tomber le discovery one shot pour favoriser du discovery continu. Comment je fais ça ? Tout simplement déjà des coffee break récurrents avec les PM et les stakeholders qui sont un peu clés avec lesquels l'équipe produit travaille le plus souvent. En clair, j'essaye de prendre chaque semaine, de faire 2-3 coffee break, soit distance soit en présentiel, de 20 minutes avec les PM pour comprendre quelles sont les difficultés qu'ils rencontrent actuellement, mais également pour tester aussi les projets que je suis en train de mettre en place pour voir si en effet ça répond bien à leurs besoins. Ça c'est important, puis finalement quand vous êtes PM, là aussi on vous pousse à faire de la discovery en continu, de faire des interviews en continu. Donc ça c'est la même approche que j'ai décidé de choisir. Deuxième manière de faire du continuous discovery quand on est pour DuckTops, c'est l'analyse des rétrospectives après chaque sprint. Donc tous les deux semaines, je passe un peu de temps dans la documentation qu'on a chez Brevo, donc des personnes qui mettent, les équipes qui réalisent du coup les rétrospectives, pour essayer de voir s'il y a des patterns identifiés, s'il y a des problèmes récurrents que du coup les différentes équipes pouvaient rencontrer. Et ici je vous ai mis un exemple, il y a quelques semaines justement on avait quatre équipes qui se plaignaient du process mis en place sur la traduction. On est un outil en six langues et globalement ce qui était intéressant ici c'était de se rendre compte que les équipes avaient un vrai pain concernant le processus de traduction. Donc une des actions rapides à mener ça a été de discuter avec les localisation managers, essayer de simplifier un peu le process pour permettre d'éviter les problèmes aux équipes. Sur ce point-ci je voulais vous dire c'est que ce qui est important c'est d'identifier des problèmes que les individus ou que vos équipes ne peuvent pas résoudre. Rappelez-vous la citation tout à l'heure de John Cutler, il ne faut pas faire d'interventionnisme sur les rétrospectives. Par exemple, je vous donne un exemple très classique, mais si vous avez une équipe qui a un problème parce que les user stories sont mal détaillées, je n'interviens pas sur ce genre d'élément parce que je considère que c'est aux individus, aux personnes au sein de l'organisation de pouvoir s'améliorer sur leur pratique. Troisième approche, l'analyse quantitative des artefacts, ce que j'ai appelé artefacts, mais pareil toutes les deux semaines je passe un peu de temps sur l'outil qui permet de catégoriser les feedbacks. Là le constat que je fais c'est que je vais devoir revoir ma solution, revoir le paramétrage de l'outil pour favoriser l'adoption parce qu'actuellement cet outil n'est pas du tout utilisé, il est très peu utilisé par l'équipe et clairement il faut que je revoie la solution que j'ai proposée. Inversement, je vous ai repris l'exemple du coup des roadmaps et des documents de roadmaps que je vous ai cités tout à l'heure, là sur le constat que je peux faire ici c'est que je passe toutes les deux semaines et je regarde un peu si les fiches sont correctement qualifiées, si les dates sont à jour afin de communiquer du coup aux différents stakeholders et là le constat que je fais et la solution que je mets en place c'est plutôt sensibiliser les PM, sensibiliser les product directors finalement au fait de suivre ce qu'on a mis en place. Vous voyez finalement selon problème identifié je vais avoir une approche plus ou moins différente. Enfin sur la dernière phase de discovery que je peux mettre en place on a mis en place un conseil Ops, c'est à dire qu'il y a un product Ops, un design Ops, un product data Ops, un engineering Ops, un research Ops donc on est tous un peu nouveaux, on est tous arrivés quasiment en même temps au sein de l'organisation et rappelez-vous que nous tout à l'heure ce qui est important c'est de ne pas générer des silos et je pense que notre rôle en tant qu'acteur qui peut identifier des synergies transverses c'est vraiment important qu'on puisse discuter ensemble et qu'on montre aussi l'exemple d'une certaine manière sur le fait de créer la synergie transverse et donc du coup on se voit une fois par semaine où on parle de nos actualités, on partage également, on essaie d'identifier si on a des projets communs, clairement entre un design Ops, un product Ops et un engineering Ops, vous vous doutez bien qu'il y a bien des interactions qui sont communes et puis on partage aussi sur notre pratique en tant qu'Ops, comment on va faire pour que les utilisateurs, ce qu'on met en place répond aux utilisateurs internes de notre solution. On identifie une solution pour répondre aux besoins de l'utilisateur, déjà j'essaie de co-concevoir avec les PM qui ont des vraies difficultés identifiées, tout simplement parce que comme lorsque vous lancez un produit vous essayez d'accompagner au mieux, d'être au contact au plus proche de vos utilisateurs, vous allez vous adresser aux Early Adopters. Là clairement un PM qui a un problème, qui a une difficulté et vous essayez de l'accompagner pour résoudre cette difficulté c'est un peu votre Early Adopter et clairement lui va être moteur, lui va essayer de trouver une solution à votre compagnie. Donc il faut s'appuyer sur cela finalement pour réussir à le faire. J'essaie de aussi associer cette réflexion un peu plus profonde à des formulaires Slack qui sont un peu plus rapides, où je vais aller prendre aussi un peu de feedback de la part des autres équipes, histoire de m'assurer que je vais dans la bonne direction. Et dernier point important que je voulais vous préciser sur le solutionning, c'est que je parle beaucoup des PM en tant qu'utilisateurs mais ce n'est pas les seuls. Votre organisation de produit finalement est utilisée aussi par vos stakeholders, par d'autres services et là c'est aussi important de vous assurer que vous générez de l'alignement avec vos stakeholders. Par exemple je vous parlais tout à l'heure des communications internes et release, votre utilisateur principal c'est ceux qui vont prendre l'information, qui ont besoin de prendre l'information. Donc il est important de les impliquer dans le solutionning. Petit aparté, que ce soit le discovery, le solutionning, j'essaie d'y passer le moins de temps possible. Pourquoi ? Tout simplement quand on fait du product management, le discovery, que ce soit de problèmes ou de solutions, on l'a mis en place parce que c'est à moindre coût on arrive à dérisquer un projet. On essaie de dérisquer un projet tout simplement parce qu'on sait que développer une solution ça prend du temps et ça prend beaucoup d'argent. C'est pour ça qu'on fait du discovery. Là dans le cadre du product ops finalement, le delivery c'est peut-être la phase la plus simple. Déjà je suis autonome pour mettre en place des choses et deux, les solutions que je vais mettre en place finalement c'est du process, c'est de la documentation, c'est un paramétrage d'outils et ça ça prend relativement peu de temps. Donc globalement moi je prends le parti de me dire rapidement il faut aller vers l'action, il faut mettre en place des choses, on teste, on voit si ça fonctionne. J'ai pas besoin de faire beaucoup de discovery par rapport à ça ou beaucoup de solutionning. Sur le delivery, deux points. Déjà l'automatisation. Donc moi j'utilise Make, il y a Zapier, il y a PyDream qui existent aussi comme outils d'automatisation et ça finalement c'est un peu votre principal outil quand vous êtes product ops. C'est d'essayer d'automatiser au maximum pour faciliter le partage de l'information. Déjà vous allez automatiser un certain nombre de tâches réverbatifs, des tâches qui ont peu de valeur et ce type d'outils ça va vous permettre à vos utilisateurs en interne de gagner du temps. Deuxièmement ça vous évite les double entrées, la double saisie. Alors ici, le bon exemple puisque vous avez que du notion mais si vous interfacez un notion avec un Jira, un product board avec un notion etc etc, évitez de demander à vos utilisateurs de saisir de l'information ici et la même information là parce que c'est pas le même outil. Donc ce type d'outils ça va vous permettre de gagner du temps. Et dernièrement quand vous êtes dans une organisation de la taille de SendingBlue, automatiser ça, ça permet d'éviter les trous dans la raquette en termes de communication. Ça n'empêche pas aux gens de discuter ensemble, on les pousse à discuter ensemble mais au moins vous êtes sûr que vous allez avoir ici l'entièreté de l'information qui va vous servir.
circuler. Ici par exemple, on ne va pas beaucoup, mais j'ai mis en place du coup une automatisation où à chaque fois qu'on a une initiative qui passe dans un statut de développement en développement dans notre roadmap, côté produit, et bien je génère du coup une carte dans un backlog du help center afin qu'ils puissent préparer en amont leur documentation utilisateur. Donc là, selon le service, je l'envoie à telle ou telle personne. Important aussi sur le delivery, c'est d'utiliser du coup des équipes test. Alors ici équipe test ou individu test, mais par exemple, on travaille actuellement sur optimiser la collaboration entre la tech et le produit, optimiser un peu plus notre phase de delivery. Ce qui est intéressant ici, c'est qu'on a identifié deux équipes test, et en général on prend à peu près toujours la même partie, c'est une équipe qui va être un peu moteur, champion, qui a moins de difficultés afin de mettre en place facilement les choses, et une équipe où globalement vous avez beaucoup plus de difficultés. Vous savez que si ça fonctionne sur cette équipe, il y a des chances que vous pouvez ensuite scaler et reproduire ça allant à l'échelle de l'organisation. Troisième tip sur le délivery, c'est le dogfooding. C'est-à-dire que le dogfooding, c'est aussi une pratique qu'on connaît lorsqu'on fait du produit, c'est-à-dire utiliser les produits que vous mettez à destination de vos utilisateurs. En tant que Product Ops, je fais la même chose, c'est-à-dire que moi je suis un Product Manager dans l'organisation, et j'utilise les mêmes outils, c'est-à-dire que j'utilise par exemple le même format de roadmap. On a une roadmap Now Next Letter avec un indicateur d'impact et d'effort, on a différents statuts de nos initiatives, et moi j'utilise la même chose, ça c'est ma roadmap par exemple. Ce qui est intéressant à noter, c'est qu'en utilisant les mêmes outils, je peux identifier des choses qui n'apportent pas de valeur ou qui ne vont pas fonctionner. Ici par exemple, j'avais mis en place une première version du format de roadmap, et je me suis vite rendu compte qu'il y avait des choses qui étaient assez pénibles au niveau itératif, et ce que j'ai fait, j'ai revu ma copie, j'ai proposé une autre version qui a aussi profité au reste de l'organisation. Également sur les rituels, je fais les mêmes rituels que les PM, c'est-à-dire qu'on a une session chez nous de Product Review. La Product Review, c'est une espèce d'oral où on présente un peu nos différentes initiatives de notre roadmap, où on se fait un peu challenger. Je fais la même chose que ces équipes. C'est important, ça vous permet de voir que ce que vous mettez en place va fonctionner ou ne fonctionne pas, et là vous en prenez réellement conscience. On a fait du discovery, on a fait du solutionning, on a fait du delivery, mais il reste à lancer finalement après votre solution. Et là du coup, c'est à mon sens la partie la plus complexe. Comment on assure l'adoption de mes utilisateurs internes par rapport au process, par rapport aux outils, ou quoi que ce soit ? Vous l'avez vu avec l'exemple qui a été un fail, j'ai mis en place des choses, je suis passé à un autre projet par la suite. Clairement, ça n'a pas fonctionné. Donc clairement, il faut favoriser l'adoption. Comment moi je m'y prends ? Déjà, j'adapte ma communication à mon audience. Je me suis rendu compte que la documentation par texte, j'en fais, bien sûr il faut archiver toutes ces informations-là, c'est important pour l'onboarding des nouveaux par exemple, mais lorsque je communique un nouveau process, moi j'utilise un outil qui s'appelle Clap, je crois que son concurrence c'est Loom, qui est un outil qui va vous permettre de générer des vidéos. Je me suis rendu compte un jour, en faisant une première vidéo pour communiquer un process, que c'était plus facile, où il y avait plus d'engagement de la part des PM, j'avais plus de likes sur Slack, j'avais plus de commentaires dans l'outil en question, et je me suis rendu compte finalement que le format vidéo c'est ce qu'attendait les PM pour que je puisse communiquer efficacement. Donc clairement, maintenant, à chaque fois que je fais une évolution de process, je génère une vidéo. Il faut savoir aussi que, comme je vous l'ai dit tout à l'heure, on est sur plusieurs fuseaux horaires, et globalement un format vidéo c'est aussi plus engageant et c'est peut-être plus facile dans le cas d'une organisation internationale comme Brevo. Important aussi, peut-être l'aspect le plus laborieux, j'accompagne les PM ou les utilisateurs des process sur la première. Par exemple, on a mis en place ce qu'on appelle des cartes d'itération, c'est-à-dire globalement des sous-ensembles de vos initiatives que vous travaillez pour la roadmap. Et là, globalement, j'ai une vingtaine de tracks, donc une vingtaine de PM qui travaillent là-dessus. Et ce que j'ai fait, c'est j'ai fait une réunion de 30 minutes avec chaque PM pour pouvoir leur expliquer l'utilisation, pour pouvoir aussi les accompagner pour la mise en place de la première. Là, par exemple, on va travailler sur une qualification d'une information qui surgira prochainement, qui est importante pour le monitoring. De la même manière, j'ai calé 20 entretiens avec des PM. C'est laborieux, mais je peux vous assurer que c'est beaucoup plus efficace que de poser un process et de passer à autre chose. Enfin, sur adoption, qu'il y a d'options, c'est mesurer l'adoption qui est véritablement si important. Ça aussi, mesurer le tracking, l'impact de ce qu'on est en train de faire en tant que PM chez Brevo, je fais la même chose. C'est-à-dire que, globalement, une fois que j'ai mis en place quelque chose, je mesure, je prends du temps pour mesurer et voir si ça a eu un impact. Comment je m'y prends ? Déjà, je définis un impact avant de commencer. Je définis un objectif smart. Je ne reviens pas sur la définition d'un objectif smart, mais en clair, là, vous avez l'exemple de mes cartes d'itération dont je vous ai parlé tout à l'heure. Au dimanche, je considérais comme un succès à partir du moment où j'ai 75% des tribes qui auront créé leur carte d'itération. Donc, vous avez à droite, finalement, le suivi de mon tracking d'impact. Je vois que j'ai atteint le succès. Et, surtout, ce qui est important, c'est aussi de conclure cette itération. C'est-à-dire, globalement, c'est que cette itération, elle prend fin à un moment. Et elle prend fin, ça veut dire faire le constat. Est-ce qu'on a atteint le succès ? Sinon, est-ce qu'on met en place une autre solution ? Si oui, du coup, est-ce qu'on passe à autre chose ? Et à quoi on passe ? Là, par exemple, moi, ça m'a permis de prendre conscience que, certes, j'avais atteint mon indicateur de succès, mais je me suis rendu compte que la qualification des informations que mettaient les P&O dedans, ce n'était pas suffisant. Ce n'est pas ce qu'on attendait. Ça me permet d'identifier d'autres éléments de ma roadmap de ProductOps. Voilà, donc, le constat après, finalement, cette approche-là. Clairement, avant une approche itérative, comme on peut le faire quand on fait du produit, c'est-à-dire développer des petits incréments et voir si cela a du succès, c'est beaucoup plus efficace. Par exemple, sur la communication en interne des releases, j'ai fait quatre itérations avant d'arriver à la bonne solution. Donc, c'est-à-dire, quatre itérations, ça me prend un mois. C'est-à-dire, globalement, je mets en place quelque chose très rapidement, je teste, j'ai l'impression que ça ne va pas dans la bonne direction, je mets en place une autre solution, etc. Donc, j'ai changé mon fusil d'épaule quatre fois avant d'arriver à la bonne solution. Mais au moins, maintenant, on a atteint le succès de notre élément. Sur l'impact aussi, finalement, de cette approche-là, je me rends compte que je suis plus légitime. Ça se traduit par des demandes qui sont formulées par l'APM plus fréquentes sur de l'aide, de l'accompagnement sur les process. Enfin, plus d'impact, plus d'impact pour le Product Ops, plus d'impact pour l'équipe produit. On est beaucoup mieux identifié et aussi plus légitime puisqu'on communique mieux aussi sur ce qu'on fait, grâce aux différents process qu'on a mis en place. Et donc, forcément, aussi plus d'impact business pour l'organisation. Je vais finir sur une note où je vais quand même mitiger. Il y a quand même des limites à l'exercice. Tout n'est pas rose, malgré la slide. Déjà, je vous conseille, c'est de choisir vos combats. En clair, je reprends un peu la citation de Mac Lauslin tout à l'heure sur le Product Ops. Ce qui est intéressant, c'est que quand vous êtes le seul Product Ops au sein de l'organisation, il faut s'atteler à éteindre les petits incendies plutôt que de construire une caserne de pompiers. En clair, ça a été aussi une de mes erreurs. C'est d'avoir une approche un peu stratégique. Je viens du monde du conseil, donc on a un peu cette posture-là parfois. Et ce qui est délicat ici, c'est que ce qu'on attend de vous, c'est que vous éteignez les incendies. Et ce qui est important, c'est d'aller rapidement à l'opérationnel, rapidement résoudre les problèmes que vous pouvez identifier. Autre point, c'est un point que je peux noter qui est compliqué, c'est de réussir à aménager la chèvre et le chou. La team produit, les stakeholders, comme je vous disais tout à l'heure. Le process, il y a plusieurs types d'utilisateurs. Vous avez forcément votre équipe produit, mais vous avez également les stakeholders, le reste de l'organisation. Et ça parfois, c'est compliqué de réussir à faire la part des choses. Je vous l'ai dit tout à l'heure, sur les roadmaps, on considère que ce qu'on a mis en place, il faut qu'on arrive à suivre un minimal process. Donc on attend des PM qui jouent le jeu. Sur d'autres éléments, vous allez considérer que le PM a raison et que d'une certaine manière, la solution qu'on a mis en place, ce n'est pas la bonne. Également, ce que je peux vous indiquer comme étant une limite de ce que j'ai pu constater, c'est le rôle entre le Product Director, entre les Product Directors, les managers finalement des PM, et les Product Ops. Moi, je suis considéré comme celui qui va réfléchir à l'amélioration de l'organisation de produits. La limite, elle est parfois fine entre l'atteinte de cet objectif sur ce qu'on met en place. Vu que j'ai travaillé à définition de cela et que j'essaie de le mettre en place, globalement, je suis parti prenant. Je suis obligé d'atteindre cet objectif-là. Mais parfois, vous avez aussi besoin des Product Directors et parfois, vous vous renvoyez un peu la balle, comme je vous l'ai cité tout à l'heure. Donc la limite, parfois, elle est compliquée de savoir où est-ce qu'on met le curseur entre le rôle d'un Product Ops et le rôle d'un Product Director. Enfin, la limite de l'approche itérative, je vous l'ai cité tout à l'heure. Quand vous changez 4 fois de process une fois toutes les semaines, votre équipe, à un moment, en a marre. Et donc ça, c'est aussi un élément sur lequel il faut faire très attention. Pour réussir à toujours asseoir sa légitimité en tant que Product Ops. Voilà pour ma petite présentation. Merci beaucoup de m'avoir écouté. Si vous avez des questions, je serai ravi d'y répondre. Merci. Applaudissements Oui, j'ai... J'arrive, James. J'ai juste une petite question pour finir par rapport à ta conclusion. Sur les limites...
Quand tu disais, attends je vais reprendre ta slide, tout à la fin quand tu mettais les limites de ton approche itérative, dans ce que tu expliquais, comment est-ce que tu différencies un peu le fait de dire à TPM, bon en fait là il faut que le procès change parce qu'il ne marche pas, VS essaye de, en fait est-ce que tu travailles plus sur la communication, leur dire en gros je suis en train de travailler un produit, enfin un procès produit donc du coup c'est itératif comme ton produit ou est-ce que tu essayes déjà de base d'éviter le nombre de fusils d'épaule, tu sais que tu as changé quand tu disais que tu avais changé 4 fois et du coup tu mets plus de travail en amont potentiellement à rester plus longtemps à creuser, enfin comment est-ce que tu mets le curseur à dire genre c'est l'espèce de syndrome du PM, je ne peux pas rester trop longtemps à creuser mon truc pour finalement finir dans un an à sortir un procès qui sera peut-être parfait mais on ne sait pas trop, c'est l'impact, c'est en clair l'impact que tu as défini par rapport à l'action que tu souhaitais mener, alors je fais mon PM là en fait mais en clair j'ai fixé un objectif à atteindre avant de commencer à travailler, est-ce qu'on a atteint cet objectif, parfois tu l'atteins donc tu ne vas pas forcément revoir le procès, certes il y a des améliorations mais tu as aussi d'autres priorités à traiter, et puis parfois le résultat est mitigé mais tu as peut-être un effort à mettre ailleurs en fait, et globalement c'est du trade-off, simplement c'est de l'échange en compagnie de tes PM, de tes utilisateurs en interne, pour leur expliquer que j'entends le point, je le note mais pour l'instant on va se concentrer sur autre chose parce qu'on a d'autres priorités. Merci, super intéressant, tu as parlé pas mal des silos que tu essaies de casser entre les différentes équipes produits mais aussi les différents stakeholders, et tu as parlé pas mal de l'aspect d'avoir des différentes fonctions Ops, et je me demandais comment tu avais fait pour t'assurer de l'adoption des équipes qui sont plutôt non produits, donc Customer Success, Sales, Go-To-Market en général, qui ont l'air assez impliqués dans ton procès globalement, surtout en termes de feedback, et donc ça m'intéresserait d'avoir ton point de vue là-dessus. J'ai envie de dire que c'est peut-être pas une réponse propre au Product Ops, mais c'est une réponse que tu as peut-être dû connaître, qu'on a peut-être dû connaître tous ensemble au sein de nos organisations, c'est qu'à un moment, il faut avoir de l'empathie et aussi de l'écoute à destination des stakeholders. Donc certes, en tant que Product Ops, j'ai envie de dire que tu es obligé d'avoir cette posture-là, clairement, mais globalement, une manière de traiter ces difficultés-là et les problèmes que tu peux rencontrer, même quand ça ne fonctionne pas, c'est d'être dans l'écoute, dans la transparence, et ce qu'on te répète quand tu es Product Manager finalement, souvent, c'est apprendre à communiquer sur ta roadmap, soyez transparent, même si on rencontre des retards, etc. Et ça, ça passe toujours mieux. Donc globalement, j'adopte ici la même approche, c'est véritablement être dans la communication. Et je considère que c'est mon rôle aussi en tant que Product Ops pour asseoir la culture produit au sein de l'organisation. Bonjour, j'avais une question. Dans ta présentation, tu as beaucoup parlé de process, et je voulais savoir, en fait, il n'y a pas du tout eu de mention de formation des gens, de leurs skills, de savoir ce qu'ils savaient faire, et ainsi de suite. Donc je voulais savoir si c'était parce que c'était dans le scope de ton poste, c'était quelque chose qui était hors scope, ou c'est quelque chose que tu n'avais pas adressé pour le moment. En fait, j'aurais voulu savoir quelle était la limite entre le process ne marche pas parce que la chose ne marche pas, ou c'est parce que les gens n'ont pas forcément les bonnes compétences pour pouvoir faire le process qui va bien, et à quel moment, du coup, la partie formation, upskilling, training, et ainsi de suite, allait être prise en compte, ou pas du tout, dans les opérations du Product Ops. Alors clairement, je sais bien que vous, en tant que Product Ops, ce n'est pas dans mon périmètre de favoriser la montée en compétences des équipes. Je peux intervenir sur, par exemple, le career path, donner mon avis sur ces questions-là, mais c'est le rôle des Product Directors. C'est donc les managers de PM qui sont chargés de les faire monter en compétences sur ces éléments-là. Maintenant, de manière un peu plus épisodique, ça m'arrive de communiquer sur du framework. Dernièrement, j'avais mis en place des sessions de formation sur le story mapping auprès des PM et auprès des engineering managers pour leur montrer comment mettre en place, découper plus finement leurs projets. Mais ça reste véritablement épisodique. Également, j'essaie de travailler à la construction d'un toolkit, où tu vas retrouver différents outils qui vont te permettre d'être efficace en tant que product et que je communique à la team. Et pareil, je pense que je suis à l'avant-garde aussi de la veille au sein de mon équipe produit. Je partage beaucoup de contenus que je peux trouver sur Internet, sur LinkedIn, sur Medium, etc. pour les acculturer sur la culture produit. Maintenant, c'est plus de l'extra que je peux réaliser parce que je pense que c'est important, mais ça n'est pas partie de mon périmètre. Oui, bonsoir. Merci, c'était très intéressant, effectivement. Moi, j'ai une question sur la solution qui a été mise en place parce que tu parlais d'utiliser des solutions, des packages existants, genre type product board ou harvester. Mais est-ce que globalement, c'est plutôt quelque chose de custom que vous avez fabriqué en interne ? Non. Pour vraiment adresser tout le process ou est-ce que c'est utiliser différents outils, en fait, le process ? Alors, on utilise différents outils, en effet. On a un outil de ticketing, on a un outil qui va te permettre de gérer la collecte des feedbacks. C'est intéressant, du coup, cette question-là parce que la posture que moi, j'ai, c'est de me dire aussi plus j'ai d'outils, plus tu génères de l'information à droite et à gauche et ça devient complexe. Et globalement, en effet, ta solution, j'ai envie de dire qu'il y a une réponse très court terme qui est comment tu améliores ce que tu as parce que, du coup, tu as des priorités à traiter. Et puis, tu as aussi une perspective plus longtermiste. Donc, en effet, dans cette réflexion de te dire quel type d'outil je vais mettre en place pour l'équipe, est-ce que demain, on n'a pas un seul produit type, je ne sais pas, Discovery Jira qui permet de gérer un peu tout ça, ça fait partie de la réflexion aussi que je dois mener. Donc, j'ai une approche très courttermiste où j'essaie de résoudre des problèmes. Et puis, une approche où il y a un moment où tu sais que tu vas atteindre la limite de ton exercice avec ta myriade d'outils. Merci pour la presse. Tu as assez peu parlé des objectifs produits, des OKR, à la fois dans la définition des objectifs, mais aussi dans la mise en place du suivi des KPI produits qui peut être un pain pour des équipes. Est-ce que c'est parce que ce n'est pas dans votre scope ou c'est géré ailleurs ? Est-ce que c'est dans votre scope ? Tu as choisi de ne pas en parler. Je n'ai choisi de ne pas en parler, en fait, mais je peux en toucher de bon. On travaille sous format OKR, en effet, au sein de notre organisation de produits, puis au sein de Brevo, finalement. Donc, on a différents OPS. Je vous ai parlé des OPS très tournés, très centrés autour de la construction du produit. Mais on a aussi un revenu OPS, on a des customers OPS, etc. Et donc, on a aussi cette espèce d'ensemble qui travaille, qui échange sur les pratiques. Et donc, oui, c'est un peu notre responsabilité de s'assurer que la définition des OKR, la tenue du planning qu'on se fixe pour les OKR, la revue de ces OKR, le bon fonctionnement des OKR, c'est dans notre périmètre en tant que Product Ops. C'est-à-dire qu'on met en place les outils qui vont permettre de définir ça, les réunions qui vont permettre de définir ça. On anime un peu tout ça. Et après, charge à chaque porteur des OKR. Nous, on a six ou sept OKR cette année côté produits. Donc, on s'assure de mettre en place les outils. Mais après, les responsables pour le bon déroulement de chacun des objectifs, ça, c'est bien sûr chacun des porteurs. Moi, en tant que Product Ops, j'ai moi-même un objectif qui est lié aux OKR produits. Est-ce que les OPM ont aussi des OKR liés à l'adoption des Product Ops ? À l'adoption des... À l'adoption des process que tu définis ? Est-ce qu'eux, ils sont incentivés sur le fait de les utiliser ? Non. Non, non, non. Tu ne peux pas demander... Tu ne peux pas demander un... À l'arrivée d'avoir une grande map à jour, tu peux... L'objectif... L'objectif qu'on fixe OPM sont plutôt des objectifs liés à l'impact business, à l'impact utilisateur. Donc, ce qui est logique, c'est plus orienté Outcom que j'ai envie de dire Output. Maintenant, la responsabilité est d'assurer que ces choses fonctionnent bien. C'est plutôt de mon côté. Et la partie Product Analytics, en fait, c'est aussi un truc qui est chez vous ? Oui. Les OCR, les objectifs principaux. Mais après, pendant ton OPM, je vais avoir des PIs... Des indicateurs secondaires ou tertiaires que je vais vouloir creuser. Parfois, ça peut être une idée... On a... Mais tout à fait. Ça fait partie de mon périmètre en tant que Product Ops. Moi, je... D'un point de vue opérationnel, je manage, du coup, un Product Data Ops, qui est sous ma responsabilité, qui, lui, a, dans son quotidien, la mise en place des outils, s'assurer que les datas sont bien collectées. Quand on a des événements à créer, s'assurer qu'on travaille avec les Data Engineers pour bien retrouver l'information. Mais travailler sur des événements aussi un peu plus stratégiques. Comment tu vas aller chercher de la donnée de revenu pour associer avec la donnée d'usage, pour que tu permettes...
de prendre les meilleures décisions qu'il soit. Donc ça c'est bien un sujet de Product Ops. Moi j'ai la chance d'avoir une personne qui s'en charge dans mon organisation, mais si j'étais seul sur ce sujet, forcément ça aurait été une de mes priorités. Merci beaucoup pour la présentation. De ce que je comprends aujourd'hui, il y a un Design Ops, un Engineering Ops, mais t'es tout seul sur la partie Product Ops. Est-ce que selon toi c'est suffisant ou pas ? Ça filme ou pas ? Je pense que quand tu as vu le nombre de personnes que tu as dans l'organisation Produit et Tech, forcément tu choisis tes combats. T'es le seul, t'essayes de mettre tes efforts sur ce qui génère le plus de valeur pour l'organisation. Maintenant si du coup on souhaite avancer plus vite sur des changements de pratiques, là ça risque d'être compliqué. Après c'est comme dans toutes les organisations Produit, j'ai envie de te dire. Tu veux faire évoluer tes pratiques, t'as pas de Product Ops qui s'en charge. Souvent ça va être ton manager finalement. Ça va être les managers, les Product Directors, les CPO, qui vont pousser justement pour le changement des pratiques, qui vont conduire ce changement-là. Et là du coup, en tant que seul Product Ops, on se répartit aussi les tâches. Je parlais tout à l'heure de l'alliance avec les Product Directors. Ils sont aussi moteurs dans le changement des pratiques. Ils vont s'assurer que les équipes utilisent les nouveaux outils, essayent de comprendre et de prendre du feedback. Donc d'une certaine manière c'est aussi des relais. Donc j'ai envie de te dire, ça dépend de tes organisations et de l'effort que tu as envie de mettre là-dessus tout simplement. Si tu devais avoir plusieurs Product Ops dans une organisation, est-ce que tu ferais plutôt en fonction du nombre d'équipes produits, du nombre de produits ? Comment tu ferais ? C'est une bonne question. Il y a un article de Mac Lauslin sur Medium qui explique justement comment scaler le Product Ops avec une posture qui est plutôt, je vais positionner du coup un Product Ops par verticaux, par domaine, par tribe, selon la manière dont il est organisé. J'aurais tendance à penser que c'est mieux d'avoir des relais au sein de l'opérationnel du côté Product Ops et de pratiquer de cette manière-là. Après ça reste de la théorie, ce que je suis en train de te citer. En pratique je ne sais pas. Product Ops, on est d'accord que c'est un métier qui est encore émergent, qui n'est pas encore bien défini. Donc j'ai deux questions en une. La première c'est comment est-ce que tu as fait pour définir ton scope ? Parce que j'imagine que ta manière d'exercer ce métier de Product Ops n'est pas le même que dans une autre organisation. Et de deux, est-ce que les gens comprennent vraiment ce que tu fais en interne ? Mes amis ne comprennent pas ce que je fais. Quand tu as des amis qui ne font pas de Product Management, déjà c'est compliqué de leur expliquer ce que c'est le Product Management, c'est leur Product Ops. Blague à part, du coup j'ai sorti une blague, j'ai oublié de la première question, excusez-moi. La première question c'est comment est-ce que tu as fait pour définir ton scope, ta base, ton rôle ? En clair, je pense qu'avant d'arriver, forcément le VP Product, le CPO avait identifié des axes d'amélioration. Des axes d'amélioration pour l'équipe produit, des axes d'amélioration sur l'organisation. Et forcément quand tu arrives, tu prends le temps de discuter avec tout ce petit monde pour essayer de comprendre où sont les problèmes. C'est ce que j'ai fait aussi un peu. J'ai une posture un peu ayant fait du conseil, tu vois. J'ai passé un peu de temps pour discuter avec les gens, comprendre leurs difficultés. Donc j'ai fait pas mal d'entretiens en arrivant pour essayer de comprendre là où j'avais mis les pieds et quels étaient les problèmes les plus prégnants. J'ai quand même passé beaucoup de temps, je trouve, à faire cette phase d'analyse de l'organisation, alors que je pense que j'aurais à le refaire, tu vois. Je pense que j'aurais été rapidement sur résoudre des petits problèmes à droite et à gauche plutôt. Ensuite, sur ce que fait le métier, je pense que ça prend du temps. C'est aussi, d'une certaine manière, je pense qu'il faut mettre beaucoup le nez dans l'opérationnel, mettre les mains dans le cambouis, montrer que tu apportes de la valeur finalement à l'organisation. Encore une fois, ça c'est un apprentissage du monde du conseil. Je pense que quand tu arrives et que tu arrives dans une nouvelle organisation et que tu as des choses à prouver, il faut montrer rapidement que tu apportes de la valeur. Donc ma posture, clairement, c'est il faut rapidement montrer que tu vas générer de la valeur et tu vas accompagner à droite et à gauche. Le ticket d'entrée, parfois, il est un peu élevé. Ça prend de l'effort, mais c'est une manière de légitimer aussi ce type de métier. Merci beaucoup pour le partage. C'était très intéressant et j'ai fait les mêmes erreurs que toi. Je pense que je n'avais pas bien compris. Tu disais que c'était un nouveau métier Product Ops. Aujourd'hui, je prends conscience en fait en quoi ça consiste. Dans ma dernière mission, on appelait ça Product Manager interne. J'étais Product Manager interne parce qu'il y avait un outil qui était développé en interne. Du coup, ce que j'aimerais savoir, c'est est-ce que tu te bases, est-ce que tu proposes des solutions uniquement sur des outils no code ? Concrètement, quels sont les types de solutions que tu apportes ? Techniquement, je veux dire, est-ce que c'est que du Notion et du Zapier ? Ou est-ce que ça peut être aussi des outils développés internes ? Ma deuxième question, et je termine là-dessus juste, c'est est-ce que tu as eu à rencontrer des points de friction avec d'autres PM, sur des problèmes de synchronisation, sur des features qui étaient attendus sur les produits externes, et peut-être que la solution aurait pu apporter en interne ? Je ne sais pas si ma question est claire. Je te réponds sur la première déjà, puis je répondis ensuite sur la deuxième. Sur la première question, non. Je fais aussi pas mal de veille sur les solutions que peuvent utiliser les gens du produit, au sein de mon équipe, tout simplement. Et ça, sur tout le spectre qu'utilise un product manager, des product designers, etc. Tout simplement parce que j'ai aussi la responsabilité de m'assurer que l'investissement qu'on va mettre dans ces outils soit efficace. Donc globalement, c'est à la fois des outils qu'on a sur le marché, du Notion, du Jira, du Full Story, d'Amplitude, etc. Et puis parfois, tu mets en place aussi un certain nombre de mécaniques au travers du Pybrim, du Zapier, etc. pour répondre à un certain nombre de besoins. Maintenant, je continue à faire de la veille sur les différents outils que je mets en place, sur les différents outils qui existent sur le marché pour toujours améliorer aussi la vie et le quotidien du produit. Et ta deuxième question, du coup, excuse-moi, c'était ? C'était, est-ce que tu as eu à rencontrer des points de friction avec d'autres PM sur des features qui étaient attendus, soit côté produits, produits utilisateurs externes, ou soit des solutions qui auraient pu être apportées sur des outils internes ? Pour être bien sûr, moi, je ne développe pas un produit au sein de l'organisation qui va être utilisé en interne. Je m'assure que je mets à disposition les bons produits, les bons outils pour les PM. Donc globalement, je ne développe pas moi, je ne suis pas PM d'une solution qu'on développe en interne pour juste une utilisation interne. Est-ce que j'ai des points de friction sur les, avec, rencontrés avec les PM ? Oui, parfois. Tout simplement quand ton process ne répond pas aux attentes ou quand ça génère de la, ça génère de l'inertie pour ton PM ou globalement, le produit ne répond pas aux besoins ou le PM ne joue pas le jeu, tu vois. Donc forcément, tu as toujours des discussions pour savoir comment essayer d'optimiser les choses. Reste encore une question ou rendez-vous sur la terrasse ? Dernière question du coup. Tout à l'heure, tu avais parlé d'un échec. Quelle est ta plus grande réussite en tant que product top sur cette organisation du coup ? D'un point de vue projet, je pense que c'est véritablement le sujet de communication interne. Je pense qu'on avait une approche de communication qui était très, enfin on sortait beaucoup de projets qui prenaient deux, trois mois, etc. Donc on a clairement changé notre approche aussi. C'est-à-dire que là, on pousse pour que les équipes génèrent des petites itérations et génèrent de la valeur. Et donc globalement, ça permet de renforcer la communication aussi qu'on a là-dessus. Pour vous donner un indicateur, pour donner un indicateur chiffré, on a communiqué au mois de mars autant de releases qu'on avait communiquées les dernières. Donc avec des effets pervers aussi parfois. Parce que quand tu as trop de communication, les gens te disent « Est-ce que vous avez vraiment besoin de communiquer là-dessus ? » J'en ai content. Mais globalement, ce qui est intéressant, c'est que là, ça génère véritablement de la valeur. Et tu as des feedbacks de la part des stakeholders qui disent « Oui, la visibilité qu'on a sur les releases est bien plus importante. » Donc oui, je pense que c'est une réussite de cette action-là. Merci beaucoup. Bonsoir, merci pour cette présentation. J'avais une question par rapport à ta structure. Comment valorise-t-elle justement et mesure-t-elle cette plus-value que tu apportes ? Est-ce qu'il y a des capillaires qui sont connus dans le domaine du Product Ops où on retrouve globalement un peu ça partout ? Ou est-ce que vraiment c'est quelque chose qui n'est pas palpable et qui se retranscrit directement dans ce qu'amènent les PM ? Je pense que si on ne mesurait pas l'impact de la découverte de ce qu'est le product pour l'octave et si on ne pourrait pas miser en échange et diviser en deux, par rapport
mon métier au sein de Brevo, on passera à côté de ce que je t'ai montré qui est de dire qu'il faut qu'on soit drivé par l'impact d'une certaine manière. Donc de la même manière, moi en tant que salarié de l'organisation, j'ai des objectifs qui sont fixés tous les semestres de la même manière que les autres PM. C'est comme ça aussi que tu mesures le succès finalement de tout ça. Après les mesures pour mesurer l'impact, je pense qu'il y a des mesures qui sont liées au temps que va prendre tes utilisateurs pour réaliser une tâche. Donc ils mettent beaucoup moins de temps pour catégoriser le feedback etc. Ça va être aussi une métrie de satisfaction. Je pousse des surveilles après ce qu'on a pu mettre en place afin de s'assurer que je prends un peu de feedback qualitatif. Là, c'est la même chose qu'un PM. Tu vas mesurer l'usage, tu vas mesurer la satisfaction et tu vas potentiellement mesurer le revenu. Ce revenu, c'est beaucoup plus dur je pense pour moi, mais c'est intéressant. C'est comme ça que je mesure aussi le succès de ce qu'on va mettre en place et ça c'est pas très différent d'un PM. Quantitatif sur les usages, clairement je te l'ai montré tout à l'heure avec la mesure de l'utilisation des artefacts. Ça permet de sortir de la data. Le nombre de releases qu'on peut faire, ça reste très quantitatif et là tu es sur de l'usage véritablement. Et puis du quali avec de la satisfaction, est-ce que du coup vous trouvez qu'on communique beaucoup mieux sur les releases ? C'est quoi les points de friction que vous avez pu relever par rapport à ce qu'on a mis en place dernièrement etc ? Est-ce que ça va et est-ce que ça va mieux qu'avant ? Donc on essaie d'avoir des indicateurs un peu C7, un peu NPS d'une certaine manière. Merci beaucoup Mickaël. Merci à vous.