- Speaker #0
Bonjour et bienvenue sur B-MyProducts, le podcast dédié aux produits et à ceux qui les incarnent. Chaque mois, nous ouvrons le micro à des acteurs diversifiés du monde du produit, des concepteurs aux utilisateurs pour découvrir comment ils donnent vie à leurs idées et innovations. Restez avec nous pour des insights uniques et des histoires inspirantes. Bonjour à tous et bienvenue dans ce sixième épisode de B-MyProducts, votre point de rencontre privilégié dédié à l'univers envoûtant du product management. C'est avec un plaisir renouvelé que nous vous convions à ce nouvel épisode de notre podcast pour découvrir d'autres acteurs du produit français. C'est avec un immense plaisir que j'accueille pour cet épisode Dia Bouali, PM, professeur chez Maestro et Thésard. Dia, nous sommes honorés de t'avoir parmi nous. Réel nous est cléé sur ton parcours inspirant et tes expériences dans le produit.
- Speaker #1
Carrément, merci beaucoup Jérôme pour l'invitation et c'est toujours un plaisir de discuter avec toi.
- Speaker #0
Avant de nous immerger pleinement dans l'essence de notre échange, je tiens à faire un rapide rappel du schéma de notre émission à nos auditeurs. Bimei Productions se divise en deux segments principaux. Le premier d'une durée voisinant les 25 minutes est dédié à une exploration approfondie du parcours de notre invité. Aujourd'hui Dia, c'est à toi de briller. Dans le second segment, l'opportunité t'est donnée de discuter d'une passion ou d'un thème qui te passionne. Tu as opté pour le sujet suivant, intégrer la data dans son paradigme produit. Réponse partage de connaissances ?
- Speaker #1
Avec plaisir, allez c'est parti !
- Speaker #0
Dia, on aimerait apprendre un peu plus à te connaître. Peux-tu te présenter, nous parler de ton rôle et de l'activité de cette dernière ?
- Speaker #1
Alors moi c'est Dia, je suis Senior Product Manager Monétique chez Gladys, donc c'est sur un périmètre un peu technique, mais ça reste... quand même un rôle de product manager qui consiste à identifier les problèmes utilisateurs qui valent la peine d'être résolus, leur trouver les bonnes solutions et sans oublier de prendre en compte les enjeux business. En parallèle avec ça et comme tu l'as mentionné pendant l'introduction, je suis test de doctorat en administration des affaires chez Odlincia qui se focalise sur les mécanismes d'expansion plus précisément l'émergéalisation par opposition aux mécanismes de saturation. en entreprise, que pas toute entreprise réussie généralement à un moment ou à un autre atteint un état de saturation. Et en parallèle avec ça, j'interviens aussi avec l'école de produits John Maestro sur le parcours du coup product management full-time. Voilà.
- Speaker #0
Vraiment une carrière riche et des activités diverses. Maintenant qu'on en connaît un peu plus sur toi, on a l'honneur d'apprendre davantage sur ton itinéraire professionnel. Comment tu as embrassé la fonction de PM et comment s'est déroulé ton voyage dans le produit ?
- Speaker #1
Particulièrement, j'ai commencé en premier rôle par avoir un rôle de Product Manager chez OpenIQA. C'était juste après avoir mon diplôme d'ingénieur à Tunis, donc après deux ans prépa, maths physique et trois ans de séquence d'ingénieur, où j'avais une spécialisation en sécurité de réseau. Mais après, je n'ai pas forcément suivi ce chemin pour ma première expérience pro, qui était une expérience entrepreneuriale, mais pour laquelle j'occupais aussi des responsabilités produits. Donc, je faisais mes interviews, recueils de buzz. des besoins, faire le relais avec les développeurs. On avait 4 développeurs, 2 en stage et 2 en externe. C'était ma première expérience avec le produit, faire monter un produit de zéro. Après, j'ai eu mon premier CDI, c'était avec MobilHealth et j'étais Team Leader dans l'équipe tech, avant de passer après en chef de projet. Mais encore, le nom c'était chef de projet parce qu'à l'époque on n'avait pas les titres. produit dans l'écosystème français. On avait un produit SaaS et je faisais la priorisation, les roadmaps, la rédaction des specs, etc. Au final, je commençais par un produit avant de faire un petit détour tech et aussi pédagogique avec le mentorat pour revenir enfin sur le produit.
- Speaker #0
Ok, c'est plutôt clair. Tu peux nous parler maintenant de quelques expériences marquantes dans ta carrière de Product Manager et comment ces expériences sont-elles préparées à ton rôle actuel ?
- Speaker #1
On peut peut-être commencer par l'expérience entrepreneuriale avec OpenIQA que j'évoquais tout à l'heure. Du coup, c'était un produit à destination des cabinets de recrutement et qui permet de matcher automatiquement les offres et les CV. Du coup, j'avais participé à la mise en place du moteur de matching sémantique qui permet de… de calculer les scores de matching. On se basait sur le référentiel européen de compétences à l'époque. Et puis, on avait des gros clients, des grands noms, qui ont commencé à utiliser l'outil comme le cabinet Manpower. On a eu notre première évaluation à 1 million d'euros pour le produit. On était en phase de levée de fonds et après, on a eu un malin prévu, un conflit entre les deux associés suite à un... une demande de répartition de part de la part des investisseurs et du coup l'expérience au final a mal tourné. C'est très simple de faire entrer un associé, par contre le faire sortir c'est beaucoup plus compliqué. Donc c'est ma première expérience en produit qui m'a permis de vivre de près la mise en place d'un produit de zéro, de surtout prendre conscience de l'aspect business dans les prises de décision. Au final on monte un produit mais il doit être rentable, peut-être pas dès les premières années. les premiers mois, mais au final, on ne doit pas oublier l'aspect business dans toutes les prises de décision parce qu'au final, un PM ou une PM, pour moi, sont des architectes de décision qui essayent de trouver les bons process de prise de décision sans forcément partir sur des process de consensus tout le temps, mais en fonction de l'importance de la décision, faire entrer ou pas telle partie prenante, avancer plus ou moins rapidement, etc. Donc voilà, le plus important pour moi c'était de travailler avec tous les associés, les clients, les premiers clients et tout, pour sélectionner et prioriser les premières fonctionnalités à mettre en place. C'est important quand on démarre un produit de zéro. Mais parfois il faut savoir trancher, savoir dire non, ne pas forcément accepter toutes les demandes qui arrivent. Ça me rappelle une vidéo, je pense que c'est un gars chez Intercamp qui a monté. On essaie de mettre en évidence un peu l'aspect quand tu pars sur le consensus tout le temps. Il a pris un exemple de formulaire de sign-up où tu demandes au marketing, ils vont ajouter des champs dans le formulaire pour pouvoir retargeter les prospects par la suite, les commerciaux pour pouvoir qualifier les leads. La conformité, ils vont demander d'autres champs ou des cases à cocher pour respecter les règles en vigueur. etc. Et tu te prouve final avec un formulaire sign up de 12 ou 15 champs. Donc, ce n'est pas forcément ce que souhaitent les utilisateurs. Donc, voilà la prise de décision pour les product managers. Pour moi, c'est un point hyper, hyper important et que j'ai pu du coup exercer de près durant cette première expérience avec OpenIQ. Oui,
- Speaker #0
donc ce que tu es en train de dire, c'est que souvent... trop vouloir le compromis on fabrique souvent des usines à gaz complètement c'est pour ça aussi que le rôle du produit manager est important puisque il faut savoir arbitrer prendre les bonnes décisions et surtout mener le projet vers la rentabilité tout à fait ta 2d expérience peut-être que tu veux nous partager peut-être des expériences entrepreneurial ou des expériences web
- Speaker #1
pourrait parler d'un site project en b2c cette fois parce qu'on entreprise toutes les expériences étaient en b2b mais par Par contre, on bite aussi, en fait, c'est un site project, une application mobile de planification de voyage, ce qu'on appelle un triplanar. En 2016-2018, j'ai pris une petite pause où j'ai voyagé en Asie du sud-est et en Amérique latine, en Amérique du sud et en Amérique centrale. Et du coup, à mon retour, j'ai conçu une application de triplanar qui était en anglais, destinée principalement sur le marché américain et qui m'a permis du coup… de maîtriser la gestion de produits en B2C qui défèrent. un peu de la gestion de produits en B2B. Au final, en B2B, on associe un facteur important au poids des clients dans les priorisations, par exemple. En B2C, ça défère un peu. Et c'était intéressant comme expérience de voir de près l'importance de garantir l'équilibre entre les coûts, parce que c'était un side project et du coup, ça me coûtait de l'argent à titre personnel. de maîtriser la balance entre ce que rapporte le projet et ce que ça coûte. Parce qu'au final, même là, c'est un side project, mais ça s'applique aussi à l'échelle des entreprises. Si tu te focalises trop sur l'aspect business et tu oublies les utilisateurs, à un certain moment, ils vont trouver ce qu'ils cherchent chez d'autres concurrents et donc ils vont switcher. Et inversement, si tu te focalises trop sur les utilisateurs et... Tu oublies un peu l'aspect business, au final la boîte ne va pas tenir sur le long terme, ce n'est pas durable. Et avoir un MPS de 70 ou 80, mais une boîte qui coule, ce n'est pas tant que non plus.
- Speaker #0
C'est cet équilibre vraiment qu'il faut trouver à chaque fois. Tout à fait. Pour être stable et savoir capter les utilisateurs et les fidéliser.
- Speaker #1
Et c'est le plus compliqué à mon avis de trouver, surtout de garantir. Peut-être on peut l'atteindre, mais après c'est un enjeu continu. à chaque fois, de le garantir dans le temps.
- Speaker #0
Tu veux peut-être aussi nous parler un peu de ton côté mentorat ?
- Speaker #1
Du coup, avec Open Classrooms, j'étais mentor sur les parcours chef projet et chef produit. Et ça consistait du coup concrètement à entretenir des séances d'accompagnement hebdomadaire avec les étudiants. Ce qui m'a marqué dans cette expérience, c'était principalement le lien humain construit avec les étudiants au fil du temps. C'est toujours touchant. quand ils arrivent à la fin de leur formation et ils obtiennent leur diplôme. Et puis aussi, moi aussi, j'ai pu bénéficier en retour de cette expérience parce que c'est ce que j'ai réalisé durant cette expérience et que la transmission de connaissances est aussi bénéfique pour les deux parties. Parce que moi aussi, j'apprenais beaucoup des étudiants à travers leurs questions, à travers quand ils me Ausha, etc. Et du coup, c'était aussi intéressant sur le plan. plan intellectuel.
- Speaker #0
Ouais, donc on voit que tu touchais un peu à tout. Tu as à la fois eu le poste de PM, ce côté auto-entrepreneur pour explorer le parti B2C, et vraiment ce côté mentor, professeur derrière, le désir de transmettre.
- Speaker #1
Ça m'aide beaucoup aujourd'hui dans ce que je fais.
- Speaker #0
Je m'étonne. Maintenant qu'on connaît un peu mieux ton parcours et ton profil, ce qu'on aimerait connaître maintenant, c'est tes ressources de référence. Tu as peut-être des podcasts, des livres qui t'ont pu t'inspirer au cours de ta carrière, que tu recommanderais aux auditeurs ou pas ?
- Speaker #1
Alors, moi, je suis beaucoup l'écosystème américain. Et du coup, mes ressources sont généralement en anglais. Je pense qu'aujourd'hui, la plupart des personnes sont plus ou moins à l'aise avec des ressources ou des podcasts.
- Speaker #0
Si on veut être à jour, de toute façon, c'est en anglais. Oui,
- Speaker #1
carrément. Du coup, peut-être, je dirais les livres SFBG, Inspired, Empowered. etc. Même si les deux derniers, je ne les ai pas lus encore. Mais mon préféré, c'est le deuxième, c'est Empowered. Après, en termes de formation continue, ma source préférée, c'est Reforge. Je trouve les formations hyper qualitatives et les templates qu'ils fournissent pour les documents et les livrables hyper intéressants. Sinon, sur la partie paiement, il y a un podcast que je suis particulièrement sur la partie paiement, ça s'appelle 11FS. Et du coup, ça me permet de suivre un peu… l'évolution des fintechs, les banques, etc.
- Speaker #0
Ok, super intéressant. Ce sont des ressources qu'on n'avait pas eues jusqu'à maintenant. Et justement, je trouve ça vachement bien qu'on puisse compléter un peu la bibliothèque avec de nouvelles ressources. Maintenant, on va passer vraiment sur ton rôle de PM. Tu peux un peu nous décrire ton rôle, tes responsabilités chez tes différents clients et comment ça les a impactés ?
- Speaker #1
Pour le rôle, d'abord, je te remercie pour le choix du mot impact parce que pour moi, c'est l'enjeu principal des équipes. produits, toutes les questions d'impact. Et pour moi, un bon product manager, il doit être conscient des enjeux business de son entreprise et de comprendre son modèle économique, comment on fait l'argent. Après, sinon, au quotidien, un PM, généralement, il travaille sur trois points différents. D'abord, ton 1, le passé, les sprints passés pour évaluer ou analyser ce qui a été livré. Est-ce que ça apportait de la valeur ou pas ? On parle souvent de valeur, mais enfin, la valeur, elle peut être confirmée à qu'une fois. Donc, en prod. Avant, on parle, il s'agit principalement de codes d'hypothèse. Et donc, une fois les features en prod, le PM doit prendre le temps de revenir sur ce qui a été livré pour l'analyser. En deux, il travaille aussi sur le présent pour accompagner les développeurs sur ce qu'on appelle le emergent work, un peu le travail, ce qu'on n'a pas prévu, peut-être pendant la phase de spécification. Et du coup, il doit toujours accompagner le sprint en cours. Et puis, en trois, c'est un peu le futur, ce sont les sprints. Merci Marie-Léa. Et du coup, sa mission, c'est évidemment de préparer les sprints qui vont arriver parce que le produit ne doit pas bloquer la tech. Quand on arrive lundi en sprint planning, on doit avoir des tickets qui sont prêts pour pouvoir planifier le sprint et avancer avec les développeurs. Donc voilà, mais sinon, d'une manière générale, en fait, il y a plusieurs manières de faire du produit. Il n'y a pas une seule manière qui est partagée par... toutes les entreprises. Donc, il n'y a pas un paradigme produit, mais des paradigmes produits parce que ça dépend au final de la nature du produit, la taille de l'entreprise. Tu sais, la qualité. Voilà, tout à fait. Par exemple, pour la nature du produit, on ne travaille pas de la même manière un produit SaaS ou peut-être une application mobile ou un logiciel embarqué. La maturité du produit aussi, c'est important. Un produit qui n'a pas encore atteint son product market fit, c'est-à-dire qui... peut adopter une approche différente d'un produit qu'il a déjà atteint et qui est même, voire, en phase de saturation. Donc voilà, les questions pratiques divergent.
- Speaker #0
Tout est une question d'adaptation au final. C'est tout l'intérêt du travail de product manager aussi, c'est de pouvoir s'adapter à son environnement, à son produit.
- Speaker #1
Exactement, tout à fait. C'est de pouvoir avoir une sorte de boîte à outils et après de choisir les bons outils. en fonction de son contexte, qui peut varier en fonction d'entreprise, mais aussi en fonction de cycle de vie du produit dans la même entreprise.
- Speaker #0
Ok. Et toi, pour toi, tu pourrais nous donner des exemples un peu de la manière dont tu as procédé chez certains clients ?
- Speaker #1
Oui. Alors, on va peut-être commencer par Mobile House, la première expérience où on était un peu en mode feature. Et du coup, au final, on livrait des fonctionnalités. C'était quand même en 2013 ou 2014.
- Speaker #0
Je te coupe un peu, mais ce que tu appelles un mode feature, tu parles d'un peu de feature factory.
- Speaker #1
Oui, au final, c'est que l'impact, c'est de pouvoir livrer une fonctionnalité, la développer et la mettre en preuve.
- Speaker #0
Ok, pour restituer aussi que c'était à l'époque. C'est ça,
- Speaker #1
tout à fait.
- Speaker #0
Ça a bien changé depuis.
- Speaker #1
Également, effectivement. C'est en 2013-2014. Du coup, j'ai aussi profité de cette période pour creuser un peu toutes les notions théoriques, produits, agilité, etc. Qu'est-ce qu'un sprint ? Comment on définit le sprint goal quand on travaille sur 15 trucs en parallèle d'un sprint ? Pourquoi on utilise souvent la suite Fibonacci, par exemple, pour les estimations ? Pourquoi on planifie alors qu'au final, on est censé être agile et s'adapter ? Qu'est-ce que c'est de la valeur ? La valeur par rapport à qui ? acquis aux utilisateurs, au business, etc. Donc, j'ai profité de cette période pour avoir un socle théorique solide, on va dire. Après, avec Expansia, qui est une solution de paiement pour les enderfrais, donc concrètement, on donne des cartes bancaires, mastercard aux utilisateurs de nos clients, qui leur permet au final d'accéder directement à l'argent de l'entreprise et éviter d'avancer leur propre argent et d'attendre par la suite. un remboursement, donc c'est un nouveau modèle. Donc on était déployé sur trois pays, en France, en Allemagne, en Espagne. Et en termes d'approche produit, on était plutôt orienté impact cette fois. Donc on avait par exemple des points trimestriels avec l'ensemble de l'entreprise où tous les PM, ils présentaient en fait l'impact, les métriques qu'ils ont shiftées pendant le quarter présent. Et les métriques... sur lesquels ils vont travailler le trimestre suivant. Et donc, en fait, on était sur des objectifs bien quantifiables et pas seulement développer des fonctionnalités pour les mettre en place. En termes organisationnels, on était sur un modèle particulier aussi où on avait quasiment tous les types de teams qui sont possibles en produit. On avait des équipes. ce qu'on appelle les feature teams qui ont un ensemble de fonctionnalités à leur responsabilité. On avait aussi les impact teams, community growth par exemple. Des persona teams aussi qui se focalisent sur un persona en particulier pour lui apporter de la valeur. Et puis des component teams aussi, par exemple une équipe plateforme qui travaille sur des sujets back-end. Pour moi, il n'y a pas de modèle particulier. qui est mieux que l'autre.
- Speaker #0
Ça dépend vraiment du contexte à qui tu t'adresses et ce que tu cherches à obtenir. Pour resituer, parce que tu parles déjà d'un factime, à l'époque, c'était quand chez Expensia que tu travaillais dans cette organisation ?
- Speaker #1
C'était en 2022.
- Speaker #0
fin 2021 si je ne me trompe pas parce que les Impact Teams c'est quand même quelque chose d'assez nouveau en France ouais je pense que ça a 3-4 ans ça a dû arriver il y a 3-4 ans on commence petit à petit à intégrer de l'Impact Team dans beaucoup d'organisations mais déjà tu sens déjà qu'Expensia avait une certaine maturité et
- Speaker #1
vous l'avez déjà intégré ça à l'époque oui tout à fait c'était en fait par la mise en place d'une équipe growth qui partageait des objectifs avec les équipes marketing qui s'occupaient du coup du final double A triple A Et du coup, elle avait en gros un seul objectif, lequel elle travaille, augmenter le chiffre d'affaires. Et elle avait du coup une marge de flexibilité très importante, de liberté par rapport aux autres squads, qui lui permet en fait de pouvoir agir plus rapidement. C'est l'essentiel des produits, des équipes growth, d'être en mode un peu test and learn. pouvoir tester des trucs très, très rapidement, avoir l'idée le matin, la mettre en place le lendemain. Deux jours plus tard, passer à une autre expérimentation. Et du coup, c'était un modèle d'équipe un peu particulier.
- Speaker #0
OK. Et tu peux nous parler un peu de ta dernière expérience chez Gladys ?
- Speaker #1
Tout à fait. Du coup, chez Gladys, on se focalise sur les résultats. On priorise par trimestre. Sur les OKR, on travaille sur des OKR semestriels. Après, je trouve un bon équilibre parce que pour les OKR, il y a plusieurs implémentations qui diffèrent d'une entreprise à une autre en termes de fréquence. Je pense que la fréquence semestrielle est pas mal parce qu'au final, partir à avoir essayé la fréquence trimestrielle et la fréquence annuelle, déjà sur la fréquence annuelle, c'est lent et aujourd'hui, le rythme d'innovation est accéléré. certains secteurs qui sont très concurrentiels, on est même obligé d'innover pour garder sa place et ne pas innover pour garder des parts de marché. C'est ce qu'on appelle un peu l'hypothèse de la reine rouge. Et donc, partir sur des OKR annuels, c'est long parce qu'on court de route. Parfois, on va être amené à les changer et les adapter. Et de la même manière, pour les OKR trimestriels, je trouve le cycle courant parce que parfois, tu as besoin de faire plus. plusieurs expérimentations en fait pour bouger la métrique on n'est pas sûr d'y arriver dès la première expérimentation et puis ça prend du temps entre les tests utilisateurs les interviews les spécifications la planification la mise en place la mesure on ne mesure pas tout de suite on doit attendre quelques semaines avant de collecter la data et tout t'arrives quasiment au mi-quarter donc c'est pas évident avec Gladys on utilise en fait là on On part sur des OKR semestriels et personnellement, je trouve le cycle un peu à garantir un bon équilibre entre le très court et le très long.
- Speaker #0
Alors, il y a débat, je pense, sur les OKR. On peut en parler longtemps. Mais c'est vrai que j'interviewais récemment Alexandra, qui était spécialiste dans les OKR, qui nous parlait vraiment d'intention. Et pour elle, les OKR, ce n'est pas forcément un objectif à tendre, c'est une intention que l'on souhaite atteindre. mais c'est vrai que si ça prend trop de temps à mettre en place, si c'est trop chronophage et que c'est contre-productif, et donc ça va à l'inverse de l'impact et qu'on ne livre pas assez de valeur ajoutée parce qu'on se focus trop sur les aucaires, c'est vrai qu'il y a un arbitrage à prendre quand même dessus. C'est pour ça que les aucaires, c'est vraiment un métier à part entière qui commence vraiment à se développer et on commence vraiment à voir des gens qui ne font que ça.
- Speaker #1
Je suis d'accord avec toi.
- Speaker #0
Maintenant, merci en tout cas de nous avoir un peu expliqué. les différents parcours que tu as pu avoir, les différentes missions que tu as pu avoir, ton rôle et tes responsabilités. Maintenant, ce qu'on aimerait savoir, c'est un peu ton quotidien. Est-ce que tu peux nous plonger un peu dans ce que tu fais tous les jours en tant que PM chez Gladys ?
- Speaker #1
Ça marche. Je dirais en amont, peut-être prendre des décisions ou aider à prendre des décisions. Mais sinon, on va aller dans le détail et peut-être les présenter à travers les livrables. Par exemple, ça peut être... Ça pourrait toucher à faire des product roadmaps, faire des product specifications, les OKR, les dashboards de suivi, faire les analyses post-lancement. Donc au final, c'est un panel large de responsabilités au quotidien et d'une importance de bien s'organiser, d'avoir une bonne capacité à s'organiser parce que sinon on risque de tomber dans le piège de traiter que l'urgent. et pas l'important. Et sinon, ce qui n'est pas urgent, on le laisse à côté jusqu'au jour où ça devient urgent. Donc là, on le traite. Après, sinon, il y a une partie du discovery, une partie délivrée. La partie discovery, elle est aussi... important que la partie déléguée dans le sens où on doit garantir de résoudre le bon problème parce qu'au final si on part sur un mauvais problème et même si on lui trouve la bonne solution, au final tout le monde s'en fout parce que c'est pas un bon problème. Donc c'est hyper important d'autant plus que ça mobilise les ressources de l'entreprise. Une squad ça coûte plusieurs centaines de milliers d'euros voire jusqu'à un million d'euros en fonction de la taille de l'équipe et des profils donc prendre le temps nécessaire. Pour bien choisir les problèmes à résoudre, je pense que c'est hyper important pour moi.
- Speaker #0
Et comment tu arrives justement à garder cet équilibre entre Discovery et Delivery ? Parce que c'est un problème, je pense, inhérent à tous les PM. Je pense que tu parleras beaucoup de PM en te donnant des pistes de solutions, mais je sais que c'est toujours un problème.
- Speaker #1
Oui, effectivement, on n'arrive pas à s'y trouver facilement. Je dirais en fait que la collaboration, ça aide beaucoup. avec les autres métiers nous par exemple chez Gladio on a la chance d'avoir des QA, des Scrum Master, des Product Designer, des Data Analyst et donc en fait on peut se partager les tâches sur la partie analyse par exemple avec l'équipe data, sur la partie solution avec l'équipe design donc ça peut aider je pense contrairement à d'autres boîtes où parfois le PM il a une double ou triple casquette. Et donc là, je pense que ça devient effectivement un peu compliqué, mais ça reste toujours un enjeu d'organisation pour pouvoir accompagner toutes les prises de décision.
- Speaker #0
Je me permets d'intervenir, mais c'est vrai que souvent, Product Manager, tu as la discovery, tu as le delivery, mais tu as aussi d'autres tâches qui t'incombent. Tu peux avoir la roadmap, les spécifications, les OKR, le dashboard, le post-launch, voire le go-to-market. Et souvent, le PM, il est pris un peu à la gorge, au niveau temps, je parle. C'est toujours une grande difficulté pour les product managers de la gestion du temps de toutes ces responsabilités. Toi, comment tu arrives à jongler entre tout ça ? Ce que tu disais, c'est vraiment la collaboration qui te permet un peu de sortir la tête de l'eau ?
- Speaker #1
Entre autres, pas que. Je dirais aussi l'organisation, le fait de planifier son travail, de planifier sa journée dès le matin. Parfois, on peut être amené à refuser ou à reporter des réunions. pour pouvoir se focaliser sur ce qui est important. Donc voilà, c'est un panel large de bonnes pratiques, on va dire, qui permet au final d'avoir la bonne passante nécessaire pour pouvoir accomplir toutes ces tâches. Ça peut même aller jusqu'à booker un créneau, par exemple, sur son agenda, tous les mardis matin ou tous les vendredis en fin de journée. pour pouvoir accomplir telle tâche et ne pas être sollicité.
- Speaker #0
C'est vraiment une bonne gestion du temps. C'est aussi savoir dire non, savoir s'entourer, savoir collaborer. Donc c'est un peu toutes ces clés que tu nous donnes pour mieux gérer son temps en tant que PM. Tout à fait, c'est bien ça. Donc, en fait, c'est toutes les questions d'organisation de la todo personnelle. Après, ça peut aller jusqu'à aussi le fait de déléguer des tâches à d'autres métiers. Par exemple, les critères d'acceptation au QA ou même la partie spécification sur des tickets bien particuliers aux développeurs, s'ils veulent participer. Donc, parfois, ça peut aussi libérer un peu.
- Speaker #1
Ok, très clair. Je te fais un aparté. Est-ce que tu veux qu'on parle du oh, oh, what ou tu veux qu'on passe à la question suivante ? Oui,
- Speaker #0
je vais y revenir plus tard.
- Speaker #1
Ok, en tout cas, merci Dia. On sait que chez Be My Product, chaque leader a vraiment sa petite touche personnelle. Pourrais-tu nous donner trois exemples concrets qui illustrent ta singularité dans l'approche produit ?
- Speaker #0
Alors, je dirais en premier point d'avoir un esprit flexible dans le sens où je n'hésite pas personnellement à changer d'avis quand c'est nécessaire. Donc, je ne suis pas le type de personne qui persiste sur son point de vue initial. Et je pense que c'est important dans la construction de produits parce qu'au final, tout le monde construit le produit, pas que le département produit. On a souvent tendance à dire qu'il y a trois questions qui sont répondues par trois métiers différents. Le how technique comment on va le faire, qui est répondu par l'équipe tech ou le développeur. Le how procédural en termes de méthode, comment on va travailler, Agile, Scrum, etc., qui est résolu par les… coach agile ou les scrum master, etc. Et il y a aussi le Watt, où généralement, on considère que c'est résolu ou répandu par l'équipe produit, mais pour moi, le Watt, c'est une question à laquelle répond toute l'entreprise et pas que le département produit. Le product manager, il travaille avec tous les autres métiers, ce qu'on appelle les customer facing teams, donc les commerciaux, les CSN, le support, etc. Et donc, pour moi, c'est important d'avoir un esprit flexible et de changer d'avis quand c'est nécessaire. En deuxième, point je dirais de se baser sur la preuve, ce qu'on appelle en anglais le fait d'être evidence-based, donc se baser sur la data. Moi je pense que grâce à mon background technique en tant qu'ingénieur, j'ai un peu une liaison avec cette partie-là puisque j'ai appliqué un peu des techniques d'analyse data et tout sans forcément solliciter d'autres métiers quand ils n'ont pas de la bande passante. Après sur les singularités, je dirais avoir une âme entrepreneuriale. Pour moi, c'est important pour un product manager d'avoir ce côté business, de comprendre ses enjeux. Les product managers, par exemple chez Gladys, on a différents profils, différents parcours. On a des product managers qui ont fait des écoles de commerce, d'autres qui ont été dans l'équipe support, d'autres qui étaient avant dans le design ou d'autres métiers. Et donc, je pense que cette richesse, elle permet d'apporter... une valeur ajoutée d'ensemble, mais aussi chaque product manager lui-même, il peut tirer de ses expériences passées et en profiter pour ce qu'il fait au quotidien en tant que product manager. Je pense qu'on arrivera souvent à trouver un lien entre ce qu'on a fait avant et entre le rôle de product manager parce que le rôle de product manager, il concentre pas mal de compétences, pas mal de skills.
- Speaker #1
Ok, très clair. Ça me fait justement penser, tu dis ça, mais... Ma précédente société de service, je leur fais un coucou à Weevew, il ne recrutait que des personnes qui étaient justement auto-entrepreneurs. Donc, ça rejoint un peu ça. Il souhaitait avoir des profils qui aient une conscience business, qui aient une conscience aussi du marché, de la rentabilité et de la valeur, et utilisateurs et autres. Et c'est vrai que c'est toujours hyper intéressant. En tout cas, on le voit souvent, des PM qui ont ce background-là sont des PM qui sont quand même le plus adaptés, on va dire, sur le marché, notamment sur tout ce qui est... recherche de l'impact et recherche de la valeur ajoutée. Bon, maintenant, sans rentrer dans le stéréotype, pour toi, c'est quoi les qualités que tu considères essentielles pour être un excellent PM ?
- Speaker #0
Une question très compliquée, Jérôme.
- Speaker #1
Ah, bien, vas-y.
- Speaker #0
Je vais peut-être résumer en un mot. Ça s'applique au product manager, en fait, mais ça s'applique à pas mal d'autres métiers. Pour moi, c'est la sagesse. Peut-être que je vais détailler pour... C'est un mot un peu qui peut englober partout.
- Speaker #1
Ouais,
- Speaker #0
c'est ça. Pour moi, en fait, c'est la capacité à comprendre les besoins humains d'une manière profonde. Par exemple, pour Dagmajor, il a besoin de comprendre à la fois les utilisateurs, mais aussi les collaborateurs internes et tout, puisqu'il interagit avec pas mal de métiers. Et pour moi, en fait, on doit commencer par se comprendre soi-même d'abord, pour pouvoir comprendre les autres. Et c'est plus important parce que ça permet par la suite de comprendre et maîtriser son environnement, puisque l'être humain, pour moi, c'est la composante la plus importante. plus complexe de son environnement. Et donc, avoir cette sagesse à comprendre les besoins profonds, ça aide à collaborer d'une manière très facile au quotidien.
- Speaker #1
C'est une empathie au final, ce que tu mets en avant. C'est comprendre les autres, se comprendre soi-même. Il ne faut pas oublier que la composante humaine dans ces sociétés, c'est la forme d'entropie la plus élevée.
- Speaker #0
Tout à fait. Et puis, le fait de pouvoir aussi combiner à la fois ses connaissances, son expérience, mais aussi... de bon sens. On parle souvent du fait des data driven mais parfois en fait on ne peut pas l'être tout le temps parce qu'on n'a pas l'ensemble des data qu'on espère souvent pour prendre la décision et parfois on manque de données. surtout dans notre monde contemporain où on est entouré de data partout. Et donc, la sagesse, elle permet de mixer à la fois la connaissance, la data, l'expérience, le bon sens, l'intuition, etc. pour le process de prise de décision. Ce qui rejoint un peu ce qu'on appelle le data informed par opposition au data driven, où tu te bases sur la data, mais tu prends en compte aussi d'autres facteurs, l'intuition, l'expérience, etc. Donc, pour moi, voilà, c'est… principalement un ensemble surtout de soft skills que je considère en fait essentiels pour revenir à ta question, essentiels pour être un excellent PM. Ok,
- Speaker #1
merci en tout cas Dia. On va maintenant passer à la partie change et réussite. C'est vrai que chez Bimei Productions, on valorise vraiment la transparence et la franchise. Dans ton parcours, quels ont été vraiment les défis et réussites qui t'ont particulièrement marqué ? Tu peux nous partager sans filtre les hauts et les bas de ta carrière. On va, si tu le permets, commencer par les bas.
- Speaker #0
La première expérience, c'était l'échec entrepreneurial. Pour moi, c'était une partie qui m'a marqué parce qu'au final, j'ai beaucoup investi dans le projet. On avait tous les ingrédients nécessaires pour réussir. Après, c'est parti à cause d'un conflit personnel. C'était regrettable parce que dans un projet de start-up, on… On investit beaucoup, c'est des mois de travail, parfois 12, 13, 14 heures de travail par jour. Et donc, pour moi, c'était l'expérience la plus frustrante pour moi.
- Speaker #1
Ok. Et en parlant peut-être de choses plus joyeuses, tu peux nous parler un peu, cette fois-ci, de réussite ? C'est quoi les moments forts que tu as vécu dans ta carrière de PM ?
- Speaker #0
Alors, je dirais d'une manière générale, ce qui fait toujours plaisir à un product manager, c'est qu'il va avoir de l'impact, tu le prouves. mathématiquement que tu as réussi à faire bouger une métrique d'une manière durable et non pas par juste coïncidence. Mais sinon sur les réussites, ça peut aussi être des réussites humaines. Pour moi, je peux citer un petit exemple avec Open Classroom, c'est un étudiant qui m'a marqué. En fait, il était atteint d'une maladie rare et il avait besoin d'un accompagnement spécifique, mais il n'y avait aucun mentor formé sur ça. Du coup, au final, j'ai accepté de l'accompagner. Et à la fin de sa formation, quand il a eu son diplôme, il m'a envoyé un mail très long, très émouvant pour me remercier. Et pour moi, cette reconnaissance, pour moi, c'était une réussite aussi qui m'a marqué.
- Speaker #1
Oui, pas seulement professionnelle, mais aussi émotionnelle.
- Speaker #0
Complètement, oui.
- Speaker #1
C'est beau. On va maintenant peut-être passer sur ces belles paroles émouvantes. On va maintenant passer à la seconde partie de l'interview. C'est vrai que tu as souhaité parler du sujet suivant qui était l'intégration de la data et le paradigme produit qui en découle. Déjà, Diap, pourquoi tu as décidé de nous parler de ce sujet ?
- Speaker #0
Très bonne question. Pour moi, parce qu'en produit, on parle souvent d'amélioration continue, mais pour pouvoir améliorer, en fait, on doit mesurer parce que ce qui n'est pas mesurable, pour moi, il n'est pas améliorable. Et donc, d'où l'importance de mesurer, de collecter de la data, d'avoir cet esprit d'analyse. Et d'où, en fait, le choix de ce sujet pour moi.
- Speaker #1
Ok, très clair. Tu peux nous expliquer un peu la bonne méthode pour utiliser des données et itérer sur un produit ?
- Speaker #0
D'abord, ça devrait, en fait, concerner toutes les étapes du produit. Ça parle de la priorisation jusqu'à l'analyse après le lancement. Et cette analyse, en fait, c'est ce qui permet de prendre les décisions pour les itérations suivantes. Est-ce qu'on continue d'investir sur la fonctionnalité ? Est-ce qu'on arrête l'investissement ? Ou est-ce qu'on la retire complètement ? Parce qu'au final, même si ça ne marche pas, la laisser, parfois, ça a un coût. Le coût de la maintenance pour l'entreprise, mais un coût cognitif aussi pour les utilisateurs. Parce qu'avoir une application avec 1000 boutons, ça génère un coût. un peu cognitive, et ça me rappelle l'exemple de Photoshop qui a rajouté la plate fonctionnalité avancée, et du coup au final, il a mis, ou il a instauré une sorte de barrière à l'entrée pour les nouveaux utilisateurs qui trouvent l'outil un peu compliqué, qui basculent sur d'autres outils beaucoup plus maîtrisables. Et donc, quand ça ne marche pas, parfois, c'est une décision dure, parce qu'on a mis le ton dessus pour la développer et tout, mais parfois, il faut l'apprendre, il faut retirer la fonctionnalité. Et ça arrive à tout le monde et à toutes les entreprises. Il y a même un site qui s'appelle Killed by Google, où on liste tous les produits et tous les modules qui ont été arrêtés par Google après leur lancement. Donc, ce n'est pas un grand échec en soi. L'essentiel, c'est d'apprendre et d'itérer par la suite. Donc, pour moi, en fait, avoir une bonne approche data, c'est aussi pouvoir prendre des décisions dures quand ils le font. Par exemple, arrêter. le développement d'une fonctionnalité ou d'un module sur lequel on a mis déjà des mots. Ça, c'est un point, mais sinon aussi, ça rejoint l'utilisation des bonnes pratiques pour les mesures de data. Ça rejoint aussi le fait de pouvoir choisir sa méthode de mesure avant de passer en prod et non pas après. Est-ce qu'on va comparer le avant et le après ? Est-ce qu'on va faire un A-B testing ? Est-ce qu'on va faire un test par marché ? On met une version sur le marché français, une autre sur le marché espagnol et on compare, etc. Donc, en fait, ces stratégies de test, c'est important. de pouvoir les définir avant de mettre la fonctionnalité en prod parce qu'une fois en prod, la donnée, si on n'a pas prévu de la mesurer, elle est perdue une fois pour toutes. Ça serait un peu tard.
- Speaker #1
Comment tu arrives à définir ça dans ta stratégie Data ? La méthode de déploiement que tu vas choisir ? Est-ce que tu pars sur un A-B testing ? Est-ce que tu pars sur autre chose ? Un ramp-up, ce genre de choses ? Ça arrive à quel moment exactement ?
- Speaker #0
Pour moi, ça devrait arriver avant le passage en prod, et puis parce que parfois, en fait, on a besoin de même ajouter des mots de code pour les mesures, mais ça dépend des fonctionnalités. Le avant et le après, c'est le plus simple à mesurer, en fait, mais par contre, c'est le plus compliqué à interpréter, parce que les métriques, elles sont souvent volatiles, elles montent et descendent tout le temps, elles ne sont pas stables, ce n'est pas une ligne droite, tout droite. Et donc, quand ça passe, par exemple, de 13,5 à 13,8 Après la mise en production, il n'y a aucune garantie que ce soit grâce à la mise en production et non pas par pure coïncidence. Et donc ça, c'est le risque un peu de l'avant et de l'après. Donc c'est un peu une arme à double tranchant, mais sinon le market test, il peut s'appliquer sur les fonctionnalités qui ont peu de risque d'être susceptibles. aux différences culturelles parce que sinon ça n'a aucun sens. Ce qui peut marcher avec les allemands ne marchera pas forcément avec les français inversement. Donc en fait en fonction des fonctionnalités et en fonction de l'importance de la décision par exemple si on travaille sur une fonctionnalité très importante et qu'on compte continuer à investir dessus des mois, pour moi c'est un peu risqué quand même de partir sur le avant et le après. comme méthode de test, à moins que ce soit durable sur le temps et qu'on observe la variation 6 ou 9 mois après. Donc voilà, ça dépend en fait de certains paramètres et ça devrait arriver avant le passage en produit.
- Speaker #1
Ok, c'est quoi un peu l'impact de la data sur la roadmap ? Comment tu arrives à concilier le roadmapping, la data, la planification des choses ?
- Speaker #0
Très bonne question. Effectivement, pour moi, intégrer la data dans son paradigme produit, ça s'arrête. pas au fait de mesurer après le passage en prod, mais ça devrait aussi se refléter sur la manière de prioriser, de présenter sa roadmap. Et l'idéal pour moi, c'est de partir sur des roadmaps orientés à objectifs et non pas des roadmaps orientés à fonctionnalités. Et donc, ça change complètement d'approche et au lieu du coup de présenter ou de s'engager sur des fonctionnalités, on s'engage à travailler sur tel ou tel objectif. Et donc, au lieu de dire par exemple que je vais le prochain quarter ajouter tel moyen de paiement, par exemple le paiement fractionné sur 4 fois ou par exemple je vais travailler sur la refonte du profil utilisateur, on peut le reformuler d'une autre manière orientée objectif, dire par exemple je vais travailler sur l'augmentation du taux de complétion du profil utilisateur pour essayer de le faire passer de X% à Y% ou de travailler sur le taux de conversion etc. Pour moi, présenter une roadmap basée sur des objectifs, c'est beaucoup plus pertinent que présenter des roadmaps qui s'engagent sur des fonctionnalités.
- Speaker #1
Ce que tu es en train de dire, au final, c'est que la data est partout, que ce soit dans le discovery, que ce soit dans le delivery, que ce soit même dans la planification ou le go-to-market. On doit vraiment anticiper la data en permanence.
- Speaker #0
Tout à fait, c'est bon résumé de ce qu'on vient de discuter.
- Speaker #1
Et pour toi, c'est quoi vraiment les défis principaux qu'il faut surmonter lorsqu'on intègre de la data dans le processus de développement ? produits. C'est quoi les barrières et les obstacles potentiels qu'on risque de rencontrer ?
- Speaker #0
Alors pour les défis ou les barrières, je vais peut-être commencer par le point que tu avais abordé tout à l'heure, le temps, comment trouver le temps pour allier tout ça. En fait, parfois c'est compliqué effectivement et du coup, on dépriorise l'analyse data au profit d'autres tâches ou d'autres sujets. Donc ça, c'est un premier défi. Un deuxième défi, ça pourrait être l'adhérence des parties prenantes, parce que c'est un travail de persuasion pour faire adhérer tout le monde, expliquer l'intérêt. Il y a aussi un enjeu de prise de décision. Au final, on peut travailler sur une métrique qu'on va améliorer, mais au final, elle va avoir un impact négatif sur d'autres métriques, parce que les métriques, elles ne sont pas indépendantes. En fait, elles sont très liées et impactées par une métrique. A peut directement impacter d'autres métriques, baisser, etc. Pour te donner un exemple concret, on prend un outil comme Notion, Figma ou peu importe. L'équipe produit, elle ajoute par exemple la possibilité d'ajouter des commentaires. Ça augmente l'engagement, c'est pas mal. Après, on fait des interviews utilisateurs et les utilisateurs demandent d'ajouter des émojis. Donc on va les développer, on met la fonctionnalité en place. Mais au final, la fonctionnalité est pas mal utilisée, ce qui est bien théoriquement. de premier abord, mais après, avec une analyse un peu plus poussée, on va en fait découvrir qu'au final, les gens, ils commentent moins, il y a moins de commentaires. Ce qu'on tente de mettre des smileys, donc en fait, il faut trancher à ce moment-là quelle est la métrique la plus importante. Et donc ça, ce n'est pas évident à faire parce que ça demande des analyses poussées, ça demande des ressources qui ne sont pas fournies à toutes les entreprises. Alors qu'en fait, on préfère en fait d'investir, de recruter plus de développeurs. ou des product managers, mais pas des data analystes ou des data scientists, alors que leur rôle est hyper important dans la prise de décision et dans le fait de trouver les corrélations, trouver ce qui favorise l'engagement des utilisateurs, ce qui est directement lié au revenu, ce qui ne l'est pas, etc. Donc ces analyses-là, en fait, ils demandent des ressources à l'entreprise et donc pouvoir être conscient de cet investissement et de ce valeur ajoutée pour moi, c'est aussi un défi et un enjeu important.
- Speaker #1
Donc, un vrai problème pour toi de ressources humaines à ce niveau-là, où si on veut avoir des analyses poussées, il faut soit du temps, soit des ressources spécialisées et disponibles pour le faire. Et tu en penses quoi, toi, des personnes qui établissent déjà tout le plan de mesure dans leur discovery et qui, au moment de la mesure, se contentent juste de mesurer les objectifs qui s'étaient fixés, sachant qu'il peut y avoir forcément des surprises lors du déploiement du produit. C'est comme d'hab, le produit change. Les contraintes peuvent changer, le marché peut changer, et souvent ce qu'on a fixé de base comme objectif peut souvent évoluer et ne pas être très relevant.
- Speaker #0
Pour moi, le fait d'avoir un schéma clair de lien entre les différentes métriques, par exemple les métriques sur lesquelles je travaille moins dans ma squad, les métriques de la stream, les métriques du pôle produit d'une manière générale, comment c'est impacté en cascade en fait, et après aussi les métriques d'autres squads, parce que par contre, Par contre, on peut travailler sur une fonctionnalité, une solution qui améliore une métrique d'une squad A, mais qui réduit ou abaisse un peu le score d'une autre métrique, d'une squad B. Donc pour moi, d'abord ça passe par la prise de conscience. Il faut faire attention, il faut surveiller ça après. Et puis peut-être par la formation pour les product managers, ou sinon le recrutement si on a les moyens de faire.
- Speaker #1
On a parlé de métrique produit. On va maintenant parler de métriques de release d'équipe. Comment de ton côté tu arrives à mesurer l'impact réel que peuvent avoir les releases d'un produit ou l'impact d'une équipe en général ?
- Speaker #0
Du coup, premier secret, je dirais... un peu être conscient de son contexte global parce qu'il y a en fait pas mal de pièges dans l'analyse post-release. Par exemple, tu peux avoir des équipes marketing qui se changent de channel de Google, par exemple, à LinkedIn ou à un autre réseau. Et du coup, ça change complètement la qualité ou la qualification des leads qui arrivent. Et donc, on peut, par exemple, dans cet exemple-là, tu peux avoir une augmentation du taux de sign-up, mais elle n'est pas due à une… mise en production, une refonte technique ou graphique, mais plutôt elle est liée à des changements côté marketing. Tu peux avoir par exemple aussi les commerciaux qui participent aux événements un peu suivis, ça impacte directement d'autres métriques. Tu as aussi la saisonnalité, tu as des outils, par exemple des outils, les produits touristiques, ils sont très utilisés pendant les saisons touristiques et d'autres. outils peuvent être utilisés par exemple en fin d'année ou c'est peut-être pendant les vacances, etc. Donc, il faut être conscient des cycles de son produit. Donc, ça, c'est un premier piège à éviter. Deuxième piège à éviter, c'est d'utiliser des nombres et non pas des ratios. Donc, pour moi, il faut toujours partir sur des ratios. Par exemple, le taux de sign-up et non pas le nombre de sign-up, le taux de support et non pas le nombre de tickets support, etc. Une autre bonne pratique de faire des reviews, avec d'autres personnes de l'équipe. Ça pourrait être des développeurs ou d'autres métiers parce qu'on fait une analyse, mais c'est hyper compliqué. On oublie des paramètres, on oublie des événements internes de l'entreprise ou externes et qui peuvent changer complètement l'interprétation des résultats et donc inclure d'autres personnes dans la review de l'analyse. avant de la partager. Pour moi, c'est une bonne pratique. Sinon, c'est de maîtriser des méthodes techniques, on va dire, et on a plusieurs. Après, théoriquement, elles sont complexes, en fait, parce qu'il y a des théories mathématiques derrière tout, mais au final, en pratique, parfois, c'est juste une seule formule. Sur Excel, par exemple, tu es testing ou coefficient de corrélation et ça te donne ton résultat et en cinq minutes, tu peux avoir une interconnexion. qui est mathématique, qui est scientifique, qui est solide et qui peut être partagée. Et donc pour moi, la maîtrise de l'ensemble de ces méthodes, ça pourrait aider pas mal, comme le t-testing, le odds ratio, les coefficients de corrélation. Ce sont toutes des méthodes d'analyse qui sont pertinentes. Peut-être aussi utiliser les outils d'IA. Aujourd'hui, on vit dans une nouvelle ère avec l'émergence des nouveaux outils d'intelligence artificielle. Et puis, en combinant l'IA et l'humain ensemble, c'est toujours mieux que l'humain seul et mieux que l'IA seul aussi. Donc, pourquoi pas ? Pourquoi se priver des outils d'IA ? Pour moi, je commence à les utiliser aussi dans la partie analyse.
- Speaker #1
Tu as quoi comme outils d'IA que tu utilises ?
- Speaker #0
Il y a des outils où tu uploads par exemple ton Excel et ça te permet de générer des insights. Ou sinon, sur un GPT, tu lui fournis ton dataset, tu l'expires. Et puis... tu lui poses la question et après, ça permet de générer des...
- Speaker #1
Des tendances ?
- Speaker #0
Voilà. Et puis, ça permet sur les calculs, je l'avais essayé sur les calculs avec les formules, je préfère Excel parce que parfois, il se trempe sur les calculs, mais par contre, sur les interprétations, je trouve qu'il est plus efficace.
- Speaker #1
OK. Comment tu arrives à combiner tout ça ? Parce que là, tu es en train de donner plusieurs techniques, tu utilises tout, toi, à l'heure actuelle ? à la fois le t-testing, les hautes ratios, la segmentation, mais également les outils d'IA, ou tu es plutôt dans l'expérimentation et tu choisis un outil ou une typologie ou une méthode que tu souhaites utiliser sur un use case particulier ?
- Speaker #0
Oui, en fait, c'est une boîte à outils aussi, donc on s'en sert au besoin. On ne va pas forcément utiliser tous les outils pour une analyse particulière, mais en fonction de ce qu'on essaie de prouver ou pas. On utilise telle ou telle méthode. Elles ont des contextes différents, des objectifs différents. Est-ce que tes variables sont boolean ou non ? Ou est-ce que tu as des variables numériques ? Donc en fonction de pas mal de paramètres, il y a des méthodes qui s'appliquent plutôt que d'autres et qui permettent de prouver ou pas des liens de corrélation pour prouver l'impact à l'avant. Mais un point important pour moi, c'est que... Souvent, avec certaines méthodes, le fait de ne pas prouver la corrélation, ce n'est pas une preuve du contraire. Donc, le fait de ne pas prouver qu'il y a un lien ou qu'il y a une augmentation, ça ne veut pas dire qu'il n'y a pas d'augmentation, mais ça veut dire juste que même s'il y a une augmentation ou une réduction, un chiffre court, on ne peut pas le prouver scientifiquement. Mais ça ne veut pas dire qu'il n'y a pas de différence, par exemple entre le avant et le après, mais il se peut qu'il y ait une différence. que tout simplement on ne peut pas la prouver d'une manière scientifique.
- Speaker #1
D'où le fait de prendre son temps pour pouvoir analyser et ne pas prendre des conclusions à la tête.
- Speaker #0
C'est un peu un risque aussi pour la boîte parce qu'il y a pas mal d'entreprises qui se vantent un peu à des entreprises data-driven, mais au final, tu as pas mal d'analyses ou d'interprétations qui ne sont pas scientifiques. Et le risque là, c'est que les équipes déclarent des chiffres, des impacts tous les quarts d'heure, mais quand tu arrives, tu prends sur le long terme, tu compares à l'année, en début d'année, en fin d'année, tu trouves les mêmes taux, ça n'a pas bougé. qu'au mois de mars, au mois de juillet, etc. On a trouvé, on a annoncé des chiffres dans les métriques, mais puisqu'ils n'étaient pas scientifiques, au final, elles n'étaient pas conformes à la réalité.
- Speaker #1
Donc, on aime un peu mentir aussi sur les chiffres.
- Speaker #0
C'est ça.
- Speaker #1
On a eu cette discussion avec Renaud précédemment qui disait qu'on pouvait faire dire n'importe quoi aux chiffres. On pouvait les utiliser à son escient, d'où la problématique de l'éthique.
- Speaker #0
Je le confirme.
- Speaker #1
Un mot de la fin, peut-être, à nous partager. peut-être sur ce sujet passionnant de la date.
- Speaker #0
Peut-être sur la formation, je pense que c'est important que les personnes en charge des départements de produits qui ont des équipes, qu'ils prennent conscience de cet enjeu et du coup, s'ils ont la possibilité, s'ils ont les moyens, les ressources financières d'investir sur cette partie-là, parce que je pense qu'au final, le retour sur investissement sera bénéfique pour l'entreprise.
- Speaker #1
Sur ces sages paroles, je te remercie, Diya. Tu auras peut-être ? des recommandations ou des personnalités invitées dans notre prochain épisode ?
- Speaker #0
J'aimerais bien peut-être l'un de nos Heads of Product chez Gladys. On a trois Heads of Product et peut-être, j'espère qu'ils acceptent. Sinon, je dirais Claire Vanderwoord. Je la suis sur LinkedIn et depuis un moment, j'apprécie beaucoup ses publications. Je suis confiant qu'elle pourra apporter une valeur ajoutée aux auditeurs et auditrices.
- Speaker #1
Et tu l'avais réparé de quel sujet, Claire ?
- Speaker #0
La refonte technique, elle fait pas mal de publications sur la refonte technique et le fait de leur associer des objectifs et tout. Et je pense que c'est un sujet important parce que dans le site de vie de tout produit, on passe forcément un jour ou l'autre par des refontes techniques. Et donc, je pense qu'elle a une expertise et une expérience sur ce sujet très intéressante.
- Speaker #1
Super sujet, en tout cas. Tu as peut-être un mot de la fin pour conclure ce podcast ?
- Speaker #0
Je te remercie, Justin. Je pense que c'était un plaisir. Merci beaucoup pour l'invitation. C'est toujours un plaisir de discuter avec toi des sujets de produits. Et bravo à toi pour cette initiative.
- Speaker #1
Merci infiniment pour cet échange, Dia. Et encore merci à tous nos auditeurs pour leur fidélité. Restez à l'écoute pour notre prochain épisode de Be My Product, où nous espérons accueillir les invités recommandés par Dia. À bientôt pour de nouvelles aventures en product management. Merci à tous de nous avoir suivis dans cet épisode de Be My Product. Votre engouement et votre fidélité nous motivent énormément. Alors n'hésitez pas à soutenir notre chaîne en vous abonnant et en partageant nos cours. N'oubliez pas de visiter également notre site web bimaproduct.com où vous trouverez tous les articles, aux sources et nos cours en ligne, disponibles directement sur notre site. Nous vous retrouvons très bientôt pour de nouvelles interviews passionnantes. A très bientôt !
