Transcription de l'épisode : "Alexandra Lung, Comment construire une roadmap produit"
Terry : Salut Alexandra.
Alexandra : Salut Terry !
Terry : Merci de prendre du temps aujourd'hui pour échanger avec moi autour du sujet principalement de la roadmap dans le product. Donc on va parler outcome-based roadmap, les problématiques autour de la roadmap, qu'est-ce que ça veut dire, à quoi ça sert, comment les implémenter. Et donc je pense qu'on va avoir une discussion assez intéressante sur le sujet. Donc avant de rentrer dans le vif de ce sujet, je te propose tout d'abord de te présenter.
Alexandra : D'accord, merci déjà pour l'invitation. Alors, moi c'est Alexandra Long, je suis fractional CPO et je fais aussi du conseil produit et du coaching, plutôt pour les product leaders. Et avant ça, j'étais CPO dans plusieurs entreprises, j'étais aussi Head of Product & Design chez Aircall. En fait, je gérais toutes leurs équipes produit et design entre la série B et D. Et par la suite, j'ai fait… avant ça, j'étais dans le produit pendant à peu près 10 ans, à la fois en conseil, grosse boîte, premier PM, donc voilà, plein de différentes expériences plutôt côté produit et leadership.
Terry : Ok, super intéressant, donc un parcours assez riche autour du produit, un parcours vraiment… le produit tout au long de ton parcours mais à différents niveaux de ce que je comprends.
Alexandra : Ouais, exactement. Après j'avais un background d'ingénieur mais j'ai toujours bossé vraiment côté business et produits.
Terry : Ok, très clair. Donc pour entrer sur ce sujet de la roadmap, déjà pour toi, je vais prendre l'angle de la roadmap plutôt sur une approche projet et pas produit pour aussi essayer de faire des parallèles entre ce qu'on a dans la roadmap pensée-produit versus celle que tu peux avoir pensée-projet. Donc moi si je me mets dans la posture d'un client qui a l'habitude de fonctionner en mode projet et donc qui a des roadmaps avec des jalons clairs, le but de la roadmap c'est quand même de savoir quand mes fonctionnalités vont sortir de manière assez stricte pour pouvoir ensuite planifier d'autres étapes dans mon projet. Donc on parle évidemment de projets digitaux. Mettons que je veux créer par exemple un système de gestion de paye et c'est un système que je vais déployer en interne dans une grosse entreprise et je veux savoir quand est-ce que ma version 1 va sortir pour pouvoir derrière déployer ensuite ma communication en interne à mes salariés puis les formations aux managers et aux salariés. Donc je vais demander à la personne responsable de ce projet de me de me construire une roadmap assez claire avec ces jalons là. Donc ça c'est la roadmap on va dire la plus courante que tu as dans un mode projet. Déjà si toi tu devais un peu nuancer en tout cas voir quelle est la une des différences principales tu vois avec la roadmap produit ou en tout cas comment tu tu aborderais un client qui vient de te voir en te demandant bah j'ai ce produit à développer et voilà mes échéances donc voici un peu une première roadmap et est-ce que tu peux m'aider à la construire comment.
Alexandra : Toi tu... Oui, c'est vrai, il y a beaucoup de différences, mais je trouve très intéressant justement que tu aies commencé avec ça, parce qu'il faut comprendre déjà comment fonctionnent les roadmaps projets aussi que l'on veut, pour justement après pouvoir apporter petit à petit la transformation et arriver à avoir vraiment des roadmaps produits. Moi, j'ai vécu aussi il y a assez longtemps plein des entreprises où on avait vraiment des roadmaps projets. Effectivement, je dirais que c'est ça. Il y a déjà l'univers temporaire qui est beaucoup plus long, il y a dans les roadmap projets, il y a aussi le fait qu'on veut définir très bien à l'avance des solutions sur lesquelles souvent, parfois, elles ne sont même pas définies par l'équipe, elles sont définies par des parties prenantes externes ou par des gens en dehors des équipes produits. et qu'on demande aux équipes de s'engager sur une certaine temporalité pour sortir ces fonctionnalités. Et après, on sait très bien qu'en réalité, un, on ne peut pas prédire parfaitement, c'est qu'il y a toujours des choses qui se passent. Ça prend aussi beaucoup de temps d'essayer d'estimer du travail, finalement ça va être du gâchis parce que ça ne se passe jamais exactement comme on prévoit. Et en fait, pour moi, un des principaux problèmes avec ce genre de roadmap, c'est que vu qu'elles sont faites avec des idées, des solutions qui sont mises dans une timeline, souvent, en fait, on crée des produits qui ne vont pas avoir du product market fit, qui ne vont pas vraiment répondre à une vraie problématique, qui ne vont pas avoir d'impact. Donc en gros, beaucoup de fois, soit le produit ne va pas survivre très longtemps, soit il va sortir, ne va pas être vraiment utilisé. Et en plus j'ai aussi vécu pas mal de cas où les équipes étaient hyper démotivées à juste créer pendant des mois et des mois et des mois du code sur des choses qu'on ne comprenait pas vraiment pourquoi on le fait. Et en plus avec une pression constante du vous êtes en retard, vous allez le faire quand ? qui crée encore plus de tension, mais sans que les équipes se demandent pourquoi on le fait. Du coup, pour moi, une des principales différences avec les roadmap plus produits, c'est que déjà pour les roadmap produits, on pense problème, donc on ne va pas enchaîner des solutions sur une timeline, on va vraiment aller découvrir des problèmes, comprendre les problèmes et les prioriser. Et par la suite, on va vraiment aller chercher l'impact qu'aura le fait de résoudre ces problèmes, on va penser au succès, à l'impact et on va tester des solutions dans le temps, sans pour autant, en essayant de garder un équilibre sur à quel point on va s'engager, sur ce qu'on peut délivrer et quand.
Terry : Hyper intéressant, donc beaucoup de choses condensées dans ce que tu viens de dire. Pour résumer déjà brièvement avec mes mots, ce que tu viens de dire autour de l'approche projet versus du coup produit sur la roadmap, c'est que dans un mode projet, en fait la question de ce que tu dois construire et comment tu vas le construire, tu te les posais avant dans l'idée et en fait tu veux pas la re-challenger, c'est-à-dire que tu as un cahier des charges plus ou moins d'une certaine manière et ensuite tu dis ben voilà on a un ou deux ans pour construire ça et maintenant c'est pour ça qu'on veut une roadmap et savoir quand les fonctionnalités vont être implémentées. Un des premiers travers de cette approche que tu mentionnais c'est pour les équipes qui construisent parfois elles trouvent qu'il n'y a pas de sens même sur ce qu'elles font parce qu'elles se rendent compte que ce qu'elles construisent ne va pas apporter la valeur qui était pensée peut-être il y a un an et qui en fait aujourd'hui n'est plus nécessaire parce qu'il y a aussi une évolution hyper rapide des besoins et ça c'est lié aussi au monde des nouvelles technologies. Donc ce premier point qui est de dire on fait un plan pour construire quelque chose pendant un ou deux ans mais en fait le moment où on commence à construire le plan il est déjà invalide et donc on demande à des gens de suivre un plan qui est déjà obsolète donc ça pose des problèmes de motivation de base en fait pour les équipes aussi qui construisent parce qu'elles se rendent bien compte de la complexité de ça. et aussi le fait de dire du coup que les problèmes ils ont été bien pensés sur cette phase amont et donc quand on se retrouve en phase de construction on peut pas remettre ça en cause parce que sinon on remettrait en cause tout ce travail qui avait été fait en amont. Donc ça c'est l'approche projet et l'approche produit donc c'est complètement l'opposé c'est à dire de vraiment se dire on va penser qu'on va vouloir résoudre tel problème, on va essayer d'apporter des solutions à ce problème et ensuite on va regarder si oui ou non on a apporté des solutions à ce problème mais sur une échelle de temps beaucoup plus courte. Mettons pendant 1, 2, 3 mois je pense que je veux, enfin je souhaite résoudre tel problème, j'implémente des fonctionnalités pour résoudre tel problème et au bout de 2, 3 mois je regarde est-ce que mes fonctionnalités ont résolu ce problème et est-ce qu'il y a d'autres problèmes à résoudre ou est-ce que ce problème il a besoin toujours d'être résoudu et avancer comme ça. Donc ça, hyper clair je pense dans ce que tu as expliqué. La question qu'on pourrait se poser, moi je me fais un peu l'avocat du diable tu vois, en posture de décideur, c'est-à-dire que ce qu'on vient de dire je pense que c'est assez compréhensible mais en même temps un décideur pourrait se dire ok, Il faut qu'on y terre, qu'on ait des boucles beaucoup plus courtes sur comment on construit notre produit. Mais en même temps, je ne peux pas dire à mon département marketing ou à mes sales ou à mes CSM ou à ceux qui vont former mes utilisateurs, on ne sait pas trop quand telle ou telle fonctionnalité va sortir parce que sinon, eux risquent de se retrouver. potentiellement avec une fonctionnalité à vendre, à former, à marketer, du jour au lendemain, sans qu'ils y aient été préparés. Je me fais volontairement l'avocat du diable. Et du coup par rapport à ce type de raisonnement, comment toi tu abordes la chose ? Parce que j'imagine que les choses ne sont pas toutes noires ou toutes blanches, c'est toujours une nuance de gris.
Alexandra : Mais oui, exactement. Il y a toujours une négociation et de toute façon, il y a toujours... En fait, pour moi, il y a plusieurs choses. Déjà, il y a la collaboration qui est très importante. Souvent, en fait, mes équipes produits, elles ne vont pas travailler dans leur coin sans vraiment parler avec personne autour. Donc forcément, il y a pas mal d'insights qu'on prend des équipes business, il y a pas mal d'insights qu'on prend... du marketing ou des autres équipes. On nous donne aussi des informations par rapport au... Là, on est en train de tester ça, on est en train d'analyser ça, on a ça comme objectif. Donc, là, c'est déjà partagé. Après, effectivement, c'est toujours une conversation, par exemple, avec les équipes marketing du... On va sortir quelque chose à peu près à quel moment. Bien sûr, mais ça, on va le faire pour les fonctionnalités qui sont les prochaines fonctionnalités. On ne va pas dire au marketing, dans trois mois, on sort quelque chose. Mais on travaille assez prochainement, souvent on a un PMM qui va travailler avec un Product Marketing Manager qui va travailler avec un ou plusieurs PM. Et du coup, lui ou elle vont être dans la boucle pour se dire, ça va sortir dans les prochaines semaines, quelques semaines. Et du coup, ça leur laisse un peu de temps pour préparer ensemble la communication, la formation des forces de vente ou autre. Après, effectivement, les tensions que je vois beaucoup chez mes clients et que j'ai pu vivre aussi quand j'étais CPO, c'est en plus avec les équipes commerciales, effectivement, qui idéalement voudraient vendre plein, plein, plein de choses à leurs clients, surtout en B2B, et avec lesquelles, effectivement, on ne peut pas On ne peut pas forcément s'engager sur quelque chose qui sortira dans 6 mois ou 9 mois. Mais sur ça, il y a aussi, je pense, différentes manières de faire. Déjà, moi, en général, j'utilise les roadmaps qui sont avec Now, Next et Later. Donc, en fait, c'est qu'est-ce qu'on est en train de faire maintenant, qu'est-ce qu'on va faire par la suite. Et plus tard, c'est vraiment un univers temporaire un peu plus lointain.
Terry : Désolé, je te fais faire une pause là-dessus parce que je pense que c'est hyper intéressant. Comment tu as ce structure, comment du coup cette roma, now, next, later, concrètement comment tu le présentes même visuellement, à quoi ça ressemble ? Est-ce que le now c'est quelque chose de, je sais pas moi, tu dis ce qu'on fait maintenant ou sur le mois qui vient, même d'un point de vue temporel un peu.
Alexandra : Exactement, en fait moi comme je disais je vais commencer avec des problèmes qu'on priorise. Donc disons que le now souvent va être un ou deux problèmes qu'on est en train de traiter maintenant. et pour lesquelles les solutions sont déjà dérisquées, validées. Donc, en fait, voilà, ça va être un ou deux problèmes en fonction de combien des équipes de développement ont géré, mais du coup, ça, c'est le now, c'est vraiment les choses sur lesquelles on est en train de travailler maintenant. Par la suite, le next, ça va être encore les deux, trois prochaines problèmes qu'on va tacler. Ça peut être encore sur peut-être, voilà, les quelques semaines à venir ou jusqu'à la fin du trimestre. Et le « later », ça va être des problèmes qu'on sait déjà, voilà, on a découvert que ce sont des problèmes plutôt importants, pour lesquels on n'a pas encore vraiment réfléchi aux solutions, on n'a pas testé des solutions, mais sur lesquels on a pas mal de certitudes qui viendront plus tard, ça peut être potentiellement le trimestre d'après. Mais sur lequel on ne s'engage pas vraiment sur des solutions. Pour l'instant, on sait qu'on ira creuser les problèmes et tester des solutions. Après, pour chaque entreprise, ça peut être plus ou moins différent. En général, on essaie quand même de donner une bonne vision en mois pour le trimestre en cours. Et après, ça dépend beaucoup de la maturité des équipes et aussi de la prédictabilité de certaines choses sur quoi on peut s'engager. Mine de rien, si on a déjà des thématiques, souvent si on a une bonne stratégie, des initiatives stratégiques pour l'année, des choses qui sont plutôt bien définies, on peut aussi donner des informations au niveau aux équipes commerciales sans pour autant avoir des solutions détaillées ou des écrans de fonctionnalités qui peuvent les aider. Mais dans le même temps, je me considère que mon expérience est quand même importante de mettre de bonnes limites. et de s'assurer que les équipes commerciales ne vont pas aller vendre des choses qu'on n'a pas créées, qu'on devra faire en dernière minute ou qu'on ne va pas vraiment vendre, bon, sauf certains cas spécifiques comme B2B, on ne va pas faire des solutions spécifiques que pour un client parce qu'il y a quelqu'un qui a demandé ça. Parce que du coup, la plupart des cas, on essaie justement quand même de standardiser, faire quelque chose qui peut avoir de l'impact pour un maximum de clients.
Terry : Hyper intéressant et tu m'as recadré indirectement en disant, quand je t'ai posé la question de la timeline, tu as dit le now on parle du problème qu'on résout maintenant, le next des 2-3 problèmes qu'on va résoudre après, le later des problèmes qu'on sait qui sont là mais on les cadrera un peu plus tard. Et je pense que c'est vraiment ça qui est pertinent, c'est l'approche problème vraiment, c'est-à-dire que dans ton approche now next later en fait, le now c'est quel est le problème que l'on résout maintenant, c'est pas qu'est-ce qu'on va sortir dans les prochaines semaines, c'est vraiment quel est le problème sur lequel on va apporter une solution.
Alexandra : Exactement. Et en fait, ce qui est vraiment cool aussi dans cette approche, c'est qu'on peut communiquer aussi sur le fait que, en fait, now, next, later, ça montre aussi notre niveau de certitude sur les problèmes et les solutions. Donc, en fait, on peut aussi dire, ben oui, ce qu'on est en train de faire en ce moment, à ce moment-là, dans le now, ben oui, on a de la certitude. à la fois sur le problème, à la fois sur la solution et plutôt voilà sur le moment où ça va être délivré plus ou moins. Dans le next, on a un peu moins de certitude, sur le problème plutôt oui, mais sur la solution encore moins et dans le later encore moins de certitude. Donc ça fait aussi avec pas mal de communication, répétition, comprendre les autres départements aussi. finalement la manière dont on travaille un peu en modeling où on va dérisquer des choses et où on n'a pas vraiment une séance exacte sur qu'est-ce qu'on va faire et quand.
Terry : Très très clair. Est-ce que tu as d'autres tips autour de l'approche ? Donc là ce qu'on dit c'est outcome-based roadmap du coup, c'est cette approche-là et en termes de comment tu le déploies dans des organisations qui sont plus habituées à fonctionner en mode plutôt projet ?
Alexandra : Oui, je peux détailler un peu plus déjà comment construire ce genre de roadmap. Donc, comme je disais déjà, je commence toujours avec les problèmes et par la suite, en fait, il y a quelque chose que je vois beaucoup de fois. Disons, en mode projet, on a la solution et ça y est. Parfois, on est dans un autre mindset, on a un problème, on va penser après à une solution. Et en fait les outcomes based roadmaps amènent ça plus loin encore parce que j'ai un problème et je veux penser à l'outcome qui va se passer si je résous ce problème. Donc je ne pense même pas à la solution. Un outcome en fait c'est vraiment le changement dans le comportement de l'utilisateur que je cherche à avoir. Qu'est-ce que l'utilisateur va faire en plus ou en moins ? Qu'est-ce que l'utilisateur va avoir comme bénéfice ou comme valeur ? Tu vois, par exemple, si je suis dans une boîte qui fait des sièges auto pour bébés, un Output c'est un siège auto pour bébés. C'est la solution. Un Outcome ça va être, ça va maintenir l'enfant en sécurité pendant que je conduis. Donc c'est vraiment cet outcome, cette valeur qu'on apporte pour les utilisateurs. Et en fait, ce qui est hyper intéressant, et j'ai fait l'exercice plein de fois quand j'essaye d'amener les équipes vers ça, c'est que souvent on a un problème et quand je leur fais penser à quel est l'outcome, on se rend compte que parfois le problème est hyper générique. L'utilisateur ne comprend pas X, l'utilisateur veut X. Mais en fait, si je creuse, est-ce que dans l'outcome, tu veux de la rapidité, tu veux une clarté, tu veux, tu vois, qu'est-ce que tu veux, ben ça nous fait revenir souvent aussi au problème et c'est dire, mais en fait, qu'est-ce que je veux résoudre ici ? Et du coup, une fois que le problème, il est très clair et que notre outcome, il est très clair, c'est que là que je vais, par la suite, aller avec des équipes et c'est dire OK. Quelle est la solution qui pourrait apporter ce outcome si on va résoudre cette solution ? Et par la suite, j'ai au moins encore une chose que je vais toujours mettre dans ce roadmap qui vont être vraiment, disons, des KPIs de succès. Donc c'est dire, ok, qu'est-ce que c'est le succès pour nous ? à la fois, ok, ça doit avoir ces outcomes qu'on a définis, mais aussi au niveau business, qu'est-ce que ça va apporter comme valeur. Et une chose qui va être aussi importante dans la manière de créer ce round-map là, c'est que souvent pour un problème, on va avoir une solution assez complète et on va toujours être en mode trailing. Je ne vais pas aller implémenter toutes les idées de la solution. On va aller implémenter une partie de la solution, voir les KPI et le outcome qu'on peut avoir par rapport à ça, et par la suite voir si on veut continuer à itérer ou si on va switcher à un autre problème.
Terry : Ouais, donc sur la partie solution, c'est-à-dire ce que tu dis, c'est que même si tu... une fois qu'on a bien identifié le problème, même si on pense avoir une solution qui va fonctionner, c'est être capable d'ajuster cette solution parce que potentiellement, c'est pas la meilleure solution à laquelle on a pensé tout de suite qu'on va réussir à délivrer.
Alexandra : En fait, normalement, ça doit être la meilleure solution parce qu'on l'a déjà testée, donc elle est dérisquée, mais disons que je vais avoir, je vais dire n'importe quoi, 10 fonctionnalités en absolu sur plusieurs pages qui vont résoudre ce problème. Et en fait, justement, on ne va pas aller dire, bon, toutes ces 10 fonctionnalités, elles sont dans mon now, je vais tout développer tout de suite. On va se dire, OK, avec quoi on commence déjà ? Et peut-être que je vais choisir les trois premières fonctionnalités. Je vais les déployer, je vais les mettre en production et je veux vraiment amener de la valeur très vite en production pour mes clients, donc j'amène ça. Je tacle par la suite mon prochain problème avec la solution et je check l'impact de ça.
Terry : Via les métriques ?
Alexandra : Oui, avec les métriques, avec je vois si j'ai vraiment l'outcome que j'ai attendu, les métriques. Et en fait, par la suite, je me dis ok, est-ce que j'ai eu le... Et ça, peu d'équipes le font vraiment aujourd'hui parce que beaucoup de fois, on lance et on se dit bon, bah c'est pas super facile, on attend X temps pour voir. Effectivement, parfois, ça demande un certain temps, mais c'est très important justement de revenir et se dire ok, on a l'impact qu'on voulait, bah très bien, du coup, ce problème, à la limite, c'est plus sur notre roadmap. Ah non, l'impact n'est pas encore là, comment on y terre ? Est-ce que du coup on va changer un peu la solution ? Est-ce qu'on va rajouter les autres fonctionnalités qu'on avait, des autres fonctionnalités qu'on avait dans notre solution ? Et du coup ce problème il revient dans la priorisation de nos problèmes dans la roadmap, souvent plutôt dans le now aussi, ou dans le next.
Terry : Très intéressant, donc j'aimerais qu'on reste un petit peu sur ce sujet. Avant de creuser un peu, ça m'intéresse d'avoir un peu toi tes retours pratiques sur par exemple des techniques pour comment mettre en place les temps d'itération. Tu vois avant de sortir par exemple 3 fonctionnalités sur 10, à peu près les temps toi que tu as pu voir qui fonctionnaient bien sur une échelle de résolution d'un problème. Mais avant d'aller là-dessus, je voudrais accentuer le point, pour être sûr de bien comprendre aussi ton approche, t'as pas parlé du challenge, du problème, une fois que tu l'as identifié. Et je trouve ça intéressant parce que ça montre bien que ce qu'il est nécessaire d'ajuster ensuite, c'est effectivement les solutions. mais une fois que t'as bien cerné le problème, donc le cas de l'exemple par exemple du siège auto bébé qui en fait le but c'est que le bébé soit safe dans la voiture, ça c'est ton problème que tu veux résoudre et ça en général c'est assez stable, c'est-à-dire qu'une fois que tu l'as identifié ton problème, lui il va pas bouger au fil, il va évoluer effectivement mais alors après peut-être que tu vas me contredire et n'hésite pas à le faire mais là ce que j'entends c'est vraiment que ce problème est plutôt stable et que par contre c'est comment on va apporter une réponse à ce problème où là on a plus d'incertitudes et où il faut qu'on teste des solutions de manière assez rapide pour les ajuster. Est-ce qu'on est aligné là-dessus ?
Alexandra : Effectivement c'est quelque chose que je n'avais pas vraiment mentionné, c'est que je me pose dans le cas des équipes qui font de la bonne discovery, et qui sont allés parler avec les utilisateurs, qui sont allés utiliser de la data Kali et Kanti afin d'avoir des problèmes sur lesquels on a beaucoup de certitude. Donc effectivement ça c'est déjà un prérequis. en quelque sorte, pour arriver à avoir des bons outcomes roadmaps, outcome-based roadmaps. Donc, ces problèmes, ils sont déjà bien identifiés et par la suite, ils sont priorisés. Souvent, en fait, je fais un atelier pour créer au moins la première version des roadmaps où il y a aussi des parties prenantes qui peuvent venir, voilà, du business, du marketing ou d'autres départements. Bien sûr, les ingénieurs, le design, le PM. Et en fait, on va prioriser. Mais du coup, comme ces problèmes, ils sont déjà assez connus, on a déjà aussi une certaine manière d'estimer leur impact parce que peut-être qu'on a déjà de la data un peu quali, on sait peut-être qu'au niveau business, combien de clients ça peut concerner ou quel potentiel business ça peut avoir. Ou si on a parlé avec les utilisateurs, on peut savoir combien payent l'utilisateur, à quel point ils sont frustrés, ils vont vraiment quitter ou c'est plus un nice to have. Donc en fait, du coup, la priorisation, elle est basée aussi sur tous les éléments qui nous ont aidés à identifier les problèmes. Et c'est pas beaucoup des fois, j'essaie de le faire de manière collaborative. Comme ça, on a moins de frictions pendant le trimestre où Quand on a vraiment une partie prenante qui va venir dire, il faut que vous fassiez ça, il faut que vous le fassiez tout de suite, bah du coup c'est beaucoup plus facile pour les PM de dire, ah mais là je suis en train de faire ça, l'item X, le problème X, bah on a tous décidé ensemble que c'est le truc le plus important. Est-ce que vraiment la chose avec laquelle tu viens Là, elle est plus importante que ça. Et souvent, quand on remet les choses en perspective comme ça, forcément, la personne va dire non, effectivement, elle n'est pas la plus importante du monde. Après, bon, il y a d'autres négociations. Souvent, les personnes continuent à insister. Mais le fait d'avoir des problèmes bien définis, de faire la priorisation avec les parties prenantes, nous permet déjà d'avoir un cadre qui est un peu plus stable et tout le monde est beaucoup plus aligné sur ce que nous allons faire.
Terry : Oui, très clair. Sur la suite de l'échange et même jusqu'à présent, on parle d'outcome-based roadmap et ces pratiques-là. Mais le prérequis, c'est d'avoir d'abord fait cette bonne discovery. On en a parlé sur un autre épisode avec Axel de cette étape-là. qui est en fait effectivement ce prérequis qui apporte, tu viens de parler d'alignement, je pense que c'est aussi une des choses qui apporte le plus de valeur aussi en interne parce que tout le monde est d'accord sur ce sur quoi on va se concentrer.
Alexandra : Après ce que je fais aujourd'hui souvent avec mes clients mais même dans certaines boîtes où j'étais avant c'est que Oui, ça, idéalement, c'est le prérequis. Après, aujourd'hui, je ne peux pas forcément transformer toutes les équipes d'un coup à faire des spread discoveries. Il faut toujours trouver un peu le moment où on peut prouver, où on a une équipe qui peut déjà commencer à faire autre. Donc, en fait, ce que je fais souvent pour commencer à transformer les équipes, c'est que ma première itération d'une outcome-based roadmap, ça va être, bon, déjà, je leur fais un peu une présentation pour les mettre dans le mindset à la fois des parties présentes et des équipes. Et par la suite, il y a vraiment, je vais faire des reverse engineering. En gros, ils ont un peu des sortes de solutions et je vais essayer de challenger en disant, mais c'est quoi le problème? Qu'est-ce que, lequel, quel est le problème? Et une fois qu'on a ces problèmes, je vais essayer de faire les gens penser, OK, quel serait le outcome? Et du coup, quand il pense à des différents outcomes, je peux le faire avoir vraiment des prises de conscience. Ça, c'est dire, ah, mais il y a plusieurs outcomes. Et notre solution, elle correspond à un des outcomes. Peut-être que, en fait, le problème, s'il est plus comme ci ou comme ça, la solution serait différente. Et ça, ça fait déjà les gens se dire, ah oui, en fait, il y a une vraie valeur de faire les choses différemment. Mais souvent, tu vois, le premier trimestre, quand je commence à implémenter ces roadmaps-là, si je n'ai pas vraiment la base, et que les équipes commencent à faire un peu discovery mais elles ne sont pas encore au niveau où j'aurais besoin, du coup je vais faire quand même une itération qui va être pas idéale mais qui va être un peu retro-engineering des solutions qu'on a, comme ça ça choque pas trop les stakeholders non plus qu'on change tout d'un coup des choses qu'ils s'attendaient à avoir. et on va quand même avoir au moins un format qui est en mode problèmes, outcomes, solutions et KPI qui est souvent aussi hyper important et souvent un peu nouveau de le penser comme ça pour les équipes. Et ça fait déjà la transition vers les trimestres d'après où on peut, voilà, amener plus les problèmes plus définis et les équipes s'habituent aussi à comment définir les outcomes.
Terry : Hyper intéressant et merci pour le retour d'expérience là-dessus et la nuance du coup parce que je pense que c'est aussi rassurant pour les organisations qui veulent transitionner de se dire on n'est pas obligé de d'abord passer une organisation full orientée discovery avant de commencer à mettre en place ce type de roadmap. Tu viens de le montrer par l'exemple qu'on peut faire trouver des hacks, des techniques un petit peu pour faire ça dans l'autre sens mais qui permettent quand même à fur et à mesure d'apporter cet état d'esprit et du coup d'insuffler la dynamique produit. Donc pour revenir un peu sur maintenant, dans ce cadre là, on va dire qu'on est dans une orga où il y a déjà un peu l'outcome-based roadmap. La partie test, on a bien identifié un premier problème que l'on veut résoudre dans le now, et on a on va dire dix fonctionnalités, on va en choisir trois premières qu'on va essayer de sortir. Toi, est-ce que tu vois qu'ils fonctionnent bien en termes de temporalité pour sortir ces fonctionnalités, les tester, et les métriques, comment les mettre en place ?
Alexandra : Oui, en fait, on va toujours être en mode dual track. Donc, en fait, disons que tu as problème 1, problème 2. Le problème 1, les développeurs sont en train déjà de développer ce que les produits et design ont déjà testé les solutions et elles sont validées avec, voilà, des tests, Lean experiments tests avec les utilisateurs. Souvent, problème 2 ou problème 3, on a des idées, des solutions et en fait le PM Redesign, ils sont en train de tester, de dérisquer cette partie-là. Donc en fait, ils vont toujours être le produit Redesign un peu en amont afin de dérisquer des solutions qui vont après être développées dans la roadmap. Après, je parle beaucoup de tout ce qui est test et l'inexperience, j'ai donné beaucoup de talks sur ça, c'est hyper important. Après, c'est aussi important de se dire qu'on ne va pas tout tester. Voilà, on teste les choses qui sont les plus risquées, on teste les choses qui ont vraiment un grand impact. le potentiel, mais on ne va pas aller tout tester, il faut vraiment toujours avoir une limite, un bon équilibre entre mal le temps et il faut tester très rapidement, en gros on ne va pas prendre un mois pour tester des choses, il faut apprendre à max avec un minimum d'effort et de temps.
Terry : Et là dessus, enfin juste rebondir sur le sujet du test, on en a parlé aussi sur un épisode avec Valentin de chez Manomano qui me disait effectivement qu'il ne faut pas avoir cette approche dogmatique parce qu'il y a des choses, par exemple sur les sites e-commerce, tu sais que tous les sites e-commerce le font, je ne sais pas moi, les suggestions de produits, donc c'est qu'il y en a qui ont déjà dû le tester, tu ne vas pas réinventer la roue et refaire de l'AB test à tout va pour cette solution-là, donc tu vas plutôt te concentrer sur des choses qui sont peut-être nouvelles ou en tout cas qui n'ont pas été déjà validées. toujours avoir ce regard critique et effectivement ce recul quand tu fais des tests. Est-ce que mon test va vraiment m'apporter des réponses sur quelque chose qui est inconnu ou est-ce qu'il va juste faire que confirmer des choses qui sont déjà admises par l'industrie ?
Alexandra : Donc, je suis totalement d'accord là-dessus.
Terry : Ouais, exactement.
Alexandra : Et en fait, cette partie test, elle peut... En fait, moi, tout à l'heure quand je parlais du format des roadmaps, ce que pour moi effectivement le minimum c'était d'avoir problème, outcome, solution entre guillemets et KPIs. Après, il y a des équipes avec lesquelles on montre dans la roadmap aussi les hypothèses de tests. Par exemple, je peux avoir une ligne dans ma roadmap peut-être liée à la solution qui est solution en test. Et en fait, j'ai trois idées de solutions et du coup, je pourrais mettre dans ma roadmap en vert, du coup, la solution qu'on a validée, en rouge, celle qu'on n'a pas validée. À la fin, finalement, pour moi, en fait, la roadmap, c'est aussi un instrument pour communiquer. où on en est. Et si je suis dans une entreprise où j'ai besoin de plus montrer cette idée de, en fait, on teste des choses, tout n'est pas prédéfini, on ne sait pas tout par défaut. Mais du coup, ça peut aussi aider à donner de la visibilité sur le fait de, ben là, ok, cette solution, elle est verte, ben, elle est testée, elle est en dev, elle va être en dev bientôt. Là, ici, on est en train de tester. Et là, ici, on n'a même pas encore testé, on réfléchit. Et aussi, d'autres choses qu'on peut rajouter sur la roadmap, c'est aussi de donner de la visibilité un peu sur le stage of development. Ça peut être, par exemple, pour un problème, je peux dire « in discovery » pour la solution ou je peux dire « en phase de test » ou « en phase de développement ». ou en phase de release et pour la release, je peux peut-être montrer ma release à je ne sais pas 10% de mes clients ou les clients de type X ou Y. Donc on peut aussi avoir ce genre d'informations pour chaque problème et dans le temps et comme ça, ça donne tout de suite un peu une visibilité aux parties présentes en se disant ah ben ça c'est bon, c'est un test, ça va bientôt. Il travaille dessus quand même, donc c'est un sujet qui a été priorisé.
Terry : Hyper intéressant encore une fois, conseil très pratique que je trouve très pertinent quand notamment tu veux insuffler ces pratiques-là dans des orgas qui ont besoin de transitionner ou en tout cas qui cherchent à transitionner vers des approches produits. La notion de transparence et de communication, c'est la clé en fait dans le métier du produit, c'est quand même des rôles de chef d'orchestre et qui doivent répéter, répéter, répéter, communiquer pour vraiment faire prendre, entre guillemets, prendre la mayonnaise, vraiment faire que les choses se fluidifie et donc tous les outils qui permettent de passer le plus d'informations possibles sont pertinents, donc là-dessus je suis totalement aligné. Juste pour revenir un petit peu, donc tu as parlé du dual track, donc en gros dans un mode de test des fonctionnalités dans le now, donc dans le cas où tu as ton problème qui est défini, tu commences à implémenter des fonctionnalités mais ensuite tu vas vouloir mesurer si ça fonctionne ou pas. Donc tu disais qu'en général tu as toujours le développement qui est en train de travailler sur une fonctionnalité qui a déjà été donc spécifiée versus en parallèle le produit et design qui sont en train de creuser la conception d'une autre fonctionnalité pour avoir toujours un petit coup d'avance et donner à manger entre guillemets aux équipes de développement. Ma question elle est très pratique, c'est sur à peu près les échelles de temps, sur pour toi, une fourchette, il n'y a vraiment pas de réponse magique, mais sur les cycles de développement, la durée à peu près que tu vois qui fonctionnait bien, sur combien de temps avant que tu vois cette fonctionnalité en cours de développement sorte, et combien de temps pour cette équipe, de toute façon j'imagine que le temps est le même pour l'équipe produit design qui est en train de faire la spec de l'autre fonctionnalité que l'équipe de dev devra reprendre derrière.
Alexandra : Oui, c'est dur de donner vraiment un chiffre exact. Après, disons que si les équipes sont souvent sur les cycles de semaine, je dirais que produits et design, ils peuvent avoir au moins 2-3 cycles d'avance quand même pour être assez confortable dans le sens où tu as parfois des vacances, parfois tu as des choses qui arrivent et pour être sûr, voilà. Et parfois aussi, on n'arrive pas à avoir les utilisateurs toujours à l'air. le jour J quand on veut. Donc souvent, voilà, là, si tu vas deux, trois cycles, ça te fait quand même un mois et demi d'avance. Tu sais quand même que t'es développé, ils ont des choses plutôt dérisquées. Après, j'ai eu aussi des équipes qui étaient hyper à l'aise avec une discovery super rapide, des tests super rapides. Et parfois, ça m'arrivait que le pied me disait, il dérisquait des choses pour la semaine d'après parce qu'il y avait quelque chose d'hyper important qui arrivait. Mais ils avaient un rythme qui était vraiment très, très... mis en place des points de vue, des tests. Du coup, il pouvait se permettre parfois de faire des choses un peu plus, je dirais, dernières minutes entre guillemets, mais ce n'était pas du tout mauvais parce qu'il savait qu'il était très rapide dans la manière de le faire. Mais je dirais, oui, deux, trois semaines. Après, je dirais, j'ai vu aussi des équipes qui ont beaucoup pris d'avance. Ils étaient à deux mois, trois mois. Et là, ça devenait un peu plus….
Terry : Donc, l'avance, tu parles de l'équipe Produit.
Alexandra : Design qui a l'avance sur… Produit Design qui avait déjà presque développé, développé, designé les choses pour les, je ne sais pas, prochaines trois, quatre mois. C'est pas mal, mais tu commences à rentrer quand même dans des dynamiques où… Tu vois, je pense qu'il y a une sorte de biais aussi pour le design, on a déjà ça, t'es moins flexible dans ce que tu peux apporter. Par exemple, si t'as une solution que t'as sorti et tu vois que l'impact n'est pas le même que tu attendais, bah du coup, c'est pas si facile forcément pour eux dans leur dynamique de se dire « Ah, mais attends, on va travailler sur ça, on va retester quelque chose ». Donc pour moi, je pense que ça rassure les équipes, mais c'est un peu trop dans beaucoup de cas. Après bon, chaque boîte a un peu son rythme aussi, c'est pour ça que moi je le mettrais à 2-3 cycles en plus juste pour être… confortable mais pas non plus arriver à presque designer en avance.
Terry : Ouais, ça fait parfaite transition sur le sujet des métriques du coup, puisque si tu vas trop en avance après du coup t'es moins enclin à challenger, parce que si en plus t'as tout designé t'es moins enclin à dire bon bah en fait ça on le met à la poubelle parce qu'on va devoir redesigner autre chose. Mais du coup pour résumer trivialement ce que tu viens de dire, Ecoute moi si pour toi je dis une bêtise mais donc en gros des cycles de développement qui sont à peu près entre 2-3 semaines on va dire dans une grosse moyenne le temps pour sortir une fonctionnalité et en parallèle de ça une équipe produit design qui elle a donc sur ces cycles de 2-3 semaines 2 à 3 cycles d'avance donc de fonctionnalités préparées à donner aux devs Oui, disons.
Alexandra : 4 à 6 semaines pour dérisquer la solution. Après, souvent quand je dérisque une solution, peut-être que j'ai un prototype très low fidelity, donc si 5 semaines avant j'ai testé ça, ça va quand même prendre du temps au design de faire le design final, ça va quand même prendre du temps au produit de spécifier les choses. Les développeurs sont aussi impliqués bien sûr à l'avance pour voir la faisabilité technique et des enjeux un peu plus techniques. Donc, à la fin, l'idée, ce n'est pas qu'on va vraiment avoir un backlog six semaines à l'avance, c'est vraiment qu'on a des interviews utilisateurs ou des bites ou voilà les tests qu'on fait, peu importe les tests qu'on fait, qui se passent deux, trois cycles à l'avance pour qu'on aille justement le temps après d'affiner parce que les tests, c'est des tests, peut-être que la solution n'est pas du tout la bonne si c'est mis à l'avance et que du coup, deux semaines plus tard, il faut retester. Donc, c'est juste pour nous laisser assez de temps pour pouvoir itérer justement sur ces tests-là.
Terry : Très clair. Et donc pour aller vers les métriques, quelles sont un peu les métriques clés que tu as pu voir pertinentes pour vérifier si des fonctionnalités sont à l'attente de ce qu'on avait pensé en termes de résolution des problèmes et comment les mettre en place dans des produits tech aussi et les mesurer derrière ?
Alexandra : Yes. Les métriques vont être très, très différentes en fonction du produit et du problème qu'on est en train de tacler. Mais une chose qui est très importante, c'est qu'en fait, souvent, une fois que j'ai la première version de la roadmap avec mes équipes, un exercice qui est intéressant, souvent, comme je disais, je le fais dans un atelier. Donc voilà, on va tous, à la fin, on va avoir les premiers problèmes qu'on peut remplir avec des idées de solutions, des idées de KPIs. À ce moment-là, on va souvent aussi se dire, commencer à s'interroger, à se dire, ah, quels KPIs? Ah, est-ce qu'on a vraiment la data zéro pour que ce KPI ou pas? Est-ce qu'on est en train de traquer ou pas? Donc, ça nous fait déjà une première compréhension d'où on en est. Et souvent dans ces premiers ateliers, peut-être qu'on ne va pas vraiment avoir une idée parfaite de ces KPIs, mais c'est ok parce que par la suite, c'est plus du coup le PM ou peut-être avec des personnes à data ou d'autres personnes. qui vont creuser plus à se dire, ok, niveau solution, on fait comment ? Niveau KPI, on fait comment ? Et en fait, c'est à ce moment-là qu'on va un peu refiner la première version de la roadmap. Il y a une chose qui est importante, c'est toujours de se dire, ok, quels sont mes objectifs ? Ré-regarder les objectifs du trimestre. et s'assurer que les problèmes qu'on est en train de résoudre et les KPIs, ils seront bien en corrélation avec l'objectif. Et moi ça m'avait arrivé une fois, en fait on avait trois ou quatre objectifs.
Terry : Objectifs, pardon, tu parles d'objectifs business du coup ?
Alexandra : Souvent c'est un peu les OKRs, les équipes produits. qui très souvent ne sont pas vraiment, voilà, on a des objectifs business au niveau de la boîte et normalement les OKPIs des équipes produits sont des objectifs on peut rétravailler afin que ça ne va pas être on fait X des chiffres d'affaires, ça va être vraiment lié à une stratégie que le produit peut amener ou une action que le produit peut amener afin de, voilà, toucher les autres KPIs de la boîte. Et du coup, à un moment, ça m'avait arrivé de me dire, ok, ça c'est la roadmap et j'ai vu qu'on a priorisé un problème. En fait, on avait priorisé plein de problèmes et en fait, il y avait un des objectifs qui n'avait aucun problème lié. Et du coup, je suis allée voir les parties prenantes en disant voilà, en fait, cet objectif, il n'y a aucun problème qui a été priorisé par rapport à lui. Est-ce que ça veut dire que c'est un objectif que peut-être qu'on n'a pas vraiment de problème qui peut impacter ça, donc pour l'instant, est-ce qu'on le laisse de côté ou est-ce qu'on va aller quand même creuser parce que c'est quelque chose d'important pour nous ? Donc ça m'a vraiment fait ce check, ça m'a vraiment permis d'avoir cette conversation. Dans ce cas-là, en fait, on s'est dit bah non, finalement, s'il n'y a pas vraiment de problème, on peut impacter à fond les autres objectifs. Et du coup ça, ça aide, il faut toujours faire ce check, s'assurer toujours qu'on est en corrélation avec nos objectifs. Et du coup les KPIs, bah aussi, normalement si les problèmes sont liés aux objectifs, les KPIs aussi. Et après en termes de comment les réfléchir, Je pense qu'il y a pas mal de choses. Il faut vraiment passer du temps dessus. Parfois, je vois des réponses très rapides et je me dis, bon, combien de gens cliquent sur cette fonctionnalité? Mais c'est déjà ça. C'est vrai que dans des cas, c'est pas mal. Il faut voir s'il y a de l'usage. Mais en fait, souvent, justement, quand on pense au problème, à l'outcome, à ce qu'on veut aussi pour le business, on va au-delà de l'usage en soi. et à voir quelles autres choses on est en train d'impacter. Après, encore une fois, ça dépend du niveau où on est dans l'entreprise. Ça m'arrive de travailler aussi avec des entreprises où on n'a pas du tout de data et que du coup, quand on crée la première version du roadmap, c'est aussi la prise de conscience et c'est dire que la data est à zéro, bon ben du coup, on va traquer des choses et par la suite, on va voir.
Terry : Ouais parce que là-dessus il y a un point, je t'arrête deux secondes là-dessus parce que je pense que c'est un point hyper pertinent, sur le fait quand t'as pas de données ou aussi quand t'es pas très sûr de comment tu vas mesurer en fait l'impact de ta fonctionnalité, tu le mentionnais au début c'est-à-dire que parfois t'as très bien identifié ton problème et donc ensuite tu imagines des solutions et ensuite la difficulté que tu peux rencontrer c'est de dire bah les solutions que j'imagine je vois pas un usage tout de suite qui a l'air de prendre de manière importante mais en même temps je me dis qu'en fait il faut du temps pour que les utilisateurs s'adaptent etc donc cette difficulté à se dire une fonctionnalité fonctionne ou pas pour répondre à mon problème et est-ce que je dois continuer à mettre de l'effort en fait sur consolider cette fonctionnalité versus passer sur autre chose lorsque tu n'as pas cette donnée zéro ou que tu as des points difficiles sur comment mesurer, parce que comme tu disais, c'est pas toujours juste un taux de clic sur un bouton, ça peut aller au-delà effectivement du produit, et souvent c'est le cas, c'est-à-dire que c'est l'expérience globale que tu vas vivre au travers du produit. Ça peut être compliqué du coup d'arbitrer en fait, et je me pose aussi la question, tu vois, en t'écoutant, sur des problèmes d'alignement qui peuvent se poser à ce niveau-là, c'est-à-dire que Autant tu peux être très aligné sur le problème, autant une fois que tu designes des solutions, tu as toujours un peu des divergences sur quelle est la meilleure solution pour répondre à ce problème. Et derrière, sur quelle base solide se baser pour dire est-ce que la solution A était mieux que la B ?
Alexandra : C'est là que les outcomes vont t'aider. Parce qu'en fait, si tu as bien défini ton outcome, tu sais quel est le changement dans le comportement de l'utilisateur que tu veux apporter. Qu'est-ce que l'utilisateur va faire de plus, de moins ou différemment ? Donc là, ça ne va pas être que l'utilisateur fait un clic quelque part, l'utilisateur va gagner X temps parce que ou l'utilisateur va s'engager dans une autre action qu'il ne faisait pas avant ou il va comprendre quelque chose qu'il ne comprenait pas avant, qu'il va débloquer d'autres parties de ta fonctionnalité ou de ton produit. Si ton outcome est bien défini, tu sais ce que tu cherches comme changement de comportement, donc tu vas aller chercher des preuves de ce changement de comportement, déjà niveau utilisateur. Après, ce changement niveau utilisateur apporte certains impacts niveau business. Et c'est là, est-ce que tu as la data zéro ou pas ? Voilà, il faut aller chercher. Mais du coup, cette partie outcome, ça t'aide déjà à aller chercher même la solution. En fait, ça va être la solution qui va vraiment apporter ces changements dans son comportement par la manière dont on résout le problème.
Terry : Ouais donc c'est vraiment toujours avoir cette prise de recul en fait entre ce que tu es en train de faire concrètement au niveau de ta fonctionnalité et peut-être pas se concentrer sur des métriques purement techniques du style le nombre de clics sur un bouton, le nombre de temps resté sur une page mais plutôt ensuite d'aller chercher des métriques qui vont donner de la donnée plutôt qualitative sur l'expérience globale que ton client a vécu suite à cette évolution là et d'où parfois d'ailleurs des questionnaires qu'on peut avoir ou ce genre de choses sur des produits qu'on utilise qui peuvent avoir une visée à comprendre une fois qu'une fonctionnalité a est sortie est-ce que j'ai réussi à impacter de manière beaucoup plus importante le comportement de mon utilisateur tout en remontant ça, en fait en reconnectant ça avec effectivement l'outcome qui était visé puisque c'est ça in fine.
Alexandra : Exactement et après on va chercher du quali, du quanti, du volume, pas volume en fonction de ce qu'on a. Et après il y a aussi des manières de de créer de la data même en amont. Par exemple, à un moment, j'étais dans un projet où on était en train de refaire un espace client assistance online. Et en fait, on ne savait pas qu'est-ce qu'on devait refaire toute la partie où les gens posent des questions. Mais en fait, on ne savait pas, on avait zéro data, on ne savait pas quelles questions les gens posaient. Donc en fait, nous, on devait créer des menus, plein de choses, mais en fait, on ne savait pas même quelle information il faut amener en avant. Et du coup, ce qu'on avait fait niveau test avant de faire la solution, c'est qu'on avait mis, d'ailleurs c'était intéressant par rapport à ce qu'on teste ou pas, c'est qu'on s'est dit la solution, les gens ils cherchent des réponses, mais on va faire un search. Du coup, avec l'équipe, on s'est posé la question, est-ce qu'on va tester ça parce que ça a l'air tellement évident. Bah, tu cherches un truc, tu mets un search, c'est pas sorcier. On a décidé de tester avec l'équipe. Et en fait, les gens, ils ne cliquaient pas trop sur le search et il s'est avéré que dans notre contexte, le search n'était pas la bonne solution. Donc, on a fait des ABC tests par la suite. On a vu qu'ils voulaient plutôt voir ça dans des menus d'une certaine manière. Mais ce qu'on avait fait quand même, c'est qu'on a mis un search. de manière très quick and dirty en fait, donc ça amenait vers les infos existantes et tout. Et en fait, les gens ils cherchaient, pas tout le monde utilisait ce search forcément, mais les personnes qui l'ont utilisé, ils nous donnaient de la data sur quel topic ils étaient en train de chercher. Donc ça, ça nous a fait créer des datas en 2-3 semaines, le temps d'affiner le reste de la solution. Et du coup, on a pu commencer avec quelques catégories de questions-réponses au lieu d'essayer nous de deviner. Donc, il y a toujours un peu cette idée de comment je peux me créer de la data rapidement même si ce n'est pas toujours parfait, je ne vais pas avoir l'échantillon sur tous mes clients, mais être toujours dans cette dynamique de créer.
Terry : Super anecdote donc en fait c'est tes utilisateurs qui étaient minoritaires mais ceux qui utilisaient le search qui t'ont fait tes premières FAQ en fait avec assez intéressant. Du coup on a fait je pense un tour assez sympa là de qu'est-ce que c'est qu'une Outcome Based Roadmap et puis un peu comment transitionner. Est-ce que déjà il y a des sujets, avant d'aller vers mes questions type de fin d'épisode, est-ce qu'il y a des sujets autour de la roadmap que tu aimerais mentionner qu'on n'a pas abordé ou axé un point particulier dessus ?
Alexandra : Peut-être il y a aussi le fait que dans le format des roadmaps, comme je parlais tout à l'heure, il y a aussi, surtout quand les équipes commencent à scaler pas mal, il y a pas mal de questions de dépendance entre équipes et que du coup les roadmaps, surtout quand on commence à mapper des dépendances ou à faire les équipes collaborer dessus, les roadmaps peuvent aussi être un moyen de mettre ça en avance. ou d'être un peu la chose qu'on montre quand on discute entre équipes et que du coup ça pourrait aussi faire prioriser quand il y a des dépendances par rapport à un impact, à un problème et pas juste après on a aussi l'effort de la solution dans ce cas là qui est rentré en jeu mais qui nous aide un peu plus à mettre en perspective quand il faut prioriser qu'une certaine équipe travaille pour une dépendance pour une autre.
Terry : Alors, c'est revenu. Essaye de parler pour voir si je t'entends.
Alexandra : Oui, je parlais d'interdépendance.
Terry : Ouais, ouais, pardon. Petit problème technique. Donc, ouais, non, je disais, hyper intéressant parce que ça rappelle encore une fois de plus l'importance de la communication et l'intérêt en fait de tous ces outils pour communiquer, pour mettre en évidence. Là, tu parlais des interdépendances qu'on peut avoir dans toute organisation qui commence à être de taille importante, tu as toujours ces problèmes de silos et effectivement ça permet aussi de mettre en évidence des dépendances entre différents départements et de réaligner toute l'organisation sur est-ce que là on est tous alignés sur l'output qu'on avait visé ou pas.
Alexandra : Oui et pour moi vraiment les roadmaps sont un outil de communication en fonction de ce que tu veux communiquer. Moi je joue pas mal de fois avec les formats et même pareil avec le leadership team t'as pas le même format, t'as des roadmaps en externe t'as pas le même format. Donc en fait je joue souvent avec le format pour justement pouvoir communiquer, passer certains messages, aligner les gens et même quand on crée les roadmaps de manière un peu collaborative je crée plus d'alignements avec ça et j'amène aussi plus les gens vers un mindset plus produit vu qu'on les crée déjà comme ça.
Terry : Super. Déjà merci pour tous ces partages avec Sandra et donc pour aller vers mes deux questions type sur Just A Click donc la première c'est est-ce que donc tu as une conviction forte assez clivante avec laquelle en général tu es en désaccord avec tes pairs à partager ou en tout cas une conviction assez...
Alexandra : J'ai pas mal de convictions. Alors, ça arrive parfois d'être en désaccord. En fait, moi, c'est plus sur... En fait, moi, à un moment, j'ai appris à faciliter pas mal l'atelier pour les prises de décisions. Et souvent, quand je suis dans des codires ou je bosse avec des... différents leadership teams, j'essaie d'amener tout le monde à converger vers certaines choses. Et en fait, pour moi, dans la prise de décision, l'intelligence collective, elle est très importante, à la fois parce que je trouve que souvent, ça nous amène à de meilleurs résultats. Tout seul, on ne peut pas vraiment avoir toute la vision et la vérité absolue, mais aussi par le fait que les gens, ils sont beaucoup plus embarqués. par la suite, une fois qu'ils ont eu leur mot à dire. Et si on le fait d'une manière très efficace, dans un atelier, en une heure, on va éviter plein d'aller-retours et des réunions. Pour moi, c'est... voilà, moi souvent je suis très partisane de ça et ce que je fais en général quand je travaille avec différents codiers ou même avec des équipes produits. Après j'entends aussi pas mal de fois des leaders qui disent bah moi je suis le CEO, c'est moi qui décide, c'est moi qui va dire comment faire et on va pas perdre le temps à débattre. Donc c'est vrai que voilà c'est deux avis assez différents. Après moi je suis quand même très partisan de cette manière plutôt collaborative. Après bien sûr il faut être efficace donc si on est dans un atelier et qu'on n'arrive pas à se décider vraiment Normalement, on arrive avec plein de méthodes, mais si on n'arrive vraiment pas, ben là, il doit y avoir quelqu'un qui a le dernier mot, donc dans ça, oui. Mais pour moi, c'est toujours très important d'embarquer les gens, d'avoir vraiment cette approche collaborative. Je ne suis pas vraiment en mode, moi j'ai la vérité, je vais vous dire comment faire. Et je trouve que les résultats par la suite, le niveau d'implication des gens et les idées qui ressortent sont beaucoup meilleurs.
Terry : Ben là-dessus, en tout cas, t'es pas en désaccord avec moi, je suis totalement aligné là-dessus. Par contre, là où je te rejoins et moi je mets un point fort, c'est de te dire qu'effectivement, dans l'intro du podcast ou sur la conclusion, je le dis, seul on va vite, ensemble on va loin, parce que moi je suis persuadé qu'effectivement, c'est le collectif qui fait que tu peux avoir les meilleures réponses. En revanche, là où je te rejoins complètement et là aussi où j'ai une conviction moi forte, c'est sur le fait qu'au moment où il faut décider, où il faut trancher, il doit y avoir une personne qui doit décider et cette personne doit être tenue responsable de la décision. Et c'est là pour moi où les rôles du coup de CEO, enfin vraiment de directeur de département et autres ont tout leur intérêt, c'est-à-dire qu'ils doivent pour moi se nourrir de l'intelligence collective mais ensuite avec ce qu'ils ont eu de cette intelligence-là, c'est à eux derrière d'assumer une décision qu'elle soit alignée avec ce qui avait été généré durant les ateliers d'intelligence collective ou non alignée mais c'est à eux derrière de porter ça et là dessus je te rejoins aussi du coup de quand il faut décider par contre c'est peut pas y avoir 15 personnes qui décident sinon tu perds l'ownership.
Alexandra : Derrière — Oui, effectivement. Après, il y a aussi le concept de « disagree » et « commit » qui est très important. C'est que voilà, on a tous débattu, on n'est pas d'accord, mais la plupart des gens, ils ont voté X. Je ne suis pas d'accord, mais je vais quand même « commit » à arriver à ce résultat-là. — Je vais m'engager effectivement. — Mais après, je pense que c'est quand même un sujet où il y a pas mal de débats, parce que récemment, je parlais avec... En fait, il y avait un codire qui me disait que eux, par exemple, ils étaient pas mal jugés par leurs investisseurs et par le vicifant avec lequel ils bossaient parce qu'ils étaient trop collégial dans la manière de prendre des décisions et que leurs investisseurs auraient voulu qu'ils aillent quelqu'un qui tranche plus différemment. C'est très différent, je pense, en fonction de la situation.
Terry : Yes, clairement. Et du coup, merci pour ce partage. Et sur la question de la dernière, c'est celle des ressources que tu pourrais recommander aux personnes intéressées autour du produit, notamment sur la partie roadmap. Et toi, les choses qui t'inspirent, qui te nourrissent aussi dans ce que tu fais, dans ton rôle de fractional CPO, d'aide dans les orgas dans lesquels tu interviens. Je suis curieux d'écouter un peu tes ressources clés.
Alexandra : Wow, il y a plein de choses. Je pense que là on a pas mal de chances, on produit, il y a pas mal de choses. Après, c'est… voilà, il y a plein de livres. D'ailleurs, il y a un livre sur les outcomes-based roadmaps qui est très, très bien. Même, bon, les fameux livres de Marty Kagan ou sur la partie plus lean startup ou celle de Ash Moria. Donc, il y a pas mal de livres qui sont très bien. Après, ça ne remplace pas forcément la pratique. Ce qui est vraiment important pour moi c'est la pratique. Après moi personnellement j'écoute plus des podcasts. Par exemple les podcasts de l'année sont hyper intéressantes où ils ont vraiment des deep dive sur comment ils ont fait certains sujets. Il y a plein de podcasts en France aussi qui sont très très intéressants comme celui que tu fais aussi. Il y a pas mal d'autres. Moi j'écoute quelques podcasts. Après il y a aussi Toute la partie parler avec d'autres gens, je pense que c'est hyper enrichissant de faire du networking, de rencontrer des gens et d'échanger sur différents sujets. Il y a un peu moins de meet-ups après la pandémie, mais même aller dans certains meet-ups, échanger après avec les pairs, poser des questions. Et pour moi c'est aussi trouver très rapidement des petites occasions dans ton entreprise à essayer d'implémenter ce que tu as lu ou ce que tu as entendu parce que sinon ça peut devenir un peu frustrant de juste avoir de la théorie et de se dire moi en fait je ne peux pas faire ça. Donc trouver des petites occasions même si ce n'est pas idéal et commencer à apprendre aussi sur le temps, sur le fait.
Terry : Super, et bien merci, je pense que t'as donné pas mal de conseils pratiques aussi dans cet échange donc j'espère que ça donnera aussi des idées aux PM qui nous écoutent et merci pour ton temps Alexandra.
Alexandra : Avec plaisir.
