Transcription de l'épisode : "Marion Lecerf et Nicolas Poitelon, Construire une organisation comme un produit"
Terry : Salut Marion, salut Nicolas.
Marion : Bonjour Terry.
Nicolas : Salut Terry.
Terry : Merci du coup de prendre du temps aujourd'hui pour parler produits, pour parler en particulier d'orgas produits. Et ce qu'on va essayer de faire, contrairement à ce qu'on peut lire beaucoup sur le net en ce moment, c'est d'aller dans des cas concrets, des retours d'expérience, parce que à vous deux vous cumulez pas mal d'expérience, malgré votre jeune âge à tous les deux. Donc avant de rentrer dans ce vif du sujet, je vous propose tout d'abord de vous présenter, puis de présenter ce que vous faites aujourd'hui pour les personnes qui vous connaîtraient pas.
Marion : D'abord, merci de nous avoir invité Terry. Je vais attaquer. Je suis Marion Le Cerf, je suis coach produit. Ça fait un peu plus de 16 ans maintenant que je fais du produit. Rapidement, j'ai commencé par le product marketing avant de transitionner en tant que PO, puis PM, puis Head of Operation. J'ai balayé un peu en 360. tout ça dans différents secteurs, puisque avant de faire du conseil que j'ai commencé il y a quatre ans, j'étais interne et j'ai beaucoup travaillé en médias d'information. Je travaille aussi en start-up, j'ai fait du e-commerce, j'ai fait plein de choses. Donc je mets tout ça au profit aujourd'hui de mon rôle de coach produit que j'ai entamé il y a quatre ans et notamment accompagner les organisations dans leur challenge, dans leur organisation, dans la formation des PM, etc.
Terry : Très clair.
Nicolas : Top, merci beaucoup, merci de nous recevoir Terry. Donc pour moi, alors Nicolas Poitron, je suis malheureusement peut-être un peu plus vieux, mais c'est... Je ne sais pas comment dire ça, mais ça m'a apporté pas mal d'expérience tout du long. J'ai commencé comme développeur il y a quelques années. Et de développeur, de fil en aiguille, on prend un peu de responsabilité et on se rend vite compte que l'orga est un grand axe de progrès, de performance de tous les projets dans lesquels on peut oeuvrer. Et cette organisation m'a donné envie de... d'aller un peu plus loin et de ne pas être focus sur un projet, mais plutôt d'essayer d'apporter cette performance à d'autres entreprises. Et donc à ce moment-là où j'ai monté une agence web basée sur les pratiques et les principes de l'agilité, ça a plutôt très bien fonctionné. On a eu des très belles expériences, on a cassé un peu les codes autour du cahier des charges et plutôt quelles étaient les clés de la réussite des projets qu'on pouvait oeuvrer pour des clients et donc de casser un peu tout ce système. Ce qui m'a donné mes premières armes en tant que coach Agile. Et c'est là où j'ai rejoint Mythic en tant que coach Agile et j'ai pris petit à petit le lead sur l'organisation produit au sens large de Mythic. Au bout de quelques années, ce qui s'est passé c'est que l'organisation qui était très focus sur le delivery et petit à petit remonter sur une organisation produit à l'échelle, donc dans cette logique de mise en oeuvre de l'organisation et à l'échelle, c'est là où on a commencé à se poser les questions de, évidemment, les OCR, comment ça se passe, comment on pilote ça, c'est quoi la vision, voilà. C'est à partir de ce moment-là, les 3-4 dernières années, où on s'est posé les bonnes questions de Pour qu'on ait un bon delivery, in fine, c'est par où ça commence, quelles sont les bonnes questions, comment on l'organise collectivement, hiérarchiquement. Et c'est là où on a fait nos plus beaux ajustements, parce que le delivery, ça fait quand même pas mal d'années qu'on bosse sur ce sujet. mais de le faire à une échelle avec une direction, la vision, quels sont les bons outils, est-ce que c'est les OKR, est-ce que c'est d'autres choses, voilà. C'est un peu la fin de mon expérience chez Mythique, et là aujourd'hui on se lance dans une nouvelle aventure avec Marion.
Terry : Et du coup, vous avez fait un lancement il n'y a pas longtemps, c'était hier ou aujourd'hui, on enregistre fin décembre 2023, donc qu'est-ce que vous avez lancé là ?
Marion : On a lancé FLUHO. FLUHO, c'est le fruit de notre association avec Nicolas. C'est aussi une association avec IETA. On est en symbiose, on crée une nouvelle bulle dans l'écosystème IETA. La mission de FLUHO aujourd'hui, c'est d'associer nos complémentarités à Nicolas et moi, au profit des organisations. On est dans le thème. Ce qui nous passionne, c'est accompagner les organisations vers plus de culture produit, vers aussi plus de pilotage par l'impact, et se dire aussi, c'est quoi une orga-produit ? On va dérouler tout ça ensemble, mais on a beaucoup de choses à dire. Mais voilà, c'est de se dire, on prône le sur mesure. Chaque organisation est différente. Chaque organisation a sa culture, a sa maturité, a ses besoins, a son type de produit. Et aujourd'hui, nous, on est assez persuadés que la réussite de ces orgas et de toutes les personnes qui les composent, elle vient par le surmesure et le construire comme un produit, c'est un bon axe, parce que ça allait écouter finalement ce qui se passe, prendre le pouls du système et comprendre là où ça va pêcher. Et voilà, je ne sais pas si tu veux rajouter Nicolas là-dessus, mais... Ça.
Nicolas : C'Est un peu notre proposition de valeur qu'on fait, entre guillemets, à nos futurs clients, etc. Je pense qu'on a assez d'expérience pour aujourd'hui être capable d'accompagner tout type d'organisation quelle que soit sa taille. Surtout en appliquant ce qu'on a appris sur ce que je décrivais tout à l'heure par exemple à Mythique. Mais c'est pas qu'une question de délivrerie. Et ça commence avant tout par certaines étapes fondamentales. L'OKR est un peu ouvert. cette réflexion, particulièrement en France, mais il y a plein de choses à faire avant, on parle des visions, etc. Donc ça, c'est vraiment la promesse, entre guillemets, de notre produit FLUHO. Mais ce qu'on cherche aussi à faire, c'est avoir une autre manière de faire du conseil, mais de l'intérieur. C'est-à-dire que nous, On n'est pas des gestionnaires à la base, on est des « sachants », on est des experts de ce métier-là. Et on a envie d'organiser une structure de conseils qui fonctionne différemment, très collective. On a envie de s'entourer de personnes qui ont beaucoup d'expérience, qui pourront nous nourrir et nourrir ce qu'on appelle notre framework, puisqu'on aimerait aussi poser les bases assez structurées. On parle d'un framework parce que c'est un peu le mot-clé pour parler d'une méthode, d'une façon de faire et surtout d'une démarche. Et on a envie de construire ça collectivement, parce que même si on est à nous deux, on couvre un scope assez large du product management à l'échelle. Ça reste quelque chose d'assez compliqué, on veut pouvoir bien le faire, on veut pouvoir le faire de manière très structurée, et on parle souvent de safe puisque c'est quand même le ténor du sujet et c'est normal d'en parler. On a envie d'avoir une approche qui ne tombe pas dans ces travers, qui est très entre guillemets top down, très il faut faire comme ça, et donc ça déroule une espèce de, un peu de cahier des charges, d'une cible qu'il faudrait atteindre, un peu comme un rail, et on a envie de sortir de ça, et on a envie de, et ça nous permet de, voilà, d'amorcer un peu notre discussion autour de comment on manège une orgue à produits, ça n'est surtout pas, et Marion l'a très bien dit tout à l'heure, dédicter comment les gens devraient travailler, puisque fondamentalement, une des clés, moi je l'ai vécu à Métik, c'est la maturité de l'organisation. Donc on peut à la limite structurer, et par exemple le Scrum le fait très bien, pourquoi on fait les choses, quelles sont les bonnes étapes et quelles questions on doit se poser, les objectifs qu'on doit atteindre, mais par contre les méthodes, les pratiques, L'organisation, ça dépend de plein de choses. Ça dépend des paramètres de maturité, de mindset, de compréhension. Le problème, quand on est dans une logique où on applique bêtement une structure, c'est que les gens n'en comprennent pas les enjeux et souvent, malheureusement, c'est pas adapté. C'est-à-dire qu'appliquer du save dans une structure de peut-être 50 personnes n'a pas de sens, parce que c'est un framework qui est extrêmement... qui comprend énormément de choses, donc on a l'impression de sortir une espèce d'armada qui, sur le papier, est très sexy, évidemment, mais qui... — Ils.
Marion : Ont repris quand même toutes les pratiques ? Forcément ?
Nicolas : — Après, ils cumulent plein de choses, et le but, c'est pas forcément de parler exclusivement de SEF, mais c'est d'essayer de comprendre pourquoi SEF, ça peut très bien marcher dans certaines structures. Et pourquoi dans d'autres ça marche pas ? Bah en fait c'est qu'on essaye d'appliquer exactement la même chose à des enjeux qui sont pas du tout les mêmes, des tailles qui sont pas les mêmes, une maturité qui sont pas les mêmes. Et ça c'est un des fondements d'une logique un peu produit quand on pense l'organisation comme un produit, c'est de se dire OK, on a à peu près une vision de là où on veut emmener notre organisation, c'est-à-dire on veut l'utilisateur au centre, on veut se poser des questions, faire des feedbacks. OK, c'est ce que devrait faire une organisation produit, mais comment on l'amène ? En fait, ça va dépendre de plein de choses, de plein de paramètres, et les étapes sont nécessaires.
Terry : Yes, très clair. Merci déjà, ça pose bien le décor. Ça me fait penser à une première question en termes de... On comprend bien le cadre dans lequel vous pouvez intervenir. Ma première question qui me vient en tête, c'est ce type de réflexion, on peut se les poser qu'à partir d'une certaine taille. Si je viens, je me dis, petite start-up de 10 personnes qui pourraient venir vous voir et vous dire, oui, c'est génial ce que vous faites, mais en soi, aujourd'hui, je ne vais pas me poser ces réflexions-là. Vous répondrez quoi à ce type de challenge et comment aborder les différentes problématiques d'organisation d'équipe en interne en fonction des tailles de structure ?
Marion : C'est une super question. Moi, je pense qu'on peut accompagner tout le monde. Pourquoi on a monté FLUHO ? Je le disais en intro, moi, j'ai fait de la start-up, j'ai fait du média, j'ai travaillé chez RTL, chez France Télévisions, j'ai travaillé chez My Little Paris. Et c'est un bon exemple, par exemple, quand je suis arrivée chez My Little Paris, donc c'était il y a quand même quelques années. C'était une création de poste, j'étais head of operation, je gérais... On est venu me chercher pour restructurer le e-commerce. Bon, donc les box, My Little Paris, tout le monde connaît. Qu'est-ce que j'ai observé en arrivant ? Des équipes qui ne se parlent pas, des équipes qui n'étaient pas alignées. Donc j'avais l'équipe tech, j'avais une PO, j'avais un designer, j'avais le service client, j'avais aussi le CRM, le PRM. Bref, tout ce qui fait que tu vas finalement vendre ton produit, suivre tes ventes, faire de l'acquisition, de la rétention, etc. J'avais tout dans mon scope.
Terry : Et en termes de taille, juste pour visualiser.
Marion : 15 personnes. Donc tu vois, finalement, on n'est pas sur des échelles de 200. Et rapidement, en fait, je me suis dit OK, il y a un dysfonctionnement. Les gens ne se comprennent pas. Pourtant, on bosse tous ensemble. On veut tous vendre et avoir la plus belle expérience qu'on puisse. Il y avait un côté aussi dans la promesse, dans l'approche en plus purement produite de d'avoir une belle expérience utilisateur, de faire plaisir aux abonnés, etc. Donc ça, c'était vraiment très, très fort chez My Little Paris. Ça l'a toujours été. Mais c'est de se dire, comment est-ce que moi, j'allais organiser tout ce petit monde ? Et il m'a pas fallu beaucoup de temps. Ça a été une des premières victoires. Ça a été de se dire qu'en un mois et demi, deux mois, en fait, j'ai commencé simplement en se disant, déjà, je vais mettre tout le monde dans le même bureau, sur le même plateau. Enfin, chez My Little Paris, c'était des petits appartements, mais on s'est tous mis au même endroit. Hop, il n'y a pas la tech d'un côté, les autres services de l'autre côté. Non. Et là, on va se parler. Et puis, je vais commencer à introduire de l'agile, en fait. Donc on nous éduque en banc. Voilà, c'est des choses assez simples. J'ai structuré tout ça. Je les ai formés à l'agile aussi parce qu'ils n'étaient pas formés. Et je les ai fait se parler. Et les premières victoires, ça a été de se dire... on va faire des rétros déjà, on va se parler tous ensemble, donc je prenais vraiment service client, tout le monde, on va se mettre autour de la table et ok, responsable logistique aussi j'avais... la logistique elle pète, pourquoi ? On va se parler et on va construire le produit ensemble et on va se donner du sens, de l'alignement, donc finalement tu vois, donc ça c'est un petit exemple. Et après on a découlé, on a lancé plein de chantiers évidemment, je pourrais en parler pendant des heures parce qu'on a fait beaucoup de choses en deux ans. On a fait des refactos, on a fait pareil, remettre à plat la data, etc. Mais c'était donner cette dynamique à mon équipe en fait de se dire on travaille tous ensemble, les victoires on les fait ensemble. les merdes qui peuvent arriver, on les gère ensemble aussi, moi j'étais là pour eux, on les gérait ensemble, on trouvait les solutions hyper rapidement, voilà.
Terry : Hyper intéressant comme retournée par exemple, donc ça montre, enfin ce que je retiens de ce que tu dis, c'est aussi avoir pris en fait des bouts de choses qu'on va retrouver dans des frameworks beaucoup plus larges, agiles, et prendre des choses qui étaient pertinentes pour la taille d'équipe dans laquelle tu t'intégrais. Ma question là-dessus c'est, ouais et Nicolas après je te laisse rebondir avant ou après la question comme tu veux, c'est toi qu'est ce que tu as vu qui a marché assez rapidement lors de la mise en place par exemple la mise en place des premiers rétros et autres versus des choses qui étaient peut-être un peu plus complexes à faire adopter et sur lesquelles il a fallu peut-être plus de temps mais sur lesquelles tu as appris aussi pour les expériences futures voilà.
Marion : Ce qui a marché, il y a eu effectivement faire comprendre le mindset et le faire adopter par l'équipe pour que ça soit agile produit. Ça a été reposé une vision produit aussi de se dire, ok qu'est-ce qu'on fait avec ce produit ? C'est quoi le produit Mytalbox ? Qu'est-ce qu'on veut apporter à nos utilisateurs ? Bah, vision produit, on l'a posé. Et ensuite, je suis arrivée, il y avait 1000 chantiers. Enfin 1000 chantiers, j'exagère un petit peu. Il y en avait beaucoup. C'est de se dire par quoi on commence, les gars ? C'est quoi notre stratégie ? C'est quoi la stratégie sur l'année qui vient ? Et ensuite, c'est quoi la tactique ? Et qu'est-ce qu'on se met par quarter ? Et après, ça, c'était mon rôle aussi de le faire remonter à la direction et de le faire adopter à la direction, ce qui s'est très bien passé puisqu'on a été en autonomie pendant deux ans, on a amené tous les chantiers qu'on voulait. Et on a avancé petit pas par petit pas, on a paralysé des choses, on avait des gros problèmes techniques, on les a paralysés, on a remonté une plateforme, on a continué à servir nos abonnés, on a continué à faire des campagnes marketing. La vie s'est pas arrêtée, mais on était tous soudés sur on sait où on va, on sait où le cap est. Et finalement qu'on soit 15 ou qu'on soit 200, pour moi si ce cap il est pas là, il y a quelque chose qui va dysfonctionner et qui va dysfonctionner très fort en redescendant sur les équipes.
Nicolas : Oui, Nicolas, du coup... Oui, je voulais compléter sur... Tu nous posais la question sur petites et grandes équipes, grandes organisations, etc. En fait, j'ai essayé de le décrire tout à l'heure, il y a deux aspects importants, il y a le pourquoi et le comment. Le comment, fondamentalement, va différer en fonction de la taille des organisations. Ça peut être une petite équipe qui a son propre produit, et comme ça peut être un produit qui est géré par plein d'équipes et elles doivent collaborer, feature team, peu importe. Mais en fait, ce qui doit primer avant tout dans les bonnes questions et le pourquoi qu'il faut avoir au centre des attentions, c'est en fait, quel que soit le produit, sa taille et le nombre d'équipes, on doit toujours avoir sa vision, ses objectifs, qu'est-ce qu'on va aller chercher et mesurer auprès des utilisateurs, quelles sont leurs problématiques, Et qu'est-ce qu'on leur délivre ? En fait, toutes ces questions-là, elles sont fondamentales, quelle que soit la taille des équipes, quelle que soit la taille du projet. Et c'est surtout, tout produit doit, devrait. C'est un peu dogmatique de dire ça, mais c'est légitime de se dire à un moment, à quoi sert notre produit ? Où est-ce qu'on veut l'emmener ? Qui sont nos utilisateurs ? Et qu'est-ce qu'on leur apporte comme solution par rapport à leurs besoins ? ça, pour nous, c'est un peu la clé de ce qu'on essaye d'inscrire dans le framework. C'est vraiment ça, ça fait partie des bonnes questions nécessaires à se poser. Par contre, sa mise en œuvre, ça peut être du Scrum avec du Discovery et une vision élaborée avec une partie de la hiérarchie parce qu'il y a une petite équipe derrière qui est maître de son produit et autonome. Mais si on est sur une organisation beaucoup plus à l'échelle, avec plus d'équipes, plus de squads, etc., des feature teams, il faut juste décomposer cette démarche avec des niveaux hiérarchiques. On imagine que le CEO va se poser la question de quelle serait la vision, quelle est la promesse du produit. Et après, son équipe va définir quels sont les grands objectifs. Ça dépend des modèles hiérarchiques, mais en tout cas, les questions sont toujours légitimement posées et il faut juste l'organiser en fonction de l'organisation de produit et des gens qui la composent.
Marion : Oui, il y a des choses qui... C'est assez complexe, en fait. Là, on parle de, forcément, vision strata, etc., parce que tout est lié, mais c'est aussi de l'orgasme, et aligner les personnes, comprendre vers quoi on va et quels moyens on va mettre à disposition, finalement, et quels changements de paradigme on peut effectuer, parce qu'on fait du changing, quand même. Je parlais de My Little Paris, j'étais interne à l'époque, depuis je suis passée coach, j'ai d'autres expériences, de se dire qu'est-ce qu'on va manipuler pour permettre finalement d'avoir une prise de conscience, de se dire peut-être qu'il faut qu'on change des choses et c'est des petits pas, c'est pas des Big Bang, évidemment parce que les Big Bang ça marche pas. On parlait de save tout à l'heure, donc il n'y a pas de recette miracle, les frères morts qui perdent, fermé, verrouillé, étape 1, étape 2, étape 3, ça non plus pour moi ça ne fonctionne pas. Et après il y a plein de choses qui sont pour moi du bon sens mais qu'il faut faire adopter. Là-dessus tu vois j'ai fait des accompagnements, j'ai passé plus de 14 mois dans une BU chez Decathlon. Le prisme de départ, ils sont venus me voir en me disant Marion, on a essayé de mettre en place des OKR, on galère un peu, comme tout le monde globalement, c'est normal, c'est le premier truc que je leur ai dit aussi aux équipes, donc une BU c'est à peu près 150 personnes. J'en dis, c'est normal, les OCAIR, ça prend du temps. C'est pas la première année où on se dit, ouh, c'est super, on a tout atteint, on sait mesurer notre impact, tout est nickel-chrome, les dépendances, le truc, le bisou. Non. Il faut deux, trois ans, facile, pour, tu vois, itérer aussi sur, s'approprier, se dire, OK, comment est-ce qu'on va fonctionner ? Et donc, ça passe par, je suis arrivée là-bas, par former les équipes. et leur dire, en fait, ouais, les OKR, parce que ça peut traumatiser. Moi, j'ai vu des équipes qui disaient, oh là là, non, mais les OKR, c'est bien dur. C'est un exemple, évidemment. Il y a plein d'autres choses qu'on peut utiliser. Mais juste, en fait, c'est quoi ? À quoi ça sert ? À quoi ça va nous servir ? Comment est-ce qu'on va l'appliquer dans notre contexte ? Et finalement, pas forcément by the book. Moi j'adapte à chaque fois à mes clients, donc on a fait du framework simplifié Ambition Impact et c'était déjà vachement bien. Il y avait une bonne quinzaine d'équipes produits, de se dire comment on va danser tous ensemble, comment est-ce qu'en fait on va se dire aussi on est dans une grosse BU, on est hyper nombreux. de savoir, moi PM, ce que va faire mon autre copain à côté PM, qu'il y a d'autres finalement qui est aussi dans un scope plus ou moins proche, mais comment est-ce qu'on va bosser ensemble, comment est-ce qu'on va trouver aussi des solutions ensemble, s'aider, parce que tout est lié forcément, on est dans une organisation qui fait un produit. Normalement, les choses sont connectées. Et en fait, c'est faire des petits pas et puis faire des rétros. Enfin, je parle beaucoup de rétro, mais c'est aussi valable dans ces contextes-là de se dire on teste, on est en place sur trois mois. Comment est-ce qu'on va mesurer que finalement, l'organisation adopte des changements et se sent bien. Et pour moi, ce qui est important aussi, c'est que les gens soient heureux de faire du produit.
Terry : — Là-dessus, clairement, ce que je retiens bien, c'est la logique d'itération, évidemment, et de mesure de feedback par rapport à ces itérations pour savoir si on est dans la bonne direction ou s'il faut changer. Je voudrais revenir sur la logique de gros changement d'un coup. Et je vais challenger ça pour une raison particulière, c'est de se dire que Avec vos retours d'expérience jusqu'à présent, on comprend que si on amène bien les équipes opérationnelles sur ces nouvelles méthodos et qu'on s'adapte à elles, on va réussir à trouver des manières de faire qui vont fonctionner. Et même si au départ, il y a toujours un peu de réticence, surtout quand on arrive de l'extérieur, ils peuvent se dire, bon, c'est qui qui vient nous expliquer comment faire ? On sait très bien, etc. Mais une fois que, on va dire, cette vitre est brisée, ça avance très bien en général. Et parfois, ce qui peut arriver comme blocage va être plutôt au niveau de top management parce que, in fine, même si l'opérationnel fonctionne plutôt bien, si derrière, il n'y a pas un gros alignement vers la nouvelle façon de fonctionner côté top management, ça peut bloquer. Du coup, pour revenir sur la partie gros changement d'un coup, parfois, ces gros changements que les organisations veulent pousser à l'échelle du jour au lendemain, c'est aussi parce que niveau top management, il y a eu ce shift complet de mindset et qu'ils veulent ensuite aller trop vite dans la mise en œuvre. Mais malgré tout, ce shift là de mindset va être nécessaire, pas de manière organique, mais plutôt de manière forte au niveau top management, afin d'avoir derrière, côté opérationnel, le buy-in des leaders et de pouvoir avoir cette latitude de penser outcome plutôt que output, etc, etc. Du coup, comment vous pourriez répondre à ça par rapport, enfin, pas répondre, mais discuter sur ce sujet du buy-in du top management et du coup, des fois, sur des organisations qui veulent faire cette bascule, plutôt là, pour des leaders, en fait, des organisations, quels seraient un peu les les clés de lecture aussi pour eux, pour mieux comprendre aussi peut-être ce qui se passe quand on leur dit on va plus parler d'output mais d'outcome.
Marion : C'est une question qui est hyper complexe à adresser parce qu'en fait, donc je vous disais tout à l'heure pas de big bang, pour autant effectivement si on n'embarque pas le C-level, le top management, ça va faire flop à un moment donné. on peut intervenir localement, on va dire, mais s'il n'y a pas l'adhésion plus haut, que ce n'est pas porté, que ce n'est pas encouragé, finalement, ça peut vite retomber. Et c'est là où notre travail, c'est aussi d'aller voir ces personnes-là, des acculturées, de leur faire comprendre aussi que le changement passe aussi par leur changement d'état d'esprit potentiellement, et l'adhésion aussi à la démarche, parce qu'en fait on vient aider des équipes, on vient apporter des nouvelles choses, des nouvelles pratiques, des nouveaux principes, etc. Mais il faut aussi que là-haut ça adhère en fait, et que ça porte tout ça.
Nicolas : — Bien sûr. Après, je compléterai sur... Ce qu'on essaie de faire nous dans notre vision des conduites de changement, c'est évidemment, souvent, il y a une envie de se dire, je donnais des exemples un peu débiles, mais on veut que ça délivre plus, on veut que ça avance plus vite, pourquoi on met autant de temps pour délivrer telle feature, etc. Donc ça c'est souvent un point de départ un peu classique, parce que les enjeux business sont qu'on a envie d'aller très vite, plus vite, etc, que le TTM soit de plus en plus rapide. Mais quand on commence à opérer une vraie évolution d'organisation, pour ne pas dire de transformation, puisque c'est quelque chose qui se fait petit à petit, et tu parlais d'itération tout à l'heure, en fait ce que nous on essaie de faire c'est plutôt d'avoir une vision de la transformation un peu comme des lasagnes en fait. Donc au lieu d'être dans un Big Bang à un entre-endroits, on est plutôt sur une un travail systémique, c'est-à-dire que si on se dit que les enjeux, par exemple sur délivrerie, c'est d'être plus impactant, parce que le sujet ce n'est pas forcément de plus délivrer, mais d'avoir plus d'impact, il est nécessaire d'avoir un pilotage qui est plus mature aussi. Et donc l'évolution de la transformation, l'évolution de la maturité organisationnelle au sens très large du terme, doit aussi s'opérer sur une direction, sur celle qui pilote le delivery, celle qui « nourrit » le delivery, pour qu'elle soit en capacité de donner les bons éléments, voir la bonne autonomie aux équipes, pour qu'elle soit en capacité de raisonner. de répondre aux enjeux qu'on leur donne, par exemple, qui est celui, on aimerait avoir tel niveau d'impact sur tel timing. Donc ça, on peut parler de carburant, donc ça fait partie du cadre qu'on donne quand on veut que les équipes soient matures et autonomes, et donc on travaille sur ces leviers-là aussi. Parce que si on veut pouvoir, et c'est une des clés d'une bonne organisation, avoir des équipes performantes, elles doivent être autonomes, et il faut poser ce cadre d'autonomie, et seule la direction peut le faire. Et donc on est obligé mécaniquement, d'accompagner une direction pour prendre conscience de ça, de l'équiper des bons éléments, ça peut être des outils de type se poser les bonnes questions pour apporter les bonnes réponses, on peut parler d'artefacts, on peut parler de rituels à l'échelle, comment ils se retrouvent entre directeurs pour parler pas de features mais plutôt de d'outcome, de quels résultats, de ce qu'on voudrait mesurer comme résultat, et combien on paierait pour ça, puisque les équipes correspondent à un carburant, c'est-à-dire que des équipes elles ont des quarters, elles ont 6 semaines, elles ont une année pour atteindre des objectifs, donc combien une organisation à l'échelle dépense sur ses équipes pour atteindre tel objectif. Voilà, donc une transformation aujourd'hui, elle ne peut plus être à l'échelle d'une partie de l'organisation, mais elle se veut beaucoup plus systémique, parce que le pilotage est la clé majeure d'une bonne évolution.
Terry : Très clair, et du coup, je serais curieux de savoir sur vos expériences jusqu'à présent, ce que vous avez pu voir qui fonctionnait pour justement amener le C-Level sur ces sujets-là, et je vais prendre un cas plus ou moins concret La problématique qu'on peut avoir parfois avec la partie commerciale, c'est-à-dire que la partie produit qui va construire les choses, réussir à avoir le buy-in du CPO, ça va pas être un gros problème. En revanche, le directeur commercial qui peut-être va avoir une habitude de fonctionner aux incentives, puisque c'est comme ça aussi que les commerciaux sont rémunérés, va vouloir dire oui mais là du coup tu es en train de me demander la valeur que je vais pouvoir livrer, enfin qu'on va pouvoir réussir à générer grâce à ta nouvelle fonctionnalité et va peut-être se dire je risque de me faire loquer parce que si je donne un chiffre de valeur sur cet outcome, demain on va me mettre des objectifs alignés à ça et si je les attends pas je vais pas avoir ma prime de fin d'année sur ce que j'ai réussi à vendre. et donc une complexité à embarquer aussi les commerciaux dans cette logique outcome et produit. Là-dessus, un peu avec vos différents retours d'expérience, je suis curieux de savoir comment les choses que vous avez vu fonctionner, les choses peut-être plus complexes.
Marion : Là-dessus, quand je coach des PAM ou des head of, etc., c'est souvent leur dire, allez partager votre quotidien, allez communiquer. Donc on a beaucoup parlé d'alignement, de communication face à la base des OKR, par exemple, et c'est de se dire, en fait, OK, j'ai posé une vision, j'ai une stratégie, j'ai une tactique, comment je la partage plus largement ? en sein de l'organisation et comment je vais aller m'accorder finalement aussi avec toutes ces parties prenantes en fait parce que mine de rien on vend quelque chose quand on fait du produit donc de se dire comment je vais aller collaborer avec tous les services qui gravitent autour. pour se dire en fait la clé elle est là parce que ma data elle me donne ça et que je pense que l'impact il est là donc commercialement on peut aller chercher quelque chose de nouveau donc là après on part en discovery etc mais c'est cette communication qui est hyper importante et finalement c'est casser tous ces silos aussi petit alors évidemment ça se fait avec le temps c'est petit à petit pas par petit pas Mais c'est de se dire inviter. Alors il y a plein de choses qu'on peut actionner. Inviter aux démos. Moi j'ai vu des orgas où les démos sont faits juste entre Product People. Bah non, inviter les sales, inviter le market, inviter la com, inviter la brand, inviter tout le monde. Parce qu'en fait il faut montrer là où on en est. Il faut expliquer aussi, acculturer Product Management. c'est pas nouveau, mais ça a besoin aussi d'avoir un ancrage fort et de se dire, c'est pas si simple ce qu'on fait, on fait un métier compliqué, et de le partager et d'avoir un peu, c'est de se dire, on avance tous dans la même direction. C'est un peu ce côté-là. Des fois, je me dis, mais en fait, quand je dézoome un peu sur des accompagnements que je peux faire, de me dire, mais pourquoi ça se tire un peu ? Ça se tire dessus, entre guillemets. Ça frotte entre, je sais pas, les sales, le produit, chacun veut son truc. Bah non en fait, faut parler d'une seule voix, parce que c'est comme ça qu'on génère vraiment de l'impact.
Terry : Très très clair, je sais pas si Nicolas tu veux compléter là.
Nicolas : Alors moi sur ce sujet mes expériences sont plutôt larges, disons que Juste pour en prendre un peu de théorie, on a quand même, depuis pas mal d'années, remarqué que quand on mettait dans une même pièce la tech et le produit, c'était vachement mieux, c'était plus efficient. C'est la même chose à l'échelle. Moi je l'ai expérimenté à Mythic sur des projets un peu spin-off, c'est-à-dire des petits produits qui se lançaient à côté de grandes marques comme Mythic. On pourrait parler d'Event ou d'autres. où au début on sentait qu'il y avait la partie marketing qui n'était pas forcément toujours, pour de très bonnes raisons, hyper alignée avec le produit parce que les enjeux peuvent être différents, l'approche peut être différente. Et en fait, la clé à un moment, c'est de se retrouver tous dans la même pièce et de définir des objectifs communs. Et ces objectifs communs, en fait, ce n'est pas est-ce que c'est moi qui ai raison ou est-ce que c'est moi qui ai raison ? Peu importe les parties. L'idée, c'est plutôt de s'aligner sur c'est quoi les critères de réussite de notre produit ? Qu'est-ce qu'on va aller chercher ? Et un produit, par exemple, puisque je parlais de marque et de construction de marque, l'un ne peut pas aller sans l'autre, c'est-à-dire que la construction in fine du produit organisé par les équipes produits ne peut pas marcher sans sa propre marque et la construction de sa marque. Donc l'idée c'est plutôt comment on travaille de concert et donc quels sont les bons objectifs à définir. Et quand on parlait de vision, objectifs, etc., en fait la construction de ce travail en amont du délivré, de la fabrication du produit, elle est forcément construite conjointement. Comme la fin est construite avec tech et produits, le travail en amont sur la vision est construit avec la market, mais aussi peut être construit avec les sales. Ça dépend des structures organisationnelles. Le mythique n'a pas des sales au sens strict avec des commerciaux, ça n'existe pas. Mais le marketing, la construction d'une marque, c'est quelque chose d'extrêmement fondamental. Et donc on ne peut pas imaginer construire un produit, un nouveau produit, tout l'aspect marketing, sans qu'il y ait une vraie synergie entre ces deux mondes. Parce que l'histoire qu'on raconte mythique à ses utilisateurs ne peut pas être en incohérence avec le produit in fine et l'un doit nourrir l'autre. Donc en fait, c'est qu'il y a des moments en amont qui permettent de définir les objectifs communs et de comprendre les autres.
Terry : Très très clair du coup je voudrais rebondir sur un sujet dont on a pas mal parlé en trame de fond la partie stratégie et la partie delivery alors pourquoi pourquoi là dessus parce qu'en fait la stratégie elle est valide à un instant t et après on l'ajuste on pivote qu'on soit startup ou pas Et derrière, du coup, pivoter la stratégie, ça veut évidemment dire aussi faire pivoter ce qu'il faut livrer. Et ça, ça peut être complexe à entendre quand t'es opérationnel et que t'as commencé à structurer, en fait, ton plan de livraison sur plusieurs semaines, qu'on te dise du jour au lendemain, en fait, non, là, il faut qu'on parte complètement de l'autre côté. Et en fait, il n'y a pas le choix parce qu'on s'est aligné, on s'est tous mis d'accord que c'était vers là où il fallait aller. Et donc, comment réussir à faire accepter ça aussi ? C'est-à-dire que la version entre guillemets simple de ça, c'est de se dire on définit une stratégie et puis sur un an, on part là et on arrive à aligner les gens, répéter les choses pour être sûr qu'on... qu'on soit tous bien alignés. Mais globalement, si on s'est donné un an et que sur un an, on ne change pas de cap, ça va. Mais la réalité des choses, c'est que souvent, le cap, il se fait ajuster en cours de route et que c'est là où il peut y avoir de grosses frictions parce que certaines personnes ont besoin du temps long pour aussi concevoir les choses, notamment sur les produits assez techniques. Comment est-ce que vous pourriez répondre à ça et aider potentiellement des boîtes dans ces situations sur l'accompagnement de l'ajustement nécessaire au fil de la mer qui évolue ?
Marion : J'aime bien cette petite métaphore. Moi, je vais reprendre le prisme des OKR, parce que c'est un bon outil pour gérer ça. Quand j'accompagne les équipes, je leur dis qu'on va poser des ambitions stratégiques. Je ne parle pas d'objectifs. Je trouve qu'il y a une mauvaise traduction, par exemple, d'OKR en français. La partie objectifs, je trouve qu'il y a un biais quand on se dit qu'on va poser des objectifs stratégiques, c'est-à-dire qu'il faut tous les tacler dans l'année. Là où je préfère parler d'ambition, tu vois, c'est justement se donner un peu ce côté... On se donne un cap, mais ce cap, il va évoluer. Donc on va poser des ambitions stratégiques, et ensuite, les équipes vont travailler des tactiques, donc vont travailler des outcomes au quarter. Et pourquoi au quarter ? Parce que au quarter, ça pourrait être un temps plus petit. Je ne conseille pas de le faire sur six mois, mais le quarter, pour moi, c'est le maximum, pour justement se dire, ok, on va se donner, moi, équipe produit A dans mon écosystème, je vais me fixer deux outcomes que je veux tacler, en tout cas que j'aimerais atteindre, et je vais apprendre, en fait, C'est un moyen, finalement, de se dire j'aimerais aller vers ça, je pars de là. Et la mesure, elle est hyper importante parce que c'est de se dire, déjà, est-ce que je suis en capacité de me mesurer, de savoir de là où je pars vers là où je vais ? Souvent, les équipes ne savent pas se mesurer. C'est là où ça picote un petit peu au début, c'est de se dire, en fait, t'en es où ? Tu veux atteindre tel impact, mais c'est quoi ta data zéro ? Tu pars d'où, là ? Et en fait, ça, c'est déjà compliqué. Souvent, c'est beaucoup de travail de data, donc on commence par ça. Et ensuite, c'est de se dire, mais qu'est-ce qu'on va apprendre ? On contacte avec nos utilisateurs, on contacte avec toutes les personnes aussi en interne qui vont amener du feedback, ceux du service client, etc. Et finalement, c'est là où, oui, tu disais, on va pivoter, mais en fait, c'est l'essence même pour moi du produit et de l'agilité, c'est qu'on apprend, et donc on y terre, on prend du feedback, et donc forcément, on va pivoter un petit peu en permanence. Et c'est là où on arrive à avoir des produits qui ont de l'impact. Il y a des choses que j'ai observées où j'ai l'impression qu'on fait des retours en arrière un petit peu selon les organisations, selon aussi le marché étendu, de se dire on veut des plans, on veut des dates, on veut des roadmaps avec des dates. Je veux dire, stop les roadmaps avec les dates. Ça, c'est un peu ma bataille. Je prône, tu vois, les roadmaps basés sur les outcomes pour justement se dire, en fait, on sait ça, on répond une strat. À la fin du quart d'heure, on aimerait bien faire bouger ça, en fait, comme indicateur. C'est ça, nos outcomes. Et puis on fait le bilan. Et en fait, souvent, on nous dit... J'ai eu des PM ou des groupes PM ou des head of qui me disaient... Ouais, mais là, tu vois, Marion, on avait fixé ça en début de quarter et ça marche pas. Est-ce que c'est grave ? On a appris, en fait. Donc, on arrête de s'entêter. Et ce qu'on a appris qui marchait pas, on va prendre un autre chemin pour tester autre chose et peut-être découvrir une autre opportunité business de dingue ou une opportunité utilisateur. Et c'est comme ça qu'on avance. En fait, pour moi, c'est un système qui est... qui doit être complètement apprenant en permanence. On ne se donne pas d'idée fixe, on ne se dit pas il faut aller là. Parce qu'on a décidé que le plan était comme ça, un plan ça se démonte en permanence.
Nicolas : Tout à l'heure, on parlait de différentes couches, vision, objectif, etc. Ce qu'on essaie de nous décrire. Et là, je l'ai vécu, cette frustration de se dire, c'est un projet, ça fait 3, 4 mois qu'on est dessus, voire plus, on l'arrête presque du jour au lendemain, on ne sait pas trop si c'est terminé. Et en fait, il y a quand même un truc qui est très important, auquel on croit beaucoup et que moi j'ai vécu amitié, c'est qu'il y a un moment dans les organisations qui ne sont pas toujours très matures, c'est qu'il y a un fort décrochage entre le delivery et la strata. Souvent, la strata, elle est montrée, démontrée par le biais de slides, mais dans le quotidien, ça devient très abstrait. Ça ne correspond pas à son quotidien, on se demande sur quoi on travaille. Et déjà, pour moi, il y a quelque chose de fondamental, c'est de raccrocher opérationnellement ce qu'on fait à la strata. C'est-à-dire, ce truc-là, ça sert à ça et donc à tel objectif qui permet d'atteindre telle vision. Et donc si à un moment on se dit on arrête quelque chose, on perd pas le sens. On perd pas le sens parce qu'on est quand même à raccrocher une vision. Si la vision n'existe pas, si les objectifs de cette vision n'existent pas et qu'on est dans une logique un peu feature factory, évidemment quand on coupe, on est perdu. Mais si on coupe quelque chose mais qu'on sait encore vers où on va, quelle est la bonne direction, c'est déjà moins problématique, parce qu'on sait fondamentalement pourquoi on le coupe, puisqu'on l'explique, et ça ne tue pas la vision de départ, la promesse de notre produit, et on est capable de justifier pourquoi on l'arrête, parce qu'il y a des enjeux, concurrence, peu importe, mais on continue à avancer vers notre vision. C'est ça qui est très important, c'est si jamais on n'a pas couplé les deux, C'est-à-dire, le produit final, comment on le construit, et notre stratégie, et comment ce lien se fait au quotidien, c'est là où on a des mécanismes de frustration quand on arrête des projets.
Terry : Hyper intéressant, et ça complète ce que disait Marion, dans le sens où il faut avoir la data pour pouvoir être capable de derrière, d'arbitrer de manière assez pertinente, et ça permet même d'avoir la logique d'Home Power Month, où tu vas voir même tes équipes elles-mêmes, qui pourront dire, ben là en fait il faut qu'on arrête, parce que de toute façon on n'est pas alignés. Là-dessus, je trouve très bien exprimé et très complémentaire dans cette explication. Je vais challenger par contre la partie data, c'est-à-dire que oui, il faut de la data. En revanche, on est sur des produits complexes dans lesquels ce qui peut impacter la réussite, le succès d'un produit, il va y avoir beaucoup de facteurs, c'est multifactoriel, ça peut être potentiellement même systémique au niveau de l'organisation et donc se dire qu'est ce qui a vraiment fait que cette feature marche ou marche pas ou savoir en fait sur donc déjà avoir la capacité de dire tel curseur a tel impact et l'autre problématique c'est de se dire là ça marche pas du tout mais qu'est ce qui fait que je vais quand même pousser parce qu'en fait il va y avoir un renversement de la situation au prochain quarter Et ça, aujourd'hui, on sait que c'est une problématique présente d'avoir cette donnée pertinente et aussi cette capacité de pousser les choses plus loin, même si on est très loin de l'objectif initialement pensé. Et du coup, par rapport à ça, quel retour vous avez sur ces sujets-là ? Parce qu'après, on pourrait tomber dans la logique où on se dit « Ok, l'indicateur est vraiment éloigné de ce qu'on voulait, En revanche, le sea level a dit on y va et du coup derrière au niveau opérationnel on pourrait penser ouais mais en fait le sea level il travaille aux doigts mouillés, il pense que le vent part là-bas du coup on y va. Comment un peu, parce que derrière il y a la problématique d'alignement comme tu le disais Nicolas aussi, qui n'est plus une problématique à partir du moment où tu as des indicateurs.
Marion : Cette question elle est assez fondamentale, elle revient aussi à l'essence de dire qu'est ce qu'on mesure et pourquoi. Quand je manageais des équipes, maintenant quand je les coach, c'est la même chose. C'est de se dire, c'est quoi vos capillaïs produits ? C'est quoi vos capillaïs principaux ? Alors quand on me sort une flopée, qu'on m'en dit, ah ben on en a 25, ok, on va regarder tout ça ensemble, on va ouvrir le capot, on va surtout s'accorder sur des définitions. 25 c'est trop, je pousse le... le curseur exprès, souvent je dis, sortez-moi 3 KPIs sur un périmètre, si je suis sur des grosses équipes par exemple, enfin des gros périmètres on va dire, des gros orgas, 3 KPIs produits là sur ton périmètre et la définition, à quelle récurrence tu vas analyser ta data, qu'est-ce qui se passe, finalement est-ce que tu sors la bonne data aussi, Donc il y a toute cette question-là à aller creuser. C'est assez fondamental aussi, je refais le parallèle avec les zookers, mais si on n'a pas ça, déjà ces capillais-là, moi je dis on ne pilote pas ce qu'on ne mesure pas. Donc ça c'est un peu ma phrase. dans tous mes coachings aussi, mais c'est hyper important. Et c'est de se dire aussi, en fait, l'équipe va découvrir des choses, va avoir des idées, de faire confiance finalement à ses équipes produits pour être remettre en fait de... Mes trois KPI produits, c'est ça, parce que je pense ça, parce que je connais mon périmètre, parce que je connais mes utilisateurs, parce que j'ai testé ça, ça et ça. Et donc, je les pose, je les fais remonter. Je m'accorde avec aussi ma hiérarchie sur on va suivre ça. Et ça va permettre finalement aussi d'avancer dans quels impacts finalement tu fais, quels outcomes tu vas aller générer après. Ça c'est une base. Si t'as pas ça, forcément c'est complètement, on se base un peu sur pas grand chose en fait, du ressenti, ou c'est frustrant, il va y avoir de la frustration, parce qu'en fait on n'arrive pas à savoir où on en est. Donc ouais, c'est se reposer les bonnes questions et les questions essentielles. Et souvent, définition, c'est quoi la définition ? Par exemple, j'ai un exemple assez facile, je pose toujours la question, c'est quoi un utilisateur actif chez vous ? Ça veut dire quoi ? Là, en général, on me sort 10 définitions différentes. Donc, tu vois, cet exemple, il est assez simple, mais il est quand même assez... En fait, c'est quoi, chez vous, un utilisateur actif ? Ça veut dire quoi ? Il revient combien de fois ? C'est quoi la temporalité ? Et c'est une question assez clé, tu vois, parce que quand on sait pas y répondre, c'est qu'à partir de là, il faut avoir toute la data. J'exagère un peu mais...
Terry : Je trouve ça très très bon, je prends en note, j'aime bien cette question. Assez pertinente parce qu'entre le point de vue tech ou point de vue data, juste de voir du log, versus le point de vue market, d'avoir de la conversion, versus, enfin, il y a pas.
Marion : Mal de... Ouais, et c'est de se dire comment on le pousse, comment tout le monde, en fait, s'aligne sur la même mesure finalement, le même chiffre et la même définition. À partir de là, normalement, il y a des choses qui doivent plus ou moins bien s'emboîter pour réussir à mieux se piloter.
Terry : Donc par rapport à ce que tu dis, si je résume un peu, donc il y a rationaliser les métriques qui vont être utilisées pour ne pas en avoir trop parce qu'après on mesure plus rien non plus. Si on mesure pas, on pilote pas, mais si on mesure trop, on pilote pas non plus. Ça ne rime pas, mais voilà.
Marion : On se perd, on se noie.
Terry : Donc là-dessus, très clair, je sais pas, Nicolas, si tu veux compléter sur ce point.
Nicolas : C'est dur d'être dogmatique et de dire non mais il ne faut pas y aller si on n'est pas capable de mesurer. Je pense que tout entrepreneur à un moment a envie de soit prendre des risques et de lancer des projets auxquels il croit ou la concurrence se lance et on sent qu'on n'a pas trop le choix, il faut absolument y aller, c'est vital et on ne sait pas forcément le mesurer. Je ne vais pas dire que ce n'est pas dérangeant, je dirais que ça ne doit pas être une norme, fondamentalement. On peut se le permettre sur quelques sujets, mais à un moment on doit nécessairement être capable de mesurer si ce qu'on apporte à l'utilisateur est bénéfique, répond à un problème, résout un problème, apporte quelque chose. Donc, je pense qu'on peut se permettre d'ouvrir des portes et de tester des choses, mais très rapidement, il faut se dire, OK, maintenant qu'on a stabilisé le, entre guillemets, le nouveau système, le nouveau produit, là, il faut lever la tête et se dire, OK, comment ça bouge ? Qu'est-ce qui bouge ? Qu'est-ce qui est positif pour l'utilisateur ? Quels sont ses retours ? Et là, commencer à cartographier des mesures, c'est-à-dire où on est, vers où on veut aller. Tiens, il utilise ça plus que ça, ça a l'air chouette, ça lui plaît, on prend des retours. Mais très vite, il faut retomber sur un système mesurable, parce que sinon, c'est juste un travers de conviction très vite. Très vite, on retombe dans les mécanismes d'une feature factory, parce qu'à la base, on a dit des objectifs, mais fondamentalement, on est quand même en train de créer un produit, donc des fonctionnalités qui résoutent des problèmes utilisateurs. Mais si on ne sait pas les mesurer, est-ce qu'il y a vraiment des problèmes ? Encore une fois, on peut se permettre d'avoir des des thèses, des bêtes, comment dire... Des paréproduits. Des paré, tout simplement. OK, mais toute la construction d'un produit ne peut pas être dans cette logique-là. Sinon, il n'y a plus de vision, il n'y a plus rien, on se lance un peu dangereusement dans un risque qui est presque binaire.
Marion : Oui, clairement. Et c'est vrai que je parlais de bien fixer ses capillailles, mais ça n'empêche pas effectivement de tester des choses. Il y a plein d'outils à dispo, des AP-tests, on peut faire des smoke-tests, on peut balancer plein de trucs pour essayer de tester des hypothèses. Et c'est pas pour autant que tout de suite il faut se dire, ouh là là, ça, il faut que je remonte dans un dashboard, etc. Non. D'abord, on teste les concepts et puis on voit si ça marche. Et puis potentiellement ça va ajouter des nouvelles mesures et puis on va en laisser d'autres de côté puisqu'on va en trouver des plus pertinentes aussi. Et c'est ça qui est assez passionnant dans ce qu'on fait, c'est de se dire d'aller chercher toujours un peu plus loin le truc qui va faire que vraiment on arrive à savoir ce qui se passe. Et après parfois on n'y arrive pas, c'est compliqué, on balance surtout sur du B2C, t'es en plein Messi middle, tu sais pas ce qu'il se passe en termes d'adoption, tu parlais tout à l'heure de temporalité, ce qui marche aujourd'hui va pas forcément marcher demain, mais on teste un truc aujourd'hui sur une mauvaise saisonnalité, peut-être que ça marchera dans six mois. Il y a tout ça à garder aussi et du coup ça fait appel à d'autres principes, moi je donne aussi de se dire loguer un peu ce que vous avez testé. C'est-à-dire, faites-vous des petits recs de... Ça, on l'a testé, ça n'a pas marché. Pourquoi ça n'a pas marché ? Parce qu'on a eu tel résultat, machin. Mais peut-être qu'en fait, tu vois, c'est un peu le... C'était John Cutler qui poussait beaucoup ça à une époque, d'avoir cette espèce de backlog de choses qu'on a testées. Parce qu'en fait, sans rappeler déjà, c'est hyper important. Parce que quand on fait du produit, on fait mille trucs en même temps et on oublie des fois ce qu'on a fait il y a six mois. Mais c'est de se dire, ok, ça n'a pas marché, mais peut-être qu'il y a un autre chemin, peut-être que ce sera le bon moment, peut-être qu'on était trop en avance.
Terry : Il y a vraiment beaucoup de choses. — Je vois que tu voulais rebondir là-dessus, Nicolas.
Nicolas : — Je voulais juste conclure en deux secondes. Parce qu'on se dit qu'on n'a pas de mesures, donc on a un niveau de risque qui est quand même assez élevé. Si on prend juste les bons principes d'une orga produite, d'une orga agile, c'est juste qu'il faut itérer très vite et dérisquer le plus vite possible. Pour moi, la clé, elle est là. On a le droit de se tromper, mais il faut se tromper. Et il faut juste qu'on soit capable de le mesurer et d'apprendre le plus vite possible.
Terry : Très très clair et très complémentaire j'aime bien c'est vrai la nuance de effectivement faut pas se bloquer on peut pas mesurer donc on teste pas non on va tester ensuite mais rapidement passer ensuite sur un mode plus productisé plus industrialisé aussi sur la façon de mesurer les choses pour revenir sur ce que tu disais juste avant marion par rapport à la capacité aussi à garder une trace en fait de ce qui a été fait dans le passé moi ça me permet de remettre une pièce dans la machine sur le sujet de la synchrone, parce que la culture de la synchrone et de l'écrit en fait, derrière la synchrone moi je mets la culture de l'écrit, je trouve ça très très important et pertinent justement pour être capable de faire ça, c'est-à-dire que quand tu traces tout par écrit, même si une décision à un instant T fait que tu vas acquérir une fonctionnalité, peut-être que deux ans plus tard, tu vas avoir des nouvelles personnes qui n'étaient pas là avant, ou même les personnes qui étaient présentes au moment du kill de la fonctionnalité ont oublié la raison pour laquelle cette fonctionnalité a été killée, mais va être nécessaire en fait dans le futur. Et donc le fait d'avoir tout tracé permet aussi de comprendre le raisonnement qu'il y a eu à l'époque, d'éviter de le refaire une deuxième fois. et du coup de partir sur le nouveau raisonnement qui va permettre potentiellement de changer la décision. Et donc ça montre aussi que les décisions comme ça ne sont pas gravées dans le marbre, mais le fait de tracer ça permet aussi au nouveau de comprendre que ça n'a pas été fait en freestyle et que ça a été réfléchi également. Et c'est vrai que ça c'est un sujet, j'en avais parlé il y a un petit moment avec Audrey quand elle bossait chez 360 Learning qui est une scale-up princesse qui a une grosse culture de la synchrone. et qui m'expliquait justement que tu avais des capacités à vraiment remonter très très loin dans les choix qui avaient été faits et donc qui permet derrière aussi de faciliter l'avancement. J'aimerais revenir sur le point dont on parlait au début sur se poser ces questions d'organisation, ça peut être pertinent peu importe la taille de l'entreprise, il faut distinguer le pourquoi du comment. Donc le pourquoi, à partir du moment où on a réussi, je vais dans un schéma d'exemple, on va dire que la boîte, globalement, le pourquoi, il est là. Maintenant, ils sont plutôt sur le comment et donc sur les spécificités en fonction des tailles d'entreprise. C'est-à-dire, comment je fais pour commencer à mettre en place des petits éléments qui mettent dans mon orgaproduit quand je suis une TPE de 10 personnes ? Comment je fais quand je suis plutôt autour de 50 personnes ? 250 et puis après et après on peut passer aux ETI et au grand groupe si vous avez un peu des voilà pour chacune de ces tailles de boîtes quelques petits quick wins ou en tout cas dans le comment ou plutôt que quick win on va dire piste de travail sur sur le sujet mise en place d'orgas produits en partant du principe que ces entreprises là n'auraient pas d'organisation produit qu'elles seraient sur les cultures très projet, voire complètement freestyle. Je te mets un post-it sur le bureau et c'est ça qu'il me faut.
Marion : Pour dans deux semaines. Il y a pas mal de choses. En fait, moi, j'analyse déjà là où l'organe est. L'idée, c'est pas de tout péter. Il y a toujours plein de bonnes choses, même si c'est pas mature, etc. Je veux dire, c'est quand même une organisation composée d'humains. Ils sont tous là pour travailler, pour apporter quelque chose, pour être contents, on se lève le matin pour aller bosser quand même, donc il faut être quand même content le soir aussi de rentrer et de se relever le matin. Donc c'est analyser déjà les pratiques en fait, les gens, la culture, d'où est-ce qu'on part, et d'y aller petit pas par petit pas. Je me disais pas de big bang, etc. C'est hyper important parce qu'en fait, chaque boîte est différente. Alors pour le coup, si on peut parler de start-up, j'ai parlé de plus grands groupes à l'échelle de BU, à l'échelle plus large, etc. Il faut prendre en considération tout ça. Pourquoi on a créé FLUHO aussi ? C'est parce que... on est très axé aussi sur l'humain. Je vais faire une digression par rapport à ta question, mais même si ça va être assez complémentaire. Pourquoi moi je suis devenue coach produit et j'ai arrêté d'être head of ou autre ? C'est pour aider en fait, pour aider, transmettre et faire en sorte que les équipes que j'accompagne soient fiers d'elles, ne soient pas dans la souffrance aussi, parce qu'il y a des organisations qui sont en souffrance. et c'est apporter finalement quelque chose dont ils vont pouvoir se saisir. Moi, je n'ai pas toutes les réponses, je n'ai pas toutes les clés. Je vais pousser des choses, je vais essayer de planter des petites graines, essayer de faire adopter des choses aussi, leur montrer aussi une autre façon, un autre paradigme, une autre façon de penser. Et c'est à l'organisation finalement de prendre tout ça et d'avancer avec moi. avancer avec moi, oui, je les guide, je les accompagne, et de faire son cheminement et de te dire ça c'est bien pour nous ou ça c'est pas bien pour nous. Moi j'arrive pas en me disant ça ça va être super bien, il faut faire ça, ça, ça, ça, ça, ça, non ça ça marche pas. C'est comme si je débarquais chez toi en me disant attends toi ton salon il est pas à la bonne place, moi ta cuisine je l'aurais pas organisée comme ça, les assiettes je les aurais mises en haut et les verres en bas. Non. Ça, ça fonctionne pas. Donc voilà il y a vraiment une intelligence à aller chercher dans le collectif Et on parlait d'autonomie des équipes. En fait, c'est ça que je vise aussi à in fine. C'est cette autonomie, c'est de se dire mais en fait, vous avez des équipes produits, techniques, etc. Vous avez rassemblé des personnes, elles savent faire des choses, elles sont compétentes. Donc il y a le credo un peu, c'est ceux qui savent qu'ils font. Laissez un peu plus de latitude à vos équipes. Et finalement, on en revient à l'empowerment in fine et c'est ça. L'approche de Marty Kagan, elle est hyper belle, elle est hyper dure à aller chercher. C'est souvent ce que je dis aussi dans les accompagnements. Il y a quand même un long chemin avant de se dire, on est tous hyper empowered, autonomes, etc. Donc ça passe par plein d'étapes et plein d'acculturation aussi et de temps. Le temps long est aussi important.
Nicolas : Moi, ce que j'ai fait à un moment mythique, c'est cartographier. J'étais là depuis pas mal d'années, mais quand je dis cartographier, c'est surtout le partager. Qui fait quoi dans ce qu'on appelle un product flow. Tout à l'heure, on a parlé de vision. Donc, quelles sont les étapes de maturation du produit ? Qui fait quoi et qui est responsable de quoi ? Bon, c'est que le dev y dev, je caricature, évidemment, il y a différentes typologies de développeurs, je suis un ancien développeur, donc je suis plutôt très à l'aise avec le sujet, mais voilà, c'est dire qui fait quoi, qui est responsable de quoi, est-ce que c'est clair quels sont les niveaux de responsabilité ? On parle souvent de rôle et responsabilité dans une organisation, et c'est important à un moment de les définir. Et ça ne veut pas dire est-ce qu'elles sont bonnes ou mauvaises, c'est juste déjà de descendre le niveau de l'eau et de rendre ça transparent. Et une fois qu'on a bien posé ça, se dire, est-ce que ça fonctionne bien ? Est-ce que tout le monde est à l'aise ? Est-ce qu'il n'y a pas des rôles et leurs responsabilités qui se percutent, qui génèrent de la frustration, etc. Donc à partir du moment où on a descendu un peu le niveau de l'eau, qu'on voit les choses de manière beaucoup plus claire, un peu comme un miroir, ben là on peut commencer à se poser des questions d'un point de vue managérial. Est-ce que c'est les bons rôles ? Est-ce que c'est les bonnes responsabilités ? Est-ce que la qualité est placée au bon endroit ? Est-ce que c'est normal que que celui qui fabrique quelque chose, qui pousse en production, n'est pas responsable, in fine, des bugs associés. Voilà, c'est d'amener ce genre de questions qui sont, pour moi, qui sont clés. Est-ce que c'est normal de dire à un product manager qu'on a formé à faire du discovery, on lui a dit product manager, c'est un peu un mini CEO, il va pouvoir faire tout ça, et in fine, on lui pousse des features ? Voilà, c'est d'essayer de mettre toutes ces incohérences au milieu, tu vois, un peu comme le cadavre de la vache au milieu de la table, c'est une expression assez classique en agilité, mais voilà, qu'on les pose et qu'on en discute sereinement et de se dire, ok, bon, on voit qu'il y a des choses qui ne sont pas logiques, tu vois, cognitivement ça ne marche pas, on se pose, on en discute avec les bonnes personnes, on se dit, ok, maintenant qu'on a tous les curseurs devant nous, qu'est-ce qui se passe si on se dit, puisqu'on veut aller sur un paradigme d'autonomie, Comment on peut le nourrir ? Quel est le bon cadre de jeu ? Qu'est-ce qu'on leur donne ? Quelles sont les bonnes questions qu'on se pose au bon moment ? Est-ce qu'on y associe des rituels ? Et en fait, quand on parle souvent de framework, nous on va essayer d'en dessiner un qui n'est pas du tout dogmatique, mais je pense qu'à un moment, une structure doit pouvoir poser une structure, une organisation de produits, son propre framework. Ça veut dire framework, c'est-à-dire quelles sont les bonnes étapes, qu'est-ce qu'on fait à tel moment, qui fait quoi, qui est responsable de quoi, comment on échange les bons éléments au bon moment, le bon cadre de définition, par exemple sur le delivery, mais aussi le discovery et toutes les étapes. Et à un moment, je pense que c'est important de le, surtout pas de le figer, mais de l'écrire collectivement. Et une fois qu'il est relativement clair, de le faire évoluer naturellement. Et par contre, la chose auquel je crois beaucoup, c'est qu'il faut quand même assez incarner cette structuration et cette évolution. Souvent il y a des rôles, on parle des coachs agiles, etc. En tout cas, on doit avoir des personnes qui sont responsables de le poser, de l'animer, de l'améliorer comme un produit. On parlait tout à l'heure une organisation produit se manage comme un produit, donc il faut des personnes qui sont un peu comme des product managers, comme des développeurs, s'occupent de formaliser, s'occupent de l'améliorer, font des démonstrations de l'évolution, mesurent le succès auprès de leurs utilisateurs, etc. Et donc, il y a un moment, le produit final doit exister et doit être améliorable. Et donc, je pense que c'est ces étapes-là qui sont importantes, de bien définir qui fait quoi à un moment. In fine, ça créera ce produit qu'on améliorera dans le temps.
Terry : Très clair. Merci pour la réponse. On pourrait se dire, la réponse sur le comment, il n'en a pas eu Terry, mais en fait, si, parce que ce que vous m'avez dit, je trouve ça très pertinent et ça revient à l'essentiel qui reste la base qui est l'humain, c'est-à-dire que sur ce comment, avant de penser toutes les méthodes qu'on veut, c'est d'aller se remettre au contact de l'humain et de comprendre avec eux et de créer avec eux. la bonne organisation, donc là-dessus très clair, et du coup ça mène aussi une cohérence sur tout l'échange, donc merci pour ça. Avant d'aller vers les fins de questions d'épisode, est-ce qu'il y a un sujet en particulier sur lequel vous aimeriez mettre un petit peu l'accent, qu'on n'a pas abordé, ou voilà, un point que vous voudriez rajouter avant mes deux questions phares de fin d'épisode ?
Nicolas : On ne l'avait pas préparé ! Non, j'ai l'impression, en tout cas moi, qu'on a pas mal fait le tour. On a essayé un peu de distiller notre façon de faire, de voir les choses. Marion a très bien parlé de l'humain. Je pense que c'est une clé fondamentale de la réflexion. Et ça ne veut pas dire, alors évidemment, on est tous un peu humanistes, mais d'être un peu dans une logique bisounours. Non, ça veut juste dire, encore une fois, dans la clé de lecture, nos organisations est un produit. En fait, ce qu'il compose les gens, on doit être empathique vis-à-vis d'eux, de comprendre quelle est leur difficulté, et ça peut être un problème de compréhension, ça peut être un problème de sens, ça peut être un problème de plein de choses, mais voilà, cette dynamique de l'humain, elle n'est surtout pas bisounours, elle est juste sincèrement empathique, parce qu'in fine, ce qu'on cherche à faire, c'est à rendre les entreprises plus performants, d'atteindre leurs ambitions, mais sans avoir la clé de voûte, la compréhension de ce qui compose leurs organisations, ça ne peut pas fonctionner. quand on challenge un peu SAFE et on se dit c'est comme ça que ça devrait fonctionner, ça ne prend pas en compte cet « humain » qui compose les organisations d'une entreprise et on a besoin de comprendre comment ça fonctionne, comment ils fonctionnent, quels sont leurs degrés de maturité, quelles sont les bonnes prochaines étapes pour eux, qui ne seront pas trop « big bang » mais au contraire qui seront légitimes. Quand on passe d'un modèle de « je veux telle fonctionnalité » à « je veux atteindre tel objectif », Moi j'ai vécu un moment normal comme tout le monde, on va faire des OCR et on faisait des pyramides d'OCR et à un moment on s'y perd, on ne comprend plus rien, les gens ne comprennent plus rien. Maintenant il faut déjà se dire, on va arrêter de parler de features, on va se dire qu'est-ce que tu veux atteindre avec cette feature ? C'est déjà un premier package gigantesque, c'est un changement de parating. qui a été ultra fort à Mythique, et toutes les boîtes devraient passer déjà par ça. Et en fait, pourquoi j'utilise cet exemple, c'est que si on ne prend pas en considération de manière très empathique ou en son les gens, et ça ne veut pas dire que nous on sait mieux que les autres, c'est comment je peux t'aider à faire mieux ce que tu aimerais faire, au sens très large du terme, je pense qu'on risque de passer et d'être vite fait comme ça, parce que c'est comme ça que ça devrait être fait.
Terry : — Très clair. Tu veux ajouter quelque chose, Marion ?
Marion : — Non, je crois qu'on a bien fait le tour.
Terry : — On a fait un bon tour, yes. Donc pour aller, ma première question, c'est est-ce que vous avez un sujet sur lequel vous avez des positions fortes ou, en général, vous êtes en désaccord avec vos pairs ? Sujet un peu clivant.
Marion : Alors oui, forcément. Moi, il y a un truc que j'observe, c'est... Alors on a parlé de framework, on monte un framework, mais qui est, je le redis, sur mesure, adapté, adaptable, voilà. Il n'y a rien de rigide là-dedans. Par contre, ce que je vois comme des rives, c'est qu'il y a plein de frameworks qui sortent. Et c'est le buy the book, tchac tchac tchac, il faut faire ça comme ça. Enfin, on en a parlé un peu, évidemment, pendant tout l'épisode, mais non, faites pas ça. Appropriez-vous des choses, est-ce qu'elles font sens pour vous ? Tu vois, j'ai parlé de Zocker tout à l'heure, j'adapte ce framework-là à la maturité des équipes, à leurs besoins. Mais c'est pareil sur le Discovery, vous vous posez pas douze mille questions ? Disait Teresa Torres, elle vous donne plein de clés. Alors évidemment, elle a une vision qui est hyper poussée et j'adorerais que toutes les organisations et tous les PM puissent faire ça, mais déjà juste un tout petit peu, c'est déjà bien. Faut pas se lancer dans un truc qui va finalement transformer le framework, donc le cadre de travail, en un process rigide. Et ça, c'est un truc qui arrive hyper rapidement. Je l'ai vu aussi avec des productops où on est là pour aider, mais finalement, qu'est-ce qu'on produit ? C'est du process, du process, du process, du process, sur lequel tout le monde doit se calquer. Et en fait, une équipe produit A et une équipe produit B, si elle est autonome, elle ne va pas fonctionner de la même façon. Elle ne va pas innover de la même façon. Donc laissez-les s'auto-organiser. Alors après, il ne faut pas que ça soit le chaos. Évidemment, en organisation, il y a des choses, il y a des rituels qui sont posés et qui doivent être suivis. Mais voilà, il y a ce côté attention, je le vois, on se parlait un peu de tout ce qui est posté sur LinkedIn tout à l'heure, mais voilà, le framework-ci, le framework-ça, ouais, en fait, juste lisez-le, comprenez-le, allez chercher l'essentiel dedans, mais ne le prenez pas en disant, ouais, ça c'est super, on va l'adapter jour 1, jour 2, jour 3, jour 4. Voilà, ça c'est un peu mon combat. — Très clair.
Terry : Toi Nicolas ?
Nicolas : — Alors c'est drôle, parce que... tes questions étaient anticipables, et on s'est posé pas mal de fois, voilà, qu'est-ce qu'on pourrait raconter, etc. Et en fait, je me suis fait à la réflexion pendant qu'on discutait, c'est, en fait, on a MonteFLUHO, et donc, on a deux modèles de pairs maintenant. On a nos... les coachs qui sont nos pairs, coachs groupes produits, coachs agis, c'est nos pairs, donc on peut parler des accords qu'on pourrait avoir avec eux, et... Et Marion le fait très bien. Et j'étais en train de me dire, mais en fait, il y a aussi nos pères, et c'est pour ça qu'on a monté FLUHO, qui sont aussi des gérants de boîtes de conseils. Et là où on a... Moi j'ai un désaccord avec eux, et c'est pour ça que j'avais envie de monter ma propre structure. Voilà, quand j'ai quitté Mythique, j'en ai rencontré plein. Et en fait, là où moi j'ai vraiment eu envie d'entreprendre, c'est que je sais que l'approche, j'ai pas du tout la même. J'ai fait... plus de dix ans de conseils, j'étais chez Steria, Extir, etc. Et j'ai quand même découvert un monde où l'objectif majeur, c'était le business, financier, au détriment bien souvent des enjeux qui étaient ceux des clients, en fait. Et là où moi, j'ai un point de désaccord, je souhaite que ça réussisse, évidemment, ce qu'on est en train d'entreprendre avec Marion, mais ça ne se fera pas dans une logique où il faut absolument qu'on fasse du business même si ce n'est pas dans l'intérêt du client. Et ça, ça fait partie de ma culture, j'ai jamais entrepris des choses auxquelles je ne croyais pas moi et surtout qui n'étaient pas bonnes pour ceux que j'accompagnais, que ce soit des clients Preuve en est, quand j'ai monté mon agence web, j'avais des cahiers des charges qui arrivaient. La première chose que j'ai fait, c'est en fait, ça ne peut pas marcher. Alors oui, je pouvais gagner de l'argent en faisant un cahier des charges, mais je savais in fine qu'à la fin, tout le monde était perdant, peut-être pas financièrement, mais qu'on était forcément perdant. Et très vite, j'ai essayé de trouver des solutions et d'y sculpter un petit peu l'approche et d'essayer au contraire d'accompagner à l'époque nos clients à comprendre quels étaient leurs enjeux et leurs vraies clés de succès. Ça sera la même chose aujourd'hui. Là où nous, j'espère qu'on différera, c'est que bien sûr qu'on veut gagner de l'argent, on veut pouvoir être autonome, on veut pouvoir faire en sorte de grandir naturellement. Mais l'argent est une conséquence de quelque chose qui est bien fait. Ce n'est pas un objectif primaire. Si j'étais là, entre guillemets, que pour l'argent, il y a des choses beaucoup plus simples.
Marion : On n'aurait pas monté plus haut.
Nicolas : Le freelance est beaucoup plus efficace. Il n'y a pas trop de débat là-dessus. Mais en tout cas, j'avais envie de de vivre une aventure humaine, de raconter une relation différente, comme moi j'ai pu la vivre à Amitik, mais de le faire avec plein plein d'autres entreprises, de raconter une histoire très... Et voilà, de créer des relations humaines où les gens ont confiance en nous parce que, in fine, ce qu'on apporte, entre guillemets, est bon pour eux et pas juste un objectif financier. Non, non, on reste dans ta mission parce que bon, le contexte est compliqué, etc. Et donc, ça crée des relations qui sont un peu malsaines. En tout cas, nous, on a envie d'être très sincères dans notre démarche, très transparentes, presque un peu no bullshit, c'est un peu dans nos valeurs, mais voilà, d'avoir une approche très forte et très puissante là-dessus.
Terry : Très clair, pour rebondir sur vos deux un peu convictions fortes, là sur ce que tu disais Marion, moi de mon côté, enfin sur la partie framework comme tu l'as dit, je pense que c'est important en fait de les connaître pour pouvoir derrière les challenger. En fait je suis pas anti-framework ou pro-framework, je suis plus dans le sens qu'il faut s'acculturer de toute façon parce que ça donne également, moi ce que j'aime à dire c'est que ça permet aussi de parfois donner un point de départ plus ou moins commun, souvent qui est faussement commun parce que justement chacun sa propre interprétation mais au moins il ya quelques on va dire éléments de langage vocabulaire qu'on va pouvoir utiliser sur lequel on va pouvoir plus ou moins s'aligner et après s'adapter enfin se l'approprier et faire ce qui fonctionne pour nous et sur la partie dont tu viens de parler nicolas au niveau de l'aspect plus boîte pour un aspect purement financier versus évidemment servir tes clients. Moi j'aime bien dire, là c'est plus large, ça va au-delà du produit, c'est que l'argent pour moi c'est un moyen, c'est pas une fin. C'est-à-dire que dans le monde dans lequel on vit, c'est quelque chose dont on a besoin puisque c'est comme cela que le monde... C'est un carburant. Voilà, c'est un carburant. Et donc vouloir en gagner c'est pas à mon sens malsain quand c'est derrière pour une fin qui elle est saine. C'est une question beaucoup plus large de société, de culture, de valeur. J'ai eu une période où je fantasmais les US. J'étais parti travailler à Londres, c'était normalement le tremplin pour partir ensuite en Californie. Et en réalité, quand j'ai vécu à Londres, j'ai adoré, mais je me suis dit, en fait, la culture européenne, je la préfère à la culture américaine. Et justement, parce que je pense qu'on a une histoire beaucoup plus longue, beaucoup plus forte. Et je trouve que certaines fois, il faudrait qu'on se réapproprie plus notre propre héritage, plutôt que juste de dire, ah, les Américains, ils ont tout compris, il faut qu'on fasse comme eux, quoi. Mais ça, voilà, après, ça débarre largement du cas du post-apocalypse.
Marion : — Ça, ça, on peut faire un autre épisode. — Ouais.
Terry : Et du coup pour ma dernière question, c'est qu'est-ce qui vous nourrit intellectuellement, qu'est-ce que vous avez comme ressources, Rocco, de choses que vous faites en dehors du travail ou même dans le contexte du boulot mais avec lequel vous trouvez des points dans votre activité pro ?
Marion : Alors, la veille est hyper importante, bon ça je pense que tout le monde te le dit, mais pour autant j'ai vu des PM, des head off, etc, que je ne fais pas de veille. Ok. Alors là c'est quand même un peu problématique parce qu'on est sur un métier qui évolue tout le temps, avec plein de points de vue différents. Bah tu vois on a enregistré un podcast avec toi aujourd'hui, c'est aussi pour raconter des choses à ton audience. Donc faites de la veille, faites de la veille, faites de la bonne veille. Alors on vient juste de parler des US, moi je me nourris beaucoup de John Cutler, Jeff Patton, Marty Kagan, j'aime beaucoup ces analyses-là. qui sont finalement des choses aussi où on se dit, quand on les lit, au démarrage, pour les plus juniors qui vont nous écouter, on va jamais y arriver. Mais non, il faut s'adapter, se nourrir de tout ça. Il y a déjà ça. Faites de la vraie veille pour se nourrir, pour grandir dans le métier, pour comprendre ces frais morts, comprendre les travers, mieux se les approprier, ne pas en faire des usines à gaz, etc. Et après, moi, ce qui me nourrit, moi, au quotidien, c'est la musique. Je fais beaucoup de concerts, je fais beaucoup d'expos aussi, l'art me nourrit beaucoup. Je trouve que c'est une façon de reprendre conscience d'autres choses, finalement, se reconnecter un peu au monde. Et il y a des choses qui sont intéressantes à observer dans toutes ces dynamiques-là, je dirais.
Terry : Très clair. Merci pour les partages.
Nicolas : Pour ma part, je ne reviendrai pas sur la veille. Je pense que quand on aime notre métier, qu'on est un tant soit peu dans une recherche d'excellence, lire et tout ce qui peut s'écrire par des ténors comme tu les as cités, il n'y a pas trop de débat. Je pense que c'est passionnant et on est quand même dans des environnements extrêmement complexes. Et donc, avoir des certitudes aujourd'hui, c'est se fourvoyer. Mais tu vois, tout à l'heure, si je sors d'un peu de ce registre, on parlait un peu de, tu vois, thinkerview, ce genre de choses. Moi, j'ai... On vit des moments humainement, de société. Enfin, voilà, on est une... Depuis quelques années, on est une actualité assez incroyable, pour ne pas rentrer dans les détails. Chacun a sa perception des choses, mais je trouve que ça nous apprend de manière très bienveillante, très empathique, beaucoup de choses sur la nature humaine, bien, pas bien, peu importe. Je pense que ça, ça devient très personnel, mais on comprend beaucoup le fonctionnement humain dans ces moments-là. Moi, j'ai découvert des réactions humaines que je m'attendais pas forcément à des niveaux structurels de la société. Et je trouve que mes paradigmes ont beaucoup été bousculés ces derniers temps. On pourrait penser que les grandes écoles ne font que machin et qu'inversement ça ne fait que machin. En fait j'ai constaté, après c'est mon avis personnel, en tout cas tu me demandes ce qui aujourd'hui m'inspire, c'est d'essayer de décliver un peu ça, de sortir des paradigmes grande école, donc forcément nanani nanana, mais c'est plutôt de se dire, ok, si on enlève tous ces paradigmes, ces principes, ces manières de voir les choses, en fait, objectivement, comment les gens réagissent, pourquoi, quels sont leurs enjeux, et c'est hyper inspirant, tu vois, parce que tout ça c'est très systémique, c'est très humain, il y a beaucoup d'empathie dedans, et c'est hyper inspirant, passionnant, pas toujours très agréable malheureusement. Mais en tout cas, moi, ça m'inspire et restons positifs.
Terry : Merci encore pour votre temps, Nicolas et Marion. Et puis, si les gens veulent vous contacter, du coup, LinkedIn, site Internet, Flueau.fr, LinkedIn.
Nicolas : Tout beau, tout neuf.
Marion : Exactement.
Terry : Merci à tous les deux.
Marion : Merci. Merci à toi, Terry.
