Valentin Ménard, Quel est le rôle du product manager ?

Transcription de l'épisode : "Valentin Ménard, Quel est le rôle du product manager ?"

Terry : Salut Valentin !

Valentin: Hello !

Terry: Merci du coup de prendre du temps aujourd'hui pour échanger sur ton retour d'expérience chez ManoMano sur une organisation du coup que vous avez mis en place et que t'as, on va dire, conceptualisé, t'as écrit un article, enfin plusieurs parties d'articles sur Medium pour en parler. Donc c'est le framework que t'as nommé Pulse. Donc de mémoire, il y a plus de 70 personnes qui ont contribué à la genèse, on va dire, de ce framework. Et donc l'idée de cet épisode aujourd'hui, ça va être de rentrer un peu dans les détails de ce framework, des apprentissages, d'essayer de challenger un peu tout ça. Et donc avant d'aller dans le vif du sujet, je te propose de te présenter et puis de présenter ManoMano pour ceux qui ne connaissent pas cette entreprise.

Valentin: Ouais ok. Du coup je m'appelle Valentin, je fais du produit depuis à peu près 8 ans. J'avais fait une école de commerce donc pas de base particulière dans la tech. J'avais lancé une startup en sortant d'école. Donc ça s'appelait Needle et c'était une sorte de Mapster spécialisé pour les restaurants. Et comme j'avais aucune base, ça a été vraiment l'expérience où j'ai mis les mains dans le cambouis, que ce soit le code, j'avais fait le wagon, et donc j'ai passé la moitié de mon temps à coder, le design aussi. Et à la fin de ces deux ans, je me suis rendu compte que ce qui me plaisait dans le métier de fondateur, en fait, ce qui me plaisait le plus, c'était toute la partie qu'on appelait Product Management. Et donc là, j'ai rejoint BlaBlaCar avec je pense un peu le complexe de toute personne qui fait les choses par elle-même et qui se demande mais est-ce que je suis pas parti dans une direction totalement à l'ouest et BlaBlaCar avait une super réputation côté produits et des gens qui me fascinaient là-bas donc j'ai rejoint cette expérience là j'étais sur les sujets très orientés design sur la refonte du design system de BlaBlaCar qui faisait un changement de brande et ils commençaient à réfléchir sur un projet de bus, déjà à l'époque, et donc c'était faire des Google Sprints sur quelle serait une expérience de bus faite par BlaBlaCar, comment elle se distinguerait des autres. Et alors il y a eu un gros turnover au sein de BlaBlaCars à ce moment là et j'ai suivi mon ancien manager chez Clustry. Donc là à nouveau très différent pour donner les ordres de grandeur en taille, BlaBlaCars c'était 600 personnes, ma startup on était 4 et Clustry on était une quarantaine. Et là, maintenant, c'est un pilier très axé data science. Donc, on a été une solution d'intelligence artificielle pour aider les grands groupes à faire des mobilités qui soient plus transverses. Donc, si tu es employé de Orange, de SNCF, comment est-ce qu'on te conduit à pas seulement monter très classiquement dans le job de dessus, mais te proposer sur d'autres segments ?

Terry: Et...

Valentin: Ouais globalement donc là expérience très différente et assez intéressant de voir comment est-ce que tu fais du produit quand ton outil, ta proposition de valeur principale c'est des algos de data science où tu n'arrives pas à comprendre pourquoi est-ce qu'ils t'ont donné certains résultats et quand ils font des erreurs c'est complètement absurde. Et donc ça c'est une expérience qui a duré deux ans, on s'est fait racheter par un grand groupe et moi je suis parti à ce moment-là et j'ai rejoint ManoMano. ManoMano pour ceux qui ne connaissent pas, c'est du e-commerce, c'est on pourrait dire le Amazon français du do-it-yourself ou le Laura Merlin en purement digital. Et donc moi j'étais très curieux de cette dimension beaucoup plus business que j'avais un peu moins dans mes expériences précédentes. Parce que si tu vas dans un retailer, ils regardent leur chiffre d'affaires à la demi-journée presque. Et donc j'étais assez curieux de ça et il y avait une communauté produit très forte chez ManoMano. Donc voilà, pour donner les ordres de grandeur, ManoMano ça va être une des plus grosses équipes produit je pense. Il y a une quarantaine de product managers, une équipe tech de plus de 400 personnes, une équipe au global de plus de 800 personnes, 700 millions d'euros levés. Et l'argent qui transite sur la plateforme, on est à plus d'un milliard.

Terry: Et qui a été créé 2013, c'est ça ? De mémoire ?

Valentin: Sans doute, on va fêter les 10 ans dans pas longtemps.

Terry: Donc c'est une très belle boîte française aujourd'hui. C'est vrai que même là, on enregistre dans les locaux. Quand je suis arrivé, c'est une des rares boîtes où je suis arrivé. C'est vrai que c'est ça que je trouve intéressant avec ce retour d'expérience que tu vas partager. Vous commencez à avoir la taille, alors c'est pas un grand groupe mais c'est une belle ETI quoi, et donc une taille assez importante qui parfois pourrait laisser à penser que c'est compliqué derrière de mettre des organisations plus agiles, plus que l'on retrouve dans les startups. et là l'idée aussi de cet épisode en fait c'est que tu nous partages un peu tous ces retours sur comment vous vous avez réussi à en tout cas vous travaillez à mettre en place cette organisation hyper agile autour du produit dans une entreprise qui fait cette taille là c'est à dire que quand tu as plus de 700 du coup non plus de 600 plus de 800 employés dont à peu près la moitié c'est de la tech ça fait quand même une sacrée masse de personnes à coordonner et se dire qu'on arrive à le faire avec des approches assez agiles et surtout assez proches de ce que l'on peut trouver dans des startups. C'est quand même une belle preuve de fonctionnement de ces méthodes-là. Et donc je pense que le but ça va être d'aller dans ce sujet. Donc si tu peux nous parler un peu de Pulse, je te laisse prendre l'angle que tu veux pour rentrer sur le sujet et puis on va le décortiquer petit à petit.

Valentin: Ok, pour reprendre un peu l'angle que tu avais sur la taille de l'entreprise, ce qui n'est pas évident, parce que je ne pense pas qu'on ait autant à agir qu'une startup et je ne pense pas que ce soit souhaitable d'ailleurs. Tu ne peux pas faire des mouvements de balancier aussi importants que dans une startup parce que tu as quand même plus d'équipes qui sont interconnectées les unes des autres, qui ont besoin de visibilité. Là où on a un enjeu par rapport au nombre de personnes, c'est qu'on a des niveaux de séniorité au sein des product managers qui sont très différents, qu'on a des logiques de mobilité interne avec des personnes qui ne viennent pas forcément du produit, qui vont venir dans le produit, mais qui du coup n'ont pas forcément tous les codes du métier. qu'on a pas mal d'interlocuteurs avec nous qui connaissent pas forcément ce métier qui est quand même assez nouveau et pas si clair que ça. Et aussi, dans une boîte comme Manomano, on a beaucoup de produits. On a le produit que tous les clients vont voir, mais on a aussi un produit pour les pros, on a un produit pour les vendeurs, et on a les produits un peu internes sur les back-office pour les gens du marketing qui font les promotions. On va avoir tout le produit qui est pour créer le catalogue et envoyer ses informations. Et en fait tout ça pour dire que moi je suis pas un expert de l'agilité et comment faire en sorte qu'on soit agile à scale. Mon rôle était plutôt par rapport à comment est-ce qu'on clarifie le rôle du produit parce qu'on voyait que ça générait des frustrations tant côté produit que business. Et ce rôle du produit, ce qui renforçait le fait qu'il n'était pas très clair chez nous, c'était justement la diversité des profils qui faisaient du produit, la diversité des profils qui interagissaient avec les product managers et la diversité des environnements dans lesquels faire du produit.

Terry: Ok. Très clair. Et du coup, par rapport à ces différents profils, si tu devais sortir le plus gros enjeu quand t'es arrivé, tu t'es dit il faut qu'on arrive à trouver une solution sur cette problématique-là et puis faire avancer ensuite à partir de preuves qu'on a réussi à répondre déjà à cette problématique et enchaîner. C'était quoi le premier gros problème auquel tu t'es attaqué ?

Valentin: Ouais alors sachant que moi quand je suis arrivé, j'étais surtout dans une démarche, ok Mano Mano va enfin m'aider à mettre des mots clairs sur ce qu'est mon métier. Les problèmes par rapport au flou du métier de Product Manager, je les avais déjà eu beaucoup avant. Voilà, je pense que quand j'étais chez Clustery, donc nous on travaillait avec des clients, donc des très grandes boîtes, et donc les CSM qui travaillaient avec nous avaient une expérience au préalable de ces grands groupes, ils venaient de ces grands groupes. Et donc la culture était très différente.

Terry: Excuse-moi juste pour l'acronyme CSM, du coup pour Customer Support... Success Manager. Success Manager, pardon.

Valentin: Ouais, donc c'est notre équipe client. Et donc c'est des personnes qui n'étaient pas vraiment au fait de quelle est la culture produit. Et on voyait dans nos interactions que ce n'était pas simple en fait. Toute la démarche très naturelle pour quelqu'un du produit qui est, ok, maintenant que tu as une solution, on va essayer de trouver quel est le besoin sous-jacent et on va trouver la meilleure solution donnée. Eux, ils vont arriver et ils vont dire, écoute, on est prestataire de service, on a quelqu'un qui nous demande quelque chose, en fait on exécute. Et ça je pense que beaucoup de gens peuvent se retrouver dans ces situations sans pour autant être dans du SaaS avec des grands clients mais juste avec des business stakeholders. Donc cette notion de c'est quoi un PM, c'est quoi ses grandes responsabilités, c'est quoi sa mission, pour moi le flou il était là bien avant d'arriver chez ManoMano. Et pourtant j'avais été dans des écoles produits assez fortes, notamment Blablacar. Donc quand je suis arrivé chez ManoMano et toute cette communauté, donc il y avait Pierre Fournier, Amandine Dur, des Clément Caillol, Sébastien Courtois qui sont passés par là, qui ont quand même vachement influencé la culture produit, j'avais surtout des attentes de clarté. Et ce que j'ai vu, c'est qu'on avait une culture côté produit à appliquer un peu by the book les process Marty Kagan. et que ça créait des frustrations chez nos interlocuteurs côté business qui avaient commencé un peu à s'empiler et les grandes frustrations c'était c'était ok les gars vous êtes très rigides sur ce côté avant de délivrer il faut faire une discovery hyper cadrée, hyper claire, hyper fournie Et ce qu'ils nous disaient c'est, bon, ça fait dix ans qu'on fait du e-commerce, c'est notre réculteur qu'on avait, ils nous disaient, ça c'est de fonctionnalité, juste le fait de mettre des produits complémentaires, c'est juste un basique, on va pas commencer à réinventer la roue, à faire trois mois de recherche utilisateur, juste pour retomber sur la même conclusion que tout le monde. Donc je pense que eux, quand ils voyaient notre méthodo, ils avaient vraiment cette incompréhension et ce sentiment qu'on était déconnecté du terrain et du pragmatisme.

Terry: Parce que du coup là, ce que tu expliques, c'est que la culture produit qui était déjà en place au sein de ManoMano, elle a été aussi mise en place au fur et à mesure du coup que l'entreprise a grandi, mais qu'elle a grandi aussi par la tech, et que en grandissant, ManoMano a aussi attiré des profils venant peut-être de milieux, comme tu le décrivais avant, qui étaient moins tech, où les cultures produits étaient moins fortes. Et donc c'est là où il y a eu en interne, j'imagine, plus de friction ou en tout cas, comme tu viens de l'expliquer, des gens qui sont très product driven, qui appliquent les principes à la lettre de Marty Kagan versus des personnes qui n'ont pas du tout cette culture-là et qui comprennent difficilement parfois qu'on fasse de la discovery, comme tu viens de l'expliquer, sur un sujet où, en gros, il n'y a plus à démontrer que c'est la bonne méthode de le faire. Et c'est un peu à ce moment, enfin c'est comme je le comprends, ce que je comprends c'est que c'est un peu à ce moment, je sais pas si on peut dire charnière, mais en tout cas à ce moment de bascule où t'as une taille d'entreprise où tu commences à attirer pas mal de talents qui viennent de mondes assez différents. et en même temps un cœur de l'entreprise qui est très data et product driven et comment t'arrives du coup à reconnecter ces deux mondes. C'était aussi ça, alors je te laisse me corriger mais c'est comme ça que je comprends que ça a été un de tes challenges à ce niveau là et la raison pour laquelle tu as travaillé sur Pulse.

Valentin: En fait, la raison pour laquelle j'ai travaillé sur ce sujet, c'est que j'étais très attiré par cette conception produit très carré sur les principes, mais je voyais que d'un point de vue pragmatique, ça créait des problèmes avec nos équipes business qui, elles-mêmes, aussi étaient pragmatiques et de bon niveau. Et donc, je me disais, en fait, ce cadre théorique qu'on voit beaucoup, Peut-être que dans les faits, il ne marche pas si bien que ça ou qu'il faut l'adapter. Donc, je n'étais pas forcément dans une logique de me dire, bon, les gens qui viennent du business, ils ont tort. C'était plutôt, ok, super, c'est un rôle qui est flou. On a des principes assez forts, mais déjà, il y avait quelque chose qui m'embêtait un peu, c'est que en tant que product manager, on passe notre temps à dire, ne me donnez pas une solution toute faite, donnez-moi votre besoin et après, j'arriverai avec des solutions. et on arrivera ensemble avec des solutions la plus pertinentes. Alors que dans le fait même de définir notre rôle, si tu demandes à un project manager c'est quoi ta mission et donc c'est quoi le besoin auquel tu réponds dans ton organisation, c'est pas forcément si clair que ça. Par contre si tu lui demandes c'est quoi les principes qu'il faut faire, et bien là on va te donner plein de principes. Et donc je me disais, on travaille un peu à l'inverse de ce qu'on connaisse quand on fait du produit. Et donc j'avais un peu ce truc qui me trottait quand même dans la tête. Et vu que ça faisait longtemps que j'avais un peu l'impression d'errer dans un flou sur le métier de Product Manager, je me disais, là, le fait qu'il y ait un débat sur des choses aussi cœur, c'est ce qui va permettre de définir les contours.

Terry: Ok, très clair. Et donc parmi ces contours, donc le premier ça a été Pulse pour, alors là je prends mes notes parce que... Passe !

Valentin: Ouais alors Pulse en fait ça arrive presque à la fin, au sens où l'objectif majeur c'était comment est-ce qu'on arrive à clarifier en une phrase c'est quoi le rôle du product manager, c'est quoi les grands principes qui globalement semble guider ce métier et enfin comment est-ce que de manière très pragmatique j'arrive à les mettre en place dans mon quotidien et c'est là où Pulse intervient et au fur et à mesure des entretiens ce qui est arrivé très nettement c'était que pour arriver à une conception claire du product manager fallait se détacher de certains mythes et ces mythes C'est des principes selon moi erronés de ce que devrait être un product manager et tant qu'on les a en tête... ça nous empêchait de voir clairement quel était notre rôle. Et les cinq mythes, du coup, c'est tout l'article 1. C'est le côté, le product management, c'est user-centric. Le product management, c'est de l'innovation. Le product management, c'est du long terme. Le product management, c'est de l'incertitude et on ne peut pas donner de visibilité. Et le cinquième, forcément, il m'échappe, mais bon, on le trouvera dans la discussion.

Terry: Juste avant de revenir sur ces 5 mythes, ce que tu expliques c'est que pour trouver une solution à cette problématique de définir le rôle d'OPM, tu as adopté, tu l'as dit un peu en filigrane, les interviews donc en fait en interne dans l'entreprise, ce que je disais en intro, tu allais parler avec un peu toutes les fonctions, ça m'intéresse de comprendre aussi comment tu as conduit un peu cette recherche toi en interne, comment tu as mené ta barque pour justement après en arriver à...

Valentin: L'idée c'était d'essayer d'appliquer une méthode produit à cette problématique.

Terry: Et...

Valentin: Donc concrètement moi c'était partie aussi d'une exploration un peu individuelle où je me disais bon bah je vais essayer de garder un cap parce que je vois que les choses elles bougent je vais essayer de garder un cap sur c'est quoi être un bon product manager et donc je vais commencer à parler avec les gens vraiment seniors que je connais bien en produit pour leur demander les deux questions les plus importantes c'était c'est quoi pour toi en une phrase la mission du PM et c'est quoi les grands principes qui l'enregistrent.

Terry: En interne là du coup ?

Valentin: En interne ouais. Et donc là j'ai fait une dizaine d'interviews et je me rendais compte que c'était pas simple d'arriver à avoir des réponses, que ça faisait réfléchir beaucoup les gens. et que tout le monde avait une réponse différente. Ensuite, j'ai tendu en allant discuter avec d'autres gens assez seniors, avec d'autres sensibilités dans d'autres boîtes. Et donc là, il y a eu chez Péfitte Michel Ferry, il y avait chez Blablacar Rémy Guyot, chez Malte Fred Tan, donc j'ai essayé de... Martin Boudge chez Doctolib, donc essayer d'avoir une vue un peu plus globale et progressivement je me suis dit bon bah en fait cette définition elle n'a pas l'air d'exister Donc je vais essayer de me la créer pour moi. J'ai continué à interroger les gens. Au bout d'un moment, ça s'est su en interne que je faisais ça et on m'a demandé d'en faire un audit plus complet et être vraiment représentatif. J'ai interrogé des gens en produits à tous les levels de la hiérarchie, de associés de PM à VP Product, et en essayant d'être représentatif sur tous les scopes. Parce que typiquement, quelqu'un qui est Product Manager sur la partie catalogue qui est très back, il n'y a aucune interface. C'est quoi le point commun avec le PM qui s'occupe d'améliorer le taux de conversion par exemple du panier d'achat ? Donc ça, ça a été la première phase. Et donc à la fin de cette première phase, je l'ai présenté au Head of Product, au VP Product. Et eux, leur conclusion, c'était OK, ça nous va. En revanche, on est dans une logique d'entreprise où on cherche à améliorer la collaboration entre les équipes business et produits. Et du coup, il faut s'assurer que la vision qu'on a de notre métier, elle colle aussi avec la vision que le business va avoir de notre collaboration. Autrement, on va juste avoir un framework théorique qui va servir à rien et qui va rester sur une étagère. Et donc là, j'ai commencé un deuxième audit. Le premier a dû durer aux alentours de 4 mois, le deuxième à nouveau 5-6 mois, je dirais. où là j'ai interrogé aux alentours d'une quarantaine de personnes, et à nouveau même démarche, du bas de la hiérarchie jusqu'à tout notre comex, nos fondateurs, tout le comex a été interrogé individuellement pendant 45 minutes. Et à nouveau, tous les pôles de l'entreprise sont représentés. Enfin, quand je dis tous les pôles, c'est tous les pôles au sein des équipes business. Parce que vraiment, là où il y avait un flou dans notre conception du métier, elle était entre le business et le produit. Je n'ai pas essayé de traiter le rôle entre le produit et la tech, ou le rôle entre le produit et le design. Nous, la zone de flou a été vraiment là. Et à la fin de ces deux audits, j'en ai fait une conclusion globale et qui a été présentée progressivement aux équipes produits, design, tech, business, notre équipe agile et notre e-team. Et donc, au fur et à mesure, globalement, c'était très enthousiaste, quoi, les conclusions et les retours. Et au fur et à mesure, je peaufinais un peu les conclusions, surtout avec les trois articles que tu as vus, qui étaient une manière d'aller vraiment au bout du bout de la démarche, en disant exactement qu'est-ce que ça veut dire, là où une présentation, ça peut avoir du flou. Donc jusque dans les articles, qui font à peu près une trentaine de minutes tout au global, il y a une trentaine de personnes qui ont fait des retours pour ajuster exactement ce qu'on voulait dire.

Terry: D'accord, donc même sur la com externe qui a été faite sur les articles sur Pulse, tu as fait cette approche un peu collaborative pour t'assurer aussi que le message que tu passais à l'extérieur était cohérent avec ce que les personnes avaient compris en interne.

Valentin: Oui, parce que le message externe, il avait deux objectifs. Le premier, c'est que tu es toujours plus exigeant quand tu communiques à l'externe qu'à l'interne. Donc ce message qu'on partage à l'externe, c'était aussi ça qui allait nous servir en interne. Et le deuxième point, c'est de voir aussi l'accueil qui lui est réservé, quels sont les retours qu'on a pour itérer sur ce framework et améliorer encore notre connaissance produit avec l'externe.

Terry: Yes, très clair. Et donc pour rentrer vraiment dans le concret des différentes solutions auxquelles vous êtes en train de travailler, qu'est-ce que... Donc tu disais PASSE, l'acronyme PASSE, pardon. pulse l'acronyme il vient la fin parce que c'est un peu pour on va dire avoir un effet un peu dont on se souvient de qu'est ce que c'est mais mais malgré tout dans chacun de chacune de ses premières lettres tu tu as différents différents inside différentes choses que tu as trouvé que vous cherchez à améliorer Donc si on devait les découper, alors je ne sais pas si tu veux les prendre dans l'ordre de P, U, L, S, E ou dans le désordre, peu importe, mais pour voir un peu dans chacun de ces mots, ce que toi et avec les équipes chez ManoManos, sur quoi vous travaillez pour améliorer cette collaboration, pour améliorer la compréhension et du coup l'alignement plutôt de qu'est-ce que c'est qu'un PM pour faciliter ensuite la collaboration et le travail du PM au sein de la boîte. Est-ce que tu veux commencer avec Pass ou avec Uncover ou Line Up ou Supplement, Unvision ?

Valentin: Non, l'intérêt justement c'est de les prendre dans l'ordre. Peut-être pour redonner un peu de contexte là-dessus, Le risque qu'on arrive en tant que Product Manager, c'est qu'on a plein de principes en tête qui sont assez propres à la culture digitale et on a des gens en face de nous qui ne comprennent pas totalement. Typiquement dans le digital, on a quand même cette faculté de pouvoir itérer très rapidement. Quelqu'un qui vient du secteur de l'automobile, par exemple, si tu te loupes dans le lancement, c'est une catastrophe industrielle. Si tu as fait un modèle, les gens n'aiment pas la forme, ou tu as des erreurs techniques, les freins ne marchent pas aussi bien qu'ils devraient, tu as fait toutes tes chaînes de production, tu as des problèmes, tu dois tout rapatrier ou ça ne se vend pas. Et c'est pas comme si tu pouvais changer et dire ok tout va bien. Et donc t'as des profils qui peuvent avoir comme caractéristique principale de se dire ok bah en fait je fais un plan à trois ans par exemple, hyper chiadé, et après on lance une fois qu'on a fait le plan. Parce qu'ils sont obligés de le faire dans ce genre d'industrie. Chez nous, c'est très différent. Si tu lances quelque chose et tu te rends compte que les gens n'aiment pas trop, tu peux ajuster le cap. C'est pour ça que quand on parle du Lean Startup, si ça s'applique aussi bien au digital, c'est que vu que tu as cette capacité à ajuster ton cap, plutôt que de faire un plan d'ensemble dès le début, tu vas essayer de crash tester chacune de tes hypothèses au moment où tu avances et donc ton chemin évolue au fur et à mesure de tes réceptions clients pour être sûr que tu colles à leurs attentes et ça typiquement pour moi c'est un des trois grands principes amenés par le digital où en tant que product manager tu te sens un peu responsable d'avoir cette philosophie C'est pour ça que quand on parle de culture produit, parfois j'ai l'impression que c'est la culture digitale dont sont particulièrement au courant les product managers qu'ils essayent de faire respecter ou ils essayent d'éduquer. Le deuxième, c'est que tout ça s'est permis parce qu'on a une capacité de traquer qui est sans précédent. Ce qui permet de voir si tu colles bien aux attentes, c'est parce que tu es capable, nous, sur une product page, Si on fait un AB test entre deux versions où il y a un bouton un peu différent, à 0,5% de conversion, je suis capable de dire que celle-là marche mieux. Et du coup, les utilisateurs ont l'air d'être plus intéressés par ce genre d'informations que par celle-ci. Et ça, aucune autre industrie ne peut rêver d'avoir un truc pareil. Parce que tout ce qu'on fait laisse une trace et qu'on a ces capacités à isoler vraiment deux groupes de grande ampleur. Et le troisième point, c'est une culture traditionnellement axée utilisateur en se disant, il y a des économies d'échelle qui sont tellement fortes en produit, en digital, que certes tu as un coût fixe important quand tu crées le site, néanmoins chaque utilisateur qui vient en plus, ça ne te coûte pas grand chose. Donc il y a un enjeu d'être très centré utilisateur, d'être très conscient des besoins utilisateurs, Parce que c'est ça qui va pouvoir te faire une grosse croissance de ta base d'utilisateur et de faciliter la monétisation pour la suite et de capturer des marchés et tout. Ce qui fait que souvent les product managers ils ont ça aussi en tête de, ok comment est-ce qu'on optimise pour l'expérience d'utilisateur parce que ça peut ouvrir des opportunités gigantesques plus que dans d'autres industries. Donc je crois que déjà, il y a une difficulté quand tu arrives en tant que PM et que tu as lu tous ces livres, que tu as été éduqué à tout ça, et que tu baignes avec des gens qui n'ont pas forcément cette culture de « ok, je veux tout mettre d'un coup ». Et typiquement, les utilisateurs, on ne peut jamais savoir exactement ce qu'ils ont en tête, on peut faire plein d'hypothèses, mais le plus simple c'est de discuter avec eux. Et donc, Du coup, le piège en tant que PM, c'est de vouloir tout changer et de rentrer presque dans un conflit de vision et de culture avec nos stakeholders et que ça se transforme rapidement au clash parce qu'on a des visions très différentes de faire les choses. Mon point typiquement c'est quand t'arrives dans une équipe, et c'est là où on en arrive à Pulse, t'arrives dans une équipe ou dans une nouvelle entreprise, c'est très fréquent qu'ils attendent un PM depuis plusieurs mois, qu'il y a une liste de fonctionnalités qui s'empile, Et eux, leur première attente, c'est qu'on a du mal à interagir avec les développeurs, la communication n'est pas fluide, il y a pas mal de bugs qui arrivent en prod dès lors qu'il se passe des choses. Est-ce que vous pouvez nous aider à fluidifier ? Et que toi tu arrives, et c'est ce que j'ai pu faire dans le passé, avec ok ok les gars en fait c'est pas comme ça que ça se passe on va essayer d'abord de poser une vision de bien comprendre tous les problèmes s'assurer qu'on fait bien les bonnes solutions en comprenant bien l'utilisateur et en fait tout ça ça te met un process assez long pour arriver à faire les choses by the book et en attendant il se passe rien il n'y a rien qui se délivre vraiment et tu ne leur résout pas leurs problèmes et eux te disent mais les gars juste vous n'êtes pas pragmatiques et toi tu leur dis les gars vous n'êtes pas carrés dans votre manière de faire les choses Et le risque de cette confrontation, c'est qu'en tant que PM, le plus grand risque pour moi, c'est que tu te lasses. Et je dis bon, vous savez quoi les gars, vous voulez pas comprendre cette manière de faire du produit, et bah je vais juste être le passe-plat, je prends vos idées et je les mets aux devs. Et en fait, vu que personne n'a vraiment d'attente sur le métier de produit, très bien, tout le monde est content de moi. et je suis bien payé, je suis pas stressé et tout va bien. Et le risque de ça c'est que toi en tant qu'entreprise t'es pas en train d'optimiser l'impact que tes PM pourraient avoir et toi en tant que PM intellectuellement c'est pas très stimulant. Donc le Framework Pulse, c'est comment est-ce que tu arrives à mettre en place les meilleures pratiques produits sans t'épuiser ou sans te perdre en chemin, sans abandonner. Et ça, en arrivant à apporter de la valeur progressivement autour de toi, à tes stakeholders, à ton contexte, aux métriques que tu vas faire bouger. Le but infini de Pulse c'est à la fois d'aider les PM à se rendre compte de tout l'impact qu'ils peuvent avoir, à séquencer leurs progressions et aussi à éduquer les business owners pour qu'ils comprennent que En fait c'est pas quelque chose d'abstrait, de rigide, c'est juste voilà comment à chaque étape votre partenaire produit va pouvoir aider dans le fait que vous, vos objectifs business, vous allez les atteindre mieux, plus rapidement par exemple. Et je crois que ce qui est important avant même de parler de Pulse, c'est de garder en tête la mission du PM. Le PM c'est d'aider, c'est de conduire les évolutions produits vers les objectifs de l'entreprise. Et ça peut paraître basique de dire ça, mais en fait, c'est quand même le cadre de base. Et tant qu'on n'a pas cette mission en tête, je pense que c'est ça qui peut nous rendre rigides parce qu'on se perd dans des principes. Justement parce que je pense qu'on a peur en tant que PM de ne pas être un bon PM. Et vu qu'il n'y a pas de cadre clair, on se rattache toujours aux principes.

Terry: Et ça c'est un bon point. Souvent je pense que quand tu n'es pas clair sur ce pourquoi tu bosses, tu essaies de te rattacher sur des méthodes qui seraient la méthode pour bien faire ton job mais sans vraiment savoir à quoi ton job sert. Et donc c'est le pire en fait puisque déjà tu deviens dogmatique et en plus de ça tu sais pas vraiment pourquoi tu l'es. Donc là dessus je te rejoins totalement. Donc ce que tu dis là c'est concrètement avant même de parler framework, méthode, etc. reposer clairement quel est le rôle, mais au sens assez macro, du PM, donc comme tu disais, permettre du coup aux produits de servir une vision business. Et ensuite, là où les frameworks interviennent, et notamment Pulse, c'est plutôt sur comment tu mets ça en musique, comment tu l'implémentes ensuite. Et ce que je retiens aussi de ce que tu viens de dire en intro sur ça, sur Pulse, c'est l'aspect très progressif de la manière aussi dont tu l'as mis en place et dont tu recommanderais je pense de mettre en place, que ce soit ceci ou un autre, mais d'essayer d'insuffler un peu plus de culture produit dans des équipes qui ne l'ont pas parce que Effectivement sinon tu prends le risque de te braquer et du coup c'est complètement contre-productif pour tout le monde. Donc cet aspect progressif je pense que c'est un vrai point parce que si dans des organisations de produits ou même dans des organisations de dev qui pourraient reprocher des fois d'être trop justement perturbés en permanence par des besoins business aux dernières minutes, donc ils vont venir te dire ben nous on fait du scrum en sprint de trois semaines et tu m'en veux pas pendant trois semaines au moins je peux faire du code propre ou ce genre de choses. Souvent quand tu as ce type d'un peu de friction c'est justement parce qu'il y a un problème sur une vision plus globale de qu'est ce qu'on fait, pourquoi on le fait et ensuite où on va parce que en soi, là je prends l'exemple des devs parce que c'est quelque chose qui me parle mais changer quelque chose durant trois semaines sur ce que tu avais prévu de faire trois semaines avant, c'est pas dramatique si la manière dont c'est amené elle est pertinente et si on t'explique pourquoi tu dois le faire et si tout le monde est aligné en fait sur cette même vision. Mais par contre ce problème de réussir à aligner les gens vers où on va, comment on y va, enfin déjà vers où on va et ensuite de travailler sur le comment on y va. Mais ce que tu dis c'est déjà de bien savoir vers où on va et ensuite on travaille sur comment on y va.

Valentin: Ouais et là je parle même de, c'est même pas savoir vers où on va en tant que scope mais en tant que méthodologie pour mieux traiter ce scope. Et c'est aussi, je pense qu'il peut être dur pour un PM, j'ai l'impression comme s'il y avait un gap énorme entre t'es un chef de projet et t'arrives, il y a les gens du business qui te donnent quelque chose et tu le transformes dans des fonctionnalités. C'est comment est-ce que tu passes de ça, qui est le delivery manager, à la version un peu full stack de Marty Kagan où tu as l'impression c'est bon j'ai une vision et tout découle sur les grands KPI. Et le but c'est de le décomposer en étapes aussi pour que tu te rendes compte de quelles sont les briques de valeur que tu apportes. Et pas un empilement de principes mais vraiment un empilement de briques de valeur.

Terry: Ok et donc aujourd'hui là vous fonctionnez comment concrètement si je vais un peu décrire les interactions entre les différents types d'équipes donc t'en a mentionné un peu tout à l'heure les typologies d'équipes, les typologies de product manager et du coup leur rôle en fonction de ceux qui sont très orientés je sais pas sur la partie conversion et d'autres beaucoup plus sur une partie back office comment elles sont structurées les équipes aujourd'hui chez Manohan ?

Valentin: Alors sachant que du coup ce framework donc là on a créé l'alignement en janvier donc c'est vraiment récent et on est encore dans la phase de diffusion auprès de toutes les équipes et de réfléchir à comment est-ce qu'on met en place avec les équipages. Il n'est pas encore mis en place et je peux pas dire du coup on a mis ça et ça cartonne pour telle telle raison. Mais traditionnellement, nos équipes fonctionnent... Juste avant.

Terry: Que tu expliques comment elles fonctionnent. Donc l'idée, si ça te va, c'est que tu expliques comment là elles fonctionnent et que tu pointes du doigt un peu ce que vous espérez peut-être faire changer. Comme ça, ça fait un bon parallèle pour expliquer aussi là ou par rapport à votre fonctionnement actuel, l'approche que vous avez un peu théorisée autour de tes différentes interviews et les différents ateliers que vous avez faits. pourraient apporter des solutions là où aujourd'hui vous voyez des problèmes ?

Valentin: Je crois que le plus gros enjeu c'est qu'elles fonctionnent toutes différemment. C'est que tout PM a sa propre vision de ce qu'est un product manager et de ce qu'il est censé apporter comme valeur. Et donc tu peux avoir des équipes qui vont être très orientées et délivrées, sans se dire qu'elles peuvent aller beaucoup plus loin, et d'autres qui vont vraiment essayer de co-construire la vision avec le business, voire des... alors ça c'est le piège inverse, qui vont créer leur vision presque unilatéralement et qui vont l'imposer. Donc il y a quand même eu un énorme travail des équipes agilistes pour arriver à homogénéiser certaines choses. Donc on a tous les quarters, ce qu'on appelle un PI planning, qui est chaque équipe s'aligne avec tous les interlocuteurs, donc design, tech, data, business et produits, sur quel va être notre roadmap, donc quels sont les gros sujets à la fois de delivery qu'on va faire, et les gros sujets d'exploration qu'on va faire. Et les sujets d'exploration vont nourrir ensuite la roadmap suivante.

Terry: Ok mais du coup vous faites du safe du coup ?

Valentin: Ouais alors c'est un safe qui est adapté. Donc à chaque quarter on iter sur le process, mais l'inspiration de base c'était safe.

Terry: D'accord ok. Et donc aujourd'hui par rapport à CPI Planning et derrière la déclinaison sur le trimestre suivant, quels sont les axes d'amélioration sur lesquels vous allez essayer de travailler sur l'année qui vient ?

Valentin: Pour moi, c'est plus simple de parler à l'échelle micro. Si je prends une FT, une personne, comment est-ce qu'elle peut s'améliorer ? Et après, on peut voir ce que ça veut dire d'un point de vue macro. Mais si on prend justement le framework Pulse, appliqué à une équipe, nous du coup, il y a une équipe, son enjeu c'était justement d'arriver à passer outre ce côté juste pass. La première étape chronologique c'est PaaS. Donc PaaS c'est juste le passe-plat entre le business et la tech, qui déjà apporte de la valeur. Ça veut dire que, imaginons avant il n'y avait pas de dev, c'est ce qu'on disait, la communication n'est pas toujours simple entre le business et la tech, mais aussi le business et le design, chacun ont aussi des langages un peu différents. que la manière du coup ensuite de checker que les fonctionnalités marchent bien, tu peux laisser passer beaucoup plus de bugs. Donc, il y a une valeur d'un PM qui arrive à déjà fluidifier tout ça, à être ce pont entre ces univers, en s'assurant que tu prends tous les edge case en compte, en étant assez clean sur la délivery, en arrivant à anticiper la roadmap, comment ça va arriver et du coup donner de la visibilité aux gens du business. et ensuite à faire le follow-up de la fonctionnalité, qui est presque la phase advanced de cette première phase passe, mais qui est cette fonctionnalité, elle a marché, elle n'a pas marché, on continue d'y tirer dessus, ou on accepte, ou on kill. Et donc ça, c'est typiquement ce dont Marty Gagnon appelle les delivery team. Et là, tu es un project manager. Mais je veux quand même insister, tu apportes déjà de la valeur. Et ça, c'est en tant qu'intégration dans une nouvelle équipe, potentiellement, c'est de ça dont ils avaient besoin dans les premières semaines, voire premiers mois où tu arrives. Et donc, il ne faut pas le vivre comme un complexe de « je fais mal mon taf, je suis un mauvais PM ». Non. En fait, tu résouds le besoin qu'ils ont à ce moment-là.

Terry: Et tu gagnes en confiance et en légitimité vis-à-vis de l'équipe aussi en question.

Valentin: Exactement. Et il faut quand même se dire que nous, notre matière première, c'est quand même la collaboration. On n'arrête pas de le dire, on est au croisement de la tech, du design et du business. Donc, si tu veux être au croisement, il faut que tu arrives à créer de la collaboration et de la confiance. Et donc si t'arrives tout de suite dans une logique confrontationnelle en mode, ouais ouais vous avez vos sujets mais en fait les vrais trucs c'est d'arriver avec une méthode au clair, en fait tu mets en danger ce que t'as de plus précieux. Et donc voilà, donc là tu crées progressivement ton capital confiance. Ensuite t'arrives à la deuxième étape. Donc la première étape, t'as été capable de shipper une solution, t'as été capable de shipper une fonctionnalité par rapport à une solution qu'on t'a donnée. Deuxième étape, tu vas chipper une fonctionnalité, parce que notre taf, c'est de chipper des fonctionnalités. On peut dire ce qu'on veut, mais un humoriste, son taf, c'est de faire des blagues. Tant mieux, les gens, ils se sentent mieux. Mais dire, mon job, c'est que les gens se sentent mieux, oui, en faisant des blagues. Nous, c'est d'atteindre les objectifs de l'entreprise en faisant des fonctionnalités. Parfois, on en réduisant, mais sinon, tout est du produit. Parfois, j'entends, oui, en fait, quand tu fais une newsletter, c'est du produit. Non, c'est le marketing qui fait sa newsletter. Tout le monde cherche à améliorer les objectifs de l'entreprise. Et nous, c'est via les fonctionnalités.

Terry: Ouais, c'est intéressant. Avant d'aller sur l'autre étape, du coup, ce point-là, je comprends ce que tu dis. C'est vrai qu'à vouloir parfois trop tout sur-conceptualiser et sortir de son contexte, on peut effectivement appliquer des méthodos. Quand tu tires jusqu'au bout la chose, tu peux dire, oui, je fais du produit dans tous les cas, peu importe le domaine d'activité, et ça va aussi sur d'autres sujets. et parfois ça peut être du coup dangereux parce qu'on en oublie les fondamentaux de quand même quel est un développeur même alors si jamais Rudy écoute ça va pas lui plaire ce que je vais dire mais un développeur il doit quand même malgré tout coder et son rôle c'est pas de passer des heures et des heures à faire des architectures ultra clean ça reste quand même de développer des choses pour que ça marche Et de la même manière que tu dis, un product manager, même s'il doit travailler sur la vision, il doit travailler sur comprendre effectivement un problème pour pas non plus répondre à des solutions qui n'ont pas de... Alors c'est là où je nuance. C'est que pour moi, à mon sens, le premier rôle du product manager, c'est de s'assurer que le problème auquel tu veux répondre, il existe. Et que tu vas répondre au vrai problème. Pour moi, la partie vraiment purement delivery, je la mettrais plus du côté des développeurs. Par contre quand tu es dans des contextes où en soit là vous êtes une plateforme de e-commerce donc au niveau des problèmes de base, enfin le cœur d'activité de ManoMano il reste quand même assez clairement connu et donc tu vas peut-être avoir un penchant plus côté faut tester des nouvelles fonctionnalités donc là effectivement ta casquette est plus sur, vraiment, il faut shipper des fonctionnalités, il faut pas passer des heures à juste savoir faire du A-B testing sur des petits trucs ultra peu impactants par rapport à la masse du reste. Mais c'est là où je nuance par rapport à ce que tu disais Product Manager, il doit shipper des fonctionnalités. Je dirais qu'en fonction du contexte, il peut avoir un rôle beaucoup plus axé sur Quel est le problème que l'on veut résoudre ? Notamment dans des boîtes qui essaient de trouver, comme tu as eu ton expérience en start-up, leur market fit, leur product market fit. Là, pour moi, le product manager, son vrai rôle, c'est au contraire, ça peut être un travers de vouloir tout de suite shipper des choses s'il ne se confronte pas assez à la compréhension du problème. C'est plus là-dessus où je lui rentrerais. Mais je te rejoins sur le fait de vouloir après trop à chaque fois théoriser tous les sujets, on finit par en perdre l'essence même de chacun des rôles. Il reste malgré tout une certaine spécificité à chaque rôle dans une boîte qui fait de la tech. Il y a quand même des différences entre le PM et le marketing, c'est pas la même chose.

Valentin: En fait, je vais reformuler ce que je disais en intro. Ton rôle, c'est de conduire les évolutions produits qui permettront d'avoir le plus d'impact par rapport aux objectifs de l'entreprise. Donc, in fine, ta mission, c'est d'avoir de l'impact pour l'entreprise. Mais ta manière d'y arriver, c'est via les fonctionnalités du produit. Après, justement, chacune des étapes pulse, c'est d'arriver à prendre de plus en plus de recul pour que les fonctionnalités que tu livres, elles aient le plus d'impact possible. Donc c'est là où je ne suis pas en train de dire que le PM, son rôle principal, c'est la délivrée. Mais in fine, tout ce qu'on fait, c'est censé se retranscrire dans des fonctionnalités que tu sors, ou que tu retires d'ailleurs, qui auront du coup de plus en plus d'impact. Donc typiquement, quand on dit le rôle du PM, c'est de générer des learnings sur ses utilisateurs. Non, c'est un moyen qui va pouvoir l'aider à avoir plus d'impact. Et ça, du coup, ça fait partie justement des étapes de progression. Donc si on reprend, l'étape une, c'est que tu es capable de livrer des fonctionnalités par rapport à une solution qui t'a été donnée. L'étape 2, c'est donc uncover. T'essaies de te demander, ok, ça c'est la solution qu'on m'a donnée, mais est-ce que c'est la meilleure par rapport aux besoins que je cherche à résoudre ? Donc là, il y a trois phases dedans. C'est d'aider les gens qui t'ont donné cette solution à essayer de comprendre quel est le besoin sous-jacent. Et ce n'est pas si simple. Ce n'est pas si simple, notamment quand tu es du SaaS, B2B et que nous, chez Cluster, on avait un rapport de force de nos clients qui était gigantesque. Quand tu as seulement huit clients et que le mec dit c'est ça que je veux, sinon je ne renouvelle pas. Et tu sais que s'ils ne renouvellent pas, du coup, ça va te donner une image catastrophique sur le marché. Et donc, tu as tous tes sexes qui sont là « non, non, non, il faut absolument que tu fasses ta fonctionnalité ». Donc, je veux dire, ce n'est pas simple. Mais du coup, l'enjeu, c'est de dire « ok, très bien cette solution, mais ça va vous permettre de résoudre quoi ? À quel moment ? ». Et donc, une fois que tu as réussi à comprendre le besoin, c'est arriver avec d'autres idées de solutions. Ça peut être soit elles viennent de l'extérieur, du benchmark, soit d'ateliers, de workshops en interne. Et une fois que tu as ce pool de solutions, tu demandes ok c'est laquelle qui a l'air d'être la meilleure ? et s'assurer qu'elle soit bien cohérente avec la stratégie de l'entreprise et avec le reste du flow. Nous, par exemple, on a une expérience B2B, une expérience B2C, ce n'est pas la même expérience entre l'app et le web. Est-ce que la solution proposée est bien cohérente avec tout cet ensemble ? Et donc là maintenant, à la fin de cette phase 2, et donc toute cette phase 2 c'est un peu ce qu'on appelle classiquement la discovery. Le côté on donne un sujet et tu dois t'assurer que tu crées la meilleure fonctionnalité par rapport à ce besoin. Et c'est ce que Marty Kagan appellerait maintenant une feature team. Là on donne des trucs, maintenant fais moi la meilleure fonctionnalité par rapport à ce besoin. Et donc là maintenant, tu es capable de shipper la meilleure fonctionnalité par rapport à un besoin donné. Donc avant c'était par rapport à une solution donnée, maintenant c'est mieux, c'est par rapport à un besoin. L'étape d'après c'est, est-ce que je suis en train de travailler sur le bon besoin ? Et quand je dis le bon besoin, c'est est-ce que ce besoin, c'est celui qui contribuera le plus à atteindre les objectifs de l'entreprise. Donc là à nouveau, l'idée c'est de collecter un peu tous les besoins, toutes les idées, parce que pareil on dit parfois il faut partir d'un problème et aller à la solution. Parfois en fait on te donne une solution, tu sens qu'elle est intéressante, tu te dis attends ça vient connecter à quel problème ? En fait le vrai sujet c'est d'avoir un couple problème-solution qui marche. Mais parfois ça vient d'une solution. Donc là l'idée c'est que tu collectes auprès de tous les stakeholders qui gravitent autour du sujet, toutes leurs idées, tous leurs besoins, tout ça tu le rends très visuel. Donc tu essaies de donner à Big Picture, moi je me sers beaucoup des tris, donc les opportunities tris, où tu parles de c'est quoi l'OKR qu'on cherche à faire bouger, c'est quoi toutes les idées qu'on a, et en fait tu le construis un peu à l'envers, à ce moment-là c'est ok, en fait ça rentre dans quel bucket, ok donc en fait on voit qu'on a trois grandes dimensions, et donc voilà OKR, on a trois grandes dimensions pour y arriver, et voilà tous les projets qui permettent d'y arriver. tu mets en grâce ceux qui ont l'air d'être les plus importants, tu valides un peu avec tout le monde. Et après, justement pour arriver à cette priorisation, tu essaies de le confronter par rapport à une North Star Metric. Et donc c'est ce que je disais avec Locker, c'est notre équipe, c'est quoi le sous-objectif de l'entreprise qu'elle prend, qu'elle cherche à faire grandir ? et on va essayer de juger du coup chacun de nos projets par rapport à ce sous-objectif. Et on peut faire des RISE, on peut utiliser des logiques de priorisation comme ça. Moi de mon expérience ce que je vois c'est que quand t'es sûr d'avoir l'exhaustivité des projets, que t'es très au clair sur ce que chacun veut dire, l'objectif de chacun et que t'as une North Star claire, En général, les projets les plus importants, ils émergent assez naturellement. Ce qui est compliqué, c'est quand tu es dans une équipe qui cherche à faire bouger beaucoup de North Star Metrics différentes, et dans ce cas-là, tu as une priorisation entre les North Star Metrics. Mais même là, en fait, ça devient plus de la politique de, en fait, c'est quoi les grandes priorités de l'entreprise, et du coup, on va choisir quelle North Star Metrics plutôt qu'une autre. Mais ce côté purement RISE pour aider à prioriser, souvent j'ai trouvé que ça n'aidait pas forcément tant que ça. Mais donc l'enjeu dans cette phase, c'est surtout avoir un alignement sur lequel on est cohérent de quels sont les besoins qui nous permettront le mieux de répondre à l'objectif de l'équipe. Et donc ça c'est line-up. C'est ce qui permet de dire ok bah du coup on va pouvoir travailler là-dessus. Et donc là maintenant, une fois que tu es à ce stade-là, parce que les wagons en fait tu les enchaînes, maintenant tu as été capable de délivrer une solution, tu as été capable de faire une discovery, maintenant tu es capable d'aligner. Donc maintenant que tu es là, si tu prends depuis le début, ça veut dire que tu vas être capable d'aller jusqu'au bout de la chaîne et donc de délivrer les meilleures fonctionnalités par rapport à toutes les opportunités que les équipes ont en interne. Le truc, c'est que souvent, en interne, tu manques d'imagination. Tu n'as pas tout le contexte. Et tu crois l'avoir, mais c'est ce qu'on voit aussi quand on fait des discoveries où on se rend compte que jamais on n'aurait pensé qu'un utilisateur aurait pensé ça. Donc ça, c'est la même chose aussi à l'échelle des opportunités. l'étape 4 qui est S, c'est Supplement, et c'est venir enrichir ton arbre d'opportunités avec une connaissance beaucoup plus approfondie et élargie de tes utilisateurs. Donc là, tu n'es pas... Tu vois, avant, bien sûr, on a déjà discuté avec les utilisateurs. Dans le cas d'une discovery, bien sûr, tu essaies de t'assurer que le besoin, tu trouves une solution qui matche avec les besoins de l'utilisateur. Mais là, c'est beaucoup plus prospectif et c'est, ok, par rapport à notre scope, c'est quoi les besoins de nos utilisateurs ? Et en étant très large, et voir comment ces besoins, tu peux arriver à les connecter à tes enjeux business.

Terry: Alors ça, c'est un point où j'étais pas sûr justement de comprendre la nuance entre le uncover et ce que tu es en train de décrire là. Parce que le uncover, comme tu le disais, c'est l'analogie avec la discovery. Et ce que tu décris là, c'est aussi de la discovery. Donc je vois pas en fait quelle est la nuance entre les deux. Entre le supplement, c'est le supplement dont tu parles là, et le uncover en fait.

Valentin: Oui, parce que c'est un peu comme quand tu fais de la user research, il y a deux types de research. Tu as des research sur des research très exploratoires pour essayer de comprendre, de dégrossir un besoin vraiment macro et tu as des recherches qui sont très liées à un projet. Donc quand tu vas être dans la phase 2, tu vas prendre un besoin et tu vas essayer de déminer ce sujet. Quand tu es dans la phase supplement, c'est venir enrichir ton arbre d'opportunités. Donc tu n'es pas sûr, tiens on a ce besoin, comment est-ce qu'on l'améliore ? C'est comment est-ce qu'on se demande si on a bien mappé l'ensemble des opportunités au sein de notre scope.

Terry: Donc la phase de Supplement c'est plutôt d'aller du coup faire la discovery très spécifique c'est comme ça si je devais le résumer versus le Uncover où c'est une discovery beaucoup plus générale où t'es moins sûr du problème que tu veux trouver.

Valentin: C'est l'inverse.

Terry: C'est l'inverse.

Valentin: Ouais, en gros là, typiquement, donc tu vois par exemple, sur un scope où tu cherches, donc moi le scope sur lequel j'étais à un moment, c'était, comment est-ce que j'améliore la conversion depuis la page produit ? La user research que tu vas faire en phase 2, donc de Discovery, ça va être, ok on sait que, On sait qu'on a un besoin sur le fait qu'on n'est pas très clair dans la manière d'afficher les informations de produits. En un coup d'œil, comprendre c'est quoi les informations clés du produit. On a vu que c'était un besoin, ça nous a été remonté par les équipes clients, en interne tout le monde s'en rend compte. Et donc là tu vas essayer de creuser le sujet pour vraiment être sûr que tu as bien compris le besoin et ensuite pour t'assurer que la solution que tu as en tête elle marche bien. Donc ça c'est vraiment la phase 2 et donc c'est assez précis. Quand t'es en phase 4, là pour améliorer la page produits et la conversion, ce qu'on voit c'est que t'as un gros besoin qui a l'air d'être de clarifier les informations par rapport aux produits. Il y a un besoin qui a l'air d'être de clarifier toutes les informations par rapport à la livraison. Il y a un besoin sur proposer des produits complémentaires par rapport à l'achat donné parce que sinon t'es un peu stressé de dire peut-être qu'il va pas marcher solo et je vais devoir refaire une commande pour en acheter un autre et c'est relou. Il y a un besoin d'arriver à te réorienter sur cette page si c'est pas le bon produit pour toi. Il y a un besoin de voir les avis. Et l'enjeu de Superman c'est de se dire ok, mais est-ce qu'il n'y en a pas d'autres des besoins ? On croit avoir couvert l'ensemble du sujet, mais est-ce qu'on l'a vraiment couvert ?

Terry: Ok, c'est plus clair. Et du coup, juste pour revenir sur l'enchaînement, comme tu disais, c'est un peu des wagons que tu enchaînes. Tu commences par Passe, par du coup Shippé, ensuite Uncover, Line Up et là on est à Supplement. Du coup, l'enchaînement, est-ce que tu le vois aussi comme un niveau de maturité après dans l'organisation sur de maturité produit, on pourrait dire ? ou de manière un peu plus... un peu moins générale, c'est plus... de toute façon c'est quand même sain de toujours passer un peu par chacun de ces wagons parce que ça permet aussi pour ceux qui sont plus très pragmatiques de faire mieux passer la pilule que des fois on va faire ce type de recherche très exploratoire parce que de toute façon au préalable on a fait quand même de la feature qu'on attendait. Est-ce que toi tu vois ces wagons, ce framework pulse comme quelque chose à répéter de manière continue ou plutôt à apprendre de chacune des étapes pour à la fin être capable juste de rester sur le E que tu décriras juste après et oublier les autres étapes ?

Valentin: C'est pas que tu les oublies mais c'est comme si tu gagnais en approfondissement de connaissances de ton scope. Donc l'idée c'est pas de dire à chaque fois dans ta future une fois que t'es arrivé au E tu repars au P, ça n'aurait pas de sens, c'est plutôt comment est-ce que toi tu t'appropries le scope chronologiquement.

Terry: D'accord. Ok. Yes. Donc comment, en tant que product manager, tu vas réussir à t'approprier... En gros, c'est net pour que toi, en tant que product manager, tu réussisses à rentrer dans le sujet sur lequel on t'a donné une responsabilité. Et du coup, tu recommandes... Enfin, c'est ces étapes que vous avez réussi à conceptualiser, de dire je commence par l'étape 1, 2, enfin le P, le U... Et en fait, quand t'arrives à la dernière étape, Là, effectivement, t'as en théorie un niveau de compréhension du périmètre sur lequel t'es censé évoluer qui est assez élevé quoi. Ouais.

Valentin: Ouais, carrément.

Terry: Donc si on revient, parce que là on est reparti en arrière sur Uncover parce que t'étais sur Supplement, du coup sur une compréhension des besoins plus larges que ceux qu'on aurait pu identifier de base. Je sais pas si t'avais d'autres sujets sur Supplement ou...

Valentin: Ensuite, la dernière phase de ce côté-là, c'est comment dans tes North Star Metrics, une fois que tu as une super compréhension utilisateur, comment est-ce que tu t'assures que tu as un bon ratio objectif business, objectif utilisateur ? Parce que si t'arrives dans une équipe qui est très business driven et donc pour l'instant tu priorises tous les sujets par rapport aux enjeux business, t'as un côté ok. Est-ce que maintenant dans notre priorisation, on a tous les enjeux utilisateurs aussi, est-ce qu'on arrive à avoir le bon équilibre entre eux ? Donc globalement, là maintenant que t'en es là, ça veut dire que les fonctionnalités que tu vas shipper, c'est les meilleures fonctionnalités que tu pourrais à partir de toutes les opportunités globalement qui semblent exister autour du périmètre, tant de l'interne que de ce que tu as découvert en externe. Et la dernière étape, donc Envision, c'est... Donc nous, par exemple, on fonctionne beaucoup au quarter dans nos roadmaps. Mais tant que tu restes à une vision quarter, tu risques inconsciemment de te brider. C'est seulement quand tu dis, OK, en fait, tu projettes tout dans deux ans. Tu te dis, oh, OK, j'avais pas pensé que... C'est à ce moment-là où tu ouvres un peu tes chakras et que tu te permets d'être plus ambitieux. Et donc là, c'est arriver à co-construire une vision avec tes stakeholders. Un an, deux ans, ça dépend aussi de ta boîte, quel est le bon angle. Mais je pense que vraiment, la sensation c'est juste que ça donne de l'air pour arriver à être plus ambitieux. et ensuite du coup être capable de pouvoir dire ok dans ce quarter on va prendre tant de pourcentage de notre bande passante sur du purement tactique pour nos objectifs court terme mais aussi tant de pourcentage stratégique pour commencer à aller dans cette direction. Et donc maintenant une fois que tu es là, tu es capable de shipper les meilleures fonctionnalités ou de retirer à nouveau certaines fonctionnalités avec une conscience du sujet la plus grande possible.

Terry: Ok, très clair.

Valentin: Sachant aussi un dernier truc, c'est que moi quand j'étais arrivé chez ManoMano, on m'avait dit, et j'ai trouvé ça génial, on m'avait dit au début, bon t'as pas besoin de te mettre dans tout ce qui est chip et des fonctionnalités, on veut que tu prennes du recul, que tu prennes de la hauteur, que tu crées ta vision, et comme ça après tu pourras dérouler. Et c'est ce que je disais, du coup ça a créé pas mal de friction avec les équipes business et les équipes tech parce qu'on a beau te dire t'inquiète t'es pas attendu là-dessus en tant que boss moi j'attends rien de toi en attendant t'es devenu le responsable de l'équipe et du coup tout le monde te regarde en mode tu sers à quoi et donc d'un point de vue confiance ça aide pas et surtout la vision que j'ai créée à ce moment là théoriquement a été certes intéressante Néanmoins, une fois que tu rentres vraiment dans les sujets, que tu commences à développer, que tu commences à comprendre vraiment chacun des besoins, que tu commences à regrouper tout, en fait, t'es beaucoup plus ancré et tu te retrouves avec une vision qui finalement est plus applicable. Donc moi, l'intérêt aussi de faire les choses progressivement, c'est que le moment où tu crées ta vision, t'es quand même bien imbibé du scope. Et donc tu ponds quelque chose qui est ancré.

Terry: Et je pense que ça a beaucoup beaucoup plus de valeur et c'est hyper intelligent justement d'avoir suivi cette approche parce que comme tu le dis c'est aussi je pense parce que tu as conscience aussi du rôle clé de chef d'orchestre du pm et donc de avant tout gagner la confiance de tous les tous les acteurs aussi avec lesquels avec lesquels tu dois travailler et en premier lieu du coup avec ton équipe.

Valentin: Je pense.

Terry: Que c'est un point vraiment... Tu fais bien d'accentuer ce point-là, c'est-à-dire qu'en gros, là ça peut paraître très théorique, mais en fait c'est une approche qui a été ancrée par la pratique, enfin qui a été théorisée par la pratique, et même toi, du coup, vraiment, tu as cherché à les tester, est-ce qu'effectivement ça fonctionne, et justement pour pas tomber juste sur quelque chose de... de très théorique où derrière les équipes elles te tombent dessus en te disant mais en fait ton framework là il est déconnecté complètement de la réalité là c'est toi tu as fait le chemin inverse c'est plutôt de partir de la réalité pour ensuite un peu conceptualiser essayer de théoriser ça pour le pour le scaler aussi puis pouvoir le partager à l'échelle quoi.

Valentin: Bah ouais carrément et donc typiquement là je manageais quelqu'un qui était à une phase où il maîtrisait totalement le côté délivrerie et où il se disait bon bah la prochaine étape c'est d'avoir une vision et donc très concrètement on disait ok mais il était un peu perdu sur comment on y va Et donc là, en fait là où ce framework qui m'est utile c'est de pouvoir dire ok bah on va s'en servir pour faire un audit et s'aligner sur ok est-ce que on est d'accord que toi t'es à peu près à cette brique là en ce moment de développement et donc bah on va y aller t'inquiète pas prochaine étape on va se concentrer là dessus pas de stress Et ouais donc c'est aussi en tant que PM pour te donner confiance que de voir comment est-ce que tu es capable d'ajouter de plus en plus de valeur.

Terry: Top, très clair. Est-ce que du coup autour de Pulse il y a un sujet ou même global là que tu aurais aimé aborder, qu'on n'a pas traité ou sur lequel tu veux accentuer avant d'aller vers mes deux questions de fin d'interview ?

Valentin: Non pas vraiment, je pense que le sujet là aujourd'hui qui se pose chez ManoMano c'est comment est-ce que ces principes on les applique à l'échelle et ce qui est intéressant c'est quand j'ai partagé ces réflexions à celui qui chapote l'équipe d'agilité et qui a mis en place SAFE C'est drôle parce que nous d'un point de vue macro, sans en avoir conscience, c'est ça qu'on a essayé de mettre en place. D'abord, la toute première version de SAFE, c'était juste, on a mis en place un outil de collaboration pour que le business voit ce qui est en train d'arriver. Purement un truc de visibilité. Après, on s'est assuré qu'il y a une préparation au quartier suivant, on s'est assuré qu'il y a une préparation en amont, pour que les besoins aient bien été exposés et que du coup les features qu'on allait mettre dans la roadmap elles répondent vraiment aux besoins. Le troisième c'était... bon bah... bon je vais pas tous les faire mais du coup ce qui est marrant c'est que eux-mêmes finalement étaient arrivés sur une approche de on va construire pas à pas en construisant cette... en construisant cette valeur progressivement. Et je pense que ce qui n'est pas évident, c'est comment est-ce que tu arrives à avoir une homogénéité de la qualité du produit au sein d'une boîte qui a plus de 40 product managers, sans pour autant imposer des process dans tous les sens et imposer des manières de faire qui vont pas correspondre à tout le monde. Typiquement le tri moi je trouve ça vachement bien et pour l'instant à chaque fois que je manège quelqu'un je lui demande de le faire si ça lui va et ça lui va pour l'instant mais il peut très bien y avoir des personnes qui aimeront pas cette manière de faire et qui voudront une autre visualisation et fine. Et donc il y a un enjeu en tant que boîte de comment est-ce que je m'assure que les équipes vont jusqu'au niveau 5 par exemple mais en même temps, sans être trop restrictif dans les manières d'y arriver. Et aussi, comment est-ce que dans des logiques, dans des contextes où les choses changent beaucoup, donc de dire, OK, en fait, l'objectif jusque-là était là-dessus, et maintenant, il y a des enjeux de profitabilité, donc on change un peu l'angle d'attaque des grands sujets qu'on va attaquer, donc on va remodeler un peu les équipes. si t'as des logiques où tu changes les équipes fréquemment dans une logique d'agilité, comment est-ce que tu fais pour accélérer justement ce pulse, ces cinq étapes, pour pas à chaque fois que ça prenne trop de temps pour une équipe de s'approprier un scope. Et voilà, pulse potentiellement suivant en plus le niveau de maturité d'une équipe, de tout l'history qu'il y a déjà. La première étape, elle peut se faire en deux semaines. C'est pas forcément long, c'est ça que je veux dire.

Terry: Ok, très clair. Donc sur mes deux questions classiques maintenant en fin d'interview, la première c'est est-ce que tu as un sujet sur lequel souvent tu trouves que tu es en désaccord quand on discute avec tes pairs mais que toi tu as des convictions fortes sur ce dernier ?

Valentin: Je crois qu'en ce moment le plus grand c'est que le product doit être user-centric et de mettre l'utilisateur sur un piédestal. Et je crois, je suis en train de clarifier un peu dans ma tête toutes les ramifications de ça, mais un premier truc c'est l'utilisateur n'est pas au-dessus des besoins de l'entreprise. Et je pense que parfois, il y a un idéal qui est... On voit des startups qui mettent tout sur l'utilisateur et on se dit, wow, ben voilà, c'est ça que je cherche. Comme s'il y avait un aspect... Elles le mettent au-dessus de tout, alors que c'est une stratégie de croissance. T'es une boîte, tu cherches ton product-market fit. En fait, si tu veux réussir, il faut que ton produit globalement, il soit dix fois meilleur que le produit des autres pour que les gens bougent sur le tien. Pareil, ce qu'on disait sur les économies d'échelle, t'es dans une logique de start-up et de grandir très vite, donc t'es dans une logique de croître ta user base avant de commencer à monétiser. Donc c'est pas parce qu'ils ont un idéal que l'utilisateur est au-dessus de tout qu'ils font ça, c'est que d'un point de vue très pragmatique, si tu veux arriver à créer une boîte qui va faire beaucoup de valeur, bah tu vas sans doute commencer par ça. L'autre, c'est un peu comme si moralement, l'utilisateur c'était pur et le business c'était impur. Dans ce cas-là, il faut travailler dans une association. Si tu regardes sur la BPI, la définition d'une entreprise à but lucratif, qui est l'immense majorité des startups dans lesquelles on est, c'est de faire de l'argent. Bien sûr, il y a une responsabilité sociétale, une responsabilité utilisateur, mais dans les termes même de la définition de ce que c'est, c'est de faire de l'argent. Donc déjà, il y a quand même, je trouve, un sujet quand on se dit, non, non, moi, mon rôle, c'est de faire un produit qui va satisfaire l'utilisateur dans les contraintes du business. En fait, je ne suis pas d'accord. En fait, quand tu regardes les termes d'une entreprise, c'est de faire de l'argent. Après, que tu choisis une entreprise qui essaie de le faire en étant respectueuse le plus possible des utilisateurs, bien sûr, on cherche tout ça. Mais il faut quand même avoir en tête dans quoi on met les pieds.

Terry: Intéressant, c'est un point qui a le mérite d'être rappelé aussi parce qu'effectivement c'est ce qui distingue une entreprise d'une association comme tu le dis, c'est que le but même d'une entreprise c'est effectivement de faire de l'argent.

Valentin: Et puis même est-ce que c'est moral en fait dire que l'utilisateur il est au-dessus de tout ? Il y a quand même quatre gros interlocuteurs, il y a quatre gros acteurs, il y a les actionnaires. Imaginons que c'est ta retraite qui est en jeu parce que tu as une retraite par capitalisation, tu as investi dans des boîtes. et qu'en fait là t'as investi dans une boîte et les gens dans la boîte disent normalement en fait maintenant on s'en fiche de faire de l'argent, ce qu'on veut c'est juste que l'utilisateur il soit heureux et on sera neutre. Bon il y a Tartrade qui vient de partir en fumée, est-ce que c'est juste ? Il y a la société, pour un utilisateur de beurre c'est beaucoup plus cool de pouvoir mettre son vélo n'importe où, c'est sûr ça lui prend aucun temps. Par contre pour la société parisienne qui ne se sert pas des vélos, même les autres, est-ce que c'est juste une boîte comme Amazon qui justifiait d'être pendant longtemps et qui payait pas très bien ses salariés parce que tout était l'utilisateur first ? À nouveau, est-ce que tu trouves ça juste d'être mal payé parce qu'on te dit, l'important c'est l'utilisateur ? Je trouve qu'il y a un peu une confusion entre on a mis le secteur du digital mais énormément l'utilisateur en avant parce que t'as ces gains d'échelle et que c'est comme ça que tu crées des grosses entreprises. Avec, c'est l'absolu moral, alors que non, genre c'est un équilibre à trouver entre ces quatre parties prenantes.

Terry: Hyper intéressant ouais et c'est vrai que je l'avais pas pensé comme ça, cet angle user first et du coup effectivement le mettre sur un piédestal j'avais peut-être pas mesuré autant ce que tu décris mais maintenant que tu l'expliques c'est vrai qu'on voit souvent, on peut entendre des discours similaires à ce que tu dis qui sont bah non c'est l'utilisateur first et c'est lui qui prime c'est pour ça que c'est pas cher etc quitte à derrière être au détriment comme tu disais par exemple pour Amazon des salariés Moi, personnellement, la vision que j'ai, c'est une que j'avais vue partagée par un ancien, l'ancien fondateur d'une compagnie aérienne américaine qui disait, lui, donc il y a certaines entreprises qui disent client first, ensuite employees et investisseurs, stakeholders. Lui disait, c'était employees first. Moi, tu vois, la vision que j'ai, c'est plus, alors c'est, c'est un peu en parallèle à ce que tu dis, c'est-à-dire déjà d'être très conscient que oui une entreprise son but c'est de faire de l'argent et ensuite comment tu le fais. Tu peux en avoir qui vont dire c'est user first, moi je pense qu'il faut plutôt être employé first parce que c'est avec les personnes en fait que tu vas pouvoir ensuite faire de l'argent et tu mets ton utilisateur en deuxième parce que si t'as pas des employés qui savent faire les choses, enfin qui sont bien, ça va être difficile de créer des choses à valeur ajoutée. Mais ça c'est un peu Je trouve.

Valentin: Ça intéressant et surtout moi ce qui m'amuse là dedans c'est qu'on n'est pas les CEO, on est Product Manager. Du coup, quand on dit user first, ce n'est pas à nous de le dire. Si on est dans une boîte où les CEOs, leur culture, c'est user first, est-ce que ça t'intéresse de venir ? Ok, très bien. Mais on n'est pas des mini-CEOs, au sens, ce n'est pas nous qui créerons la culture de la boîte. Et donc, si c'est une boîte qui est très employee first, et que toi, dans ton univers, c'est user first qui prime, t'es peut-être pas dans la bonne boîte, mais en tout cas te dire moi mon rôle c'est user first, bah non t'as été embauché dans une boîte qui affiche clairement qu'elle est employee first.

Terry: Ouais, ça aussi, ça revient à ce qu'on disait, à un peu remettre aussi les rôles à la place à laquelle ils appartiennent. Hyper intéressant. Et donc sur les recours que tu pourrais donner de lecture, blog, podcast, que ça soit directement ou indirectement relié à l'activité de PM, mais aussi à ce qui... à toi, comment tu réfléchis, des gens qui t'inspirent, est-ce que t'aurais des ressources à partager ?

Valentin: J'aime beaucoup les podcasts parce que bon, je pense que c'est juste d'un point de vue à écouter, je trouve ça plus simple que la lecture, mais ça, c'est hyper perso. Et j'aime beaucoup écouter Rémi Guyot, que je trouve très clair et justement très raisonné entre cette approche pragmatique et tout en ayant la culture produit. Ensuite, et c'est un peu paradoxal avec le fait d'avoir écrit quelque chose sur le produit, mais je trouve qu'un des risques c'est de trop naviguer que dans cet univers produit. et d'aller lire des choses qui sont en dehors de ça. Déjà quand on dit le produit c'est le croisement de la tech, du business et du design, et bien dans ce cas-là lire des ressources sur le design, lire des ressources sur le business par rapport au business de ta boîte par exemple, ou lire des ressources sur la tech. Mais donc, en tout cas, rester trop dans la lecture produit, je trouve que c'est un peu limitant. Moi, ce que j'aime bien, c'est les livres où je trouve que c'est du bon sens qui s'applique beaucoup plus largement. Typiquement, ma dernière lecture, c'était « The Art of the Good Life » d'Obelli, je crois. Et c'est 50 principes. de raisonnement que je trouve géniaux. Après il y a Principles de Redalio que j'avais trouvé vachement bien. Principles je le trouve particulièrement bien sur le côté... le côté chef d'orchestre et comment est-ce que tu... comment est-ce que t'arrives à créer de la confiance avec tes stakeholders et t'arrives à créer des relations fortes. Où lui tout est basé sur une transparence très forte.

Terry: Top, ok, super. Merci beaucoup Valentin.

Valentin: Avec plaisir.