Romain Monclus, Comment mettre en place la meilleure organisation produit ?

Transcription de l'épisode : "Romain Monclus, Comment mettre en place la meilleure organisation produit ?"

Terry : Salut Romain.

Romain : Salut Terry.

Terry : Merci de me recevoir aujourd'hui chez Thiga. Donc aujourd'hui, on va parler d'organisation produit, mais contrairement à ce que j'ai pu faire dans pas mal d'épisodes dans le passé, et puisqu'on peut lire pas mal sur les réseaux aujourd'hui, on va aller dans des cas pratiques. Et du coup, dans des retours d'expérience pour voir un petit peu entre la théorie et la mise en pratique, reconnecter ces deux mondes, puisqu'il faut les deux. Mais l'idée là, ça va être de faire un épisode assez centré sur la pratique de la mise en place d'orgas produit. Donc avant de rentrer dans ce sujet, je te propose tout d'abord de te présenter, puis de nous présenter Thiga également.

Romain : Salut Terry, moi c'est Romain, Romain Monclus, j'ai 35 ans, je suis un jeune papa, je travaille chez THIGA depuis 9 ans, j'ai fait une grande partie de ma vie professionnelle dans cette belle boîte. J'ai un background de Product Manager, avant ça j'ai fait une école d'ingé et un Master's de commerce. Aujourd'hui je suis directeur de notre practice Orga, qui vise à conseiller nos clients sur la mise en place d'organisations produits.

Terry : Très clair, très clair du coup. Donc voilà, tu viens de dire ce que vous faites chez THIGA pour ceux qui connaîtraient pas. Donc au niveau Orga Produit, qu'est-ce que pour toi ça signifie ? Qu'est-ce qu'on entend quand on parle d'organisation de produit ? On met souvent ça en parallèle avec les organisations de projet, ou en tout cas en opposition plutôt. Toi, par quelle porte tu rentrerais pour définir un peu ce que tu entends par organisation de produit ?

Romain : Alors déjà, il y a un abus de langage, c'est quand on parle de produits, c'est souvent de produits numériques, parce qu'il y a aussi les produits physiques, et quand on travaille en corpore, on se rend compte que ce qu'on appelle l'organisation produit devient très complexe parce qu'on doit gérer des produits numériques qui s'inscrivent dans un business model qui est fortement porté par des produits physiques. Donc organisation produit numérique, qu'est-ce que c'est ? C'est une organisation qui facilite la création de valeur pour l'entreprise autour des produits numériques. Donc nos convictions, elles sont autour d'avoir déjà un alignement fort sur quelle valeur on a envie de créer. C'est quoi la valeur ? Ça va aider à la priorisation, à la création de la stratégie. Ensuite, c'est de favoriser la collaboration entre les membres des équipes, pour s'assurer du fait qu'un projet voit vite le jour. Un parti pris, c'est de se dire qu'une équipe pluridisciplinaire va être plus efficace que des équipes qui travaillent en silo. Ça, c'est deux choses très fortes de la culture produit. Très clair.

Terry : Du coup, sur la partie valeur, justement, tu as parlé de se poser aussi les questions. Je pense qu'il y a ça en termes de basculement, de façon de penser les choses quand on va sortir un produit sur le marché, donc un produit digital. C'est le fait de se dire, avant même de commencer à sortir des fonctionnalités, à se dire on va faire ça, on va faire ça, c'est de se poser vraiment les bonnes questions de qu'est-ce qu'on va apporter à quel problème on veut répondre auprès de nos utilisateurs et auprès de nos futurs clients et donc c'est plus une façon de penser assez différente de là où avant on était plus sur une logique top-down ou en tout cas on avait globalement une idée de ce qu'on voulait pousser comme produit ou service et on allait plus se concentrer sur la capacité à construire sans vraiment se poser la question de quels sont les problèmes auxquels je réponds.

Romain : Alors en vrai, même en mode projet, alors souvent on oppose projet et produit, pour moi ils fonctionnent ensemble, et en projet on va aussi se poser la question de quelle valeur ça a, juste je pense qu'une des grandes différences c'est qu'on va l'exécuter très différemment. En mode produit on va accepter le fait qu'il y a de l'incertitude, qu'il faut aller le plus rapidement possible choper du feedback et potentiellement se remettre en cause. En mode plus old school, il y a un peu cette culture de « ok j'ai raison, j'ai une idée géniale, on va y aller ». Et c'est pas forcément corrélé à des vieilles entreprises ou des nouvelles entreprises. Aujourd'hui on voit des startups qui fonctionnent en mode projet parce qu'on a des founders qui sont convaincus du fait qu'ils ont la bonne idée, qui vont trouver leur product market fit du premier coup. C'est quand même assez complexe et je pense que c'est aussi lié à un état d'esprit des personnes, donc pas uniquement des outils, des frameworks, mais plus une culture, la capacité à douter, la capacité à être en empathie avec ses utilisateurs. Voilà, c'est des changements qu'on parle de changements d'organisation produit, le terme organisation il est piégeux parce qu'on peut penser que c'est une structure, que ça va être une usine qu'on va construire, l'usine produit, une fois qu'on a construit l'usine produit on va bien travailler sur notre produit, mais c'est plus aussi, enfin c'est également et surtout une question de mindset à tous les niveaux, donc du leadership jusqu'aux opérationnels.

Terry : Et là-dessus, c'est vrai qu'on pourrait tendance à dire un peu comme quand il y a eu l'avènement effectivement des startups dans pas mal de grands groupes, on a vu pop des Digital Factory ou un peu ces unités qui étaient responsables du coup d'utiliser, de capitaliser sur le digital, un peu en mode... En mode silo. Tandis que ce que tu expliques, c'est que là, le basculement vers l'approche produit, c'est vraiment au global, au niveau organisationnel, en plus d'être dans la partie exécution, sur l'état d'esprit à avoir.

Romain : Oui, l'état d'esprit joue une grande partie dans le succès.

Terry : Et donc pour prendre des cas, des exemples concrets un peu du coup sur ça, toi qu'est-ce que t'as pu voir comme exemple sans citer de nom d'organisation ou autre, mais en tout cas des retours d'expérience d'organisation qui avait vraiment cet état d'esprit quand t'es arrivé déjà bien en place versus d'autres où ça l'était moins, et donc des choses qui t'ont positivement marqué, autant d'un point de vue orga qui avait ça en place, d'autres qui l'avaient peut-être pas mais qui fonctionnaient aussi très bien avec une approche et comment t'identifier ça sur tes différentes missions ?

Romain : Avant d'entrer dans le détail, on a tendance à se projeter dans un modèle d'organisation idéal. Mais ce modèle n'existe pas. Les organisations vont avoir leurs forces, leurs points d'amélioration et on va les faire grandir sur différents aspects. On a théorisé ça, on a quatre piliers qui sont la stratégie, le discovery, le delivery et la culture. Et avec ça, on arrive à couvrir les grandes lignes des pratiques produits. Et après, dans les entreprises que je vois, il y a des boîtes qui ont une super stratégie, qui ont une vision claire d'où elles ont envie d'aller. Mais ensuite, la connexion avec l'exécution ne se fait pas bien. des boîtes qui arrivent à le faire, on a d'autres qui sont moins bonnes là-dedans et je trouve que c'est très complexe parce que ça demande un leadership aussi de communiquer, de récupérer du feedback des équipes pour bien exécuter et donc ça m'arrive régulièrement d'arriver dans des organisations où on donne des documents de stratégie, il y a des belles slides qui expliquent le marché qu'il faut adresser, dans quel ordre on va y aller, avec quelles initiatives, etc. Mais derrière, des équipes qui ont du mal à s'aligner entre elles, qui ont du mal à prioriser sur le court terme. En fait, de passer de 3 ans à 3 mois, en vrai, c'est super compliqué, parce que ça demande de prioriser, ça demande de s'aligner, etc. Donc ça, c'est une première problématique que je vois dans les différentes organisations. Il y a aussi un autre sujet, on parlait d'exécution, c'est la stabilité technologique. Je vois de grandes différences entre des boîtes qui ont maîtrisé le delivery, c'est-à-dire une tech qui est bien posée, peu de legacy, je ne vais pas dire pas de legacy parce qu'il y en a toujours, mais en tout cas, peu de freins liés à la technologie, et un operating model des équipes qui fonctionne très bien. Donc ça, ça se voit tout de suite quand on rentre, hormis parfois le directeur technique qui dit, t'inquiète, chez moi c'est nickel, pas la peine de regarder. Mais en effet, on a souvent de très bonnes surprises par rapport à ça.

Terry : Donc des boîtes sont vraiment capables de sortir des fonctionnalités rapidement, sans trop de.

Romain : Bugs... Et ça, ça se passe pour des petites, pour des grandes entreprises. On fait ce constat-là. Et par contre pour d'autres qui ont des gros problèmes, donc les deux cas, on va dire typiques, ça va être la startup qui n'a pas eu le CTO qui a permis de mettre en place le truc de ouf dès le départ, donc c'est-à-dire une boîte qui est encore scrappy, qui a peut-être beaucoup pivoté, qui vient de trouver son product market fit, et donc là il va y avoir cette logique de sanitisation, de sortir quelque chose qui va permettre à l'organisation de scaler.

Terry : Parce que là on parle du coup de grosses dettes techniques qui va bloquer le passage à l'échelle sans... Peut-être on.

Romain : A fait, alors ça je l'ai peu vu, mais on a fait beaucoup appel au no code, ça peut être un truc. Un truc c'est en fait les premiers founders côté tech, sont partis avec une solution du marché qui n'est plus la bonne par rapport à ce qu'ils souhaitent faire, et par ailleurs peut-être que c'est intéressant de construire soi-même sa stack technique si on a des besoins très spécifiques, donc ça veut dire justement mettre en place de nouvelles choses. Il y a aussi le côté, souvent quand la startup commence à avoir une vingtaine de devs, Là il va y avoir cette logique de scale, on parle de 20 personnes, c'est pas non plus énorme, mais cette logique de, on veut doubler l'équipe, mais ça veut dire changer totalement la manière dont l'organisation fonctionne, en créant des squads, bref, créer plusieurs équipes, et donc là vient le sujet de comment je scale, comment je l'organise ça. Ça, c'est quelque chose qu'on voit souvent. Et du coup, pour les grandes entreprises, les problématiques techniques qu'on voit, ou les freins, ça va être des gros projets de sorties de systèmes. Donc voilà, on bossait sur, j'en sais rien, Oracle. On a envie de sortir d'Oracle, passer sur une architecture microservice qui va nous permettre justement d'avoir une approche beaucoup plus modulaire des développements, de réduire les dépendances entre les équipes, etc. Des choses très structurantes. Et ça, c'est des projets qui peuvent durer des années. que j'ai vu dans plusieurs entreprises. Donc ça, c'est un vrai frein et un vrai sujet de focalisation. Comment est-ce que je gère ce projet de décommissionnement ? Je ne suis pas un expert du sujet, mais j'ai vu des articles sur le sujet récemment. Et en effet, c'est décommissionner en mode produit. Ça se fait, mais il faut bien cadrer le truc dès le départ.

Terry : Donc là il y a plusieurs points sur lesquels je vais vouloir qu'on rentre un peu dans les détails.

Romain : Attends juste, je termine. Tu me disais, c'est quoi les trucs concrets que tu vois sur le terrain ? Je pense qu'il y a encore une pratique que je trouve encore complexe, c'est problème versus solution. Donc c'est vraiment passer du temps sur le cadrage d'un problème avant Et ça c'est un biais je pense, je m'adresse au PM qui je trouve est assez fort côté tech et côté PM, je le plaide coupable également. Cet attrait du construire, de faire un truc, on est des builders donc on a envie de faire un truc stylé, mais avant ça faut s'assurer du fait qu'on n'est pas en train d'optimiser un truc qui sert à rien. Et cette gymnastique, je trouve qu'elle n'est pas encore acquise dans la plupart des environnements dans lesquels on intervient.

Terry : Très très clair mais du coup tu me permets de rebondir là dessus par rapport à ce que tu disais au début sur la problématique en fait d'alignement entre ce qu'une direction de boîte va avoir en tête et la partie plutôt exécution et du coup au niveau exécution pas trop savoir dans quel ordre prioriser les choses etc. Comme tu viens de le dire, il y a aussi cette logique de penser produit, ça veut aussi dire penser problème avant de penser solution, donc quels sont les problèmes auxquels je veux répondre avant de partir construire des choses qui pourraient potentiellement ne servir à rien. Mais en même temps, quand tu parles d'une stratégie d'entreprise qui a été définie, on pourrait avoir tendance à se dire, ben en fait les problèmes, la direction de l'entreprise a déjà décidé quels étaient les problèmes et nous on n'a plus qu'à mettre en place. Tu vois ça c'est un discours quand je parle avec mes pères aussi potentiellement que j'ai assez souvent. Donc toi comment tu réagis face à ça une équipe tu vois de PM qui est plus du coup sur la partie aval une fois que la stratégie a été posée et que voilà c'est à deux ans c'est ça notre North Star Metric et que eux se disent ben en fait on n'est plus que des exécutants qu'est ce que tu me demandes de penser au problème le problème il est déjà fixé.

Romain : Alors c'est un sujet qui m'intéresse énormément, donc je donne une formation sur la stratégie produit, et on parle de ça. En gros, pour simplifier, on peut voir le sujet à deux niveaux. Le niveau qu'on appelle stratégique, c'est 3 ans. T'as le niveau tactique qui est 6 mois. 3 mois, 6 mois. ces niveaux sont imbriqués. Donc tu peux avoir une stratégie à 3 ans, et d'une certaine manière une stratégie plutôt tactique, mais ça reste quand même un cadre d'autonomie à 6 mois. Et du coup il va falloir définir ce cadre-là. Donc le cadre, admettons, on prend une scale-up qui est une stratégie à 2 ans ou 3 ans. Donc elle, elle va avoir ses OCR stratégiques, en tout cas sa direction à suivre. Il va y avoir un truc important, déjà ça va être de rendre le truc spécifique, donc pas juste je vais être le premier du marché, mais dire aujourd'hui on a tel segment de clientèle, et c'est ça nos forces, c'est ça nos faiblesses, c'est ça la concurrence, on veut gagner un avantage concurrentiel, voici ce qu'on va devoir changer, voici ce qu'on va devoir arrêter, faire mieux, etc. Donc voilà, là on est sur une vraie direction un peu plus spécifique. Mais derrière, il va y avoir des projets, en effet, qui vont sous-tendre l'exécution de cette stratégie, mais ces projets, on ne va pas aller jusqu'au bout de leur définition. On va dire, pour adresser tel nouveau segment, on va devoir adresser une nouvelle géographie, par exemple. Et une fois qu'on a commencé à détourer ce chantier, il va falloir très vite embarquer les équipes qui, elles, vont proposer un plan un peu plus tactique sur le court terme, en disant, OK, on a entendu la direction, on a bien compris, en effet, make sense, Allons-y, on colle au plan, on est OK, on n'a rien à redire là-dessus, ça fit avec les retours qu'on a du terrain. Maintenant, nous ce qu'on vous propose, c'est qu'on connaît bien le sujet, on a déjà rollout de pays, ça a bien fonctionné de cette manière-là, on pourrait continuer, donc voici ce qu'on vous propose. Donc c'est cette discussion qu'il va falloir opérer. Donc cette partie briefing et ensuite debriefing des équipes qui va devoir avoir lieu. Ça en vrai c'est compliqué à organiser. Et dans le rush de fin d'année, pour être très concret, c'est parfois, ok, la direction a mis du temps à définir son plan, à se mettre d'accord, à s'aligner, etc. Et donc en fait ça devient, ok faites ça, on est tous dans le rush donc on n'a plus trop le temps de... C'est établir ce dialogue en fait qui est compliqué, et aussi établir ce dialogue qui demande un truc, et là je reviens au mindset, c'est la confiance. C'est le truc au fond de tout ça, on n'est pas dans un outil, dans un rituel, dans un machin, on est dans la confiance. Donc c'est en fait à ce que le leadership pense les équipes capables de les guider sur une stratégie opérationnelle ou une tactique. Et ça c'est le début en fait.

Terry : Parce qu'en fait t'as ton leadership pour le coup là qui va identifier plutôt du coup les opportunités business et là où il va emmener la partie business mais ensuite qui va dire bah vous côté côté exécution vous êtes capable de savoir me guider pour aller mettre faire faire rentrer le business qu'on a identifié comme étant le business vers lequel on veut aller.

Romain : Ouais c'est ça et c'est aussi je pense qu'il y a un Alors il y a le sujet de la confiance, il y a le sujet de la bande passante. Donc c'est très souvent, ce qu'on me dit c'est ouais t'es gentil mais mes équipes déjà elles sont à la ramasse sur leur roadmap trimestriel, là il n'y a plus rien qui rentre, ils font du full delivery, ils ont ras la casquette, jamais ils vont pouvoir sortir la tête de l'eau et dire ok nous on pense que pour faire le rollout il faut aller dans telle direction.

Terry : Oui, parce que pour rebondir sur ce que tu dis, parce que souvent ces équipes-là elles ont aussi soit de la dette technique, soit des projets pour le business as usual ou en tout cas continuer à délivrer les clients actuels qui sont considérés comme majeurs parce que sinon on risque de perdre les clients et donc elles se retrouvent un peu entre deux chaises en train de se dire bah oui faut qu'on continue à corriger ces problèmes sinon on perd les clients actuels que l'on a et on est en train de parler d'aller chercher d'autres clients mais j'ai même pas la bonne passante pour corriger les problèmes des clients actuels. Et donc là, comment tu agences ?

Romain : Là-dessus, ce que j'ai souvent, c'est que c'est le serpent qui se mord la queue. Ça, c'est le premier scénario, c'est vraiment ce truc systémique d'enfer, où en fait, la stratégie n'est pas claire, pas clairement définie, donc les équipes n'arrivent pas à prioriser, donc les équipes font trop de choses, donc les équipes sont sous l'eau. Et en plus, comme elles font trop de choses en même temps, et on ne s'est pas bien posé les questions des impacts, elles n'ont pas trop d'impact. Donc les leaders, ils vont se dire quoi ? Attendez les gars, vous voulez réfléchir plus alors que vous n'êtes déjà pas capables de délivrer l'impact qui va nous donner confiance en vous. Donc on est vraiment dans un truc, genre dans une dynamique qui n'est pas la bonne. Et ça, c'est horrible parce que du coup, l'équipe, jamais elle ne va avoir le droit, ou en tout cas, dans cette dynamique-là, jamais on ne va lui donner les clés du camion entre guillemets. Donc là-dessus, nous ce qu'on pousse, c'est de choisir, donc c'est la simplicité. Rémi Guillot, j'adore, qui a fait un passage chez Thiga, lui c'était vraiment son cheval de bataille, et j'y crois vachement, c'est simplifier, choisir les quelques sujets qui vont avoir un vrai effet de levier, et se commit dessus, c'est pas les traiter comme ça, la petite semaine, tiens c'est fait, on passe à autre chose, c'est vraiment, on se commit sur cette thématique, on l'adresse quoi, vraiment, en profondeur. Donc ça c'est un changement, je pense, de mindset, c'est faire moins mais mieux, qui est un truc profond en fait, en termes de comportement. Ça demande de savoir dire non. Et derrière c'est aussi dans le... la structure de l'équipe produit, un levier à prendre, c'est d'ajouter dans la structure de l'équipe des personnes qui ont une philosophie business. Et ça, ça va changer le paradigme dans l'organisation, c'est que ta squad en général tu mets PM, dev et peut-être un designer. Est-ce qu'il y a un PMM, un Product Marketing Manager qui est rattaché à la squad ? Pas toujours. Est-ce que ton PM a un vrai mindset business et pas uniquement je ship des features ? Pas toujours et même rarement. Et donc ça, ça pose des sujets en scale-up. Mais ça va aussi poser des sujets en corpo, parce qu'en corpo, en face, t'as le business traditionnel, briquet de mortards. Dans le retail, tu vas voir les chefs de catégorie, par exemple. Comment est-ce que tu fais travailler un chef de catégorie et un PM ensemble pour qu'ils arrivent ensemble à une proposition ? C'est très rarement le cas, en vrai. Donc tu vas avoir aussi ce levier qui va, en ajoutant des compétences business dans l'équipe produit, à lui donner une hauteur de vue plus grande.

Terry : Et du coup donc très très très clair, les problématiques posées et du coup des axes pour aller les adresser. Toi un peu des retours qui te parlent, qui ont bien marché justement de mise en place, un peu de petites actions, de quick wins, ou peut-être des plus longs, mais que tu as pu voir chez différents clients pour essayer du coup à faire cette transition ou en tout cas l'amorcer et après avoir eu des... Est-ce que tu aurais des retours assez sympas à partager là-dessus, de choses qui ont bien fonctionné pour des boîtes où au départ on pourrait se dire... Ouais.

Romain : Alors premier changement je pense sur cette partie donner confiance et gagner en hauteur de vue. Nous c'était dans une boîte des médias. En gros, c'était un accompagnement à la base sur les OCR. Donc, on est allé dans l'organisation, on a regardé comment les équipes travaillaient. Ce dont on s'est rendu compte, c'est qu'il y avait une forte volonté de mieux maîtriser son impact. C'est-à-dire qu'à Super, on est une delivery factory, on livre des choses, mais derrière, on n'est pas capable de dire ce qu'on a livré a créé un uplift significatif de temps. Ça, c'était un sujet. Et on s'est dit, OK, on va faire deux choses avec vous. qu'il y avait une dizaine d'équipes produits à accompagner, on va mettre en place des aucaires et on va vous aider à mieux maîtriser la mesure. Et donc dans un premier temps, c'était changer un peu la manière dont tu priorises, où tu vas mettre l'outcome, donc la finalité, comme vecteur de ta roadmap. Donc la manière dont tu vas visualiser les choses, ça va toujours être représenter l'impact que tu as envie de créer. Donc ça, ça crée un changement en fait d'état d'esprit. C'est que ton objectif, c'est plus de livrer la feature qu'on t'a demandé, c'est de répondre à l'impact que tu as fixé et que tu as validé avec ton management. Donc ça, ça change un premier truc. Mais pour y arriver, il faut le mesurer. Donc là, parmi les auditeurs de Just Click, je sais pas comment ça se passe, mais c'est souvent un vrai sujet. Et notamment dans les OCR, il y a souvent, en ayant fait pas mal ce travail-là, t'as un peu l'euphorie pendant l'atelier où tu te fais « Ouais, génial, on va mesurer tout ça, ça va être trop bien ! » Et en fait, le lendemain, ta scientist te dit « Non mais vous avez fumé ou quoi ? C'est impossible de mesurer ce truc, ça va jamais être significatif, etc. » Donc il y a ce travail d'intégrer les équipes data dans le travail. Donc ça c'est pas forcément... tu vas pas y penser tout de suite. Donc le premier round tu vas te planter et peut-être la fois d'après tu vas inviter l'équipe data si elle n'est pas déjà intégrée dans tes workshops. Et derrière ça va être d'être capable de créer les dashboards de mesures. Donc ça c'est des choses qu'on a faites et on a vu que ça avait quand même bien changé la dynamique de priorisation.

Terry : Et donc sur la partie mesure, parce qu'effectivement c'est un des gros sujets quand tu penses à outcome-based au lieu d'être sur de l'output, parce que l'output c'est simple, ta feature elle n'est pas là pour le mesurer, mais effectivement ce n'est pas la bonne approche quand tu veux faire du produit. Là, concrètement, la donnée était déjà présente, c'était une question de bien l'agréger ou il a fallu aussi aller mettre des endroits pour faire remonter de la donnée ?

Romain : Il y a eu les deux, oui.

Terry : Et ça, ça s'est fait du coup vraiment main dans la main avec une équipe d'Atta qui avait aussi compris la finalité derrière de faire tout ça.

Romain : Du coup, il faut convaincre, c'est-à-dire de dire, écoutez, nous on a besoin d'un demi-ETP, un ETP, donc équivalent temps plein dans l'équipe, pour nous aider à bootstraper la stack et derrière faire en sorte que le pipe de données soit à jour. En l'occurrence, c'était dans une entreprise assez grosse du secteur public, donc il y avait cet enjeu d'évangélisation.

Terry : Du coup, ça me fait rebondir sur... Tu parles d'évangélisation, donc assez clair là, et merci pour le partage sur cet exemple-là. Sur la partie, donc, pour revenir sur l'évangélisation et la formation aussi des collaborateurs en interne, parce que c'est vrai que là, ceux dont on parle, des personnes qui sont assez ouvertes, qui sont notamment dans des boîtes tech ou qui sont dans les départements tech des entreprises, on va dire que c'est des sujets qu'elles peuvent s'approprier assez rapidement à partir du moment où on leur explique en quelques workshops, en tout cas, l'idée et la philosophie derrière. En revanche, sur des verticals ou des métiers qui sont assez éloignés de la tech, ça peut être plus compliqué de comprendre tout ça, toute cette démarche. Moi, j'ai des exemples qui me viennent en tête, d'expériences personnelles, ou voilà, avoir travaillé avec des commerciaux qui étaient d'une autre génération, qui me disaient, fais ce que tu veux, ton agilité, tes sprints, ce que tu veux, moi je veux que ça, ça sorte à la fin et que mon client est satisfait, c'est ça qui importe. Et du coup c'est vrai que je trouvais ça assez complexe de réussir à expliquer sans non plus passer pour un autre dogme parce que ces personnes-là en général elles ont vu un paquet de transfos digitales dans leur entreprise parce qu'elles sont là depuis des décennies et donc elles se disent bon c'est une énième transfo de toute façon la finalité reste toujours la même, il faut qu'on vende des choses et puis qu'on fasse rentrer de l'argent dans la société. Donc comment toi tu abordes cette question-là de la formation des collabs qui sont peut-être moins tech justement ?

Romain : Oui, carrément. Déjà, il faut s'assurer du fait que tout le monde soit aligné sur le même dictionnaire. Donc, quand tu dis des choses, est-ce qu'on se comprend ? Est-ce qu'on parle de la même chose ? Et aussi, moi je parle en tant que consultant, mais quand tu viens de l'extérieur et que tu te ramènes avec ta boîte à outils et tous tes mots-clés, parfois il faut... Voilà, y aller mollo et reprendre les termes utilisés en interne, bon c'est la base. Ensuite si t'es interne et que t'as envie de mener cette acculturation, en effet ce qui est important c'est de faire des premières phases de sensibilisation, donc pour poser à plat justement le mindset, voilà on parlait de l'état d'esprit, les pratiques, et ensuite je pense faire venir des gens de l'extérieur qui racontent Donc des homologues qui racontent en quoi ça s'est bien passé d'appliquer telle chose et telle chose, de montrer par l'exemple, c'est super important. Donc là, tu fais revenir tes points de vue externes. Et ensuite, c'est dans le changement. Donc si tu as besoin de convaincre, mettons, ta partie prenante de travailler différemment avec toi pour shipper davantage de qualité, ce qui va marcher, ça va être la pratique. Ça va pas être, tiens, tel framework ou tel article de Marty Kagan a dit que machin, non non, ça, ça va pas marcher. Il faut dire, OK, on fait un test. Pendant trois mois, on va tester un nouveau truc. On t'embarque, etc. Et on fait le bilan. Et en général, il y a beaucoup de choses qui changent, en fait. Donc ça c'est un truc à ancrer, c'est qu'on a tendance à s'accrocher au framework parce que c'est logique, c'est bien huilé, c'est bien on a une triforce avec des éléments très précis ou un beau diagramme de veine, etc. C'est bien pour le modèle mental, mais derrière il va falloir il va falloir prouver par l'exemple.

Terry : C'est hyper intéressant parce que t'as mis trois points là qui sont en plein dans le mille à mon sens. Le premier qui est la partie vocabulaire en fait et utiliser les bons mots par rapport au contexte de l'entreprise parce qu'effectivement tu peux vouloir, enfin si tu utilises les mauvais mots tu peux tout de suite braquer les gens alors que c'est qu'une question d'avoir le langage approprié pour expliquer ce que tu veux expliquer. la partie évidemment pratique. Et le troisième point que je trouve hyper intéressant, que j'avais déjà entendu aussi, un des épisodes récents que j'ai partagé, c'était avec Bastien Naudet, qui est coach Agile, qui m'avait fait son retour, que dans certains cas, il faisait venir d'autres équipes, d'autres entreprises, au sein des entreprises qu'il accompagnait, pour leur montrer, pour qu'elles partagent aussi entre elles un peu les freins, les choses qui avaient marché, etc. Et ça je trouve que c'est un peu intéressant quand tu parlais du coup de faire venir ces homologues ou de prendre des exemples de comparaison.

Romain : Et aussi pour ajouter à ce sujet, moi c'est une tendance que je vois actuellement, c'est... En fait je pense que les... Alors l'ayant vécu, je pense que ces 5-6 dernières années, l'enjeu des PM c'était de travailler de manière ultra smooth avec la tech. Tout ça c'était les années 2010. Aujourd'hui on est à un truc où en général je trouve qu'il n'y a plus vraiment de sujet, alors parfois ça peut coincer mais plus pour des questions de soft skills ou de personnes qui ne s'entendent pas bien, mais globalement l'agilité et comment le PM s'intègre là-dedans dans le modèle opérationnel. c'est plus vraiment un sujet. Le sujet, là, il est tes équipes productives, qu'elles sont structurées dans les entreprises, et maintenant c'est comment est-ce qu'elles bossent avec le business. C'est là l'enjeu. Et du coup, les PM, mais j'ai vu là quelques articles popés ces dernières semaines sur les PM arrêter d'être en train de vous regarder le nombril, là, CEO du produit, machin, on se calme, genre vous faites partie d'une entreprise et vous devez aussi acculturer le reste de l'entreprise, ou en tout cas, vous interfacer en fait, et moins fonctionner dans votre coin. Et donc nous c'est un sujet qu'on voit systématiquement. On a beaucoup de directeurs produits qui nous disent que leur enjeu numéro un c'est de mieux bosser avec le business. Donc voilà, c'est cet enjeu d'acculturation, cet enjeu de comprendre aussi pourquoi en fait le product management va apporter plus de valeur à l'entreprise en certains contextes. Là ça va être clé.

Terry : Hyper intéressant, tu fais bien de rebondir sur ce point. Effectivement, j'ai en tête un article et j'ai eu François de Bodinat CPO de chez United qui avait fait un article sur Thiga et qui était venu aussi partager son retour sur le podcast. Exactement ce que tu viens de dire, ce qu'il expliquait c'était que quand tu es CPO, en fait tes clients c'est le board et ce sont les investisseurs de l'entreprise et du coup il faut surtout comprendre leurs problématiques business à eux, comprendre leur P&L, comprendre comment eux derrière vont présenter leurs résultats à leurs investisseurs pour aussi savoir travailler avec eux. et sur les rôles notamment plus head of CPO quoi, là où ceux qui sont plus dans l'opérationnel bah ils se concentrent sur les users effectivement pour délivrer. Là dessus sur la partie du coup faire en sorte que les PM se rapprochent plus du business, donc on voit émerger en France en tout cas pas mal le rôle du product marketing manager, toi c'est quoi un petit peu ton sentiment et comment tu Tu penses que le rôle de PM devrait évoluer ? Par rapport à ce point-là, je te donne un peu ma vision des choses là-dessus. C'est que malgré tout, on va dans des entreprises de plus en plus technologiques, qui ont de plus en plus besoin de construire des produits tech assez poussés, puisque les tech de base, on va dire, On arrive maintenant à avoir des choses sur étagère qui sont très bien, très customisables, donc on va aller vers des sujets de plus en plus poussés, notamment autour de la donnée, autour de tout ce qui est algorithme d'intelligence artificielle, machine learning, tous ces sujets-là qui vont demander aux personnes quand même d'avoir des pas grands de plus en plus, à mon sens, assez technique, ingé, matheux, et en même temps, comme tu l'as dit, pour que ces produits très technologiques puissent être mis sur le marché et bénéficier à leurs utilisateurs, il faut qu'il y ait ce lien avec le business. Donc, le rôle du PM, moi, je n'ai pas la réponse, en fait, tu vois, vers quoi, je ne sais pas si tu l'as non plus, mais vers quoi il va évoluer. Je pense qu'il faut quand même qu'il ait un fort accent technologique, c'est-à-dire que pour moi, un PM, il a besoin de comprendre la tech, et que je ne pense pas que ce soit antinomique le fait d'être capable d'être assez pointu techniquement et d'être capable d'aller vendre. Notamment les boîtes américaines, tu vois on voit parmi les GAFAM, je veux dire ceux qui sont à la tête de ces boîtes là, c'est des ingés qui ont des doctorats parfois. assez poussé sur les sujets technologiques. Toi c'est quoi un petit peu ta vision des choses et notamment sur le marché après français européen ?

Romain : Ça me fait penser aussi à la prise de position de Brian Chesky qui a fait un propos sur les PM en mode j'ai... qui a été compris sous forme de j'ai arrêté les PM alors que pas du tout mais... mais oui carrément bah... Alors j'ai pas frameworkisé la réflexion comme ça là. Moi ce qui me vient à l'esprit c'est que déjà il y a plusieurs trucs à prendre en compte. C'est la place du produit dans l'entreprise, dans le business de l'entreprise. Est-ce que le product, c'est ce qui drive, donc le produit digital, est-ce que c'est ce qui drive plus de 90% du business ? ou est-ce que c'est un truc en plus que l'entreprise suit parce qu'elle doit se transformer, elle doit digitaliser ses revenus, elle doit gagner en satisfaction client sur la Customer Experience et que ça c'est très basé sur du digital, voilà. Mais qu'à côté de ça elle continue à vendre des baskets, des parfums ou des cloisons pour bâtiments, voilà. Donc ça c'est déjà une première question qui est super importante parce que ça va driver je pense pas mal la répartition des rôles et la définition d'UPM et d'où il vient. Pour les premières entreprises, donc entreprises purement technologiques, moi je vois plutôt bien en effet cette évolution d'UPM qui devient très bise mais basée sur une équipe tech qui a une bonne autonomie et une bonne capacité à réaliser les projets. Alors je reviens sur projet produit là, Pour moi, tu construis un produit avec des projets. Et derrière, ce qu'il faut, c'est que stratégiquement, que ce soit sur la stratégie tactique à 6 mois ou la stratégie d'entreprise à 3 ans, il faut savoir itérer, apprendre du terrain, etc. Super important. Mais ça ne veut pas dire que tu arrêtes de faire des projets. En tout cas, cette équipe tech, elle doit être capable de prendre ton projet, le découper, le délivrer de manière prédictible, donc c'est-à-dire on sait s'engager, on sait fournir une date d'atterrissage et à peu près la respecter. Et que du coup, dans ces entreprises-là, le PM peut prendre une facette plus business et owner davantage le business de sa team, quitte à être incentivé sur le PNL, etc. Sur des entreprises où le digital n'est pas le cœur du business, je pense que le PM peut garder cette posture-là, mais va forcément devoir avoir des intervenants, donc des business owners ou des parties prenantes ou autres qui eux portent le business brick-and-mortar de l'entreprise. Et tant qu'il n'y aura pas eu un renversement de situation où le digital devient l'asset principal qui crée du revenu, Tant qu'on n'aura pas ça, je pense que cet équilibre devra rester tel quel. Et là-dessus, je n'ai pas de formule magique, mais c'est juste clarifier et surtout fluidifier les interactions entre PM et Business Owner. Et le PMM peut aider à faire ça, notamment dans des contextes SaaS B2B, PMM fait le lien entre la stratégie sales acquisition et la stratégie produit.

Terry : Et ça ouais, donc très clair et effectivement tu fais bien de distinguer les deux types de sociétés, celles qui sont des pure players comme on dit versus celles qui ont des secteurs du retail qui doivent digitaliser leur expérience parce que c'est pas effectivement la même chose quand t'as un business historique ou quand tout ton business repose sur un produit digital. Donc très très clair. Sur le rôle de PMM, du coup toi c'est quoi un peu le... parce que ce... alors j'ai des épisodes à venir sur ce sujet aussi, mais comment tu vois toi le... cette interaction entre... on parle du PM qui doit devenir donc plus business, en tout cas qui va vers... se rapprocher de plus en plus vers le côté business, et ce rôle de Product Marketing Manager qui est aussi en soi cette interface-là entre un PM qui serait peut-être plus... orienté tech versus un qui serait plus orienté business, je sais pas, toi un peu ton regard là-dessus sur comment est-ce que déjà il faudra... ou ce que t'as pu voir peut-être aussi en cas concret plutôt que de se projeter, ça peut être des retours d'expérience de ce que t'as pu voir.

Romain : Tu veux dire entre le PM et le PMM ?

Terry : Ouais entre le PM et le PMM. Entre le PM en fait plus business et un PMM. Parce que du coup moi je pourrais me dire bah oui mais en fait ça va faire doublon. Tu vois je pourrais dire le PM business il va savoir très bien travailler avec le marketing donc pourquoi on lui mettrait un PMM et en même temps c'est pas pour rien que ce rôle est en train d'émerger donc je suis.

Romain : Curieux d'avoir Je t'avoue que j'ai pas la réponse. Le PMM, à mon avis, sa valeur va être de clarifier le positionnement au produit avec les équipes, je pense Market, Strat et Sales, et faire des tâches qui vont être complémentaires à celles du PM. Après, je pense que ça va vraiment dépendre des contextes et j'ai pas la réponse.

Terry : Comme je le disais, il y a des épisodes à venir sur ce sujet. Par rapport aux retours d'expérience que tu as eu sur des choses qui ont bien marché, tu as partagé sur la culturation des techniques pour aider à culturer des collabs qui n'étaient peut-être pas familiers avec l'approche produit. Maintenant si je prends un point dont on n'a pas trop parlé, quand tu découpais un petit peu les choses que tu voyais dans des boîtes qui fonctionnaient bien versus moins bien, les cas où tu as des boîtes avec une grosse dette technique et qui doivent pour autant accélérer leur développement, la création de business, qu'est-ce que t'as pu voir comme chose du coup qui était complexe à craquer et qui ont plus ou moins marché en fait sur aider ses potes à résoudre leurs problématiques ?

Romain : Le plus complexe c'est que tu as un chantier technique d'ampleur qui va coûter cher, qui va prendre du temps et à côté de ça un business qui continue à tourner. Donc c'est comment est-ce que tu continues à livrer ton service utilisateur et à le faire évoluer, à le maintenir. et en même temps sortir des briques d'un système pour le mettre dans un nouveau. Les erreurs c'est de faire des vœux pieux du type bah oui on va tout freezer, on va recoder tout ça, ça ça marchera jamais, il y aura toujours une pression énorme du business qui fera qu'on devra faire les choses dans les deux systèmes en fait. Donc à mon avis il faut plus l'accepter, mais derrière le piloter. Donc voilà, on accepte qu'on va devoir certains use cases les faire dans les deux systèmes, et on va le sortir bout par bout, en raisonnant la valeur. Donc je pense la plus grande erreur c'est de ne pas piloter ce truc là, de ne pas se mettre d'indicateur et de se retrouver dans une transformation qui dure longtemps, qui fatigue tout le monde et on n'en sort jamais. La motivation baisse, les équipes n'ont plus envie de bosser dessus, plus de visibilité. Et voilà, donc pour moi c'est vraiment un effort de dynamique à créer, parce que c'est des sujets, je pense, la plus grosse problématique, alors t'as les coûts, mais t'as la fatigue des gens en fait.

Terry : Ouais, c'est ce que j'allais dire. La fatigue notamment des équipes tech quand elles doivent abattre énormément de résolutions de bugs pour rattraper toute une dette technique. Et c'est souvent, et ça se comprend venant moi la base du monde de la tech, le fait de dire bah au bout d'un moment, non arrêtez de me demander de nouvelles features, si vous voulez qu'on essuie la dette technique, vous me laissez 3-4 sprints tranquilles pour qu'on puisse vous nettoyer ça, et en même temps t'es obligé de faire tourner le business as usual. Donc là-dessus, je suis curieux de savoir, toi, est-ce que tu as un peu des... Enfin, le premier point que tu as dit, il fait complètement sens de se dire, en fait, il ne faut pas justement rentrer dans cette logique, on freeze, et puis une fois que c'est corrigé, on passe à la suite. Il faut trouver cet équilibre qui est complexe. Ce n'est pas pour rien que ce sont des sujets, de toute façon, qui reviennent, parce que c'est un sujet complexe. Mais du coup dans ce contexte de mise en place de cet équilibre entre correction de dette technique et en même temps servir le business as usual, de choses qui ont bien fonctionné et un peu ce que tu peux toi avec le recul maintenant te dire ah oui c'est parce qu'il y a eu tel ou tel sujet qui a été mis en place qui fait que ça s'est bien passé quoi.

Romain : Y'a un sujet, alors j'en ai pas vécu 15 000, des trucs comme ça, mais j'ai travaillé il y a quelques années chez Voyage SNCF quand ils passaient sur Oui SNCF, donc pour ceux qui ont vécu cette époque où on passe du site un peu old school à Oui SNCF, donc c'était avant SNCF Connect, À ce moment-là, il y a eu un vrai shift à la fois d'expérience utilisateur et de plateforme technologique, et le choix qu'ils avaient fait c'était de découper le parcours utilisateur, et ensuite de sortir petit à petit le funèle, et donc de le passer sur une nouvelle plateforme. C'était piloté, ils sortaient des nouvelles feature teams et ils avaient une core team legacy qui gérait le run. Alors tu avais toujours les complexités de bord qui sont le release management, etc. Mais ils avaient plutôt bien industrialisé l'approche. Je trouvais que ça s'était mieux passé que dans d'autres contextes cette approche là.

Terry : — Ok, très clair. Parce que du coup, comme tu dis, il y avait cet aspect pilotage pour savoir du coup où ils en étaient, ce qui marchait, ce qui marchait pas... — Ouais.

Romain : Après, t'avais un effet de bord qui est que tes squads, ils étaient pas partie du parcours utilisateur. Et donc bon, quand t'es PM et que tu gères la page de résultats de recherche, Au bout d'un moment, tu vois, t'as pas la transversalité du parcours utilisateur, ces choses comme ça, donc ça peut être frustrant sur le long terme. Mais en tout cas, je pense que ce mode d'organisation, il était adéquat pour ce contexte-là. D'ailleurs, ça me fait faire un lien avec le sujet des évolutions des organisations, où en fait, une organisation, ça répond à une stratégie. Et en fait, une fois que tu as atteint ta stratégie ou que tu l'as suffisamment adressée pour derrière pouvoir changer de cap ou fixer un nouveau cap, le changement d'organisation devient nécessaire pour l'exécuter au mieux. Et donc dans ces cas-là, il faut savoir aussi accepter le fait que pour sortir ton projet de décommissionnement, il faut peut-être revoir ton organisation parce qu'elle n'est pas adaptée. au délivrer de ton sujet de sortie du legacy, de réduction des techniques, que sais-je. Donc tu peux mettre une équipe en ownership fort sur un sujet important, plutôt que de le laisser tacler en transverse, parce que c'est là où on va perdre en réactivité. Mais voilà, du coup le message c'est aussi, dans le cadre de projets comme ça, il faut changer l'organisation, l'accepter, et derrière régulièrement revoir si l'organisation est en face des objectifs qu'on s'est fixés.

Terry : Ouais et ça c'est toujours le rappel du coup pour le coup du terrain qui dit bah effectivement quand t'es sur le terrain c'est jamais tout noir ou tout blanc donc tu as une première idée tu dis ça va marcher, ça marche quelques semaines après tu te rends compte qu'il y a des points bloquants, t'ajustes et ça c'est parce qu'on reste sur des sujets qui sont Là où la théorie aide au départ vers quel angle partir, ensuite il faut vraiment s'approprier les choses pour mettre en place des choses qui sont beaucoup plus éloignées peut-être de la théorie mais très proches des problématiques pratiques. Donc là-dessus, très aligné avec ce que tu dis. Ensuite, question, on l'a quand même traité un petit peu là tout à l'heure, mais toi un peu sur les cinq prochaines années, comment tu vois évoluer le métier du coup de product manager, et puis peut-être aussi, à sens un peu plus large, les sujets autour des organisations web produits. Comment tu vois, t'as parlé du coup du CEO d'Airbnb qui avait fait un peu ce poste, qui avait fait qu'il avait expliqué qu'il n'avait pas de product manager mais juste des product designers et qu'il travaillait très bien avec les équipes tech. Ensuite il est revenu en arrière, il a dit qu'il ne voulait pas tuer le rôle de PM. C'était assez marrant de voir aussi la levée de bouclier au moment où il a écrit ça, tous les PM disaient non, non, il dit n'importe quoi. Donc toi, un peu sur les années à venir, comment tu vois évoluer ce rôle qui, on le comprend aussi je pense, De plus en plus, plus on se rapproche de la pratique, plus on voit à quel point c'est mouvant les techniques utilisées, les choses et les outils. Mais derrière, on comprend aussi, je pense, en trame de fond, les soft skills qui sont très importants pour pouvoir être capable d'assimiler ces changements et de les intégrer de manière la plus douce possible dans les entreprises.

Romain : Ouais, donc ce que tu dis est pertinent et tu poses déjà les axes. Alors je t'avoue que je n'ai pas réfléchi des heures sur la question. Je pense, bon là c'est d'actualité et tout, mais si on se pose la question de l'IA et de comment elle va changer le workflow d'un PM et sa répartition de ses tâches, ça peut être un changement majeur d'un point de vue économiser du temps sur certaines tâches, que ce soit de la veille marché, que ce soit de la rédaction de tickets, de collaboration avec les équipes tech, etc. Ensuite un outil, ça va jamais changer, liste of skills du PM et son rôle en fait de leadership au sein de l'équipe. Ça je pense c'est difficilement délégable ou automatisable et donc c'est là-dessus qu'il y a la valeur et c'est en ça à mon avis que ça disparaîtra pas. Après est-ce que demain grâce à Augmenter par l'IA un PM peut gérer une équipe de dev beaucoup plus conséquente voire s'affranchir d'une équipe de développeurs parce qu'avec un prompt qui peut plaire à tout le monde en disant ça. D'ailleurs, je n'y crois pas trop. Je pense qu'il y aura toujours besoin de la même manière d'intervention humaine sur les tâches complexes. Donc voilà, je le vois peut-être évoluer en termes d'impact, de peut-être gérer un périmètre plus grand. peut-être de gagner en transversalité ou en tout cas en compréhension de l'environnement externe parce qu'on peut agréger de la donnée plus simplement, la visualiser plus facilement et rendre la prise de décision plus efficace. Après je ne vois pas des product managers, il y en a depuis les années 70. Je ne vois pas le rôle disparaître. En termes de perspectives d'évolution, et tout à l'heure tu me poussais sur les périmètres tech, mais je pense que tu vas avoir besoin de PM tech aussi profondément, donc moins orienté business mais plus orienté sur l'interne. On a les Platform Team, l'équipe qui va gérer la plateforme technologique, que ce soit une API, une brique métier, au sein d'un système, il faut bien qu'une personne s'en occupe, qui est orientée product parce qu'on va réfléchir à la valeur qu'on va créer pour l'organisation. Ça va être des personnes plus tech qui vont subsister. Moi je vois plus une évolution organique qu'une rupture sur le sujet.

Terry : Très clair, et du coup si tu devais sortir 3 soft skills d'un PM qu'il soit plus business ou plus tech justement, mais que tu pourrais fusionner entre ces deux rôles, quels seraient-ils ?

Romain : Je pense qu'il y a une grosse dose de leadership latérale. Quand t'es PM, t'es pas le manager de ton équipe, en tout cas pas toujours, moi je le vois très rarement. Mettons qu'un PM manage ses devs par exemple, ça peut arriver mais c'est rare. Ton équipe, c'est l'embarquer dans un objectif par l'inspiration, la force de conviction, négociation, et aussi la capacité à donner un cap commun. C'est super dur. Et en externe, c'est communiquer. Et pas fonctionner dans son coin, mais être vraiment team player avec le reste de l'organisation. Parce que PM, t'es dans ton équipe, tu vas avoir d'autres équipes adhérentes avec toi, eux ils ont leurs projets. Le business va te demander des trucs, tu vas pas pouvoir dire non tout le temps, donc c'est faire preuve d'empathie, comprendre et savoir communiquer aussi. Donc ça c'est des skills qui sont ultra clés dans le métier de PM.

Terry : Ça, sur la communication, je ne peux que plus soyer et ne pas hésiter à surcommuniquer. Parce que parfois, on peut avoir tendance à se dire que ça a déjà été dit. Mais je pense que la surcommunication, c'est vraiment une des clés pour réussir.

Romain : Aujourd'hui, je pensais aussi faire preuve de curiosité et d'ouverture d'esprit parce que les outils changent, les technologies changent. Les usages changent rapidement aussi, donc c'est savoir se remettre à la page régulièrement, savoir se remettre en question, savoir accepter que ton projet n'a pas d'impact et qu'il faut passer à autre chose. Donc c'est aussi des choses à ce niveau-là, donc remise en question et curiosités qui sont importantes.

Terry : Très clair, ça fait une bonne liste de soft skills et je partage de toute façon tout cela clairement. Du coup, avant d'aller vers les fins de questions d'épisode, est-ce qu'il y a un sujet en particulier que tu aimerais aborder, mettre un point dessus, tu trouves qu'on n'a pas assez traité ou quelque chose à ajouter par rapport à ces discussions ?

Romain : Ouais, alors je me suis un peu intéressé à l'analyse systémique récemment, donc avec deux bouquins qui sont la cinquième discipline et Thinking in Systems. Alors l'analyse systémique, elle était vachement popularisée avec le traité de Rome, donc dans les années 70, traité sur le climat avec les limites à la croissance, donc on peut pas continuer à croître indéfiniment un système où les ressources sont limitées. Et c'est quoi le rapport avec le product management, tu me diras ? En gros, l'idée, c'est de se dire qu'une organisation ou une entreprise, c'est un système complexe dans lequel il y a des boucles, donc de rétroaction. Parfois, on a la méthode des cinq pourquoi, donc pourquoi, pourquoi, pourquoi, pourquoi. Mais dans certains problèmes, en fait, on se rend compte qu'on tourne en boucle. C'est-à-dire que les effets ont pour cause eux-mêmes. Et ça, tu peux le voir à plein de niveaux dans l'organisation, sur des problématiques de management, sur des problématiques de manque de visibilité sur les objectifs des autres, sur des mécaniques de récompense. Par exemple, une de ces mécaniques, c'est Winners Takes All. La récompense du gagnant lui donne davantage de pouvoir, ce qui fait que ceux qui ne gagnent pas restent à leur niveau. Donc ça, ça peut se traduire dans la société, et ça peut se traduire dans une entreprise. Et donc ces mécaniques-là, je les trouve vraiment passionnantes. Ça ne parle pas de product. Mais ça ouvre vachement l'esprit sur plein de choses, notamment la cinquième discipline qui est en fait la systémique appliquée au management, qui est vraiment passionnante. Et en fait quand tu le lis, tu comprends en fait les OCR et la vision, ça sert à donner un cap commun à des gens, comme ça ils vont avoir des objectifs reliés entre eux, et éviter les guéguerres de périmètre. chose qu'on voit malgré des hockeurs, on peut toujours le voir, mais voilà, tu vas voir ça, tu vas voir le rapport au temps long, donc c'est réfléchir à quelque chose de sustainable, bon là c'est dans l'air du temps avec la crise, mais c'est vraiment ce côté de, en fait, ton win court terme, va falloir s'attacher aux conséquences qu'il peut avoir sur le long terme, et avoir toujours cette vision long terme. Et donc c'est parfois cette problématique qu'on peut avoir entre PM et business, où le business veut sortir son truc pour obtenir ses objectifs Q1, et que toi t'es PM, t'as une vision à 5 ans, et que t'es plus dans cette logique de temps long, de capitalisation, etc. Voilà, et donc je trouve ça passionnant.

Terry : Oui, mais c'est un sujet qui est vraiment passionnant pour faire le lien et là je veux encore plus sortir, même si là on voit complètement le lien, même si ce n'est pas directement lié au product management, mais avec les organisations en général comme tu l'as expliqué. Un autre exemple pour donner aussi du contexte sur l'analyse systémique, dans le cas du coup des sujets de soutenabilité et d'environnement, tout le monde connaît maintenant la plateforme Vinted d'achats à revente de vêtements de seconde main, Mais en fait un des problèmes par exemple qui peut être causé avec cette plateforme là où au premier abord on pourrait se dire bah c'est cool plutôt que d'acheter du neuf j'achète de l'occaz, oui mais en fait vu que ça te revient moins cher et que tu peux revendre potentiellement tu vas plus consommer. Et donc en fait là où à la base l'idée de base était intéressante de se dire bah je vais prendre des vêtements de seconde main pour ne plus acheter du neuf, en fait je vais en racheter encore plus donc je surconsomme donc j'utilise plus d'énergie. Et donc il y a un effet rétroactif par rapport à l'intention de base qui était de se dire on travaille de manière plus circulaire. Et c'est là où l'analyse systémique c'est très très très complexe parce qu'en fait ça touche à tous les systèmes, mais d'où l'intérêt derrière.

Romain : Et je pense que nous, en mission, c'est un truc qu'on utilise notamment pour identifier les effets de levier. Donc c'est-à-dire... En fait, t'interviens dans un système qui est là, qui a ses boucles de rétroaction, comme tu dis, qui a ses effets et tout, ses dynamiques. Et ce qui est important, c'est pas de travailler sur tout. c'est de trouver l'effet de levier qui va permettre de changer la dynamique. Et donc l'exemple que je donnais tout à l'heure autour de la mesure de l'impact, l'effet de levier c'était de reconnecter les initiatives à des objectifs et d'être capable d'avoir cette vraie mesure du feedback, de ne pas faire semblant en fait, de vraiment mesurer le feedback. et souvent dans plein d'organisations, ce qui leur manque pour passer dans un vrai mode produit, c'est d'activer sérieusement la boucle de feedback. Que l'EPM puisse prendre une décision informée sur ce qui l'est livré, il ou elle. C'est rarement le cas.

Terry : — Effectivement, très clair. Merci en tout cas pour ce partage, Romain. Et donc pour aller vers mes deux questions de fin d'épisode, est-ce que tu as une conviction forte avec laquelle, en général, quand tu la partages avec tes pairs, tu te retrouves en désaccord ? Une conviction qui peut être un peu clivante, pas nécessaire d'être en désaccord avec tout le monde.

Romain : C'est la différence entre PM en start-up et PM en corpo, ou en scale-up, ou que sais-je. On parlait de soft skills tout à l'heure. Pour moi, il n'y a pas un monde qui sépare les deux. Je ne crée pas deux mondes, le monde des corpos et le monde des startups. Je parle en termes d'organisation si on revient sur le sujet. Après moi j'aime bien considérer les choses dans leur globalité. Mais voilà pour moi c'est important de se dire que Pour moi, il n'y a pas de séparation entre les deux, et c'est vrai que parfois on a tendance à entendre ces deux mondes très différents. On voit dans la communauté qu'ils ne se parlent peu. Thiga participe à l'organisation de LPC, la product conf. Du coup, c'est ultra, ultra startup, scale-up, écosystème, produit. Alors ça change petit à petit, mais je vois que dans les grandes entreprises, les PM se sont pas forcément fait appartenir à cette communauté, alors que pour moi, ça reste le même métier. Mais ouais, on voit comme ça des effets. C'est assez intéressant de le voir qu'on a des écosystèmes qui se parlent assez peu, alors que pour moi, ils ont plein de choses à échanger et à partager.

Terry : Assez clair pour rebondir sur ce point, moi je dirais que ma vision là dessus c'est effectivement qu'il y a des liens clairement entre les deux jobs, puisque ça reste quand même beaucoup de points en commun, notamment sur la partie soft skill. Après effectivement sur la façon dont c'est exécuté, la façon dont tu vis le job au quotidien, c'est peut-être là qu'il y a quand même des différences assez fortes, dans le corps pot t'as beaucoup de politique, T'as peut-être des aspects sur la partie soft skills qui sont pas les mêmes nécessaires que ceux que tu vas avoir dans des environnements très très rapides qu'on peut trouver dans des startups ou scale-up. Mais de toute manière, à plus échanger ensemble, on peut que tous y gagner. Donc là-dessus, je te rejoins à 100%. Et donc pour aller vers la dernière question, c'est un peu les ressources, les choses qui toi te nourrissent intellectuellement. T'as déjà commencé à toucher du doigt en parlant de l'analyse systémique, et je trouve hyper intéressant.

Romain : Ouais. Est-ce que t'as d'autres points ? Ouais. Alors j'ai lu des bouquins en plus de boulot cette année, mais j'aime bien la littérature aussi, qui permet aussi de sortir la tête du taf et de s'inspirer. Mais là, en termes de bouquins de taf, j'ai lu l'Essentialisme, je crois, de Gregor McGowan. Tu pourras mettre le lien. C'est un peu... C'est un bouquin de... Comment on dit ? de pratiques personnelles sur qu'est-ce qui est vraiment important pour toi et d'arrêter de diffuser son effort dans mille directions différentes et de choisir les sujets vraiment importants. C'est un bouquin qui m'a aidé parce que cette année chez THIGA en interne, j'ai monté cette équipe Orga là. Ça demandait vraiment du focus sur des sujets et tu prends une place dans l'entreprise où t'as beaucoup de personnes qui te demandent plein de choses donc il faut réussir à faire des choix. Moi je suis d'un naturel plutôt à vouloir faire plaisir aux gens. Et donc... Et donc ouais, réussir à garder résolument un cap, et pas se perdre dans les détails. Et j'ai trouvé ce bouquin assez inspirant. Voilà, même si bon, il fait 200 pages, et je pense qu'en 50 pages...

Terry : C'est un bouquin américain.

Romain : Ouais, c'est ça, exactement ! Je pense que GPT-4 te fait un super résumé du bouquin. Voilà, donc ça, ce bouquin, j'ai bien kiffé. Et sinon, j'écoute beaucoup de musique. Et même si c'est pas... Enfin, c'est introspectif en fait. Mais j'aime beaucoup les musiques répétitives avec un peu de... Voilà, qui mettent en trance et je... Je trouve qu'il y a un côté, ça te clean l'esprit bien, voilà, donc aller à un concert et voir un groupe qui joue fort, des trucs répétitifs, moi j'adore. Top.

Terry : Je pense que c'est la première fois que j'ai ce retour-là et je le trouvais hyper intéressant.

Romain : C'est un peu de la méditation en fait.

Terry : Ouais, exactement. Mais je trouve ça hyper intéressant comme point pour s'enrichir. aussi personnellement. En tout cas, je te remercie beaucoup pour tous tes partages Romain, pour ton temps, et puis si des personnes sont intéressées de toute façon par te contacter, est-ce qu'elles peuvent le faire direct via LinkedIn ? Est-ce qu'il y a un forum sur Thiga ou autre, s'ils veulent continuer les échanges avec toi ?

Romain : Ouais, contactez-moi sur LinkedIn s'il vous plaît.

Terry : Top. Merci Romain.

Romain : Avec plaisir.