L’Écart Produit-Processus : Comment Stopper Cette Fuite Dans Le Budget De Votre Organisation
Lisez la transcription :
Nous expérimentons la transcription de nos podcasts avec un programme informatique. Merci de pardonner toute faute de frappe, le robot n’étant pas exact à 100 % du temps.
Hannah Clark : L’une des grandes forces des organisations agiles, c’est que nous expérimentons et apprenons continuellement pour améliorer nos organisations et les produits que nous offrons. Chaque avancée dans la tech est le résultat d’une forme ou d’une autre d’expérimentation, mais il y a un revers à la médaille : les expériences ne conduisent pas toujours à des résultats positifs. Beaucoup d’expériences sont en réalité très biaisées — et lorsqu’on mise des centaines de milliers de dollars sur le résultat d’une expérience, la dernière chose souhaitée, c’est de devoir prendre des décisions à partir de données erronées. Et le plus inquiétant : la plupart du temps, on ne réalise que les données sont fausses que lorsqu’il est trop tard.
Mon invité aujourd’hui est Manuel Da Costa, fondateur de Effective Experiments. Comme vous pouvez l’imaginer, Manuel a pour mission principale d’aider les organisations à mener de meilleures expérimentations, aboutissant à de meilleures prises de décision produit. Si les bons outils permettent certes d’améliorer expérimentation et analyses de données, il a aussi identifié un phénomène qui apparaît discrètement à la marge des organigrammes, appelé l’écart produit-processus — et il coûte silencieusement des millions aux entreprises technologiques. Entrons dans le vif du sujet.
Bienvenue à nouveau dans le podcast du CPO Club. Je suis aujourd’hui avec Manuel Da Costa.
Manuel, merci beaucoup de nous rejoindre aujourd’hui.
Manuel Da Costa : Bonjour à toutes et à tous ! Hannah, merci de m’avoir invité.
Hannah Clark : Pouvez-vous nous parler un peu de votre parcours et de comment vous en êtes arrivé là où vous êtes aujourd’hui ?
Manuel Da Costa : Bien sûr. Je suis le fondateur d’Effective Experiments. Nous sommes une entreprise qui propose un logiciel pour aider les sociétés à mieux collaborer et prendre de meilleures décisions produit. Mon parcours, eh bien, commence il y a longtemps, dans l’environnement lean startup, où j’ai appris cette approche test & learn de validation. Je suis ensuite arrivé dans le milieu de l’optimisation de conversion, puis doucement vers mon propre produit, où nous aidons vraiment les équipes produit et expérience client à collaborer efficacement.
C’est ce qui m’amène aujourd’hui à raconter cette histoire, ce qui est le but de ce podcast.
Hannah Clark : J’ai hâte d’approfondir ce sujet.
Ce sur quoi nous allons nous concentrer aujourd’hui, c’est un phénomène que vous avez nommé « l’écart produit-processus ». Pouvez-vous commencer par nous expliquer ce que cela recouvre et dans quelles circonstances cela apparaît ?
Manuel Da Costa : Oui, bien sûr. McKinsey a récemment réalisé une étude sur l’écart entre les bonnes et mauvaises pratiques en gestion produit, et au final, cela revient à l’écart entre ce que la direction attend de la manière dont le produit doit être exécuté, et ce qui se passe réellement sur le terrain côté chefs de produits. Nous avons observé cette déconnexion, que j’appelle l’écart produit-processus : c’est vraiment l’écart entre attentes et réalité.
Il y a de nombreuses raisons à cela, nous entrerons dans les détails, mais au final, le management veut de meilleurs produits, et les responsables produit/propriétaires produit ne livrent pas ce que l’on attend. Et cela s’explique par tout un tas de raisons.
Hannah Clark : Approfondissons un peu. Vous avez dit qu’il y avait de nombreux facteurs. Selon vous, quel est le parcours ou l’origine de cet écart — comment en arrive-t-on là ?
Manuel Da Costa : Bien. Regardons déjà ce qu’on demande aujourd’hui aux équipes produit : valider chaque décision prise. L’expérimentation est devenue le moyen essentiel de valider hypothèses et pertinence du produit.
Pour beaucoup d’équipes à qui l’on confie ces expérimentations, elles n’ont pas l’expérience ou le savoir-faire, ou alors seulement des connaissances de surface sur la façon de mener une bonne expérience. Résultat : les décisions issues de l’expérimentation peuvent être biaisées. L’expérimentation menée peut manquer de rigueur — et d’autres éléments entrent aussi en jeu.
On parle ici de collaboration interéquipes, du niveau de conscience des bonnes pratiques, mais aussi de comment prioriser efficacement. Car il y a de nombreux arbitrages dans le produit, surtout avec l’ajout de l’expérimentation : comment prioriser au mieux ce backlog pour un maximum d’impact ?
Voilà certains symptômes constatés sur le terrain, où l’on demande aux équipes d’exécuter et d’intégrer l’expérimentation dans leurs pratiques — sans leur donner le soutien voulu.
Hannah Clark : Qu’est-ce qui manque dans l’équation ? On dirait qu’il y a un manque de compétences type user research chez les responsables produit placés dans cette position, ce qui entraîne un effet domino de résultats biaisés… Quels sont selon vous les facteurs principaux de ce manque de préparation ?
Manuel Da Costa : Regardons où intervient l’expérimentation. Dans beaucoup d’organisations, c’était le domaine des équipes marketing/CRO (Conversion Rate Optimization), parfois portées par une petite équipe de centre d’excellence. Progressivement, on a demandé à ces experts de transmettre leurs compétences aux équipes produit, pour qu’elles pilotent elles-mêmes leurs expériences. Le premier problème vient du manque de connaissances. On voit souvent des formations, des ateliers, des démonstrations de la méthode, mais tout s’arrête là. Ils sont formés en surface et reçoivent des outils, mais sans ressources pour évaluer leur progrès réel. On se contente de compter le nombre d’expériences menées, mais sans contrôle de rigueur ni d’analyse de la démarche.
Développer ces compétences prend du temps, c’est comme un muscle. Ce n’est pas acquis en une seule fois. Certains chefs de produits mènent de bonnes expériences, parfois simples, ou alors des expériences complexes mal instrumentées… Bref, quand ils remontent les informations à la direction pour faire des recommandations, il s’agit peut-être de données erronées — et ils n’en ont pas conscience, faute de supervision.
Ce qui m’amène au point suivant : c’est l’élément d’encadrement qui manque. Souvent, on accorde une trop grande confiance à ces équipes pour mener les expériences. Mais faute de ressources, personne ne vérifie vraiment la qualité ni la solidité des résultats.
Est-ce le fruit de bonnes ou de mauvaises pratiques ? Voilà un élément clé. Un autre facteur est l’absence d’un vrai niveau de leadership : pas au niveau du product owner, mais au rang de VP produit ou CPO, qui doivent exiger de leurs équipes accountability et leur accorder la marge de manœuvre pour s’exercer, apprendre à mieux expérimenter, mieux décider, mieux prioriser. C’est là que se creuse l’écart entre attentes et réalité, car les équipes n’ont pas la bande passante pour structurer durablement leurs pratiques.
La responsabilité incombe en partie à la direction, qui doit donner mandat et temps pour que les équipes progressent.
Hannah Clark : Concrètement, à quoi cela ressemble-t-il côté leadership ? Quelles démarches les décideurs peuvent-ils entreprendre pour éviter l’ouverture de cet écart produit-processus ?
Manuel Da Costa : La première chose est de définir des KPIs pertinents. Nous voyons souvent des incitations perverses mises en place : par exemple, « lancer x fonctionnalités ce trimestre. » Ça devient alors un jeu de quantités, la qualité ne compte plus, et l’on privilégie la sortie de fonctionnalités même inutiles pour atteindre l’objectif. Il faut donc motiver les équipes avec les bons KPIs, pour qu’elles soient récompensées correctement, pas simplement pour cocher une case.
Deuxième point : offrir aux équipes ainsi qu’à leurs référents assez de marge de manœuvre pour coacher, suivre, faire progresser les équipes produit et les aider à mieux décider progressivement. La bonne expérimentation ne s’improvise pas et ne se résume pas à un atelier de formation…
Il faut accompagner et encadrer les équipes dans la durée. Or, faute de bande passante (souvent due à l’obligation d’atteindre des objectifs de volume), elles stagnent. Le cercle vicieux… Le leadership doit donc donner les moyens de progresser pour permettre de meilleures décisions produit.
Comment y parvenir ? En expérimentant, validant nos hypothèses. La première étape, c’est d’équiper les équipes, leur donner temps, marge de manœuvre, mandat, mais aussi sécurité psychologique. Expérimenter, c’est risquer de se tromper. Si vous fixez des KPIs de type « x % de succès », les gens vont truquer les chiffres. L’expérimentation, c’est avoir une intuition sans certitude : on teste et on analyse le retour marché. Ce n’est qu’alors qu’on décide de poursuivre ou non. Cette sécurité est cruciale : sans cela, on se rabat sur la solution la plus sûre par peur de l’échec, et jamais sur l’innovation réelle.
Hannah Clark : Je vois bien comment cet écart passe sous le radar : les KPIs sont atteints, tout le monde a l’air satisfait, l’entreprise se maintient… Mais il manque quelque chose. Quels sont les symptômes silencieux d’un tel écart et les conséquences de mauvaises décisions issues d’une expérimentation bancale ?
Manuel Da Costa : Si l’expérimentation est biaisée, on le constate : CPOs et VPs ne font plus confiance aux résultats, on revient alors aux décisions à l’intuition, même s’il existe des données. Mais ces données, on les ignore faute de confiance réelle.
Et cela, c’est un symptôme clé. D’autre part, beaucoup d’entreprises affichent des discours « data driven », « orienté produit », « centré client », mais ce sont souvent des mots creux. Dans les faits, on voit sortir des fonctionnalités sans rapport avec les attentes client — une « usine à features » en somme, qui ne crée que peu de valeur business ou client.
Hannah Clark : Y a-t-il des cadres ou frameworks concrets que vous recommandez pour mener de meilleures expérimentations ou quelles démarches mettre en place pratiquement ?
Parce que de ce que j’entends, les causes de l’écart sont multiples. Quelle est, selon vous, la première étape pour commencer à résorber ce problème à l’échelle de l’organisation ?
Manuel Da Costa : Absolument. La première étape, c’est de standardiser les pratiques. Lorsqu’on équipe les équipes produit d’outils d’expérimentation, on se rend compte en comparant deux équipes d’une même organisation qu’elles ont tendance à diverger dans leur façon d’expérimenter, catégoriser et structurer les données. Commencez donc par définir le process à suivre.
Une fois défini, il faut le standardiser. Attention, standardiser ne signifie pas rigidité : l’extrême souplesse mène au chaos et rend les données inutilisables avec le temps.
Standardiser, c’est donc l’organisation des processus, de la classification des données, de la nomenclature, des règles d’analyse et de validation (qui donne le feu vert, etc.), via par exemple un RACI (Responsable, Accountable, Consulté, Informé). Ces garde-fous paraissent rigides, mais ils assurent une continuité même si l’équipe évolue.
Ensuite, il faut relier chaque décision aux objectifs de l’entreprise, pas juste aux KPIs : ne pas saupoudrer au hasard, mais agir en cohérence avec les buts business. Ce double pilier structure la base. Ce sera lent au début, c’est normal, le temps d’intégrer la rigueur dans le backlog, la priorisation, le lancement et l’évaluation des expérimentations.
Après cela, il faut garantir une supervision claire. Cela signifie que n’importe qui peut revenir à postériori sur le travail d’une équipe ou d’un individu pour l’analyser, non pas pour critiquer, mais pour détecter les axes d’amélioration et l’accompagner. Par exemple, « vous avez mené cinq expériences ce trimestre, mais certaines manquent d’une hypothèse solide ou des mauvais indicateurs : voici comment progresser ». On progresse avec feedback positif et suivi.
C’est ce tandem qui permet de refermer l’écart organisationnel.
Hannah Clark : Ce qui est intéressant ici, c’est que cela requiert une certaine intelligence émotionnelle au niveau du management pour piloter de cette manière. Beaucoup repose sur la capacité du leadership et des équipes produit à établir un climat de sécurité psychologique permettant d’essayer, d’échouer, d’apprendre.
Quelles pratiques recommanderiez-vous pour renforcer la confiance et les liens entre les équipes et les niveaux hiérarchiques, surtout lorsqu’un nouveau process est en place ?
Manuel Da Costa : Très bonne question. C’est plus facile à dire qu’à faire car l’humain et l’ego entrent en jeu, il faut accepter de se montrer vulnérable. Mais je pense que cela commence par la direction, qui doit instaurer la sécurité psychologique et modifier légèrement le langage employé.
Il ne s’agit donc pas de succès/échec, mais d’apprentissages. On déplace la discussion des victoires ou défaites vers la validité des idées pour le client, pour la valeur créée, ou d’avoir informé la décision et économisé du temps/de l’argent, ou d’avoir rejeté une piste peu pertinente. Les KPIs et la formation du management, c’est là que tout se joue.
Certes, les équipes voudraient mettre cela en pratique, mais tout est lié aux exigences de leurs KPIs… Le rôle du leadership devient donc central. Sans cela, l’organisation se résume vite à une usine à features, avançant sans réel impact.
Hannah Clark : Cela soulève un point : KPIs et tailles d’équipes varient d’un groupe à l’autre. Comment superviser efficacement à mesure que l’on scale, quand on a des équipes diverses et des nouveaux arrivants avec des niveaux d’expérience variés ?
Manuel Da Costa : Chez nous, on a conçu un rôle d’« orchestrateur », qui selon la taille des équipes, prend en charge la supervision, l’onboarding, le coaching et le mentorat d’un certain nombre d’équipes, et remonte les informations à l’échelon supérieur. Plutôt que d’avoir un leader unique pour tout le monde, un référent par équipe/sous-groupe se concentre sur le soutien à l’exécution des bonnes expérimentations.
Ce rôle d’orchestrateur est essentiel pour garantir l’application des processus, le respect des garde-fous, et dépend de la taille des équipes.
Hannah Clark : Je vous rejoins sur la notion de garde-fous. Même si cela paraît restrictif, en pratique cela réduit la fatigue décisionnelle et clarifie les rôles. Mais comment standardiser aussi l’approche de supervision, surtout lorsqu’on n’a pas soi-même l’expertise de l’expérimentation ?
Manuel Da Costa : Tout part de la création d’un cadre de gouvernance. Cela implique d’instaurer les règles sur la conception d’une expérimentation : quelles données collecter impérativement (hypothèse, vraie hypothèse…), détails techniques, cible, etc. Certaines informations sont obligatoires, d’autres optionnelles — c’est le « minimum requis » de chaque expérimentation.
Le process compte aussi un cheminement obligatoire chaque fois (ex : pas de passage en exécution sans QA, sinon on le détecte). Pour cela, nous avons créé, par exemple, un « scorecard » de santé, une check-list permettant d’évaluer tous les points d’une expérience (hypothèse oui/non, moment de création de l’hypothèse, etc.). Attention au phénomène de « harking », l’invention a posteriori d’une hypothèse pour justifier un résultat. C’est pour éviter ces pièges (sciemment ou non, sous la pression des KPIs) que les garde-fous et le cadre de gouvernance sont primordiaux.
Grâce au scorecard, on identifie si l’expérimentation a été correctement menée. On décide alors si on peut se fier ou non au résultat, ce qui offre des occasions de coaching et d’amélioration continue tant sur les décisions produits que sur la qualité des expérimentations.
Hannah Clark : Merci beaucoup pour ces frameworks. C’est vraiment utile.
Avez-vous un exemple inspirant de transformation permise par la suppression de l’écart produit-processus ?
Manuel Da Costa : Je ne peux nommer l’entreprise, mais nous avons accompagné une structure internationale de e-commerce, où le passage s’opérait d’un centre d’excellence vers des équipes produits et des équipes « marchés ». Nous n’avons pas imposé l’expérimentation à tous d’emblée. Nous avons réalisé une analyse SWOT de chaque équipe, noté leur niveau de connaissance de l’expérimentation et leur motivation.
Nous avons embarqué d’abord les équipes les plus volontaires et compétentes, les avons accompagnées pendant trois mois scindés en sprints, de sorte qu’elles soient autonomes à la fin du programme, puis utilisé ces premiers succès comme social proof pour mobiliser les suivantes, tout en animant une communauté d’entraide. Sur deux ans, malgré le turnover, le temps d’intégration d’un nouvel arrivant est tombé sous un mois, tant le processus était maîtrisé. C’était plus simple de suivre les frameworks que de réinventer de mauvaises pratiques.
Hannah Clark : Merci beaucoup pour ces exemples et tous ces éclairages précieux, Manuel.
Où peut-on vous suivre pour en savoir plus sur votre travail et Effective Experiments ?
Manuel Da Costa : Je suis très actif sur LinkedIn. Vous pouvez aussi visiter EffectiveExperiments.com pour découvrir nos solutions et lire nos articles ! N’hésitez pas à me suivre sur ces plateformes.
Hannah Clark : Parfait, merci beaucoup !
Merci de votre écoute. Pour encore plus de conseils, guides pratiques et tests d’outils, abonnez-vous à notre newsletter sur theproductmanager.com/subscribe. Vous pouvez retrouver plus d’épisodes du CPO Club en vous abonnant là où vous écoutez habituellement vos podcasts.

