L'Opportunity Solution Tree en pratique - La méthode Discovery de Teresa Torres

Wow, ok. Bonjour à tous. Je ne sais pas si tout le monde me voit, tout le monde est là. N'hésitez pas à dire dans le chat. Yes, ça like. Super. Ok, on va attendre une ou deux minutes que les gens arrivent tranquillement. Là, vous êtes déjà 25, donc c'est super cool en vrai. C'est énorme. Je peux faire des dédicaces. On fait des dédicaces à Fadel. Je ne sais pas si tu m'entends. Les gens d'état, yes, bienvenue à tous. Du coup, ce petit meet-up, on va dire que c'est un meet-up parce que ça n'a jamais été tranché le mot, mais ce n'est pas grave. Dans la team, on a Pauline qui est avec nous, qui sera à la technique, Pauline en régie. Amélie, du coup, qui sera là sur le chat et dans les sondages, etc. pour les questions aussi. Et puis moi, qui va présenter tout ça. 30 personnes. Quand vous me dites, on démarre en vrai. Super. Écoute, 13h01. Allez, on fait les agilistes. On y va ? On démarre ? C'est parti. Oui, tout le monde voit ma petite presse. Super. Du coup, aujourd'hui, déjà, petit point d'intro, c'est notre tout premier... meetup en tant que IETA. On verra à la fin un peu qui on est, qu'est-ce qu'on fait tout ça. Mais du coup, c'est pour dire aussi qu'on tâtonne un peu sur Livestorm. Donc là, on a paramétré comme on veut, comme on peut. Bon, s'il y a des trucs, des quacks, il ne faut pas hésiter à nous le dire dans le chat. On y répond, on y réactif. Et voilà. Et donc aujourd'hui, on va parler de l'opportunity solution tree. Moi, l'idée, c'est qu'on fasse 20 à 25 minutes. Comme ça, tout le monde peut avoir un maximum d'infos en un minimum de temps sur un retour d'expérience de comment j'ai pu mettre en place cette méthode-là chez un client. J'en brille direct, mais ça ne marche pas. Désolé. Voilà. Un petit point de contexte. J'ai commencé à mettre en place cette méthode pendant six mois. Donc, c'est une méthode qui a été mise en place. Ça a été un peu long, en fait, d'avoir des métriques de succès, de pouvoir avoir des retours intéressants sur la méthode. Mais du coup, c'est le condensé de ces six mois, on va dire, grosso modo, six mois d'expérience, de l'opportunity tree. Comment on a fait ? Donc, on a fait par l'exemple. Donc, la mise en place, celle s'est faite feature team par feature team. Mais de toute façon, ne vous inquiétez pas, on va détailler tout ça après. Et surtout, je me permets de rendre à César tout le crédit parce que j'ai mis cette méthode en place à Cybele Angel, qui était mon client à l'époque, et avec l'incroyable team design ci-dessous, Maureen, Karine, Julie, gros gros big up. Donc voilà, aujourd'hui on va voir tout ça, on va rentrer dans les détails un peu. quels étaient les problèmes, à quoi ça a permis, qu'est-ce que ça a permis de résoudre, de mettre en place un tri, et comment ça marche aussi surtout, et comment ça fonctionne, et comment on peut l'appliquer. C'est ça qui est intéressant. Salut Julie ! Je vous vois, je vous vois tous. Du coup, les petits problèmes. Alors, quand on est arrivé à Sibel Angel, on avait plusieurs, on s'est face à plusieurs problèmes qu'on a dû solutionner. Le premier, c'était que les... PM avait des méthodes de travail qui étaient différentes. Donc, ça peut être des choses qui vous font écho. Voilà. N'hésitez pas à réagir aussi dessus. Vous pouvez poser... C'est vrai que je n'ai pas... Pardon. Je fais une mini-pause. Donc, si vous avez des questions, n'hésitez pas à les poser dans le chat n'importe quand. On fera des pauses à chaque fin de partie, en gros. Donc, il y aura des petits temps de questions entrecoupant le meet-up. Donc, n'hésitez pas à être... à dire tout ce que vous avez besoin de dire dans le chat. Donc, je reprends. Les problèmes, c'était que chaque PM avait une méthode de travail différente. Les PM n'étaient pas vraiment très matures sur la discovery. Il y avait beaucoup de delivery, pas forcément de discovery, comme on peut le voir dans pas mal d'organisations. Les décisions produits, du coup, elles étaient prises avec peu de données. Et le design, forcément, par effet de bord, était perçu comme un... On appelle ça « design as a studio », c'est-à-dire les designers dans un coin et quand on a besoin d'eux, on les appelle. Il n'y a pas forcément de logique d'intégration ni de comment on pense le flow produit avec le design. Tout ça, c'était les problèmes sur lesquels on a dû faire face avec la team de Maureen. En gros, les questions qu'on peut se poser aujourd'hui, c'est comment on peut ramener de la disco dans les process produits. comment on peut harmoniser aussi les process par effet de bord, et puis comment on peut prioriser et rationaliser la discovery. Ça aussi, c'est un point qui est intéressant, je pense, pour tous les PM qui sont dans la chatrouille. Je pars sur, encore une fois, il va arriver le tri, ne vous inquiétez pas, mais c'est important pour moi, je pense, de passer sur cette étape-là et de dire un petit mot sur le travail par hypothèse, parce que ce n'est pas toujours le cas. Dans un process design thinking classique, on connaît, il y a de la disco, il y a de la delivery, recherche, définition, idéation, prototype, on connaît. Ça part d'un objectif et ça va jusqu'à la réalisation. Dans la vraie vie, de temps en temps, la recherche, on n'a pas trop le temps de la faire, donc on la biaise ou on la squeeze carrément. On part direct dans la définition, l'objectif c'est la définition, et puis on y va, on fait des protos, on teste si on a du temps, et voilà. Ce qui est important de rajouter à ce process-là, je pense, c'est dès la phase de research, c'est de se forcer à faire un minimum de research, même le plus petit interview, si c'est possible de faire un interview, go, et surtout de formuler à cette étape-là des hypothèses qu'on va pouvoir tester après. Ne pas partir bien en tête avec des solutions, mais plutôt travailler avec des hypothèses. Moi, j'aime bien faire ce distinguo entre hypothèse et solution. Cette base-là va nous servir ensuite pour construire le tri. C'est plus intéressant de se dire, je sais que je ne sais pas, et de poser des hypothèses à la base qu'on va définir vraie ou fausse à la fin du process. Ça fait le lien avec notre petite Opportunity Solution Tree. Est-ce que jusque-là, c'est assez basique, on va dire que c'est de l'intro, est-ce qu'il y a des questions ? Non, je ne crois pas. Tu les vois apparaître à droite, sans question. Tu as Sarah qui a commencé à poser une première question. C'est parti. C'est parti. Alors, tu as Pierre qui te demande, est-ce que vous êtes affranchi d'une roadmap classique avec la mise en place de l'Open Solution Tree ? Non, on a complété et éclairé la création de la roadmap grâce à l'Opportunity Solution Tree. On va dire OST, pour aller plus vite. Ça ne remplace pas une roadmap, je pense, parce que c'est très axé sur la discovery, tu vas voir. Mais par contre, ça te permet de faire une roadmap qui est plus documentée, en fait, et qui a plus de sens aussi, je pense. Qui n'est pas uniquement basée sur des paris business ou des inputs, etc. Qui est basée plus sur des faits, ce qu'on a pu observer, et tout ça. Voilà. Il y avait une autre question ? Alors, tu as deux autres questions. Donc, on a Sarah qui nous pose la question, qui te demande, avant de partir sur un OST, est-ce que la création d'une Customer Journey Map est un prérequis pour toi ? En fait, la Customer Journey Map, elle peut se faire en parallèle, je pense, parce que tu vas le voir ensuite aussi, mais dans l'OST, il y a toute une partie de définition de ce qu'on sait et ce qu'on ne sait pas. Pour moi, ça se parallélise avec une customer journey map. Je pense qu'il faut le faire à un moment donné, soit avant, après, pendant, peu importe. Mais c'est super cool de le faire parce que ça complète vraiment le travail que tu peux faire sur l'opportunity tree. En fait, l'opportunity tree, ça va être un cadrage. Après, tu vas plugger ce que tu veux à ce cadrage-là pour le matérialiser. Donc, des maps, du mapping, des road mapping, etc. Mais oui, ce n'est pas carrément complémentaire. Il y avait une autre question, je crois. Yes. Ensuite, tu as Farah qui te demande quel était le problème, les conséquences, risques au fait que les PM avaient des méthodes différentes ? Du coup, salut Farah. Parce qu'on se connaît. Le problème d'avoir des méthodes différentes, c'est que... Tu vas avoir de l'asymétrie, je ne sais pas si c'est le bon mot, mais dans les process de travail de chaque PM, il y a des PM qui vont accorder beaucoup d'importance à faire de la disco, par exemple. Il y en a d'autres qui vont être très axés delivery et du coup, ça va se ressentir dans leur future team, dans la manière de délivrer, ce ne sera pas uniforme. Tu as des teams qui vont délivrer moins vite que d'autres et ça va peut-être générer des frustrations au niveau de l'organisation. parce qu'on va se demander pourquoi, alors qu'en fait, ils livrent peut-être mieux que d'autres, mais il y en a d'autres qui livrent plus. De mon point de vue, c'est assez risqué d'avoir plusieurs manières de travailler au sein d'une même organisation pour le produit. Après, ça peut être de l'ordre de l'expérimentation, mais il faut que ce soit clair, en fait, que cette feature team-là est une feature team expérimentale et que ce ne soit pas généralisé, parce que sinon, après, la delivery, elle s'en ressent, je pense. Mais après, c'est un point de vue assez personnel, je pense. Il y avait d'autres questions ? Non, tu peux enchaîner. Let's go. Pour faire la définition basique, c'est une aide visuelle qui aide à activer le processus de discovery produit. On va se passer le jargon compliqué, mais grosso modo, ça part d'un objectif business qui doit être mesurable. Ce qui est écrit dans le livre en tout cas. Ensuite de cet objectif, on va définir des opportunités. Donc ces opportunités, ça va être des bénéfices pour l'utilisateur. C'est-à-dire pour arriver à augmenter de 100% mon usage de produit, quels bénéfices l'utilisateur peut tirer de cet objectif-là. Donc en fait, il faut le lire à l'envers. De ces opportunités, on va générer aussi des solutions. par quels moyens on peut actionner, on peut rendre réaliste ce bénéfice utilisateur pour compléter cet objectif. Et du coup, de ces solutions-là, on va y associer des mesures, donc n'importe quel KPI, pour valider que la solution fonctionne, ou en tout cas mesurer un minimum de réaction sur la solution. Et à partir de ça, on rentre dans ce processus d'itération, donc discovery, delivery, etc., de sprint en fait. On rentre dans le processus de sprint. Ce qu'il faut comprendre sur ce tri-là, c'est que c'est un prérequis du travail et que c'est très lié à une organisation basée sur des produits Google. En tout cas, C'est comme ça qu'on l'a expérimenté à Cybèle. Il y a des product goals qui sont définis. Je ne sais pas, ça dépend des organisations. Des fois, ça va être à 6 mois, à 6 mois. Des fois, ça va être à 3 mois, au quarter, peu importe. Il y a des product goals qui sont définis sur une temporalité. L'OST va intervenir au début de cette définition-là. On a notre product goal. Maintenant, on va... creuser ce Product Goal-là, on va essayer d'explorer des pistes et de savoir sur quoi on va travailler sur les 6 prochains mois, les 3 prochains mois. Et découper tout ça après en roadmap, en sprint, etc., en story map, comme vous voulez. Donc, l'OST, dans le temps, il arrive, je ne sais pas, en fonction de la temporalité de vos Product Goal. Si c'est à 6 mois, il y en aura 2 dans l'année, ou 2 travail de refonte d'OST dans l'année. Si c'est 3 mois, il y en aura 4, etc. Voilà, donc en gros, un produit GoLegalUnrested. Les avantages de faire cette méthode-là, c'est que ça crée un lien logique entre l'objectif et les opportunités et les itérations. Donc ça fait un peu usage de squelettes, si vous voulez, de toute l'organisation de la team produit entre les PM, les designers, les PMM aussi, les QA, j'en sais rien, les devs. ça rend la levée de solutions très concrètes, du coup, parce qu'on y associe des mesures de succès. Et après, dans cette méthode-là, qui est méthode de base, on va dire, la méthode du bouquin, c'est possible d'introduire des biais, en fait, en érigeant les solutions comme des certitudes. Quand je reviens un peu en arrière, c'est-à-dire ici, au lieu de dire, la solution, c'est une hypothèse, ça peut, dans certains cas, on peut être tenté de dire, ça, c'est une solution, et moi, j'y crois beaucoup, en fait, à cette solution. parce que j'ai entendu plein de trucs, etc. Pas forcément documenté, mais basé sur du ressenti. Et ça peut introduire certains biais, de se dire, cette solution-là, elle vaut plus que cette solution-là, etc. Donc, pour pallier à ça, on va revenir sur notre précision, notre hypothèse de tout à l'heure. Déjà, on part du product goal. Donc, comme j'ai dit, mesurable, limité dans le temps, ça soutient une vision, ok. De ce produit code-là, on va définir les opportunités. Comme je le disais, les opportunités, c'est des bénéfices utilisateurs. Mais si c'est difficile, par exemple, à Cybelle, tous les PM n'avaient pas la même manière de penser. Normal, on est tous des humains. Si c'est difficile de penser bénéfice utilisateur, on peut aussi penser problème et après le tourner en bénéfice. Ça reste une histoire de formulation. On peut aussi le penser causalité et le retourner en bénéfice. La méthode est flexible, ce n'est pas un dogme ou quoi que ce soit. Une fois que ça, on a ça, on définit nos hypothèses. On pense que pour matcher cette opportunité, on pense que ça peut résoudre une partie ou toute l'opportunité. Ensuite, on va rentrer dans un détail un peu plus compliqué que la méthode de base pour essayer de dégrossir les hypothèses. Imaginons, on pense que ça, ça va résoudre notre opportunité. Ça, qu'est-ce qu'on sait dessus ? Qu'est-ce qu'on ne sait pas ? C'est quoi les risques ? Et ça, c'est super important, je pense, de faire cette étape-là. Ça, ça va être un peu le nerf de ce tri-là et ce qui va lui donner du corps. C'est de lister avec les bonnes personnes dans la salle toute la connaissance sur l'hypothèse en question, toute l'inconnaissance aussi, et puis des risques qui peuvent être techniques. qui peuvent être fonctionnels, qui peuvent être humains, je ne sais pas. Et à ça, du coup, on va pouvoir associer après un score de confiance ou un score de maturité. On va dire que c'est la même chose. On reviendra dessus juste après. Et puis, comme tout à l'heure, mesures, etc. Et ça nous offre en fait cette snapshot de, à date, tout ce qu'on sait, tout ce qu'on a besoin de savoir pour pouvoir avancer, etc. Du coup, je détaille un peu cette histoire de score de confiance. Dans ce score, en fait, dans la manière dont on l'a pensé à Sybèle, il y a des choses qui vont impacter le score positivement et d'autres négativement. Les inconnus et les risques, on s'est dit que c'est moins un point. Une inconnue, c'est moins un, un risque, c'est moins un. Donc là, j'en ai trois, c'est fait moins trois. Les savoirs, ce qu'on sait sur l'hypothèse, c'est plus un. Donc là, j'ai plus 2. Dans ce cas de figure-là, j'ai 0 parce que j'ai plus 1, moins 1. Ce score-là a son importance parce que juste après ce travail-là, je vais pouvoir réutiliser ce score, je passe direct, dans une matrice pour pouvoir prioriser mes opportunités et mes hypothèses. C'est un peu tout l'intérêt de l'opportunity tree, c'est déjà de dégrossir tout ce bazar. Et ensuite, de prioriser les idées et les actions. Donc en gros, on a remis nos jalons de maturité sur un axe. Et sur un autre axe, on peut avoir par exemple l'importance. Alors après, vous définissez l'importance comme vous voulez. C'est en fonction des organisations, je dirais. Et du coup, ça nous donne une répartition. Donc on peut placer nos hypothèses. Et on sait que les trucs qui ont une forte maturité, où on sait beaucoup de choses, et qui résolvent un pain par exemple, ça va être dans une green zone, on sait qu'on peut le tacler direct et on y va. À l'inverse, des trucs où il y a faible maturité et que ce n'est pas très important, c'est plus un nice to have, on va essayer de le mettre en dessous du pipe et comme ça, ça va nous donner une échelle de valeur. Et puis du coup, ce qui est dans les deux autres cases, ça nous donne aussi ce qu'on doit faire en termes de discovery. Là, par exemple, si on a une faible maturité, mais que ça résout un pain, ça serait intéressant aussi de le prioriser en termes de discovery. Et du coup, voilà. Donc, une fois qu'on a tout ça, on a notre organisation, on sait par quoi on démarre, dans quel sens on va, etc. Et c'est en ça que ça aide à créer une roadmap. Parce que du coup, ça te donne déjà une priorisation de la disco, de choses que tu sais et que tu ne sais pas. Du coup, ça peut t'éclairer dans la création de ta roadmap. Je reviens vite fait en avant. Donc voilà, ça crée un lien logique, ça identifie là où on doit faire de la discours en priorité, ça augmente son niveau de confiance sur les hypothèses et ça les dérisque aussi, parce qu'on lève les risques. Ça rend la levée d'hypothèse très concrète et du coup, on y associe des mesures de succès comme la méthode de base. Et ensuite, c'est pas fini ! C'est jamais fini. Non, mais c'est important. Ensuite, on prend ce schéma-là. On est super content. On a tous nos news, nos knowns, nos risques, etc. On rentre dans nos process de discovery, delivery, développe, etc. Donc là, je vais prendre un pan, le premier pan, le 1.1. On a priorisé un premier. Et puis, on va rentrer dans le process. Est-ce qu'on a besoin de faire la disco ? Oui, non. Est-ce que, du coup, on s'éloigne pas ? Et let's go, on chip, quoi. Une fois qu'on a développé ça, on y associe notre métrique de succès qui va nous dire si l'hypothèse est vérifiable ou pas. Est-ce qu'elle a marché ? Est-ce qu'elle n'a pas marché ? Ça nous donne la marche à suivre. Si elle a marché, on continue, on fait un autre pan. Si elle n'a pas marché, est-ce qu'on laisse tomber ? Est-ce qu'on fait un autre pan ou est-ce qu'il faut faire plus de discos ? Ça nous met dans une mécanique. qui fonctionne. Plot twist, petite démo, mais avant ça, des questions, s'il y a des questions. Oui, tu as pas mal de questions. On va commencer par Benjamin, sur le product goal. Quelle serait une bonne temporalité pour un product goal pour toi ? Un mois, deux à trois mois, six mois ? Il doit être stable ou on peut changer sa temporalité d'après toi ? Par exemple, le premier a trois mois et le second a deux mois. Je ne suis pas la meilleure personne pour répondre à cette question parce que je ne suis pas un PM. Je suis produit designer, mais du coup, avec mon expérience, je dirais que six mois, c'est bien parce que ça te permet d'explorer la moitié, si tu es chanceux, des pistes que tu as développées pendant ton trip parce qu'on ne va pas tout explorer dans toutes les pistes que tu vois ici. En six mois, en fonction de ton organisation, je ne sais pas, peut-être que tu vas en explorer la moitié. Nous, à Cybelle, on avait en général une petite dizaine en moyenne. On en explorait quatre, cinq à chaque fois. Et on était contents quand ça arrivait. Les autres, ça ne veut pas dire qu'elles sont à la poubelle. Ça veut dire qu'on les sauvegarde. Pour moi, je pense que six mois, c'est une temporalité qui te permet d'être assez libre. Mais ça dépend des organisations, je dirais. Je ne sais pas. Je te vois en train de taper, si tu veux compléter. Merci beaucoup. Justement, je voulais un avis au truc MPN. Il y avait d'autres questions, du coup ? Oui. Ensuite, tu as Samuel qui te demande, par curiosité, c'est quoi le livre que vous avez pris comme référence pour expérimenter la méthode ? C'est le livre de Teresa Torres. C'est vrai que je n'en ai même pas parlé, mais c'est Customer Delivery Habit. C'est le livre de Teresa Torres. Je n'en ai même pas parlé, j'avoue. Mais je vais le... On est dans le chat, la référence. On balancera à la fin. Yes, continue. Oui, voilà, merci. Ensuite, tu as Florent qui te demande comment gérer, prioriser la disco sur chaque hypothèse d'une même opportunité. Prioriser la disco sur chaque hypothèse d'une même opportunité. Du coup, j'ai répondu avec la matrice, non ? Oui, si tu veux redire un petit mot. Non, la matrice répond à la question, à mon avis. Tu as tes deux axes, tu priorises. Par contre, je n'en parle pas là, mais la priorisation des opportunités dans la matrice, ça n'a pas trop de sens. Parce que si tu la calibres en fonction du score de maturité, le score de maturité s'applique aux hypothèses. Après, soit tu fais une pondération et tu dis... Enfin, tu fais une grille B avec une maturité qui est plus large. Je ne sais pas. Ou alors, c'est au jugé. Là, c'est un peu la faiblesse du retour d'expérience. C'est que la priorisation des opportunités n'est pas encore craquée. Mais ça, vous pouvez le craquer de l'autre côté. Du coup, je n'ai pas grand-chose à rajouter, Florent. Ça marche. Ensuite, tu as Kevin qui te demande, est-ce que tu as une technique objective pour mesurer ton savoir concernant une hypothèse ? Parfois, on entend quelque chose en interview, parfois on a des analytics. À quel moment tu te dis, ok, là, je suis sûr de moi ? En fait, je pense que le plus important, c'est à cette étape-là, où tu vas définir savoir inconnu, risque, c'est d'inviter un maximum de personnes qui… sont impactés par le travail du produit. Par exemple, ça va être les profils connexes type data, dev, QA, PMM, etc., tout ce qui gravite autour du produit pour rassembler de la donnée que tu n'aurais pas forcément. Parce que si tu bases tout sur ce que tu sais en tant que designer ou produit, etc., ou ce que tu ne sais pas, tu ne pourras pas... Tout brosser, il faut inclure un maximum de gens, il faut être collaboratif dans cette étape-là pour pouvoir brosser un maximum de choses. J'ai un milliard d'exemples où on commence un tri avec un PM et on se rend compte que les risques, on en a imaginé certains, mais les risques techniques, on ne peut pas les imaginer. On a besoin de data science, on a besoin de devs autour de la table pour les imaginer. Donc la réponse pour moi serait collaborer au maximum. Justement, tu as Farah qui te demande comment en pratique s'est organisée la conception de cette OST, atelier asynchrone, synchrone, présentiel, combien de temps, combien de personnes, qui l'idée ? J'y arrive, c'est la suite. Ensuite, tu as Fadel qui te demande n'y a-t-il pas un biais avec le fait d'arbitrairement dire que tous les risques valent moins un point ? où les risques peuvent avoir une incidence différente, beaucoup plus grave par exemple, par rapport aux autres. Si, carrément, bien vu. Moi, je vous encourage à 100% à revoir la manière dont c'est calculé, parce que c'est une manière A, mais ça se trouve, ça ne correspond pas à votre client, votre organisation, tout ça. Donc, si les risques... Je suis sûr qu'il y a des choses qui peuvent être beaucoup plus granulaires que ça. Moi, je vous encourage grave à... à repenser la manière dont c'est calculé pour la déviser. Après, là, je n'ai pas de solution, mais tu as raison, Fadel. Carrément. Ensuite, Annie qui te demande, est-ce qu'à un moment, les notions de coût, des itérations ou le niveau de valeur espérée entrent en compte dans les décisions de poursuivre ou non l'exploit à ce stade ? Pas dans mon expérience. Après, je ne saurais pas répondre à ça parce que les histoires de coups, c'est fait après, voire bien après. Du coup, c'est lié au sprint. Pas trop dans mon expérience, je n'ai pas trop de réponses. Désolé, je ne sais pas tout. Merde. Et donc, je termine par Patrick. Vous avez peut-être déjà répondu, mais c'est ce que tu définis pour mesurer ton product goal. Est-ce que ça augmente ce que tu mesures pour chaque hypothèse ? Si oui, comment tu fais si tu découvres une mesure en hypothèse non définie pour ton product goal ? Attends, tu peux répéter parce que je n'ai pas... En fait, c'est par rapport au product goal. Est-ce que tu définis pour mesurer ton product goal ? Est-ce que ça augmente ce que tu mesures pour chaque hypothèse ? Et si oui... Comment fais-tu si tu découvres une mesure en hypothèse non définie pour ton product goal ? Pareil, je ne suis pas sûr de pouvoir répondre parce que les product goals, ils étaient définis dans l'exemple, dans le retour d'expérience, ils étaient définis par le management. Donc, je n'étais pas vraiment dans ces boucles-là. Nous, on travaillait sur le product goal, donc on faisait confiance. Après, la définition, l'impact sur le product goal, il n'y avait pas beaucoup de latitude là-dessus. Donc, non, pas trop de feedback là-dessus. Déso. Ça marche. Je vais enchaîner. Je reprends cet exemple-là. Ça va nous aider. Pour répondre, c'était Farad de mémoire. Toute la partie goal, surtout opportunité, hypothèse, dans mon expérience, c'est un workshop avec une heure, PM plus designer. Et là, il faut être le plus efficace possible, on va dire, et en même temps, ouvrir au maximum les chakras, entre guillemets. Ça dure une heure en général. PM Designer, après, ce n'est pas exclu d'inviter. Là, c'est PM Designer parce que l'orgas s'y prêtait. Si ça se trouve, ça peut être PM Designer, PMM. En gros, il faut inviter la core team. Là, on est sur 1h, 1h30 pour les produits gold les plus denses. Le but, c'est de bien cadrer ces opportunités et d'abord de faire ces opportunités et ensuite de bien dérouler ces hypothèses et de les formuler correctement aussi pour éviter du coup un maximum de biais dans l'histoire. Et puis après, la deuxième partie, savoir inconnu, risque et mesure, ça part dans un deuxième workshop de 2h, 2h30, ça dépend. On peut pousser jusqu'à 3h, mais ça fait mal à la tête après. Avec PM, designer, et là, toutes les parties prenantes qui sont intéressantes à mettre autour de la table. Comme je disais tout à l'heure, moi j'encourage à mettre des profils tech, des profils market, des profils business. Peut-être pourquoi pas aussi des users, je n'ai jamais fait, mais ça a peut-être du sens. Je ne sais pas. Ou des power users peut-être, je ne sais pas. Voilà. S'il y a une communauté, je ne sais pas, j'imagine, s'il y a une communauté derrière le produit, peut-être que ça vaut le coup de mettre des power users derrière. Je vois des trucs dans le chat. La data sans l'instinct est-elle utile ? On va dire complémentaire ? Allez, on ne se fait pas d'ennemis. Tout va bien. Est-ce que c'est possible de répéter la formule une heure avec PM et designer pour chaque hypothèse, c'est ça ? La formule, c'est-à-dire la formule ? Il y a plus de détails là-dessus. Si c'est la formule du score que tu parles, c'est plus un, moins un, moins un unknown, moins un risque, plus un savoir, on va dire. Si c'est la formule des ateliers, c'est une heure de workshop pour les opportunités hypothèses avec PM et designer, et deux heures de workshop avec les PM designers et toute la team sur toute la partie savoir, inconnu, risque, mesure. Après, c'est possible que ça soit découpé en deux aussi, parce que ça m'est arrivé de faire deux fois le deuxième workshop pour bien mapper. parce que tout le monde n'est pas dispo, ou tu n'as pas eu le temps de tout faire. Une fois qu'on sort avec la mesure, après, la priorisation, donc toute la partie, je reviens sur mon truc, toute la partie-là, cette priorisation-là, on peut la faire en asynchrone, ou en faire un troisième workshop, mais ce n'est pas important d'avoir... Tout le monde autour de la table. Je pense que le PM peut être asynchrone dessus. Moi, perso, je pense que le PM peut s'auto-gérer là-dessus. Parce qu'en fait, il a toutes les billes pour pouvoir le faire. Après, s'il est frileux, on peut l'accompagner. Mais cette partie-là, elle peut se faire un peu plus de manière light. C'est bon, j'ai ma rep. Ok, ça roule. La formule pour le premier workshop. Ok, ça roule. Voilà. Je reviens sur mon petit machin. La démo, je le ferai après parce qu'il faut que je change d'écran, mais ce n'est pas grave, ça va faire ma transition. Est-ce qu'il y a des questions ? Je vois 20 questions. Non, il n'y a pas de nouvelles questions. Ok, j'enchaîne. Ce que ça a permis de faire, chaque PM avait une méthode de travail différente, du coup, une team égale un OST, une team égale un PM, donc ça harmonise un peu les manières de travailler. Après, c'était intéressant aussi le feedback des PM sur la méthodo parce qu'il y avait des PM qui étaient contents d'avoir un outil pour structurer leur pensée. Souvent, les PM ont plein d'idées, ils vont être très dans l'idéation, dans la génération. C'est cool d'avoir un outil qui te ramène un peu, qui rationalise toutes tes idées, et du coup, c'est exactement ce que fait un OST. Les PM n'étaient pas assez matures sur la disco, du coup, la disco est au cœur du process, donc tu ne peux pas trop y couper. Après, c'est toi et tes valeurs, on va dire, ou tes limites, ou tes contraintes surtout, pour gérer cette disco-là. Les discos décisions de produits étaient prises avec peu de données, du coup, Le fait de mapper les choses et de mettre les gens autour de la table, ça fait que tu as un endroit où tu as toutes les infos. Et le design, tu es perçu en Design Studio. Du coup, si c'est le design qui est on-board, c'est normal que ça change. Pour éviter l'oubli, on termine là-dessus. Instaurer des routines. Je pense que c'est important, à la fin des sprints, de revoir le tri avec le PM. Moi, j'aime bien faire ça. Et je pense que c'est admis maintenant. C'était admis à Cybelle aussi. À chaque fin de sprint, on a fait un peu de disco. Du coup, c'est cool de repartir dessus, d'avoir un petit, je ne sais pas, un code avec des couleurs ou des icônes pour se dire, ça, on le sait, bon, on le sait. Ça, on ne le sait pas, il faut qu'on cherche encore, etc. Et craquer l'avancée du truc. Donc, mettre à jour le tri. Et puis aussi, ça peut être aussi, je ne sais pas, trouver d'autres hypothèses. Transmettre la méthode, voilà, la méthode, c'est des outils. La méthode, ce n'est pas un dogme. C'est absolument nécessaire que ce soit transmis et pas gardé, à mon avis. Voilà, on arrive à la fin de ce meet-up. Le voilà était très vénère. Je pense que s'il y a des dernières questions, je crois qu'il y en a une. Il y en a une de Mathieu qui te demande qui a eu le lead pour réaliser, porter la transition de l'unification du process pour chacune des squads slash PM. Ah ouais, merci pour la question. Au départ, le lead, il était porté par le CPO et moi-même au départ. Ensuite, le lead s'est transféré sur Maureen qui est la Head of Design de Cybelle. Et du coup, ça a été principalement Maureen et puis moi en soutien, on va dire, plus en support. Mais ouais, donc ce qu'on peut en retenir, c'est que c'est quand même... facile, agréable, quand tu as quelqu'un du management qui porte avec toi la méthode. On est d'accord là-dessus, je pense. Ouais, on est d'accord là-dessus. Je peux terminer vite fait sur un petit truc. Alors, je vais partager. Attendez, il faut que je revienne sur le machin. Et que je partage un petit cadeau que j'ai pour vous. Je ne sais pas si je vais trouver le mashing. Oui, c'est bon. Hop, ça passe. Le fig jam. Tout le monde voit le fig jam. Oui, super. Il y a un petit fig jam qu'on va vous filer dans la chat room, mais qu'on vous filera aussi en mail ou en mail. Je ne sais pas comment on le file d'ailleurs. On verra, mais vous l'aurez, ne l'inquiétez pas. C'est du coup un template qui reprend tout ce qu'on vient de voir. Vous avez toutes les colonnes. avec un exemple pour vous aider, avec un cas concret d'application fictive, avec à chaque fois des exemples. Donc ça en anglais, désolé les francophones, c'est full anglais pour le coup. Et à la fin, on a notre matrice avec des petites icônes pour mettre à jour nos hypothèses, nos opportunités. Donc ça, Et puis, vraiment, il y a tout là-dedans. J'ai essayé de centraliser au maximum ce truc-là. Je peux mettre le lien peut-être dans la chat-room. Je pense que c'est une bonne idée. Trop bien. Je vais publier des petits sondages. Tu peux y aller maintenant, Romain ? Oui. Avant que vous partiez, on a deux petits sondages pour vous. Je ne sais pas si on entend les travaux autour de moi. C'est insupportable. Oui, le premier. Voilà, premier vote. Attends, je crois que j'ai un petit peu bugué. En fait, on aimerait déjà faire un petit rôti, donc qu'est-ce que ça vous a servi, et puis ensuite voir, vous, est-ce que vous l'utiliseriez ? Allez, venez tous sur le Flick Jam, comme ça, il y a tout le monde en live, là, tout le monde se voit. C'est génial, j'adore. Est-ce que ça a marché ? Vous voyez le sondage ou pas ? Le premier a marché. Je crois que je vous ai envoyé sur mon truc, mais c'est pas grave. Parce qu'en fait, je l'ai mis dans Figma Community pour ceux qui veulent. Je vais peut-être partager. Allez, tout le monde est là. Yes, trop bien. Allez, Kevin, Spideo, il y a des gens qui mettent leur boîte et tout. Non, attendez, parce que j'ai un... En fait, je l'ai mis dans Figma Community. Donc, si vous allez dans Figma Community, vous cherchez Opportunity Tree, Pollution Solution Tree, vous allez le trouver. Mais on vous remettra le bon lien pour pouvoir le dupliquer. Voilà, voilà. Et là, on a le deuxième sondage qui est lancé. Attends, mais moi aussi, il faut que je réponde. Je dièse. Super, OK. Cool. On peut peut-être profiter le temps que les personnes répondent au sondage pour dire deux, trois mots sur IETA. Oui, déjà, du coup, juste pour finir, merci à tous. S'il y en a qui doivent partir, allez-y, il y aura un replay, etc. Et puis, du coup, je te laisse la main, Amélie. Déjà, merci beaucoup, Romain, pour ton partage d'expérience. C'était hyper intéressant. Merci aussi à tous ceux qui ont participé, suivi et posé des questions. C'était chouette. Et donc, pour finir, trois mois sur IETA. Donc, on fait du conseil et de l'accompagnement sur la partie Product Management, Product Design et Coaching. En portuel, temps plein, auprès de clients, grands cons, scale-up ou start-up. Donc voilà, si vous voulez plus d'informations, n'hésitez pas, vous pouvez nous contacter sur LinkedIn ou voir notre site internet. Super, merci à Raphaël Drion dans le chat pour le lien très très cool. Je revente un petit peu, il y a Kevin, tu as une question Kevin ? Avant de couper de Kevin, tu la vois Romain ? Tu as l'air d'avoir eu de bons retours des teams sur la méthode et une belle adoption. Avez-tu des KPI mesurables pour valider le succès de ce changement de méthode ? Des KPI mesurables ? Eh bien non, malheureusement. Ou alors, je dis des bêtises. Je ne sais pas si la team Cybelle peut me corriger, mais Karine, ou quoi ? Moi, de mémoire, je ne crois pas qu'on en avait mis. En gros, c'est est-ce que les PM adoptent ? Pour moi, les meilleurs KPI, ça a été que les PM viennent vers moi et me disent « c'est vraiment bien ce que tu m'as fait faire pour l'opportunity tree, ça m'a vachement aidé à structurer ma pensée. » Moi, à partir de là, c'est bon, merci, bonsoir, je suis content. Mais non, on n'avait pas de KPI précis. Karine qui complète, nombre d'interviews, nombre d'insights, c'est vrai, tu as raison. C'était motivé par Maureen, je crois. Je ne les ai pas en tête, mais ils ont raison, Julie et Karine. Ouais. C'est un bon capillère. Le prochain meet-up, Patrick ? Je ne sais pas. Bientôt. Est-ce que c'est... Tu as le mot de la fin, Romain ? Manger des pommes. On va venir sur ça. Merci à tous. C'était trop cool. Merci. Salut. Bonne journée. Bon week-end.

Tu veux unifier les process PM et Design ? 
Tu fais trop de delivery et pas assez de discovery ? 
Tu veux augmenter la confiance dans ta roadmap ? 

Pendant 6 mois, Romain Magri, Product Designer chez Cybel Angel a testé la méthode de l'Opportunity Solution Tree de Teresa Torres avec l'incroyable team design de Maureen Rodaro. 

🪩 Allez, let's groove !