Transcription

• Speaker #0

  Bonjour et bienvenue sur Be My Product, le podcast dédié aux produits et à ceux qui les incarnent. Chaque mois, nous ouvrons le micro à des acteurs diversifiés du monde du produit, des concepteurs aux utilisateurs pour découvrir comment ils donnent vie à leurs idées et innovations. Restez avec nous pour des insights uniques et des histoires inspirantes. Bonjour à tous et bienvenue dans ce cinquième épisode de Be My Product, votre rendez-vous avec l'univers du product management. Aujourd'hui, j'ai le plaisir d'accueillir une figure bien connue du milieu, Alexandra Lung, Fractional CPO et Coach Produits. Alexandra, c'est super de t'avoir avec nous. Prête à nous parler de ton parcours et de tes expériences ?

• Speaker #1

  Bonjour, Jérôme. Oui, carrément.

• Speaker #0

  Avant qu'on plonge dans notre discussion, un petit rappel pour nos auditeurs. B-MyProduct est divisé en deux parties. La première d'environ 25 minutes est consacrée à découvrir le parcours de notre invité. Ensuite, on passe à un sujet choisi par l'invité. Alexandra, tu as choisi de nous parler de comment planifier efficacement, prévoir la vélocité et les risques d'un produit. Prête pour ce partage de connaissances ?

• Speaker #1

  Yes.

• Speaker #0

  Alexandra, pour ceux qui ne te connaissent pas encore, peux-tu te présenter et nous parler de ton rôle actuel ?

• Speaker #1

  Bien sûr. Moi, c'est Alexandra Lung et je suis Fractional CPO et coach produit. J'aide les entreprises qui ont besoin de professionnaliser les différentes pratiques produits afin de réduire la perte de temps et aussi le développement des produits ou des fonctionnalités qui n'ont pas d'héroïne. Donc, en fonction du besoin, je propose soit un audit, un accompagnement en mode mission Fractional CPO. Ou sinon, dans certains cas, plutôt du mentoring afin de pousser la croissance avec des bons choix et des bonnes méthodes produits.

• Speaker #0

  C'est hyper clair. On va maintenant parler un peu de ton parcours. Comment as-tu commencé dans le product management et quelles étapes importantes as-tu franchies ?

• Speaker #1

  J'ai commencé il y a plus de 15 ans. Donc en fait, à l'époque, le produit n'existait pas vraiment comme aujourd'hui. Je disais que souvent, les équipes produits faisaient partie des équipes marketing. Et je faisais plutôt un mix des projets marketing produits. Et je pense que... Pour moi, les différentes étapes que j'ai franchies, je pense que ce qui était intéressant pour moi, c'était vraiment à chaque fois, j'ai pris les différentes opportunités et les challenges. Et je pense que c'est aussi le fait de ne pas forcément avoir trop de cases où on s'est dit, est-ce que je peux le faire ou pas ? Par exemple, mon premier CDI, c'était des chefs de produits. Et en fait, par exemple, c'était un CDI où ils demandaient 7 ans d'expérience. Là, moi, j'ai postulé, j'avais un an avant d'expérience et j'ai eu le poste et c'était hyper enrichissant par la suite. Et en fait, pour moi, c'était un peu sur les différentes étapes. À chaque fois, c'était l'idée de me dire, OK, qu'est-ce que j'ai envie d'apprendre par la suite ou qu'est-ce qui est en train de se passer sur le marché ? Par exemple, je viens d'une formation ingénieure, même si j'ai toujours fait du produit et business. Et à un moment, je me suis dit, ouais, j'ai envie d'aller vers quelque chose qui est en train d'être très innovant. À l'époque, il y avait le cloud computing qui commençait vraiment à exploser avec AWS, Microsoft et tout. Du coup, je me suis dit, je veux aller dans ce monde-là. Et du coup, là, j'étais pour la première fois à la tête d'un SaaS qui était lié au cloud. Donc en fait, c'est vraiment pour moi les étapes à la fois de grandir, on a des nouvelles challenges, des nouvelles compétences, mais aussi plus en maturité, en management et en leadership.

• Speaker #0

  Ok, c'est super clair. Et tu peux un peu nous partager quelques expériences marquantes de ta carrière avant de devenir coach produit ? Je pense que c'est important de connaître un peu le parcours de l'invité pour connaître un peu comment tu arrives à ton rôle actuel au final.

• Speaker #1

  Yes. Moi, au début, j'étais chef de produit dans deux grosses boîtes et par la suite, je faisais un peu l'opposé. Je suis partie comme first PM dans une boîte SaaS. Et je pense que c'était une des expériences qui m'avait pas mal préparée parce que c'est hyper intéressant. Je pense que quand tu fais ça, tu touches à tout. Comme premier PM pendant trois ans, je ne faisais pas que du produit et du design. Je faisais aussi l'avant-vente, je faisais aussi du marketing, de la communication, un peu la stratégie. C'était quelque chose d'assez formateur, mais c'était aussi quelque chose qui m'avait...... un peu fait me dire, OK, je fais tout ça, mais qu'est-ce que j'aime le plus ? Et ce qui m'a fait me dire, en fait, ce que j'adore, c'est vraiment cet aspect produit.

• Speaker #0

  Ce côté touche-à-tout, c'est ça ?

• Speaker #1

  En fait, j'aimais bien le touche-à-tout, mais en fait, je me suis dit, OK, vendre et faire la vente, c'était un bon challenge. Mais en fait, une fois que j'ai relevé le défi, ce n'était pas la chose qui m'animait le plus. Je préférais plus être au cœur de comment on va concevoir le produit, comment on va gagner sur le marché avec ce produit. Et du coup, ma chance que... Par la suite, j'étais partie dans une boîte qui était hyper forte en méthodologie parce que je me suis dit, j'étais first PM, j'ai touché à tout. J'aime ce côté produit, je veux faire plus, mais je veux le faire d'une manière beaucoup plus professionnelle. Et du coup, il y avait une boîte américaine qui était très forte en méthode qui est entrée en France à ce moment-là, qui était Pivotal Labs. Et du coup, je suis partie chez eux et c'était une partie très marquante de mon parcours parce qu'en fait, j'étais dans une division consulting, mais c'était un peu particulier parce que tous les trois mois, en fait, on avait un autre projet. Donc, c'était un projet très court. où les clients étaient en mode, on a mis 2 millions dans ce produit, ça ne marche pas, vous avez 3 mois pour le sauver, entre guillemets. Et je n'étais pas seule, j'étais en fait avec d'autres collègues à moi qui venaient de San Francisco, de Londres, de Berlin, de partout, qui étaient déjà depuis un moment dans la boîte et tous ensemble, on coachait et on faisait le projet avec le client. Donc en fait, toutes les choses qu'on lit un peu, tu vois, encore dans les livres, nous on les adaptait, on les faisait tous les 3 mois et je voyais le résultat, mais juste wow ! Et en fait, ça m'a à la fois beaucoup... formé mais ça m'a aussi donné envie de prendre le challenge du public speaking. Et je pense que c'était aussi une expérience qui a pas mal marqué ma carrière parce qu'au début, c'était un peu, je pense, challenge. J'ai envie de partager à quel point ça peut bien marcher si on fait les choses un peu différemment. Et par la suite, je pense que ça m'a énormément aidée sur ma communication, sur mon storytelling en tant que leader produit par la suite. Et ça me plaît. J'adore toujours le faire, mais ça m'a fait beaucoup peur. beaucoup beaucoup apporté. Et par la suite, forcément, je pense qu'il y a eu des étapes plus leadership où j'ai leadé les équipes de la école des produits et design entre les séries B et D. Donc c'était vraiment la phase de hyperscale. Il fallait un peu jouer surtout sur la réorg, sur les équipes, sur la stratégie, sur les process. Par la suite, j'étais CPO dans une fusion acquisition. Donc là, il y avait trois entreprises qui étaient achetées par un fonds. Moi, je suis arrivée comme Global CPO. au moment de la fusion acquisition. Donc, en fait, c'était hyper intéressant de vraiment faire la vision du groupe, la stratégie du groupe, bosser directement avec les investisseurs, le chairman, les CEOs. Et puis, j'étais CPO pour une boîte dans l'IoT. Donc là, du coup, on mixait software et hardware. Et c'était hyper intéressant, du coup, de voir à quel point il y a des choses qui sont vraies, mais des choses qui peuvent être aussi différentes. Très, très intéressant. Et par la suite, du coup, je m'étais mise à mon compte. Je savais qu'après cette expérience, je voulais me mettre à mon compte. Et je pense que tout ça, ça m'a préparée parce que forcément, j'ai vu beaucoup de choses très différentes. On apprend aussi énormément.

• Speaker #0

  Oui, donc tu as vraiment une palette de carrière, en tout cas dans les postes que tu as occupés. Tu as une palette quand même de skills et de postes qui est très large. Tu es passé un peu partout. Comment tu as découvert vraiment le product management ? C'est dans cette première société américaine ou il y a une autre expérience particulière qui t'a marqué ?

• Speaker #1

  En fait, je pense que ce qui est intéressant pour moi, c'est que pendant ma carrière, je n'ai pas vraiment eu l'impression qu'il y a eu un moment où j'ai découvert le product management, où je me dis waouh, je veux faire du product management C'est qu'en fait, je pense qu'à chaque fois, un peu à la maturité, à ma maturité, à la maturité des boîtes que je voyais, j'avais l'impression que je fais du product management. C'est juste qu'effectivement, je pense que c'est dans cette boîte américaine où je me suis rendue compte qu'est-ce que c'est vraiment le modern product management et si c'est bien fait. Je l'ai vraiment vu et vécu plusieurs fois là-bas, bien fait. Et je pense que c'était un tournant très important dans ma carrière. Mais en fait, en absolu, à chaque fois, je prenais un peu le prochain challenge. Je n'ai pas eu un moment où je me suis dit, je veux faire Product Management. Parce qu'en fait, pour moi, c'était un peu une évolution d'un peu plus de 15 ans où en fait, le Product Management, la scène de Product Management changeait aussi. En France et à l'international, moi aussi un peu avec.

• Speaker #0

  Oui, donc en fait, tu ne mettais pas le mot Product Management sur ta carrière. Tu l'as découvert vraiment au fur et à mesure avec l'évolution du métier.

• Speaker #1

  Je pense que même au début de ma carrière, je disais, je suis chef de produit, je fais du produit, mais en fait, c'est très différent de ce qu'on voit maintenant. Et en fait, j'ai parfois des gens qui me disent, mais comment tu as décidé d'être product manager ? En fait, je me dis, quand je faisais mon école d'ingénieur, ce métier n'existait même pas. Quand j'ai pris mon premier job et je bossais pour un sort de VC fund à l'époque, ça ne s'appelait pas un VC fund. Et en fait, du coup, j'essaye parfois de mettre des mots de maintenant, sur les choses qu'on faisait à l'époque pour que ça soit un peu une sorte de traduction.

• Speaker #0

  On y voit maintenant un peu plus clair sur ta carrière. le chemin que tu as parcouru et les différents postes que tu peux avoir et responsabilités. On aimerait maintenant connaître un peu les ressources, les podcasts ou les livres qui t'ont inspiré ou aidé dans ta carrière. Qu'est-ce que tu recommanderais à nos auditeurs ?

• Speaker #1

  J'adore lire. Je vais toujours me lire. Je pense qu'au début de ma carrière, j'ai plus commencé avec des classiques, un peu comme la stratégie de l'océan bleu et des livres comme ça. Et par la suite, je pense que c'était vraiment les livres un peu comme Skilling Lean, Hedgeman, par exemple. en tant que manager, j'adore Radical Candor, aussi de Kim Scott. Je recommande vraiment après comme manager, mais même sans être manager, forcément. Pour la partie plus négociation, j'adore Never Split the Difference, qui est un livre de Chris Voss, qui était un négociateur FBI avant. Il y a beaucoup de bons podcasts aussi. J'écoute pas mal celui d'Eleni aussi. Je trouve qu'il touche à des sujets assez stratégiques et pas juste produits, que produits, mais qui sont toujours hyper intéressants.

• Speaker #0

  Tu peux nous développer un peu plus le livre Stratégie de l'océan bleu parce que c'est un classique. Il y a peut-être pas mal de gens qui ne le connaissent pas. C'est sur l'analyse d'opportunités, c'est ça ?

• Speaker #1

  Oui, en fait, l'idée, c'est de se dire comment je peux trouver dans un marché la partie qui n'est pas encore, où tout le monde ne baigne pas encore et où je peux avoir une forte différenciation.

• Speaker #0

  Oui, exactement.

• Speaker #1

  Pour vraiment gagner sur cette partie. partie là au lieu de me dire bon bah on fait ça vas-y je vais aussi je pense dans le même océan entre guillemets mais comment je peux trouver une niche différenciante et ce marché différent.

• Speaker #0

  Et Scaling Lean tu peux nous en parler brièvement pour donner un peu envie à nos auditeurs de le lire peut-être ?

• Speaker #1

  Je pense que c'est vraiment bon c'est vraiment la partie Lean Management ou Lean Product Management qui a un peu commencé il y a un moment sur le concept d'essayer d'éviter le je sais toujours pas comment bien traduire en français le waste Le fait de faire des choses qui ne vont pas servir.

• Speaker #0

  Le gaspillage.

• Speaker #1

  Le gaspillage, exactement. Donc, en fait, de bien analyser tes opportunités, de les tester, d'y aller de manière itérative et de t'assurer qu'au moment où tu commences à mettre de l'argent et du temps dans quelque chose que tu es en train de développer, c'est quelque chose sur lequel tu as déjà une certaine certitude et que tu as déjà dérisqué certains aspects. Et je pense que ça casse aussi beaucoup toute la partie cyclone V. Tu vois, on faisait, je pense que peut-être il y a encore des entreprises qui le font d'une certaine manière. On se dit, on va créer tout ça et après, on va voir. Et après, le waste, parfois, il est énorme parce qu'un an plus tard, quand ça sort, le marché n'est plus le même. Les clients ne veulent plus la même chose. La concurrence est là avec des choses différentes. Et du coup, c'est complètement gaspillage.

• Speaker #0

  Les choses évoluent vite, oui, c'est vrai. Bon, maintenant qu'on connaît un peu plus ta personnalité et ton parcours, on va vraiment se focus sur ton rôle actuel de coach et de CPO. C'est vrai que parfois, le rôle de coach est souvent bien mystérieux. On ne sait pas trop ce qu'ils font, ce qui se passe, ce qui se fait. Tu peux un peu nous décrire ton rôle et tes responsabilités actuelles et comment ça impacte tes clients.

• Speaker #1

  Oui, oui. Donc moi, j'ai deux modèles. En fonction du besoin des clients, en tant que fractional CPO, je vais prendre en main complètement certains sujets. Ça peut être des choix clés du produit et des priorisations, la montée en compétence des équipes et le management des équipes, des nouvelles méthodes qu'il faut adopter pour être plus efficace, etc. Il y a toujours aussi des aspects de vision, des stratégies produits qui manquent dans pas mal d'entreprises. Donc ça, c'est plus en tant que fractional CPO. Après, pour certaines entreprises, je les accompagne plus en tant que coach. Et du coup, dans ce cas-là, je travaille soit avec le CEO, soit avec le leader produit, plus sur ces challenges. Et du coup, ça peut être pour mes clients, ce que je fais récemment, par exemple, c'est le redesign d'une organisation, des grilles de compétences du PM, du hiring. La stratégie produit, c'est quelque chose qui revient aussi pas mal. La gestion des feedbacks et des priorisations. la monétisation et la stratégie du pricing. Donc voilà, ça peut être une variabilité assez large en fonction du besoin du product leader.

• Speaker #0

  Ok, c'est super clair. Tu peux nous parler un peu plus de ta touche personnelle ? Moi, je suis intimement convaincu que chaque product people est assez unique dans sa manière d'aborder les choses et de travailler. Tu pourrais nous donner, par exemple, trois exemples concrets qui illustrent ta singularité dans ton approche produit ?

• Speaker #1

  C'est une super question. Oui. Alors, je pense qu'une des choses pour moi, c'est toujours le fait que je… je vais me focaliser sur faire du produit en levier de croissance de la boîte. En fait, quand j'arrive dans une boîte, ou même quand j'étais CPO, ou maintenant avec mes clients, je ne vais pas juste m'intéresser, par exemple, je vais voir la data d'utilisation de mon produit, et ça, c'est tout. Je vais vraiment aller comprendre quels sont les enjeux business, poser des questions sur, OK, quel est le lifetime value, quel est le coût d'acquisition, vraiment comprendre et faire rapidement le tri entre les différentes informations business, produits, marketing et tech. et par la suite, faire des choix produits qui vont impacter le ROI. Donc en fait, vraiment, je vais toujours regarder tout ça, globalement, pour le lier au business.

• Speaker #0

  Toi, tu as vraiment cette vision business, tu es axée business. C'est vrai que souvent, on a cette vision produit. Toi, tu remets un peu le business et la croissance au cœur du produit.

• Speaker #1

  Exactement. Je vois encore, tu vois pas mal de SPOs, des personnes avec lesquelles je parle, qui disent Oui, mais ça, c'est un truc de la boîte, ça, c'est au CEO. Moi, je veux faire mon bout, je veux attendre que le CEO me dise ça. Et en fait, moi, je trouve que tu ne peux pas. Tu ne peux pas ignorer ces aspects, sinon tu ne peux pas vraiment lier ce que tu fais, côté produit, à la présence de la boîte. Et finalement, on le fait pour ça, on le fait pour avoir un ROI et aussi pour satisfaire nos clients. Mais il faut bien avoir ça en tête. Et du coup, moi, c'est quelque chose que je fais assez naturellement. Parfois, ça peut challenger un peu parce qu'il faut aller trouver des réponses. Parfois, on n'a pas encore les réponses niveau boîte, mais je trouve que c'est essentiel pour avoir un vrai impact avec le produit.

• Speaker #0

  Et puis on a souvent aussi des sociétés où les autres comme business ne sont pas là. Quand on les demande ou qu'on les cherche, c'est très compliqué de les avoir. Et donc c'est très compliqué aussi de mettre le business au centre du produit.

• Speaker #1

  C'est ça, c'est ça. Souvent, le cœur de la boîte, c'est d'arriver à X millions de chiffres d'affaires. Bon courage les amis du produit. Et du coup, c'est ça, je sais faire ce lien et aller poser certaines questions et définir certaines choses pour qu'après, je ne sors pas du chapeau. On ne fasse pas juste des fonctionnalités. On peut se dire que le chiffre d'affaires augmente, mais on ne sait pas trop. quoi et si nous on le fait ou pas.

• Speaker #0

  Et tu as une deuxième singularité dans ton approche produit qui t'est propre ?

• Speaker #1

  Ouais, ouais, ouais. La deuxième je dirais c'est un peu, j'ai mentionné un tout petit peu tout à l'heure, mais c'est la partie storytelling. Tu vois je me rends compte qu'à chaque fois quand j'arrive dans une boîte, j'essaie deux choses où à la fin je vais définir une vision claire, mais il faut qu'on sache où on va, genre on a une direction très claire, mais après pour embarquer les équipes, j'ai beaucoup de storytelling pour inspirer les gens, tu vois, et c'est basé sur des choses. très concrètes parce qu'il faut aller dans un sens clair pour pouvoir les inspirer. Mais je pense que c'est cette partie storytelling et inspiration, c'est hyper chouette parce qu'à chaque fois, je vois que les gens, tu vois, ils me suivent, ils sont inspirés, ils sont embarqués. Et du coup, c'est quelque chose qui est hyper important. Toute cette partie où on va raconter une histoire, on va communiquer, on va vraiment embarquer les gens avec nous. Et c'est quelque chose que, bon, je pense que maintenant, ça vient assez naturellement parce que ça fait longtemps que... Je fais cette partie aussi plus en public speaking.

• Speaker #0

  Donc en fait, c'est aussi les remotiver au final. Le storytelling sert à les motiver.

• Speaker #1

  Oui, oui, oui. Et je pense que, bon, il faut que ça aille, comme je disais, une base solide où on ne va pas juste raconter quelque chose et on se dit que c'est une bonne histoire, mais après, on se dit, mais il y a quoi derrière ? Je fais quoi ? Il faut qu'ils aillent vraiment les moyens et la clarté pour le faire. Mais je pense que pour motiver les équipes, c'est essentiel. C'est essentiel et beaucoup de fois, on sous-estime cette partie. On se dit, bon, pour moi, c'est clair dans ma tête. Je vais leur dire. ils vont faire et mon chiffre d'affaires va augmenter. Mais en fait, en réalité, ça ne se passe pas vraiment comme ça.

• Speaker #0

  Et tu as une troisième, peut-être, qualité à nous partager qui illustre ta singularité ?

• Speaker #1

  Troisième, je dirais, je pense que c'est quelque chose qui est à la fois peut-être une particularité, mais aussi une manière dont je fonctionne. Je pense que c'est la partie efficace. Je veux faire bouger les choses. Et c'est parce que je pense qu'il faut que ça bouge pour atteindre les objectifs, mais aussi parce qu'en fait, pour moi, c'est vraiment cette partie impact qui est importante. Donc en fait, en général, c'est... Dans cette partie efficace, c'est que oui, je connais pas mal de frameworks, mais pour moi, ce qui est très important, c'est de faire ce qui marche. Faire ce qui marche à l'instant T et commencer assez rapidement, commencer à avoir des résultats et par la suite, itérer, itérer, itérer.

• Speaker #0

  Ok, très clair. On va maintenant passer un peu aux qualités que tu considères pour toi essentielles pour être un excellent coach produit ou un advisor. Ce serait lesquelles ?

• Speaker #1

  D'abord, je pense que l'expérience est l'essentiel. Il y a tellement de sujets et le fait de les avoir vus à de multiples reprises, dans différents contextes, ça donne vraiment cette richesse et cette capacité à résoudre des challenges d'entreprise beaucoup plus rapidement. Parce que finalement, oui, il y a des sujets qui se répètent un peu, mais si on les a vus dans plein de contextes et on a essayé plein de choses auparavant, je pense que c'est hyper précieux. Je pense que pour être un bon coach, il y a quand même toute cette partie d'expérience qui est super importante. Après, je pense qu'il y a beaucoup la partie aussi capacité d'écoute. Pouvoir écouter, pouvoir poser les bonnes questions et par la suite pouvoir analyser et très rapidement faire le tri de ce qui est important, sur quoi j'agis, qu'est-ce qu'il faut faire.

• Speaker #0

  Et trouver des actions.

• Speaker #1

  Exactement. Oui, il faut aller concrètement vers les actions et pouvoir le faire assez rapidement. En fait, on pose les questions clés, on analyse et on sait où on va agir.

• Speaker #0

  Le côté efficace.

• Speaker #1

  J'ai un peu biaisé ma réponse. Et après, je pense qu'il y a un point très important aussi, c'est le fait de... Ça lie peut-être un peu avec l'expérience du début, mais aussi proposer, adapter des frameworks. En fait, les clients, beaucoup de fois, ils viennent vers nous et est-ce qu'ils ne savent pas comment faire ? En fait, ils n'ont jamais fait. Ils n'ont jamais fait d'une manière professionnelle, vraiment, comme un stipio qui a fait ça X fois, comme nous, on a pu le voir auparavant. Et du coup, je pense que c'est important de leur amener un framework qu'on adapte ensemble.

• Speaker #0

  Donc, tu conseilles souvent des gens qui sont démunis de solutions et tu leur apportes un... un peu des modes opératoires, des manières de procéder pour leur faciliter la vie et surtout, tu arrives à les adapter au final.

• Speaker #1

  Parfois, les gens ne se rendent pas toujours compte du fait qu'ils ne vont pas me dire je suis démunie des solutions ils vont plutôt être en mode j'ai fait cet atelier, ça a duré trois heures, avec tout le codire, ça n'a donné rien et je suis en train de réfléchir, comment faire ? Et du coup, tu vois, c'est un peu différent parce qu'effectivement, les gens ne vont pas venir en disant oh mon Dieu, je ne sais pas du tout, qu'on fait, c'est assez rare, mais en fait, il leur manque un framework et un sort de guide. Tu vois, souvent, je suis en mode Voilà, moi, je fais ça dans X contextes différents. Je le fais de quatre manières différentes. Regarde, il y a un peu ces étapes-là. Voyons ce qui peut s'adapter et comment on peut le faire pour toi. Je pense que ce genre de, tu vois, avoir un peu ces étapes et framework, ça aide en tant que coach et advisor.

• Speaker #0

  On va maintenant passer... au challenge et réussite. Puis Bimei Productions, c'est vrai qu'on valorise vraiment la transparence. On voudrait savoir dans ton parcours, c'est quoi les défis, les réussites qui t'ont particulièrement marqué ? Tu peux un peu partager avec nous sans filtre les hauts et les bas de ta carrière en commençant par les bas, si tu es d'accord.

• Speaker #1

  Yes, yes, yes. Je pense, il y en a pas mal des deux côtés. Je pense que dans le poste de premier PM que j'avais eu il y a plus de dix ans, il y avait pas mal de hauts et des bas et surtout quelques bas où il y avait des apprentissages. Pour moi, par exemple, on était sur un SaaS B2B très grand compte et à un moment, on avait notre premier grand compte, il faisait 80% de notre chiffre d'affaires. Donc, en fait, on nous a dit qu'il fallait faire un SaaS spécifique pour lui, on va faire une version que pour ce client-là. Et en fait, moi, je ne le sentais pas trop, mais bon, finalement, avec l'insistance des parties présentes, on l'a fait. Et après coup, tu vois, pour moi, c'était vraiment une erreur. C'était ingérable, hyper compliqué. C'était vraiment un désapprentissage. Je me suis dit, OK, il ne faut pas faire ça. Il ne faut plus faire ça. Ou pareil, tu vois, on avait, je pense qu'on a tous un peu vécu ça. Et peut-être on en parlera plus tard. Ils voulaient faire un grand événement en marketing. À un certain date, ils nous ont dit que pour cette date, il faut avoir toute cette liste de features. Sinon, on n'a pas de prospects, de clients, de budget marketing. C'est pour rien. Et du coup, c'était hyper compliqué parce qu'on n'avait pas pu faire comprendre à notre CEO le fait que c'était juste impossible de faire ça. Les équipes sont épuisées. À une semaine de l'événement, on s'est rendu compte qu'on ne pouvait pas. On a montré à plus B qu'il nous reste une semaine et c'est impossible. On a fait des features en mode démo pour le fameux événement. Et le jour après l'événement, on a fait un petit démonstration. il y a trois développeurs qui ont posé leur démission et presque tout le reste de l'équipe qui a pris trois semaines de congé en fait ce que tu as vécu c'est un échec produit et tu n'as pas réussi vraiment à t'en relever de celui-là je pense que à l'époque c'était ma première expérience parfois c'est très difficile de faire comprendre à un CEO surtout quand tu es au début c'était mon premier poste où je le faisais comme ça et comment ce serait mieux de le faire en absolu c'est rebondir quoi

• Speaker #0

  Comment remotiver les équipes ? C'est un sujet dans lequel on a parlé dans un précédent épisode du podcast, comment se relever d'un échec produit. C'est vrai que ce n'est pas évident du tout.

• Speaker #1

  Oui, après, on a réussi, mais le coût est énorme. Par la suite, bien sûr, tu te relèves, tu réembauches les gens, tu essaies de remotiver les gens, de donner une direction, mais dans le même temps, les gens qui sont partis, les gens qui sont fatigués, ça a un coût. C'est un coût que, beaucoup de fois, on ne voit pas avant. Et après, je pense que voilà, c'est peut-être une deuxième chose que je pense que c'était aussi un bas pour moi dans ma carrière. À un moment, j'ai fait un burn-out et c'était un moment assez difficile. Ce n'était pas vraiment lié à la chance de travail, c'était plus lié à l'environnement toxique, à un clash de valeurs. C'était une période qui n'était pas évidente, mais à la fin, ça m'a appris aussi beaucoup de choses. Ça m'a appris des choses sur moi, sur ce que je veux, sur mes valeurs, sur comment mieux trouver l'équilibre et l'environnement.

• Speaker #0

  Le plus important, je pense, c'est comment tu t'es relevé un peu de ce challenge, ce burn-out, cet environnement toxique, ces valeurs d'entreprise que tu ne partageais pas ?

• Speaker #1

  Ça m'a pris un moment et j'ai demandé de l'aide. J'ai eu la chance d'avoir aussi un executive coach à l'époque. qui m'a aidée vraiment à me poser des questions très clés sur le long terme. J'ai dû me poser plein de questions, tu vois, sur qui, quel type de leader je suis, qu'est-ce que je veux, dans quel type d'environnement je peux fonctionner. Même, tu vois, c'est un peu de cette époque-là qu'est venue l'idée de j'adore ce que je fais, mais je ne veux pas bosser cinq jours par semaine jusqu'à la fin de ma vie. À un moment, j'aimerais me mettre à mon compte. Je ne l'ai pas fait sur le coup, j'ai attendu un moment avant de le faire, mais en fait, il y avait plein de choses qui ont ressorti de toutes mes réflexions de l'époque.

• Speaker #0

  Ok, très clair. On va maintenant passer vraiment sur la partie réussite. Ça suffit de parler de négativité. C'est quoi un peu les expériences et les moments forts que tu as vécu de ce côté-là ?

• Speaker #1

  Pas mal. Je pense que c'est chouette. Un peu dans chaque expérience, on a aussi plein de réussites. Je pense que, tu vois, ce que je disais, par exemple, ce qu'on faisait chez Pivotal, où en trois mois, on refaisait des produits, on coachait les équipes. Tu vois, c'était des réussites. On voyait tous les trois mois des super résultats. Et pour moi, c'était une période… C'était dur ce qu'on faisait, mais c'était… plein de réussite et du coup c'était génial parce que tu vois par exemple quand je suis arrivée chez Aircall, toute la réorganisation de l'équipe, le management, le fait que j'ai réussi à faire ça très vite et qu'à la fin l'équipe était vraiment une équipe scalable et avec des gens hyper bien. Je pense chez Signature, le fait d'avoir fait en quelques mois juste après mon onboarding une vision du groupe, une stratégie avec les investisseurs et les CEO. Pareil dans ma prochaine boîte d'IoT, pareil en trois mois après mon onboarding, j'ai réussi à refaire avec le Codio tout ça. toute la stratégie, même la vision de la boîte.

• Speaker #0

  Il y a tant de réussite de ton côté, c'est pour ça.

• Speaker #1

  Moi non, je pense qu'à chaque fois, on a des hauts et des bas, tu vois, comme on disait tout à l'heure.

• Speaker #0

  Mais là, tu n'as plus à choisir, beaucoup de réussite.

• Speaker #1

  Peut-être que je suis aussi très positive, je vois beaucoup l'air.

• Speaker #0

  On va maintenant passer vraiment à la seconde partie de l'interview. Tu as décidé, Alexandra, d'aborder le sujet de comment planifier efficacement son produit. Tu es prête ou pas ?

• Speaker #1

  Allons-y.

• Speaker #0

  On va commencer par une question très simple. Comment tu planifies efficacement une roadmap produite pour qu'elle reste ambitieuse mais réalisable ? Et comment décide-t-on que l'objectif est atteint ?

• Speaker #1

  C'est génial, mais avec ta question, je pense qu'effectivement, tu dis comment on décide que l'objectif est atteint. Pour moi, il faut commencer de ça. Il faut déjà que l'objectif soit clair. Et beaucoup de fois, je vois des roadmaps où on a plein de choses qu'on va délivrer, mais en fait, l'objectif n'est pas super clair. Ou l'objectif, il est du genre, le Sion nous a dit qu'il faut augmenter le CA. et qui n'est pas quelque chose qu'on peut... parce qu'on fait directement un produit, on peut lier. Donc, je pense qu'il faut que déjà cet objectif soit clair et qu'on ait un métrique à impacter. Ce métrique à impacter, il faut que ce soit un métrique auquel on peut se lier vraiment et qu'on peut suivre comment il produit. Et aussi dans ces objectifs, en plus de ces métriques à impacter, c'est aussi le pourquoi. Pourquoi on fait ça ? Et du coup, si cet objectif est clair, l'impact, si on l'a ou pas, ce sera presque un no-brainer. Ce sera aussi assez facile à voir par la suite dans ce qu'on sort de notre roadmap. Par la suite, pour planifier et créer efficacement une roadmap, il y a aussi toute la partie en amont. ou c'est quelque chose sur lequel on travaille beaucoup. Je travaille en tant que CPO, même avec mes clients, c'est tout ce qui est la gestion des feedbacks et des demandes. Ça peut être aussi des demandes internes. Et en fait, tu as toujours plein, plein de sources. Donc, une fois, tu m'appelais sur, c'était un moment, OK, comment je vais gérer tout ça ? Donc, en fait, là, je pense que c'est hyper important, pareil, d'avoir un process, d'avoir un tool parfois. Ça m'est arrivé, par exemple, d'arriver dans une boîte et j'étais incapable de prendre des décisions. On a pris du plan de deux mois pendant l'été. où on a analysé tout ça pour vraiment pouvoir prendre des décisions informées. Et du coup, cette partie, une fois que tu as un process, un tool, là tu vas pouvoir déjà voir plus clair dans les différentes choses sur lesquelles tu peux agir. Mais ici, je pense qu'il y a aussi un autre aspect qui est très important, c'est le fait que beaucoup de fois, les feedbacks ou les demandes, c'est plutôt des solutions. Et il y a aussi dans ce process toute la transformation de même si on me demande une solution, il faut que j'aille comprendre le problème. Du coup, dans ce process, c'est aussi le fait de si quelqu'un à mon interne me demande ça, il faudrait comprendre à la fois l'impact et le problème. L'utilisateur m'a dit ça, mais pourquoi il me dit ça ? Donc, une fois que tu as tout ça, une fois que tu as toute cette gestion, un peu de feedback, des demandes et des opportunités, il y a la priorisation. Je pense qu'il y a plein de frameworks qu'on trouve partout, mais il faut trouver celui qui fonctionne bien, qui est efficace pour l'équipe à l'instant T. Le faire aussi en mode assez itératif parce que parfois, on a un problème, une solution et ils se disent, voilà, j'ai ce problème, j'ai 10 idées de features, je vais les faire toutes et comme ça, je suis sûre que ça va marcher. En fait, non, il faut vraiment y aller en mode itératif. C'est-à-dire, bon, déjà, je vais faire deux ou trois, je vais suivre l'impact et par la suite, je vais voir si je vais, de nouveau, le lien avec l'objectif qu'on disait au début et l'impact. En fait, en absolu, c'est un sujet que j'adore, les roadmaps, et je parle beaucoup de ça, mais je suis aussi une grande advocate de ce qu'on appelle les outcome-based roadmaps, donc vraiment les roadmaps qui sont focalisés sur l'impact et la valeur parce que ça pousse à vraiment comprendre le problème et l'impact avant tout.

• Speaker #0

  Ok, tu peux peut-être nous clarifier un peu ce qu'est une outcome-based roadmap et faire peut-être un peu… nous expliquer, donner un peu la différence entre un outcome et un output. Je pense que c'est un bon rappel, surtout pour les gens qui commencent dans le produit.

• Speaker #1

  Exact. Donc en fait, un output, c'est qu'est-ce que nous délivrons. Donc c'est en général déjà une idée de solution, une solution, c'est un output. Le outcome, c'est plutôt le pourquoi nous le délivrons. Quel est le changement pour l'utilisateur que nous allons causer ou pousser avec ce que nous allons délivrer. Donc en fait, c'est vraiment cette différence entre qu'est-ce que je délivre et pourquoi je le délivre. Donc, en fait, je dirais un outcome, c'est un peu la différence qui est faite par un output.

• Speaker #0

  Et en quoi ça consiste alors, un outcome-based roadmap exactement ?

• Speaker #1

  En fait, c'est une roadmap où on va déjà commencer avec les problèmes. D'ailleurs, c'est intéressant parce que quand je commence à introduire ce concept, beaucoup de fois, je prends un exemple un peu concret de l'équipe. Mais sur le voilà, on est en train de faire ça. Et en fait, la plupart des fois, la première conclusion, c'est Ah mince, mais en fait, on ne comprend pas le problème. On nous a dit de faire ça. Ou parfois, on me dit, je dis, mais pourquoi on fait ça ? Quel est le problème ? Le problème, c'est que les concurrents ont ça et nous, on n'en a pas. Mais en fait, ça, ce n'est pas un problème de l'utilisateur. Et si toi, tu prends quelque chose que le concurrent fait, tu te dis que tu dois faire la même chose sans comprendre le problème, tu vas faire une sorte de copie pas terrible de ce que le concurrent fait et ton impact, tu ne sauras pas du tout le définir parce qu'en fait, tu ne comprends pas trop pourquoi tu l'as fait. Donc, beaucoup de fois, tu vois, j'ai un peu les réponses d'image. Je le fais parce qu'on ne l'a pas, parce que le concurrent l'a. Et en fait, après, en creusant, on se rend compte qu'on ne comprend pas.

• Speaker #0

  super bien le vrai problème. Et du coup, une fois qu'on comprend bien le problème, on peut prioriser des problèmes et pas juste des solutions. Donc, tu vois, même la priorisation prend un autre niveau. Et une fois qu'on a ces problèmes, on peut se dire, OK, quel est l'outcome ? Quel est le changement que je peux avoir pour les utilisateurs ? Quelles sont les idées des solutions et quels sont les KPIs ? Donc, en général, pour moi, c'est le minima de ce format-là. Et d'un coup, tu vois, tu as beaucoup plus cet aspect de, OK, je comprends déjà très bien, mais je lis surtout l'impact directement et je sais le suivre par la suite.

• Speaker #1

  C'est super clair Alexandra. Maintenant, on va passer à la question 2. On va parler un peu d'intention et d'engagement. Quelle est ta perspective sur l'engagement versus l'intention dans une roadmap ? La roadmap est-elle vraiment adaptée à une approche agile et aux changements fréquents ?

• Speaker #0

  C'est une super question. J'en sais aussi la question qui fâche parce qu'on nous demande toujours Est-ce que vous pouvez faire tout ça pour le 5 juillet ? Je pense qu'en absolu, pour moi, ma perspective, c'est que c'est vraiment… Ce que je dis souvent en anglais, c'est a statement of intent and direction C'est vraiment la partie intention. Mais ce qui est très important, c'est que cette intention doit venir vraiment d'une approche minimisation des risques. Il y a tout un travail en amont que nous, on fait pour s'assurer que, comme je disais tout à l'heure, on a des problèmes qui sont validés avec les utilisateurs, qu'on a testé des risques et des solutions qui sont les plus risquées. Et du coup, tu vois, ça, ça nous donne déjà, si on a bien fait tout ce travail en amont, ça nous donne déjà des épiques ou des… thèmes dans notre roadmap sur lequel on a un niveau de confiance plutôt élevé. Après, ça va être sur une échelle, je ne sais pas, en deux mois, on ne peut pas dérisquer sur un univers très large. Mais en tout cas, voilà, tant que tout ça s'est bien dérisqué et s'est bien aligné avec les objectifs, ça ne devrait pas changer énormément. Après, il faut quand même être très flexible parce qu'il y a des choses qui peuvent se passer. Les marchés changent, des choses comme le Covid arrivent, donc en fait, il faut aussi s'adapter rapidement. En général, je me dis, si on a bien fait le travail en amont, pour le prochain mois, peut-être deux mois, il n'y a pas énormément de choses qui vont changer, mais bon, il faut quand même garder une certaine flexibilité. Après, je vois des fois, parce que ça, c'est tout ça, voilà, on prépare, on planifie ce qu'on va livrer, mais il y a une partie qui est hyper clé et que je vois quand même beaucoup d'équipes qui ne sont pas vraiment très efficaces ou qui galèrent quand même sur cette partie, c'est le delivery. Je vois beaucoup d'équipes qui n'arrivent pas à vraiment maîtriser leur delivery et leur vélocité. Et pour moi, c'est... hyper important d'avoir une certaine prédictibilité. Je ne suis pas pour dire tout le temps à nos stakeholders que je vais toujours protéger mes équipes et ne pas donner des dates fixes pour tout ce qui sort. Mais par contre, j'attends que mes équipes, je les aide, qu'on soit maîtres de cette prédictibilité et de cette vélocité. Et du coup, ça implique de mesurer des métriques comme le lead time et le cycle time, ou que les devs arrivent à vraiment estimer ensemble. Pas juste une personne qui estime et si cette personne n'est pas là, on ne sait pas comment faire. Tout le monde estime ensemble de manière cohérente dans le temps. ou que le sujet soit aussi bien compris et dégrossi en amont.

• Speaker #1

  Tu peux nous donner des exemples justement de comment tu fais ? C'est quoi tes méthodes que tu mets en place justement pour aligner cette équipe et l'engager vraiment à qu'ils prennent position ?

• Speaker #0

  Beaucoup de fois en fait, c'est des petites actions je dirais, mais qui sont hyper importantes. Mais déjà, je pense qu'il y a des choses comme le pourquoi on le fait. qui on peut passer des côtés. Comme on disait parfois, même l'objectif n'est pas très clair. Donc, il faut vraiment avoir un peu cette clarté du on a vu, c'est ceci-là, on le fait pour avoir cet impact-là. Et ça, je pense que c'est déjà un peu une base. Idéalement, toute l'équipe devrait se dire c'est cool, on va faire ça, c'est quelque chose d'hyper chouette au lieu de juste se dire bon, j'écris du code ou je fais X ou je fais Y Bon, c'est comme ça. Après, il y a des choses aussi, je pense, dans les différents rituels. souvent qu'on regarde et qu'on peut changer des choses qui peuvent être bêtes mais la manière dont tu vois il se comprend et ils ont des conversations autour du user story j'ai vu des équipes où c'était vraiment c'était très triste on montrait les stories, personne ne parlait, personne ne posait des questions tout le monde disait on a tout compris et après on sortait trois bagues en production tu voulais vraiment dynamiser un peu en fait l'idée c'est vraiment avoir des personnes qui s'impliquent mais aussi qui co-créent finalement et qui posent des questions qui parfois peut-être s'il y a des choses qui sont trop grandes avoir un pré-meeting Le pre-grooming, où on regarde juste avec le lead dev et se dire, OK, ce sujet-là, est-ce qu'on peut le prendre ? Est-ce que tu peux regarder déjà ? Quelles sont les dépendances ? Quelles sont les complexités ? Ou le prendre en discovery un peu technique. Tout ce genre de conversation, parce que souvent, c'est vraiment plutôt des conversations qui ne se passent pas, mais qu'il faut ritualiser d'une certaine manière et d'assurer en parallèle aussi que l'équipe soit assez investie.

• Speaker #1

  Oui, donc en fait, toutes ces problématiques rejoignent un problème principal qui est l'implication de l'équipe au final. Et c'est un peu de redonner du sens au produit dans l'équipe. Tu disais tout à l'heure la question du pourquoi avec le Start With A Way, qui est assez connu. Et vraiment, le but, c'est de donner du sens. Et c'est vrai qu'on a du mal à avoir des équipes impliquées quand elles n'arrivent pas à avoir du sens sur le produit sur lequel elles travaillent.

• Speaker #0

  Oui, oui, c'est carrément ça. C'est donner du sens et c'est aussi leur donner certains moyens. Tu vois, par exemple, à un moment avec les équipes avec lesquelles je travaillais, on s'est rendu compte qu'on n'avait pas ce calcul de lead time, par exemple, dont je parlais tout à l'heure. Et en fait, on ne savait même pas combien de temps ça prend depuis qu'il y a une idée qui arrive jusqu'à ce qu'on soit en production. Ton soin n'est pas important parce que je ne vais pas juger si ça te prend une semaine ou du mois. Mais c'est plutôt, tu vois, une manière de se dire pourquoi, qu'est-ce qui nous bloque ? Et aller un peu à la source des différents bloqueurs aujourd'hui pour par la suite commencer à débloquer soit au niveau du management, soit au niveau des équipes et déjà prendre conscience des choses qui nous bloquent. Par la suite aussi suivre pour améliorer ces chiffres et comprendre aussi les différents bloqueurs et après donner vraiment des, je pense que voilà, dans la Gilles avec... Tchagile ou les équipes qui travaillent ensemble, ils vont toujours trouver les différents rituels ou les différentes choses à mettre en place pour rendre concrètement plus efficace toute la partie de comment on écrit les user stories, comment on les discute ensemble. Il faut vraiment avoir une conversation dans le grooming, comment on suit aussi. Parfois, je vois des équipes où il y a un truc depuis trois semaines, on est bloqué. On ne sait pas pourquoi. Et du coup, tu as tout ça, ça ne donne vraiment pas de vélocité de prédictibilité et ça montre que ce n'est pas vraiment efficace. Et peut-être que c'est juste un truc qui était trop grand et qu'on aurait dû splitter, ou c'est peut-être un truc dont on est bloqué et qu'on ne l'a pas dit. Mais il faut vraiment avoir un certain process qui fonctionne dans l'équipe, qui rend les choses assez fluides.

• Speaker #1

  Oui, et éviter justement qu'il y ait des choses qui traînent et qui ne sont pas prises à l'encontre.

• Speaker #0

  Exactement, qu'on évite de jeter un peu la balle, ça rejoint un peu la motivation aussi, d'un à l'autre en disant non mais c'est le PM qui ne m'a pas dit, c'est le dev qui ne m'a pas dit parce que moi je ne savais pas, mais non c'est le designer qui n'a pas fait je ne sais pas quoi

• Speaker #1

  Toujours pareil, un problème de motivation et d'engagement. Justement, en parlant de delivery et discovery, comment toi dans une roadmap, tu arrives à trouver l'équilibre entre les deux et comment tu arrives à la planifier justement pour prendre en considération ces deux phases du product management lifecycle ?

• Speaker #0

  Moi, j'ai toujours le fameux double track où les PM et les designers vont faire toute cette partie delivery en amont. Et en fait, tu sais, comme je disais, il y avait le outcome-based roadmap, tu commences avec des problèmes. Donc, en fait, qui sont un peu now, next, later. Et en fait, du coup, les PM et les designers vont toujours être un peu en amont. Parfois, les devs aussi, dans pas mal de cas sur certains sujets. Du coup, ça, ça te donne le temps de pouvoir faire aussi cette partie discovery, s'introduire au delivery. Mais en fait, ce que je vois dans pas mal de cas en ce moment, c'est que je trouve parfois des équipes qui arrivent à faire du discovery pas trop mal, mais qu'en fait, là où ils galèrent le plus, c'est le delivery qui ne suit pas. Et j'ai l'impression qu'il y a parfois des boîtes où il y a un peu ce hype de on va faire du bon product management et on va bien creuser toutes les choses On amuse, ce qui est très bien, mais en fait, c'est ce qui délaisse toute cette partie de après, il faut que je sois capable de délivrer, il faut que je le fasse d'une manière efficace Et du coup, pour moi, le message, c'est vraiment de dire que le delivery, il est important et passer du temps à rendre efficace le delivery. C'est essentiel parce que ça ne sert à rien d'avoir toutes ces idées si ça te prend le double du temps. Et en plus, si la qualité ne suit pas et que tu sors des choses avec des bugs et qu'après, ça te prend X temps à régler les choses. Et en plus, ça fait de la communication autour de ce qui a marché ou pas marché. Et d'ailleurs, tu vois, on parlait de planification de la roadmap. Je pense qu'il y a plein d'éléments qui rentrent dedans aussi. Il y a toute cette partie. Quand je mets en production, quelle sera ma stratégie ? Si c'est un truc assez grand et impactant, je ne vais pas le mettre d'un coup à tous les clients. Peut-être que je le mets pour quelques clients, je prends des feedbacks. J'ai toute une partie marketing aussi de comment je vais communiquer, si c'est des grosses fonctionnalités.

• Speaker #1

  Tu as vraiment un go-to-market sur lequel il faut faire très attention, à la fois sur la manière de communiquer, mais aussi de délivrer. Parce qu'on délivre un énorme nombre. Et c'est assez intéressant ce que tu racontes. Pour revenir un peu sur les problématiques de delivery, certes on bifurque un peu du sujet de la roadmap, mais c'est quoi le constat des erreurs principales que tu as ? Je parlais tout à l'heure d'efforts qui étaient concentrés sur majoritairement Discovery, dans le constat que tu fais en 2024 des sociétés, avec peut-être un manquement sur le delivery. C'est quoi un peu les problèmes majeurs que tu constates toi dans les sociétés au niveau du delivery ? Et c'est quoi les conseils que tu donnerais pour l'améliorer ?

• Speaker #0

  Je vois différentes choses. Par exemple, j'ai des clients où je vois les PM qui galèrent beaucoup, même à avoir le temps de donner du travail aux développeurs parce qu'ils sont pris dans plein de choses, vraiment dans des gestions complexes, des parties prenantes, des analyses, plein de choses. Et en fait, je pense qu'on oublie, et mon conseil, c'est de se dire que si j'ai une équipe de développement, la priorité, c'est qu'ils aillent, je ne veux pas dire juste des choses à faire, ils aillent des choses avec un impact à faire. Mais pour moi, c'est une des choses à prioriser, parce que parfois je vois des ratios où il y a pas mal de PM, pas mal de développeurs, et pourtant ils disent mais on a du mal, comment ça peut se faire ? Je pense que c'est très important aussi de prioriser dans le cadre du rôle du PM. Après, les choses que je vois aussi assez classiquement, c'est que parfois j'ai des entreprises où il n'y a pas vraiment de user stories, ils sont écrits par les développeurs qui prennent le sujet un peu à la volée, ou par des data scientists, des équipes aussi un peu plus liées à l'IA et tout. Et en fait, tu vois, c'est le titre de quelque chose. Tu ne peux pas faire des QA.

• Speaker #1

  Bien sûr.

• Speaker #0

  En mode, non, mais on va perdre le temps. De toute façon, le père est en train de faire autre chose. Et en fait, ils ont l'impression que ça marche. Mais en fait, si tu commences à regarder la partie qualité, la partie combien de temps ça prend, la partie comment tu creuses en amont et tout, en fait, c'est hyper inefficace. Oui,

• Speaker #1

  donc ça crée énormément de techniques derrière puisque tu n'as pas de definition of ready, tu n'as pas de definition of done et tu n'as aucun critère d'acceptance. Et en plus, généralement, le titre, il n'est pas clair. Donc, ça n'a pas de sens.

• Speaker #0

  Mais en fait, tu vois, de l'extrude, tu regardes ça, tu te dis, mais ça, c'est juste pas clair. Et pareil, tu vois, beaucoup de fois je vois même dans les cas où tu as un PM qui écrit les stories et toute l'équipe qui travaille dessus, il y a quand même beaucoup de malentendus où les gens ne se posent pas forcément les questions, tu vois, où on dit oui, oui, je prends ça. Et quand quelqu'un prend le ticket, il commence à se poser des questions et à se dire ah mince, mais en fait ça, je ne sais pas et qui pourrait répondre à ça ? Et du coup, tu vois, ça crée tout un travail qui aurait pu être fait un peu de manière plus efficace, soit pendant le grooming, soit en amont, où une personne est un peu bloquée, ne regarde pas elle-même. pas et en fait ça dure hyper longtemps. Ou parfois la qualité. Je vois beaucoup de choses liées à la qualité tu vois où tu sors des bugs qui sont soit des incompréhensions, soit des choses qui sont pas bien testées. Toute cette partie test elle est aussi hyper importante. Elle est beaucoup de fois faite vraiment avec des QA ou des développeurs qui font tous les tests, qui intègrent tous les tests. Et tu vois, déjà, ça ne fait pas mal. Je pourrais encore continuer. Oui, bien sûr. C'est pour ça, je pense que c'est hyper important de vraiment se poser sur cette partie de librairie et se dire que c'est clair, parce qu'on a mes idées et la résolution de tous ces problèmes qu'on a vus et de ces opportunités, il faut qu'elles soient faites d'une manière temporelle, intéressante et avec une qualité qui est là.

• Speaker #1

  Je pense qu'on te l'invitera peut-être pour un prochain épisode pour en parler. En attendant, on va revenir sur les questions un peu plus roadmap, sur le sujet d'aujourd'hui. Pour toi ? Je pense qu'une question qui revient souvent, ce serait quoi le laps de temps idéal sur lequel une roadmap devrait s'étendre ? Trois mois, un an, et quand et comment les mettre à jour pour qu'elles restent pertinentes et utiles ?

• Speaker #0

  Ah oui, j'ai toujours cette question. Je vois un peu de tout. Pour moi, c'est vraiment, tu vois, beaucoup de fois, j'ai des initiatives stratégiques qui peuvent être un peu sur l'année, mais c'est des choses assez high level pour donner un peu la direction dont je disais tout à l'heure. On sait un peu dans quelle direction on va, mais dans la roadmap... tel quel, en général, je fonctionne pas mal avec le now, next, later. Et je sais que mon now et next, c'est un peu les prochains trois mois. Et je pense que voilà, comme je disais tout à l'heure aussi, on fait bien le travail en amont, on sait que ces trois mois, c'est assez dérisqué et on peut suivre l'impact et itérer par la suite. Et on a déjà un peu une idée, bien sûr, des problèmes qu'on va tacler, des opportunités qu'on va tacler pour le quartier prochain. Mais en général, tu vois, pour moi, les roadmaps sur un an, C'est compliqué parce qu'il y a plein de choses qui peuvent changer en fait. Tu ne sais pas ce qui va se passer dans un an. Tu peux donner un peu une direction, mais faire une liste de fonctionnalités de ce que je vais sortir en mai 2025. C'est un peu compliqué. Je pense que oui, il y a pas mal de gens qui le font, mais voilà, ça va pas mal changer. Il va falloir expliquer pourquoi. Je pense aussi, comme on parlait de discovery tout à l'heure, il faut aussi prendre en compte, même si je le fais un peu sur trois mois, je prends déjà en compte un peu le sujet du quartier prochain, discovery si besoin, ou même de ce quartier-là. Et après, je pense que, tu vois, cette question de timing, même si je dis, quelle serait ma recommandation, ça dépend aussi beaucoup du contexte. Parfois, il y a des boîtes qui ont des roadmaps. Tu vois, c'est un moyen de communication aussi. Du coup, parfois, il y a des boîtes qui communiquent en externe envers les clients. parfois ils sont un peu obligés par le marché ou par certains contraintes de communiquer un peu plus sur le long terme.

• Speaker #1

  Justement, tu en penses quoi de ce système dans certaines sociétés où il y a plusieurs roadmaps ? Ça arrive parfois qu'on ait une roadmap pour le produit, pour la communication, une roadmap externe peut-être aussi pour communiquer au public, ou même une roadmap marketing, ou même au Codier, on peut avoir certains types de roadmaps. Tu en penses quoi justement de ces différentes roadmaps et comment tu les gères ?

• Speaker #0

  C'est beaucoup de fois une usine à gaz. Après, pour moi, les roadmaps sont un bon moyen de communication. Si tu l'utilises bien, c'est quelque chose qui doit… Moi, je pense qu'il faut mettre à jour assez régulièrement. On ne va pas mettre tous les jours, mais on ne va pas non plus attendre six mois et juste changer les choses qui ont sorti en production. Je pense que si c'est bien utilisé, on peut faire de la bonne communication autour. Mais il faut toujours faire bien attention au niveau d'abstraction qu'on a. Par exemple, si on est dans une plutôt grosse boîte, où il y a pas mal de niveaux entre le co-deal et l'équipe produit, la roadmap de l'équipe produit et la roadmap que montre Codir n'aura pas les mêmes informations. Après, je sais qu'il y a, je ne sais pas, j'ai vu des cas où on avait un nombre impossible de roadmaps parce que c'était un peu, par exemple, du sastre B2B grand compte. clients, on avait un sort de roadmap un peu différent, avec des choses que le client aurait demandé ou pas, et en fait c'était une usine à gaz pour le PM, du coup c'était toujours une friction constante entre le fait que les équipes de business demandaient une dernière version, mais juste maintenir les diversions, c'était impossible, et encore plus savoir ce qui est 100% vrai, général dans ton produit versus certaines choses un peu spécifiques, qui pourraient faire spécifier pour certains clients, c'était hyper compliqué. Je pense que... On peut toujours simplifier, juste toujours pour la simplification, il y a aussi des modèles de business qui le permettent plus ou moins. Je sais qu'il y a des boîtes, même des boîtes où j'étais auparavant, si tu fais des roadmaps où tu dois communiquer externe, bon, tu ne vas pas donner le même niveau d'information, mais parfois, si le concurrent le font et si le marché le demande, effectivement, il faut aller un peu plus loin dans le temps. Tu ne vas pas donner des dates fixes, mais la prédictabilité de tes équipes, ça te rajoute, la prédictabilité ou pas, des deliveries, ça te rajoute aussi un risque plus ou moins grand. Donc,

• Speaker #1

  si on résume, toi, de ton côté, c'est trois mois et pas plus, quoi.

• Speaker #0

  Je fais plus, mais j'essaie de limiter les solutions dans le plus.

• Speaker #1

  D'accord.

• Speaker #0

  Tu vois, le plus, c'est plus mes initiatives stratégiques, c'est des, je ne sais pas comment les appeler, des sortes d'alliés, entre ce que je veux faire au niveau stratégique et des épiques très grands. Parfois, on sait, voilà, on sait de toute façon, on sait ce qu'on va faire à plus de trois mois quand même, mais j'essaie de ne pas m'engager.

• Speaker #1

  Voilà, tu ne t'engages pas, c'est ça.

• Speaker #0

  Pas m'engager 100%, surtout dans des solutions. Tu vois, si je sais, souvent, quand je fais avec mes équipes du bon discovery, on sait quels sont les problèmes. Donc, je sais qu'on va les résoudre, mais je ne sais pas encore comment parce qu'on n'a pas testé avec les utilisateurs, on n'a pas testé avec le marché. Donc, en fait, je suis très OK. Souvent, j'y vais plus loin. Tu vois, les stratégies que je fais pour mes équipes, c'est un peu stratégie pour l'année. Après, eux, ils déclinent. Mais dans la roadmap telle quelle, où tu commences à avoir des solutions, des idées, des métriques d'impact. Je ne vais pas m'amuser à le faire sur des choses qu'on n'a pas creusées. Parfois, on ne comprend même pas bien le problème d'un truc dans six mois. Ça m'est arrivé parfois de faire des choses plus longues. Parce que je t'ai donné l'exemple de ma première expérience où on avait le deadline de cet événement. Parfois, tu as une liste des choses, mais ce n'est pas ce que je recommande.

• Speaker #1

  Ok, très clair en tout cas, Alexandra. Je te remercie en tout cas beaucoup pour nous avoir expliqué un peu le sujet de la roadmap. C'est maintenant, je pense, beaucoup plus clair pour beaucoup de gens et même pour moi. On va passer maintenant à la partie recommandations. Quelles sont les personnalités que tu recommanderais à inviter dans le prochain épisode ? Peut-être des figures inspirantes dans le product management ou des connaissances que tu as ?

• Speaker #0

  Il y a deux personnes qui me viennent en tête tout de suite. La chance que je recommanderais, c'est Sarah Dufour. Elle a à la fois cette partie produit, mais aussi, elle parle beaucoup de la partie diversity and inclusion. Je trouve que c'est toujours hyper intéressant ce qu'elle dit. Pensez aussi à Stéphane Delbecq. Peut-être que tu le connais déjà. Je trouve ça tellement pertinent. Il a tellement d'expérience et c'est toujours hyper intéressant d'échanger avec lui.

• Speaker #1

  Ce sera avec grand plaisir que je les inviterai peut-être à un prochain épisode. Tu as peut-être un mot de la fin pour conclure ce podcast ? Une citation ou un mot qui te vient en tête ?

• Speaker #0

  Juste merci. C'était un plaisir d'en parler plus. Je pense qu'on pourrait parler pendant des heures, mais merci pour toutes ces questions et pour ce partage.

• Speaker #1

  Merci surtout à toi, Alexandra, pour cette échangerie chez Inspirant. Et merci surtout à tous nos auditeurs pour leur fidélité. Restez à l'écoute pour nous. prochain épisode de Be My Product où nous espérons accueillir les invités recommandés par Alexandra. A bientôt pour de nouvelles aventures riches en product management. Merci à tous de nous avoir suivis dans cet épisode de Be My Product. Votre engouement et votre fidélité nous motivent énormément, alors n'hésitez pas à soutenir notre chaîne en vous abonnant et en partageant nos contenus. N'oubliez pas de visiter également notre site web bemyproduct.com où vous trouverez tous les articles, vos sources et nos cours en ligne disponibles directement sur notre site. Nous vous retrouvons très bientôt pour de nouvelles interviews passionnantes. A très bientôt.