Le constat est brutal : la majorité des onboardings sont des cours magistraux. Un prof qui parle. Des élèves qui subissent. Et un taux de décrochage que personne ne mesure parce qu’on ne mesure pas ce qu’on refuse de voir.

Le mur de texte ne tient plus debout

Tu connais la scène. Tu ouvres un produit pour la première fois. Un modal apparaît. Quatre étapes. Des flèches qui pointent vers des boutons. Du texte qui t’explique ce que fait le bouton sur lequel tu t’apprêtais à cliquer.

Tu fermes le modal.

Tout le monde ferme le modal.

Et pourtant, derrière ce modal, il y a une équipe qui a passé des semaines à le construire. Un PM qui a défini les étapes. Un designer qui a peaufiné les illustrations. Un dev qui a branché le tracking. Et au bout du compte, 70% des utilisateurs skip le tout en moins de 3 secondes.

Le product tour est le PowerPoint de l’onboarding. Tout le monde en fait. Personne n’en retire grand chose. Mais on continue parce que “au moins on a couvert le sujet”.

Le problème n’est pas le contenu. Je suis un amoureux du contenu. Le contenu est primordial. Mais le contenu seul, livré avant que l’utilisateur ait fait quoi que ce soit, c’est une conférence à laquelle personne n’a demandé à assister.

Ce que les jeux vidéo ont compris il y a 40 ans

En 1985, Shigeru Miyamoto conçoit le World 1-1 de Super Mario Bros. Pas un tutoriel. Pas un écran d’instructions. Pas un tooltip.

Un écran. Un personnage. Un espace vide à gauche (tu ne peux aller que vers la droite). Un champignon qui avance vers toi. Un bloc doré au-dessus de ta tête.

En 30 secondes, sans un mot, le joueur apprend trois mécaniques fondamentales : le déplacement horizontal, le saut, et la collecte de power-ups. Miyamoto le résume en une phrase : “Once the player realizes what they need to do, it becomes their game.”

Le premier Goomba que tu croises, tu meurs. Le deuxième, tu sautes. Le troisième, tu sautes sans y penser. Tu n’as lu aucune instruction. Tu as appris en faisant. Et surtout, tu as appris en échouant dans un environnement où l’échec ne coûte presque rien.

C’est le principe du safe fail. Les premiers obstacles de Mario sont conçus pour être pardonnants. Tu peux mourir, mais tu recommences deux mètres plus loin. L’erreur fait partie du design. Elle n’est pas un bug du parcours, elle est le parcours.

Portal pousse le concept encore plus loin. Chaque salle est un micro-puzzle qui enseigne une mécanique. Le jeu entier est un onboarding déguisé en expérience. Tu ne lis jamais comment fonctionne le portail. Tu le découvres en tirant sur un mur et en voyant ce qui se passe.

Zelda Breath of the Wild te lâche sur un plateau avec zéro indication. Tu ramasses un bâton. Tu tapes un arbre. Une pomme tombe. Tu la manges. Tu viens d’apprendre le système de nourriture, de combat et d’inventaire en cassant des trucs au hasard (qui n’était pas du tout du hasard).

40 ans de game design, et la leçon est la même : l’apprentissage par l’action bat l’apprentissage par l’explication. À chaque fois. Sans exception.

Le cerveau n’apprend pas en lisant. Il apprend en faisant.

Ce n’est pas une opinion de game designer. C’est de la neurologie.

Quand tu accomplis une action et que tu obtiens un résultat positif (même minuscule), ton cerveau libère de la dopamine. Pas quand on t’explique ce que tu vas accomplir. Pas quand tu lis un tutoriel. Quand tu fais.

La dopamine n’est pas juste un “shot de plaisir”. C’est un signal d’apprentissage. Les neurones dopaminergiques enregistrent l’écart entre ce que tu attendais et ce que tu obtiens. Si le résultat est meilleur que prévu, pic de dopamine. Le cerveau renforce le circuit. Tu retiens le geste. Tu le reproduis.

C’est exactement ce qui se passe quand tu tapes un bloc dans Mario et qu’une pièce apparaît. Résultat inattendu. Pic dopaminergique. Tu retapes le bloc suivant. Et le suivant. Tu viens d’internaliser la mécanique sans qu’on te l’ait jamais enseignée.

À l’inverse, quand tu lis un tooltip qui dit “Cliquez ici pour créer votre premier projet”, il ne se passe rien dans ton cerveau. Pas d’action. Pas de résultat. Pas de dopamine. Pas d’apprentissage. Tu as lu une instruction. Tu ne l’as pas vécue.

Le mécanisme est encore plus puissant quand la récompense est variable. Les neurones dopaminergiques réagissent davantage aux résultats imprévisibles qu’aux résultats attendus. C’est pour ça que les jeux avec du loot aléatoire créent une boucle d’engagement si forte. Et c’est pour ça qu’un onboarding linéaire et prévisible (”étape 1, étape 2, étape 3, bravo”) tombe à plat. Tu sais exactement ce qui va arriver. Ton cerveau a déjà décroché.

Comment les meilleurs produits appliquent ça (et comment les autres font semblant)

J’ai classé les onboardings étudiés en trois catégories. Les professeurs. Les accompagnateurs. Et les terrains de jeu.

Les professeurs t’expliquent le produit avant de te laisser l’utiliser. Product tour en 5 étapes. Vidéo de bienvenue de 2 minutes. Article “Getting Started” de 800 mots. C’est la majorité. C’est ce qui ne fonctionne pas.

Les accompagnateurs te guident pendant que tu fais. Slack est l’exemple le plus propre. Au lieu de t’expliquer comment envoyer un message, l’app te connecte directement à un chatbot (Slackbot) et te fait écrire ton premier message. Tu apprends en faisant la chose que tu es venu faire. L’empty state (l’écran vide avant que tu aies créé du contenu) n’est pas un vide à combler par du texte explicatif. C’est une invitation à agir. Et Slack pousse la logique jusqu’au bout : pas de popup de permissions, pas de notification de vérification d’email, pas de distraction administrative tant que tu n’as pas embrassé le produit.

Contentsquare fait pareil, mais en ajoutant une couche sociale. Après l’installation, chaque fois que tu découvres un nouvel outil, l’app célèbre ta progression. Et elle te montre ce que tes coéquipiers ont découvert de leur côté. Tu n’es pas seul dans un tutoriel. Tu fais partie d’une vague.

Les terrains de jeu te laissent expérimenter la valeur avant même de t’inscrire. Duolingo repousse la création de compte au maximum. Tu choisis un objectif, tu fais ta première traduction, et c’est seulement après avoir vécu la valeur que l’app te demande de sauvegarder ta progression. L’inscription devient un acte de conservation, pas un droit d’entrée.

Dans chaque cas, le pattern est le même : l’action précède l’explication. L’utilisateur fait avant de comprendre. Et c’est en faisant qu’il comprend.,

La bonne friction : quand contraindre, c’est libérer

L’intuition classique en product management, c’est de supprimer la friction. Rendre le chemin le plus fluide possible. Réduire les clics. Enlever les étapes.

C’est souvent la bonne approche. Mais pas toujours.

Sur l’une des études que j’ai menées, le produit avait un onboarding ouvert. L’utilisateur arrivait sur un dashboard avec 6 options possibles. Liberté totale. Et le résultat : paralysie. Les gens ne faisaient rien. Ou ils faisaient n’importe quoi, dans n’importe quel ordre, et ne trouvaient jamais la valeur.

La version qui a converti : un chemin unique, contraint, avec un template pré-rempli et trois clics pour lancer la première action. Moins de choix. Plus d’action. Meilleure activation.

C’est contre-intuitif, mais c’est exactement ce que font les jeux vidéo. Les premiers niveaux de Mario ne te donnent pas accès à toutes les mécaniques. Tu ne sais pas courir avant le deuxième écran. Tu ne découvres les tuyaux qu’après les blocs. Le jeu verrouille volontairement des éléments pour s’assurer que tu maîtrises les bases avant d’accéder à la suite.

En SaaS, ça se traduit par un principe simple : verrouille les fonctionnalités avancées tant que l’action d’activation n’a pas été réalisée. Pas pour frustrer. Pour guider. La friction intentionnelle crée un chemin. L’absence de friction crée un parking.

Le Time-to-Value n’est pas un KPI. C’est un verdict.

Le Time-to-Value mesure le temps entre le moment où l’utilisateur s’inscrit et le moment où il ressent concrètement la valeur du produit. Ce moment s’appelle l’Aha Moment. Et il correspond toujours (toujours) à une action, pas à une lecture.

Pour Calendly, c’est la synchronisation du calendrier et la planification de la première réunion. Pour Opal, c’est la sélection des apps à bloquer et la visualisation du temps récupéré. Pour un outil d’automatisation LinkedIn, c’est le lancement de la première campagne.

Dans chaque cas, l’Aha Moment est un verbe. Pas un nom. Pas “comprendre le produit”. Faire quelque chose avec.

Et c’est là que le parallèle avec le jeu vidéo revient. Mario ne te demande pas de comprendre le saut. Il te met devant un trou. Tu sautes ou tu tombes. L’Aha Moment de Mario, c’est le premier trou franchi. Pas la lecture du manuel.

Si ton onboarding ne conduit pas l’utilisateur à exécuter l’action qui déclenche la valeur en moins de 3 minutes, tu as un problème structurel. Pas un problème de contenu. Pas un problème de design. Un problème de conception du parcours.

Ce que tu emportes

L’onboarding n’est pas un transfert de connaissances. C’est un processus comportemental. Tu ne changes pas ce que l’utilisateur sait. Tu changes ce qu’il fait.

Deux principes qui tiennent dans toutes les études que j’ai menées :

Le contenu vient après l’action, pas avant. Help center, articles, vidéos, tout ça a de la valeur. Mais sa place est en support, pas en première ligne. L’utilisateur qui a fait sa première action pose de meilleures questions que celui qui a lu le guide complet.

La contrainte bien placée bat la liberté totale. Un chemin unique vers la première victoire convertit mieux qu’un dashboard ouvert avec 12 possibilités. Les jeux vidéo le savent depuis 40 ans. Les meilleurs produits SaaS commencent à le comprendre.

Miyamoto l’a dit mieux que n’importe quel PM : quand le joueur comprend ce qu’il doit faire, le jeu devient le sien. Quand ton utilisateur fait sa première action, le produit devient le sien. Tout le reste, c’est de la mise en scène.

Julien. Senior PM, 10+ ans à structurer ce qui craque dans les scale-ups.

Il y a quelques mois, j’ai ouvert Notion pour créer une page. J’ai atterri sur un écran qui me proposait de connecter mon calendrier, de configurer mon mail, de tester un agent IA, de créer un site web, et de paramétrer des automatisations. Avant d’écrire une ligne.

J’ai fermé l’onglet. J’ai ouvert un Google Doc.

Ce moment m’a frappé. Pas parce que Notion était devenu mauvais. Mais parce que je ne le reconnaissais plus. Le produit que j’aimais pour sa clarté me demandait maintenant de choisir entre 14 portes d’entrée avant de faire le truc pour lequel j’étais venu.

Notion a 100 millions d’utilisateurs. 2,7 milliards de dollars levés. La moitié des scale-ups européennes l’utilisent. Et une bonne partie de ces utilisateurs ne touchent qu’à 15% du produit.

C’est exactement ça, l’obésité fonctionnelle.

Le syndrome du buffet à volonté

L’obésité fonctionnelle, ce n’est pas un produit qui a trop de features. C’est un produit dont chaque feature est rationnelle, mais dont la somme produit de la confusion. J’avais décortiqué le concept dans PSF #11. Cette fois, on passe de la théorie au cas concret.

Notion en 2022, c’était un éditeur de docs avec des bases de données. Propre. Clair. Tu ouvrais Notion, tu savais ce que tu venais y faire.

Notion en 2026, c’est un workspace all-in-one avec mail, calendrier, sites web, agents IA, formulaires, automatisations, et un système de permissions qui ressemble à un arbre de décision de la Sécurité Sociale.

Le passage de l’un à l’autre ne s’est pas fait en un jour. Il s’est fait feature par feature. Chaque ajout avait sa slide de présentation, son Product Hunt launch, et son thread Twitter qui expliquait pourquoi c’était la prochaine étape logique.

Et c’est là que le piège se referme. Parce que chaque étape était logique. Le calendrier après les bases de données. Le mail après le calendrier. Les agents IA après le mail. Chaque slide de roadmap tenait la route.

La logique locale est impeccable. Le résultat global est un buffet où personne ne sait par quoi commencer.

Ce que Notion a fait (et pourquoi ça se défend)

Soyons précis. Notion n’a pas fait de la feature factory par incompétence. Leur stratégie est lisible : devenir le système d’exploitation du travail. Remplacer Google Workspace, Confluence, Trello, Airtable, Calendly, et maintenant Gmail. Un seul abonnement, un seul login, une seule source de vérité.

Sur le papier, c’est la promesse parfaite. Un outil pour tout. Moins de contexte switching. Moins de données éparpillées. Moins de factures SaaS à justifier au CFO.

Et les chiffres leur donnent raison. La rétention est forte. Le NRR tient. Les équipes Enterprise signent.

Le problème n’est pas dans les métriques business. Il est dans ce que les métriques ne montrent pas : la perception de complexité côté utilisateur.

Pourquoi on adore les produits obèses (et pourquoi Notion le sait)

Et là il faut être honnête. On est complices.

Tu te souviens de la dernière fois que tu as comparé deux outils SaaS ? Tu as choisi celui qui avait le plus de features. Pas parce que tu allais toutes les utiliser. Parce que tu aimais savoir qu’elles étaient là. “Au cas où.”

Ce mécanisme a un nom en économie comportementale : l’option value. La valeur perçue d’avoir accès à une capacité, indépendamment de son usage réel. Tu paies 20€/mois pour Notion, et quelque part dans ta tête tu te dis : “si un jour j’ai besoin d’un site web, je n’aurai pas à chercher un autre outil.” Tu ne construiras probablement jamais ce site. Mais l’option te rassure. Et cette rassurance, tu la paies.

En 2005, trois chercheurs (Thompson, Hamilton et Rust) ont publié une étude devenue classique sur ce qu’ils appellent la “feature fatigue”. Leur découverte : au moment de l’achat, les consommateurs préfèrent systématiquement le produit avec le plus de features. Plus de boutons, plus d’options, plus de possibilités. Le cerveau interprète ça comme “plus de valeur”. Mais après quelques semaines d’usage, la satisfaction s’inverse. Le produit avec moins de features génère plus de satisfaction que le produit avec plus. L’attraction et l’expérience divergent.

Notion a compris ce mécanisme. Chaque feature ajoutée renforce l’attraction du produit pour les nouveaux utilisateurs et les décideurs qui signent les contrats Enterprise. Le site de pricing affiche une liste qui s’allonge. La comparaison avec les concurrents tourne en faveur de Notion. Sur le papier, c’est imbattable.

Le prix se paie après. Quand l’utilisateur ouvre le produit le mardi matin et se demande par où commencer.

Les trois symptômes de l’obésité fonctionnelle

L’obésité fonctionnelle n’apparaît pas dans un dashboard. Elle apparaît dans les comportements.

1. L’usage fantôme

L’utilisateur a accès à 40 features. Il en utilise 6. Les 34 autres existent dans son interface sans qu’il sache ce qu’elles font ni pourquoi elles sont là.

Chez Notion, c’est visible. Combien d’utilisateurs utilisent Notion Mail ? Notion Calendar ? Notion Sites ? Les agents IA ? Si la réponse est “une fraction des utilisateurs actifs”, le produit transporte du poids mort. Ce poids mort n’est pas gratuit. Il ralentit les temps de chargement, il encombre l’interface, et surtout il envoie un signal au cerveau de l’utilisateur : “cet outil est plus compliqué que ce dont tu as besoin.”

2. La fatigue de configuration

Chaque nouvelle capacité demande un temps de setup. Un calendrier, ça se connecte. Un mail, ça se configure. Des agents IA, ça se paramètre. Des automatisations, ça se construit.

Le produit qui se lançait en 5 minutes en 2022 demande maintenant une semaine d’onboarding en 2026. Et l’onboarding n’est pas ponctuel. L’utilisateur qui pensait avoir fini de configurer son workspace découvre un nouveau panneau de settings tous les trimestres. Ce budget cognitif, tu le dépenses en continu.

3. La dilution de l’identité

Notion en 2022, tu pouvais le décrire en une phrase : “Un éditeur de docs avec des bases de données intégrées.”

Notion en 2026, essaie de le décrire en une phrase. Tu ne peux pas. C’est un “connected workspace”, un “all-in-one”, un “operating system for work”. Des mots qui disent tout et rien. Le signe qu’un produit a perdu son pitch, c’est quand il a besoin de trois phrases pour expliquer ce qu’il fait.

Et quand un produit ne sait plus se raconter en une phrase, ses utilisateurs ne savent plus le recommander. La viralité organique, celle qui a construit Notion pendant des années, s’effrite.

Le framework : diagnostiquer l’obésité fonctionnelle dans ton propre produit

Notion est un cas d’école. Mais regarde ton propre produit. Le même pattern s’y installe si personne ne le surveille.

Étape 1 : Le ratio d’usage réel

Prends le nombre total de features actives dans ton produit. Divise par le nombre de features qu’un utilisateur médian touche en 30 jours.

Si le ratio dépasse 3, tu transportes du poids mort. Si le ratio dépasse 5, ton produit est obèse.

La plupart des équipes produit ne calculent jamais ce ratio. Elles mesurent l’adoption de chaque feature individuellement. Chaque feature à 20% d’adoption, ça passe. Mais dix features à 20% d’adoption, ça fait un produit où 80% de la surface est invisible pour chaque utilisateur.

Étape 2 : Le test de la phrase unique

Demande à cinq utilisateurs différents : “C’est quoi [ton produit] ?” Si tu obtiens cinq réponses différentes, ton produit a un problème d’identité. Et un problème d’identité est le premier signe d’obésité fonctionnelle.

L’identité d’un produit, c’est l’intersection de ce qu’il fait le mieux et de ce que l’utilisateur retient. Quand l’intersection rétrécit, le produit est en train de se diluer.

Étape 3 : Le coût de la feature suivante

Avant d’ajouter la prochaine feature, mesure son coût réel. Pas le coût de développement. Le coût système.

Trois questions :

Quel pourcentage des utilisateurs actuels va l’utiliser dans les 90 jours ? Combien de temps de configuration cette feature ajoute-t-elle au setup initial ? Est-ce qu’elle rend le produit plus difficile à expliquer en une phrase ?

Si la réponse au premier point est en dessous de 30%, si le deuxième ajoute plus de 10 minutes, et si le troisième est oui, tu es en train d’ajouter du poids, pas de la valeur.

Étape 4 : Le kill meeting

J’en avais parlé dans PSF #11. Le principe n’a pas changé : un rituel trimestriel où la seule question est “qu’est-ce qu’on arrête ?”

Les features que personne n’utilise. Les options que personne ne comprend. Les settings que personne ne touche.

Chaque feature retirée libère de la surface cognitive pour l’utilisateur et du temps machine pour l’équipe. La roadmap progresse aussi par soustraction.

Pourquoi Notion ne fera probablement rien

Le paradoxe de l’obésité fonctionnelle, c’est que les signaux d’alerte ne remontent pas dans les métriques que les boards regardent.

Le MRR monte ? Oui. La rétention tient ? Oui. Les Enterprise signent ? Oui.

Alors pourquoi changer ?

Parce que l’obésité fonctionnelle tue à retardement. Les utilisateurs ne partent pas d’un coup. Ils se désengagent progressivement. Ils utilisent Notion pour les docs mais Google Calendar pour le calendrier. Notion pour les bases de données mais Slack pour les notes rapides. Notion pour les projets mais Linear pour le delivery.

Le produit reste installé. Le logo reste dans le tech stack. L’utilisateur est encore là dans les métriques. Mais il ne recommande plus. Il ne défend plus. Et quand un concurrent arrive avec une promesse plus simple, il part sans prévenir.

C’est le scénario Evernote. Evernote n’est pas mort parce qu’un concurrent l’a tué. Evernote est mort parce qu’il a ajouté un chat, un calendrier, un scanner, un gestionnaire de tâches, un éditeur de présentations. Chaque ajout “logique”. L’ensemble incompréhensible. Les utilisateurs sont partis vers des produits qui faisaient une chose bien.

Ce que ça change pour toi

L’obésité fonctionnelle n’est pas un problème Notion. C’est un pattern que tout produit en croissance reproduit s’il n’y fait pas attention.

Le réflexe naturel d’une équipe produit sous pression, c’est d’ajouter. Une feature pour le client qui menace de churner. Un module pour le marché adjacent. Une intégration pour le partenaire qui insiste. Le backlog grossit par petits oui raisonnables.

Et un jour tu te retournes. Le produit fait tout. L’utilisateur ne sait plus quoi.

Le travail du PM dans ces moments, ce n’est pas de construire. C’est de protéger la surface cognitive du produit. De s’assurer que chaque utilisateur comprend ce qu’il a devant lui. De se battre pour que le produit reste racontable en une phrase.

Et ça, c’est le travail le moins visible et le plus ingrat du product management. Personne ne célèbre un PM qui a dit non à 12 features ce trimestre. Tout le monde célèbre celui qui a livré un gros chantier. Mais dans cinq ans, c’est le premier qui aura raison.

Julien Brionne. Si ton produit ne suit plus ta croissance. C’est là que j’interviens.

Intro

En 2007, Radiohead a mis In Rainbows en ligne. Pas de label. Pas de prix fixe. Un champ texte : “pay what you want”. Le monde de la musique a parlé de folie. Le monde du produit aurait dû prendre des notes.

38% des gens ont payé. Prix moyen : 6 dollars. L’album s’est vendu ensuite en version physique premium (diskbox à 40 livres) à plus de 100 000 exemplaires. La tournée qui a suivi a été la plus rentable de leur carrière.

Radiohead n’a pas fait de la charité. Ils ont fait du PLG avant que le terme existe.

Le modèle Radiohead : détruire l’intermédiaire pour créer la relation

Le label, dans la musique, c’est ton Sales team, ton Marketing, ton Canal de distribution, et ton landlord en même temps. Il prend 85% et te dit merci. Radiohead a coupé tout ça d’un coup. Direct-to-fan. Zéro intermédiaire.

Ce qui est intéressant, c’est pas le geste politique. C’est la mécanique produit derrière.

Le “pay what you want” n’était pas une expérience philosophique. C’était un funnel. Le gratuit (ou quasi-gratuit) était le hook d’acquisition. Le diskbox à 40 livres était l’upsell. La tournée était la monétisation récurrente. Trois étages. Un pipeline.

La version gratuite de ton produit ne sert pas à “démocratiser l’accès”. Elle sert à créer un engagement suffisant pour que l’upgrade devienne évident. Radiohead l’a compris en 2007. La moitié des SaaS ne l’a toujours pas compris en 2026.

Et le résultat le plus contre-intuitif : les gens qui ont payé 0 ont quand même écouté l’album. Ils sont venus au concert. Ils ont acheté le vinyle ensuite. Le free tier n’est pas une perte. C’est un investissement en activation.

Trent Reznor : le freemium comme architecture, pas comme concession

Un an après Radiohead, Trent Reznor (Nine Inch Nails) sort Ghosts I-IV. 36 morceaux instrumentaux. Les 9 premiers : gratuits, sans DRM, téléchargeables en un clic. Le reste : payant, avec des tiers de prix. 5 dollars pour le MP3. 10 pour le FLAC. 75 pour l’édition limitée. 300 pour l’ultra-limitée signée à la main.

Résultat : 1,6 million de dollars en une semaine. Sans label. Sans pub. Sans playlist Spotify.

Ce que Reznor a fait, c’est du tiered pricing avec un free tier généreux. Et le free tier n’était pas une version dégradée. C’étaient les 9 meilleurs morceaux. Pas un teaser de 30 secondes. Pas une version avec un watermark. Le vrai produit, en vrai qualité, en vraie quantité.

C’est l’erreur classique du freemium SaaS : donner une version si limitée que personne ne comprend la valeur. Reznor a fait l’inverse. Il a donné assez pour que la valeur soit évidente. Et ensuite, il a vendu la profondeur.

Le hook gratuit doit être bon. Pas “suffisant”. Bon. Si ton free tier ne crée pas de fans, il ne crée rien du tout.

Prince : quand tu ne possèdes pas ton produit, tu ne possèdes rien

1993. Prince écrit “slave” sur sa joue et se renomme en symbole imprononçable. Le monde entier pense qu’il a pété un câble. En réalité, il mène une guerre de 7 ans contre Warner Bros pour récupérer ses masters.

Le deal était simple (et familier) : Warner possédait chaque note que Prince enregistrait. Il pouvait créer autant qu’il voulait. Mais tout appartenait à la plateforme. Son nom, ses morceaux, sa discographie entière. Prince était le créateur le plus prolifique de sa génération, et il ne possédait pas son propre catalogue.

La leçon PM est brutale : tu builds sur une plateforme que tu ne contrôles pas, tu es locataire. Tu as les clés de l’appartement, tu peux refaire la déco, inviter des gens. Mais le propriétaire décide quand il augmente le loyer. Ou quand il te met dehors.

C’est le développeur qui construit son produit sur une API tierce sans plan B. C’est la marketplace qui dépend à 100% du trafic Google. C’est le SaaS qui build son core sur AWS sans jamais penser à la portabilité. Tant que la plateforme est alignée avec tes intérêts, tout va bien. Le jour où elle ne l’est plus, tu découvres que tu n’as jamais rien possédé.

Prince a payé le prix fort. Il a livré des albums volontairement médiocres à Warner pour épuiser son contrat. Il a sacrifié 7 ans de carrière pour récupérer le contrôle. En 2014, il a racheté ses masters. À ce moment-là, il possédait enfin ce qu’il avait créé depuis le début.

La question que chaque PM devrait se poser : si ta plateforme décide demain de changer les règles, qu’est-ce qui t’appartient encore ? Si la réponse est “pas grand-chose”, tu n’as pas un produit. Tu as une permission révocable.

Jay-Z et Tidal : quand le positionnement premium ne suffit pas

2015. Jay-Z rachète un service de streaming et le rebaptise Tidal. Positionnement : “artist-owned”, audio haute fidélité, contenu exclusif. 19,99 dollars par mois pour le tier HiFi. Contre 9,99 chez Spotify.

Sur le papier, c’est de la différenciation premium classique. En pratique, Tidal n’a jamais dépassé quelques millions d’abonnés. Spotify en comptait dix fois plus à la même période.

Le problème n’était pas le prix. Le problème était que personne n’avait demandé ce produit. “Artist-owned” est un argument qui parle aux artistes, pas aux utilisateurs. “Audio HiFi” est un argument qui parle aux audiophiles, soit 2% du marché. L’exclusivité créait de la friction, pas de la valeur.

Jay-Z a fait l’erreur inverse de Radiohead. Il a construit un produit autour de ce que les créateurs voulaient (meilleurs royalties, contrôle créatif) sans valider que les utilisateurs en avaient quelque chose à faire.

C’est le PM qui build la feature que l’équipe veut livrer plutôt que celle que l’utilisateur attend. Le positionnement était cohérent en interne. Il était invisible en externe.

La leçon tient en une phrase : un produit premium sans demande premium, c’est un produit cher que personne n’achète.

La prochaine fois que tu designs ton pricing, ton onboarding, ou ta stratégie d’acquisition, demande-toi ce que ferait un musicien qui n’a plus de label. Pas de budget pub. Pas de sales team. Juste un produit et des gens qui l’écoutent.

La réponse est souvent plus claire quand tu retires les intermédiaires de l’équation.

Julien Brionne. Je structure les orgas produit des scale-ups en croissance. Et j’écoute In Rainbows en boucle pendant que je le fais.

Les deux ont raison.

Et les deux vont passer les 6 prochains mois à se contourner mutuellement en souriant dans les all-hands.

J’ai vu cette scène chez Heetch, chez Back Market, chez Waalaxy. Mêmes rôles, mêmes frustrations, mêmes regards en coin pendant le stand-up. Seul le nom de l’entreprise change.

L’industrie a inventé un terme pour ça : “stakeholder management.” Comme si les gens qui bossent avec toi étaient des variables à mitiger. Des inputs à trier. Des risques à réduire dans une matrice 2x2 qu’on sort en formation PM le jeudi après-midi.

C’est le cadrage le plus toxique qu’on ait inventé en product management. Et tout le monde fait semblant de le trouver normal.

Le même match, deux terrains différents

L’objectif est le même. Toujours.

Le CSM veut que le client reste. Le PM aussi. L’OPS veut que le process tourne. Le PM aussi. Le VP Sales veut que le produit aide à closer. Le PM aussi (enfin, en théorie).

Personne ne travaille contre le produit. Tout le monde travaille pour une version différente de ce que le produit devrait être demain matin.

Le CSM raisonne en cas client. En urgence du jour. En “ce client va churner si on ne fait pas X avant vendredi.” Son horizon, c’est la semaine. Pas par choix. Parce qu’on lui a collé un SLA et un NPS à maintenir, et que personne ne lui a jamais demandé de penser au-delà.

Le PM raisonne en système. En scalabilité. En “si on fait X pour ce client, on encode une exception que 200 autres vont subir.” Son horizon, c’est le trimestre. Parfois l’année. Parfois le Notion qu’il a écrit en janvier et que personne n’a relu.

Les deux ont raison. Les deux sont incomplets. Et la conversation qui les réconcilierait ne se tient jamais. Parce que le PM ne dit pas “tu as raison, ce client souffre, et je ne sais pas quand on résoudra son problème.” Et le CSM ne dit pas “je sais que ma demande est un cas particulier, mais j’ai besoin que tu l’entendes quand même.”

À la place, on a un ticket Jira. Créé un mardi. Trié un vendredi. Dépriorisé un lundi. Mort un jeudi. Et un CSM qui, la prochaine fois, ira directement modifier la base de données.

(Oui. Directement en base. On y reviendra.)

Le musée des solutions de secours

Chaque scale-up a son musée. Il n’est dans aucun Notion. Aucun Linear. Aucun Miro. Il est dans les Google Sheets, les Airtable, et les requêtes SQL que les OPS maintiennent en silence depuis des mois.

Un CSM qui a construit un système de tags manuels dans un Sheet pour compenser l’absence de segmentation dans le produit. Chaque lundi matin. 2 heures. Depuis 8 mois. Personne côté produit ne sait que ce Sheet existe. (Il s’appelle “TEMP_segments_v3_FINAL_vraiment_final.xlsx”. Tu connais le genre.)

Des OPS qui font des modifs directement en base de données parce que la fonctionnalité ne couvre pas un edge case. Pas par rébellion. Par nécessité. Le client est au téléphone, la situation est bloquée, et le produit n’a pas prévu que quelqu’un annulerait une commande déjà partiellement remboursée un dimanche. En base, ça prend 30 secondes. Dans le produit, c’est “prévu au Q3.”

Un workflow de gestion des litiges monté entièrement sur Airtable par un lead OPS en 48 heures. Fonctionnel. Utilisé par 15 personnes. Non scalable. Et surtout, totalement invisible pour l’équipe produit qui, au même moment, faisait une discovery sur “l’amélioration de l’expérience de gestion des litiges.”

Ces bricolages ne sont pas des problèmes de discipline. Ce sont des messages. Chaque Sheet dit la même chose : le produit n’a pas résolu ce problème, alors j’ai arrêté d’attendre.

Ce que le produit rate (et c’est nous le problème)

On va commencer par l’autocritique. Parce que le PM n’est pas innocent dans cette histoire. Pas du tout.

Le PM qui ne passe jamais une journée dans la peau du support ne comprend pas pourquoi ses priorités font lever les yeux au ciel. Il lit les données d’usage. Il regarde les funnels. Il parle de “jobs to be done” et de “changement de comportement.” Tout ça est vrai et nécessaire.

Mais il ne voit pas le 9h du matin de l’équipe OPS. Les 15 tickets ouverts. Le client enterprise qui menace de résilier (encore lui). L’outil interne qui plante une fois sur trois. Le process de remboursement qui nécessite 7 clics et 3 copier-coller entre deux interfaces dont une qui met 12 secondes à charger. (Douze. Secondes. Cinquante fois par jour. Fais le calcul.)

Quand tu vis ça tous les jours et que le PM te présente une “vision plateforme à 12 mois” avec des blocs et des flèches, tu décroches. Pas parce que tu manques de hauteur. Parce que personne ne reconnaît la hauteur de ce que tu portes au quotidien.

J’ai fait cette erreur. Arriver en mission avec un plan d’innovation propre et ambitieux pendant que l’équipe en face attendait un fix sur un outil qui leur coûtait 2 heures par jour. Tu sais ce que ça produit ? De la méfiance. L’innovation sans ancrage opérationnel crée de la méfiance. Et la méfiance, une fois installée, ne se répare pas avec un Jira board partagé ni un workshop “empathy mapping.”

Le CSM qui a vu trois refontes annoncées en deux ans sans impact sur son quotidien arrête d’y croire. Il ne le dit pas en réunion. Il sourit, il hoche la tête (on connaît le pattern), et il ouvre son Google Sheet.

Ce que les stakeholders ratent (et pourquoi c’est normal)

Le CSM demande un outil. Ce qu’il décrit en réalité, c’est un symptôme.

“Je veux un bouton pour changer le statut du client” cache un process de gestion des cas qui n’a jamais été designé. “Je veux un dashboard pour voir mes KPIs” cache une absence de définition de ce qu’on mesure et pourquoi. “Je veux pouvoir modifier l’abonnement directement” cache 6 mois de demandes ignorées et un contournement devenu routine.

Le CSM n’a ni le mandat ni le recul pour voir ça. Et c’est normal. On le mesure sur des temps de résolution, des NPS, des taux de rétention à 30 jours. Personne ne lui a jamais demandé de penser au système. On lui a demandé de survivre dedans.

Résultat : il optimise la vitesse. Le PM optimise la cohérence. Les deux s’éloignent un peu plus chaque sprint. Et entre les deux, un no man’s land où les vrais problèmes moisissent en paix.

Le vrai sujet : la circulation

Dans le système que j’utilise pour diagnostiquer les organisations produit, il y a trois couches. Strategy. Operations. Communication. (C’est le SOC, pour ceux qui suivent.)

La plupart des problèmes de stakeholders ne sont ni des problèmes de stratégie (tout le monde veut la même chose) ni des problèmes d’opérations (chacun sait faire son travail). Ce sont des problèmes de communication.

Pas “on ne se parle pas assez.” Ça, c’est ce que les gens disent. La vraie fracture : les décisions, les contraintes, les arbitrages ne circulent pas entre les couches.

Le PM sait pourquoi il a dit non à la demande du CSM. Mais le CSM ne le sait pas. Il voit un ticket fermé avec “Won’t fix” comme commentaire. Pas le raisonnement derrière.

Le CSM sait qu’un client enterprise est en train de décrocher silencieusement. Mais le PM ne le sait pas. Il voit une ligne orange dans un rapport hebdomadaire que tout le monde survole.

Quand les trois couches se déconnectent, chacun optimise son bout. Les OPS optimisent la vitesse. Le produit optimise l’architecture. Le Sales optimise le closing. Trois stratégies parfaitement rationnelles. Trois directions différentes.

La communication n’est pas un “soft skill” dans un système produit. C’est le liant. Sans elle, tu as des équipes compétentes qui construisent trois puzzles différents avec les mêmes pièces.

Ce qui marche (pas du stakeholder management 101)

Je ne vais pas te dire “fais un RACI.” (Si quelqu’un te propose un RACI comme solution, fuis. C’est le symptôme déguisé en remède.)

Utilise les outils de tes OPS pendant une journée. Pas un screenshot dans un Notion. Pas une démo. Assieds-toi et traite 10 tickets. Utilise l’admin. Copie-colle entre les deux interfaces. Ressens les 12 secondes de chargement. Quand tu reviens en comité produit après ça, ta façon de prioriser change. Pas parce que tu es devenu plus empathique. Parce que tu as des données que tu n’avais pas.

Invite un CSM dans ton kick-off discovery. Pas pour valider ta solution. Pour cadrer le problème. Le CSM connaît les 5 cas qui cassent le plus. Il sait quel segment appelle 3 fois avant de churner. Il sait quel workaround tout le monde utilise et que personne n’a remonté depuis 4 mois. Cette information vaut 3 semaines d’interviews utilisateur. Et elle est gratuite. Elle est assise à 10 mètres de toi.

Rends visible le “pourquoi” derrière chaque arbitrage. Le CSM n’a pas besoin d’être d’accord. Il a besoin de comprendre la logique. “On ne fait pas X maintenant parce que Y impacte 10x plus de clients et on a la capacité pour un seul chantier ce trimestre” est une phrase que tout le monde comprend. “C’est pas prioritaire” est une phrase qui crée un ennemi.

Montre ce que tu as fait avec leurs inputs. Le cercle vicieux : le CSM remonte un problème, rien ne se passe (de son point de vue), il arrête de remonter. Le signal meurt. Même si tu ne résous pas le problème, dire “j’ai intégré ça dans l’analyse, voilà où ça en est” maintient le lien. Le silence détruit plus de relations produit/terrain que n’importe quel “non” bien formulé.

Le renversement

Le meilleur produit que j’ai livré n’est pas sorti d’une discovery avec des utilisateurs. Il est sorti d’une conversation avec un CSM qui en avait marre de faire en base ce que le produit aurait dû faire depuis un an.

Il m’a montré son process. 14 étapes manuelles. Des copier-coller entre 3 outils. Un Google Sheet de suivi qu’il maintenait seul. (Nommé “process_exceptionnel_V2_backup”, évidemment.)

Il ne l’avait jamais remonté au produit. “Les deux dernières fois, c’était pas prioritaire. Alors j’ai arrêté de demander.”

Ce process, une fois systématisé, a réduit le temps de traitement de 80%. Pas parce que la solution était brillante. Parce que le problème était évident depuis un an. Personne côté produit ne l’avait vu. Parce que personne côté produit n’avait demandé.

Tes stakeholders ne sont pas des obstacles à gérer. Ce sont les capteurs les plus proches du terrain que tu auras jamais. Si tu les traites comme du bruit à filtrer, tu filtres les signaux qui auraient dû orienter ta roadmap il y a 6 mois.

Arrête de “gérer” tes stakeholders.

Écoute ce qu’ils ont arrêté de te dire.

Julien Brionne. J’interviens dans des organisations produit qui ont grandi plus vite que leur capacité à décider. Depuis 10 ans, sur des produits B2B SaaS et B2C, j’aide des équipes à retrouver la clarté quand les frameworks ne suffisent plus. C’est ce dont je parle dans cette newsletter.

Ce territoire existe dans ta boîte aussi. Tu sais de quoi je parle. L’outil admin qui a été “construit vite” il y a trois ans et qui n’a jamais été repris. Le formulaire de remboursement qui oblige l’agent à ouvrir quatre onglets. Le workflow de gestion des litiges qui fonctionne à coups de Google Sheets et de messages Slack.

Personne n’en est owner. Tout le monde s’en sert.

Le care comme miroir

Le care n’est pas un département annexe. C’est un miroir. Il te montre tout ce que ton produit n’a pas résolu.

Chaque ticket de support est une feature qui manque, un edge case non géré, ou une décision produit que personne n’a prise. Les agents de support ne font pas du support. Ils prennent les décisions que le produit n’a pas prises. Pas par choix. Par défaut.

Un client demande un remboursement partiel, mais le produit ne gère que le remboursement total ? L’agent improvise. Un utilisateur signale un bug qui n’est pas dans la roadmap ? L’agent contourne. Une règle business change mais l’outil interne ne suit pas ? L’agent colle un post-it mental et adapte sa procédure.

Multiplie ça par 50 agents, 200 tickets par jour, et 18 mois sans investissement produit sur les outils internes. Tu obtiens un système parallèle. Un shadow product, construit par le support, qui tourne en dehors de tout contrôle produit. Et qui prend des décisions business sans mandat pour le faire.

Ce que ça coûte de ne pas investir

Le coût n’est pas où tu penses. Ce n’est pas le temps perdu par les agents (même si c’est réel). C’est la dérive des décisions.

Quand le support décide à la place du produit, les règles deviennent arbitraires. Pas par incompétence. Parce que chaque agent interprète différemment une situation que le produit n’a pas tranchée. Un agent rembourse. L’autre refuse. Un troisième escalade au manager qui prend une décision différente des deux premiers.

Le client ne voit pas un produit cohérent. Il voit une loterie.

Et pendant ce temps, le produit “principal” avance. Nouvelles features. Nouvelles intégrations. Chaque nouvelle fonctionnalité qui ne gère pas ses propres exceptions génère du travail manuel en aval. Le care absorbe les imperfections du produit comme une éponge. Plus le produit avance vite, plus l’éponge se gorge.

À un moment, l’éponge déborde. Les agents s’épuisent. Le turnover monte. La qualité de service baisse. Le churn augmente. Et le CEO demande “pourquoi le NPS a baissé” sans voir que la réponse est dans les outils que personne n’a voulu toucher.

Heetch : quand le sujet de personne devient une plateforme

Chez Heetch, l’admin interne était le sujet de personne. Product, Ops et Support s’en servaient tous les jours. Personne n’en était owner. Chaque équipe patchait de son côté. Les Ops ajoutaient des filtres. Le Support demandait des exports. Product ignorait le backlog admin parce que “c’est pas prioritaire”.

La réponse n’a pas été de “refondre l’admin”. La réponse a été de créer une équipe dédiée avec un mandat clair : construire un admin central, agnostique, en architecture BFF (Backend For Frontend). L’idée : que chaque équipe produit puisse alimenter l’admin avec ses propres données et workflows, sans dépendre d’un backlog unique tenu par personne.

L’équipe en charge gérait l’utilisateur interne comme un vrai utilisateur. Comprendre ses parcours. Mesurer son temps perdu. Réduire la friction. Le même réflexe produit que pour un utilisateur externe, appliqué aux agents, aux ops, aux équipes terrain.

Les résultats : +8% d’efficacité Care, +0.6 rides par passager par mois, NPS conducteurs de 3.5 à 4.1.

Ce n’était pas un projet sexy. Personne ne l’a mis dans une keynote. Mais c’est le projet qui a eu le plus d’impact opérationnel de l’année. Parce qu’il traitait l’outil interne comme un produit, pas comme une corvée.

Back Market : le care comme produit à part entière

Chez Back Market, la Care Platform est un exemple de ce qui arrive quand tu traites le care comme un vrai territoire produit. Pas un cost center. Pas un mal nécessaire. Un produit.

Une marketplace de produits reconditionnés génère mécaniquement plus de friction qu’un e-commerce classique. Le client achète un produit “d’occasion”. Il a des questions sur l’état, la garantie, le retour. Le volume de contacts est structurellement élevé. Tu ne résous pas ça en ajoutant des agents. Tu le résous en construisant des systèmes.

Architecture du cycle de vie des Help Requests. Migration du Help Center de Zendesk vers Intercom. Intégration omnicanale. Chaque chantier partait du même constat : le care est un produit, avec ses utilisateurs (les agents), ses métriques (résolution, satisfaction, coût par contact), et ses contraintes d’architecture.

Le signal de maturité, ce n’est pas le NPS. C’est le moment où l’organisation arrête de traiter le care comme une ligne de coût et commence à le traiter comme un levier de rétention.

La grille : est-ce que tes outils internes méritent un investissement produit ?

Pas tous. Certains outils internes resteront des bricolages et c’est acceptable. La question n’est pas “est-ce que c’est beau”. La question est : “est-ce que cet outil prend des décisions business à la place du produit ?”

Quatre signaux qui indiquent qu’un outil interne a basculé de “support technique” à “produit fantôme” :

Les agents ont développé des workarounds documentés. Des Google Docs qui expliquent comment contourner les limitations de l’outil. Si tes agents écrivent de la documentation pour ton produit, ton produit a un problème.

Les exceptions gérées manuellement dépassent les cas nominaux. Quand la majorité du travail de l’équipe consiste à gérer ce que l’outil ne gère pas, l’outil ne fait plus son job.

Plusieurs équipes patchent le même outil indépendamment. Ops ajoute un script. Support demande un export. Product ajoute un filtre. Personne ne voit l’ensemble. Chaque patch résout un symptôme et crée une dette.

Le turnover de l’équipe qui utilise l’outil est plus élevé que la moyenne. Les gens ne quittent pas un métier. Ils quittent un outil qui les empêche de faire leur métier.

Si tu coches deux de ces quatre signaux, tu n’as plus un outil interne. Tu as un produit non assumé. Et chaque mois sans investissement augmente le coût de la reprise.

Ce que tu emportes

Le care, le backoffice, les outils internes : c’est le miroir de ton produit. Si le reflet est flou, ce n’est pas le miroir qui a un problème.

Regarde qui prend les décisions que ton produit n’a pas prises. Regarde où les workarounds s’accumulent. Regarde quel outil fait tourner l’opérationnel sans qu’aucun PM n’en soit responsable.

Ce territoire que personne ne veut, c’est souvent celui qui a le plus d’impact. Pas parce qu’il est glamour. Parce qu’il touche à tout. Le care est la couche qui connecte ton produit à la réalité de tes utilisateurs. Si tu la négliges, tu construis un produit pour un monde qui n’existe que dans tes dashboards.

Julien Brionne. Senior PM freelance. Je structure les orgas produit des scale-ups en croissance.

Personne ne veut répondre. Pas par paresse. Par peur. Renoncer à un projet, c’est admettre qu’on a eu tort de le lancer. Ou pire : que quelqu’un d’autre a eu tort. Et dans une scale-up en croissance, cette conversation-là, personne ne veut l’avoir.

Résultat : on ne ferme rien. On “reporte”. On “rephase”. On colle un “P3” sur un ticket que tout le monde sait mort. Le projet reste dans le backlog comme un fantôme. Il ne bouge plus, mais il occupe de l’espace mental, du temps de sync, et parfois même un bout de sprint quand quelqu’un demande “au fait, on en est où sur ce truc ?”.

Les roadmaps ne meurent pas d’un coup. Elles meurent feature par feature, exception par exception.

Le coût invisible du “oui rapide”

Chaque “oui” a un coût caché. Pas le coût de développement. Celui-là, tout le monde le voit. Le vrai coût, c’est l’empreinte de maintenance. Le poids cognitif. Le nombre de personnes qui doivent se souvenir que ce truc existe, le surveiller, répondre aux questions dessus, le prendre en compte dans le prochain arbitrage.

J’ai bossé avec une équipe produit qui avait 12 features actives. Douze. Pour une squad de cinq. Sur le papier, trois étaient prioritaires. En pratique, les neuf autres mangeaient 40% du temps de l’équipe en maintenance, en support, en “petits ajustements rapides”.

Personne n’avait décidé de garder ces neuf features. Personne n’avait décidé de les arrêter non plus. Elles existaient par inertie. Comme un abonnement que tu paies tous les mois sans jamais ouvrir l’app.

Le “oui rapide” est addictif. Il fait plaisir. Il débloque une conversation. Il donne l’impression d’avancer. Mais chaque oui rapide ajoute une ligne dans un registre que personne ne tient. Au bout de deux ans, tu te retrouves avec un produit qui fait 30 choses moyennement au lieu de 5 choses bien.

Le renoncement comme acte de structuration

On présente souvent le renoncement comme un acte de sagesse. Le leader éclairé qui sait dire non. La maturité produit. Ce genre de récit.

La réalité est moins noble. Le renoncement est un acte de structuration. Tu ne renonces pas parce que tu es sage. Tu renonces parce que si tu ne le fais pas, personne ne sait plus ce qui compte.

Quand tout est prioritaire, rien ne l’est. C’est une phrase qu’on répète tellement qu’elle a perdu son sens. Mais observe ce qui se passe concrètement dans une équipe qui ne renonce pas :

Les PMs passent leur temps à négocier du temps. Pas à construire. À négocier. “Est-ce qu’on peut glisser ça dans le sprint ?” “Est-ce que la tech a de la bande passante pour ce fix ?” Chaque semaine, c’est un marché aux puces.

Les engineers switchent de contexte quatre fois par jour. Ils bossent sur le projet A le matin, patchent le projet B après le stand-up, et répondent à une question sur le projet C avant le déjeuner. La productivité s’effondre, mais personne ne comprend pourquoi parce que tout le monde est occupé.

Les stakeholders ne savent plus quoi attendre. Ils ont entendu “oui” tellement de fois qu’ils ont perdu la capacité de distinguer un vrai engagement d’un oui de politesse.

Le renoncement casse ce cercle. Pas parce qu’il libère du temps (ça aussi, mais c’est secondaire). Parce qu’il recrée de la lisibilité. Quand tu retires trois projets de la roadmap, les cinq qui restent deviennent visibles. L’équipe sait sur quoi elle travaille. Les stakeholders savent quoi attendre. Le PM arrête de négocier et recommence à penser.

Comment les organisations ferment les options (dans la douleur)

Les organisations qui ne renoncent pas tôt finissent toujours par renoncer. Mais tard. Et mal.

Scénario classique. Une scale-up lance quatre initiatives stratégiques en janvier. Aucune n’est staffée correctement parce que les quatre sont “priorité 1”. Au bout de six mois, deux ont avancé à moitié, une est en stand-by non assumé, et la dernière survit grâce à un engineer héroïque qui tient tout seul.

En septembre, le board demande des résultats. Le CEO fait le tri. Deux projets sont coupés en une semaine. Les équipes qui bossaient dessus apprennent la nouvelle un vendredi après-midi. Six mois de travail à la poubelle. Pas parce que les projets étaient mauvais. Parce que personne n’a eu le courage de choisir en janvier.

C’est ça, le vrai coût du non-renoncement. Ce n’est pas l’inefficacité (même si elle est réelle). C’est la violence de la correction tardive. Tu construis une maison sur un terrain que tu n’as jamais acheté. Un jour, le propriétaire revient.

J’ai vu ça chez trois clients différents en deux ans. Le pattern est toujours le même : accumulation silencieuse, puis coupe brutale. Les équipes ne s’en remettent pas facilement. Pas à cause du projet perdu. À cause du sentiment que personne n’avait les mains sur le volant.

Ce qui empêche le renoncement (et ce n’est pas ce que tu crois)

Le frein principal n’est pas l’attachement émotionnel aux projets. C’est l’absence de critères explicites pour décider.

Quand tu n’as pas de critères clairs pour dire “on continue” ou “on arrête”, chaque décision de renoncement devient un débat politique. Qui a lancé ce projet ? Qui l’a sponsorisé ? Est-ce que le VP Sales va mal le prendre si on coupe son initiative ?

La décision ne se prend pas sur la valeur du projet. Elle se prend sur le capital politique de son sponsor. Et ça, personne ne le dit à voix haute.

Le deuxième frein : l’absence de rituels de fermeture. On a des rituels pour lancer des projets. Des kick-offs, des briefs, des roadmap reviews. On n’a aucun rituel pour les fermer. Pas de “kill review”. Pas de moment dans le trimestre où quelqu’un pose la question : “qu’est-ce qui ne devrait plus exister ?”

Si tu n’as pas de moment dédié pour fermer, tu ne fermes pas. C’est mécanique.

Ce que tu emportes

Regarde ta roadmap. Pas les trois projets du haut. Ceux du milieu et du bas. Ceux que personne ne mentionne en stand-up. Ceux qui ont un owner sur le papier mais que personne ne pousse.

Pose-toi une question : est-ce que quelqu’un a explicitement décidé de garder ce projet ? Pas “est-ce qu’il est encore dans le backlog”. Est-ce que quelqu’un s’est levé et a dit “oui, on continue, voilà pourquoi” ?

Si la réponse est non, tu as un zombie. Et chaque zombie mange un bout de ta capacité d’exécution sans que personne ne s’en rende compte.

Deux choses à faire cette semaine. Première : identifier les projets qui existent par inertie. Pas les mauvais projets. Les projets que personne n’a décidé de continuer. Deuxième : créer un moment récurrent (trimestriel suffit) où la seule question est “qu’est-ce qu’on arrête ?”. Pas “qu’est-ce qu’on reporte”. Qu’est-ce qu’on tue.

Le renoncement n’est pas un luxe de leader mature. C’est de l’hygiène. Et comme toute hygiène, si tu ne la pratiques pas régulièrement, les conséquences s’accumulent en silence jusqu’au jour où elles explosent.

Julien Brionne. Senior PM freelance. Je structure les orgas produit des scale-ups en croissance. Si ta roadmap ressemble à un cimetière de bonnes intentions, on devrait parler.

Pose cette question en réunion : “C’est quoi notre produit, en une phrase ?”

Regarde ce qui se passe. Le Head of Product parle de la plateforme. Le Sales parle du use case qui signe. Le CTO parle de l’architecture. Le CEO parle de la vision. Le CS parle de ce que les clients utilisent vraiment.

Cinq personnes. Cinq produits différents. Même boîte.

Personne ne ment. Chacun décrit ce qu’il voit depuis sa fenêtre. Le problème, c’est que le client, lui, voit la façade. Et la façade ne raconte rien.

Le réflexe : “On a un problème de messaging”

Quand ce flou devient visible (le site ne convertit pas, le sales cycle s’allonge, les prospects ne comprennent pas la différence avec le concurrent), la réponse est presque toujours la même. On refait le site. On retravaille le pitch deck. On engage un copywriter. On passe trois semaines à chercher la bonne tagline.

C’est confortable. C’est visible. Et ça ne résout rien.

Parce que le problème n’est pas dans les mots. Il est dans ce que les mots sont censés décrire.

Un produit qui fait 40 choses ne souffre pas d’un défaut de formulation. Il souffre d’un défaut de décision. Personne n’a tranché ce qu’il est, pour qui il existe, et contre quoi il se bat.

Le messaging est un symptôme. Le narratif est un diagnostic.

Ce que le narratif fait au produit

April Dunford raconte un cas qui illustre ce mécanisme mieux que n’importe quel framework. Une startup avec une base de données techniquement supérieure. Personne n’achète. “On a déjà Oracle.” Ils repositionnent le même produit en data warehouse. Zéro changement technique. La croissance explose. La boîte est rachetée.

Mais la suite est encore plus révélatrice. Après le repositionnement, l’équipe a arrêté de coder des features de base de données générique. Toute la roadmap s’est réalignée sur le nouveau narratif. Le data warehouse n’a pas emballé le produit existant. Il a reconfiguré ce que l’équipe construisait.

On pense que le positionnement vient après. Qu’on construit d’abord, qu’on raconte ensuite. Que le narratif est une couche de peinture sur une structure déjà finie.

C’est l’inverse. L’histoire que tu racontes sur ton produit détermine ce que tu construis, ce que tu arrêtes de construire, et ce que tu mesures.

Le jour où on a tué les étoiles

Chez Heetch, j’ai vécu ce mécanisme de l’intérieur. Et pas sur un repositionnement marketing. Sur une décision produit qui a changé la façon dont l’entreprise se voyait elle-même.

Le contexte : le système de notation par étoiles. Celui que toute plateforme VTC utilise. Le passager note le chauffeur de 1 à 5 après chaque course. Le chauffeur note le passager. Système standard, copié sur Uber, considéré comme acquis par toute l’industrie.

Le problème, c’est ce que ce système raconte. Il raconte : “On ne vous fait pas confiance. Alors on laisse l’autre vous juger.” Le chauffeur conduit avec la pression permanente d’une note. Le passager évalue une expérience sur des critères qu’il ne maîtrise pas (le trafic, l’itinéraire, le silence ou la conversation). Personne ne note ce qui compte. Tout le monde note ce qu’il ressent à un instant T.

Les notes étaient un indicateur de satisfaction apparente. En pratique, c’était du bruit déguisé en signal.

On a décidé de tuer le système. Pas de le modifier. Pas d’ajouter des critères. De le supprimer.

J’ai géré l’expérience produit complète de cette transition. On est passés d’un système de notation à un système de retour qualitatif : des compliments pour ce qui allait bien, un signalement structuré quand quelque chose n’allait pas. Le feedback existait toujours. Mais l’histoire racontée au chauffeur et au passager était radicalement différente.

L’ancienne histoire : “Tu es un 4.7.” La nouvelle histoire : “Tes passagers apprécient ta conduite souple et ta ponctualité.”

Même fonction sous le capot (collecter du feedback sur la qualité de service). Narratif opposé.

Ce qu’un narratif change quand il est vrai

Le premier effet a été immédiat sur les chauffeurs. Le NPS a augmenté. La satisfaction a monté. Pas parce qu’on avait amélioré le service. Parce qu’on avait changé la relation entre le produit et les gens qui l’utilisaient.

Le deuxième effet, moins visible de l’extérieur, a été encore plus structurant. La qualité du feedback a augmenté. Quand tu remplaces une note de 1 à 5 par un retour qualitatif, tu obtiens de vrais signaux sur l’expérience. Pas un chiffre aplati. Des informations exploitables. On a commencé à détecter des signaux faibles qu’un système de notation ne captait jamais.

Le troisième effet est celui qui m’intéresse le plus, avec le recul. La décision a contaminé tout le reste. Le narratif “on ne réduit pas des personnes à des notes” n’est pas resté dans un communiqué de presse. Il a changé la façon dont l’équipe pensait le feedback dans l’ensemble du produit. Chaque nouvelle feature qui touchait à la qualité de service passait par ce filtre : est-ce qu’on évalue la personne, ou est-ce qu’on évalue l’expérience ?

Le branding a suivi le produit. Le produit a suivi le narratif. Et le narratif exprimait une décision que la boîte avait prise sur ce qu’elle voulait être.

Heetch était la première plateforme VTC française à supprimer la notation. Ce n’était pas un coup marketing. C’était un choix de positionnement qui disait : on n’est pas Uber. On ne construit pas la même relation avec nos chauffeurs. Et ce choix a redessiné le produit de l’intérieur.

L’absence de narratif est une dette de décision

Quand personne dans la boîte ne raconte la même histoire, ce n’est pas un problème de communication. C’est le signe que personne n’a fait le travail de renoncement.

Un narratif clair exige de trancher. Ce qu’on est. Ce qu’on n’est pas. Pour qui on existe. Qui on accepte de perdre. Quel problème on résout, et lesquels on laisse à d’autres.

Tuer les étoiles chez Heetch, c’était accepter de perdre la comparabilité avec Uber. Accepter que certains investisseurs trouvent ça bizarre. Accepter que le marché ne comprenne pas immédiatement.

Dunford avait dû faire le même renoncement : dire “on est un data warehouse”, c’était accepter de ne plus être une base de données. Et c’est précisément ce renoncement qui a débloqué la croissance.

La plupart des équipes produit esquivent ces décisions. Pas par incompétence. Par peur. Chaque positionnement clair ferme des portes. Et dans une scale-up où la pression est de tout garder ouvert, cette fermeture demande du courage.

Le résultat de l’esquive est prévisible. Le produit essaie de tout raconter parce qu’il essaie de tout faire. Le site web ressemble à une liste de features sans hiérarchie. Le pitch change selon le commercial. Les prospects comparent le produit à n’importe quel concurrent parce que rien ne les aide à comprendre dans quelle catégorie le placer.

T’as livré un produit complet. Mais personne ne sait à quoi il sert.

Le test

Prends cinq personnes dans des rôles différents. Pose la question : “On fait quoi, pour qui, et pourquoi nous plutôt qu’un autre ?”

Si les réponses divergent, le problème n’est pas le wording. C’est que la décision n’a pas été prise.

Et cette décision ne se prend pas dans un atelier messaging. Elle se prend dans un arbitrage stratégique. Qui sommes-nous. Qui nous ne sommes pas. Quel problème on résout mieux que quiconque. Et pour qui.

Le narratif n’est pas la cerise. C’est le test de cohérence de ta stratégie produit.

Si tu n’arrives pas à raconter ton produit en une phrase, le problème n’est pas la phrase.

Je m’appelle Julien Brionne. J’interviens dans des organisations produit qui ont grandi plus vite que leur capacité à décider. Depuis 10 ans, sur des produits B2B SaaS et B2C, j’aide des équipes à retrouver la clarté quand les frameworks ne suffisent plus. C’est ce dont je parle dans cette newsletter.

Les MVP qui détruisent un produit sont ceux que personne ne conteste.

Ceux qui cochent toutes les cases. Faisables techniquement. Acceptables côté business. Validés par le CTO parce que “on pourra itérer”. Approuvés par le CEO parce que “ça montre qu’on avance”. Le genre de décision qui passe en comité sans qu’un seul sourcil se lève.

Et c’est là qu’ils font le plus de dégâts.

Le béton prend vite

Un MVP est un choix tactique. Raisonnable. Documenté. Assumé sur le moment.

Le problème : ce choix encode des contraintes. Des contraintes techniques, des contraintes d’architecture, des contraintes de modèle de données. Et ces contraintes, personne ne les liste au moment de la décision. Elles sont implicites. Elles font partie du décor. Elles sont le prix caché du “on verra plus tard”.

“On verra plus tard” est la phrase la plus chère du product management.

Parce que “plus tard” ne vient pas. Ce qui vient, c’est six mois de features construites sur les fondations du MVP. Des intégrations. Des habitudes utilisateur. Des process internes calés sur le fonctionnement actuel. Du code qui dépend du code qui dépend du choix initial. Le béton a pris. Personne ne va casser le mur pour refaire les fondations.

Et un jour, quelqu’un pose la question : “Pourquoi on ne fait pas X ?” La réponse, après trois heures d’investigation technique : “Parce qu’il y a 18 mois, on a choisi Y.”

Y, c’était le MVP raisonnable.

Ce que tu encodes quand tu livres

Chaque MVP encode trois choses que personne n’écrit dans le PRD :

Une architecture. Pas au sens technique pur. Au sens des relations entre les objets de ton système. Le MVP pose les rails. Tout ce qui vient après roule dessus. Si les rails vont dans la mauvaise direction, tu pédales dix fois plus fort sur un vélo coincé sur des rails qui vont au mauvais endroit (et maintenant t’as un vélo sur des rails, ce qui n’est confortable pour personne).

Un modèle mental utilisateur. Tes premiers users apprennent à utiliser ton produit d’une certaine façon. Ils construisent une carte mentale. Six mois plus tard, changer cette carte coûte plus cher que le pivot technique lui-même. Le support explose. L’adoption stagne. Les users “historiques” deviennent tes plus gros détracteurs.

Une dette de promesse. Le MVP dit au marché : “Voilà ce qu’on fait.” Tes sales vendent sur cette base. Tes clients achètent sur cette base. Revenir en arrière, c’est admettre publiquement que le produit n’était pas ce qu’il prétendait être. Et ça, aucun CEO ne veut le faire.

Le cas qui m’a appris

J’ai vécu ça en première personne. Une boite SaaS B2B. Produit de feedback client. Le MVP avait été construit avec une logique qui tenait la route au moment du choix : on récupère les données, on les affiche, on laisse le client interpréter.

Raisonnable. Rapide. Validé par tout le monde.

Sauf que ce choix encodait une vision passive du produit. Le système collectait, mais ne traitait pas. Il n’analysait pas. Il ne poussait pas d’insight.

Je me souviens du moment précis où on a compris. Un client stratégique demande des alertes automatiques sur ses verbatims négatifs. L’équipe technique ouvre le capot. Silence. Le modèle de données stockait des réponses à plat. Pas de structure relationnelle entre les feedbacks, pas de scoring, pas de couche d’analyse. Pour faire ce que le client demandait, il fallait reprendre les fondations. Pas ajouter une feature. Reprendre les fondations.

Le CTO a regardé le PM. Le PM a regardé le plafond. Tout le monde dans la pièce savait que la décision d’il y a 14 mois venait de se rappeler à nous. Personne ne l’avait contestée à l’époque. Personne n’avait tort à l’époque. Et on était coincés quand même.

Le produit s’est retrouvé entre ce qu’il était et ce qu’il aurait dû devenir. Pas par manque de vision. Par excès de pragmatisme au moment du MVP.

Le pragmatisme sans projection, c’est de la myopie avec une bonne excuse.

“On itérera” : le mensonge par omission

Chaque MVP vient avec cette phrase. “On itérera.” C’est le lubrifiant universel de la décision produit. Ça permet de valider le choix sans assumer le coût réel.

Le mensonge n’est pas dans l’intention. La plupart des gens qui disent “on itérera” y croient. Le mensonge est dans l’omission. Ce qu’on ne dit pas :

On itérera. Si la pression business le permet. Si l’équipe n’a pas changé. Si le contexte est le même. Si le CEO ne décide pas que le prochain trimestre est consacré à un autre sujet. Si personne ne construit trois features qui dépendent du choix actuel entre-temps.

Autrement dit : on itérera dans un monde qui n’existera pas.

L’itération est un luxe qui se planifie. Pas une promesse qui se lance en réunion pour débloquer une décision.

Ce que tu peux faire (concrètement)

Pas un framework. Pas une matrice 2x2. Trois questions à poser avant de valider ton prochain MVP.

Qu’est-ce que ce choix rend impossible dans 12 mois ?

Pas difficile. Impossible. Si personne dans la salle ne sait répondre, c’est que personne n’a regardé au-delà du sprint.

Si on ne revient jamais sur cette décision, est-ce qu’on vit avec ?

Parce que statistiquement, tu ne reviendras pas. Teste la décision comme si elle était permanente. Si elle ne passe pas le test, elle ne devrait pas passer le comité.

Qui dans l’équipe a dit “on itérera” pour débloquer la discussion ?

Identifie cette personne. Demande-lui de préciser : itérer quand, avec quel budget, à la place de quoi. Si la réponse est floue, la promesse est vide.

Le vrai coût

Le coût d’un MVP n’est pas son coût de développement. C’est le coût de tout ce qui se construit dessus en supposant que les fondations sont les bonnes.

Les boites meurent rarement d’un seul mauvais choix. Elles meurent d’un choix raisonnable, suivi de 50 décisions qui en dépendent, prises par des gens qui ne savent même pas que la contrainte initiale existe.

Le MVP raisonnable est dangereux parce qu’il a l’air bien. Il rassure tout le monde. Il passe toutes les validations. Et il encode silencieusement les limites de ce que ton produit pourra devenir.

La prochaine fois que tout le monde dans la salle est d’accord sur le MVP, c’est le moment de t’inquiéter.

Julien Brionne - Je remets de la clarté dans les organisations produit qui ont grandi plus vite que leur capacité à décider.

Le contexte change. Les acteurs changent. Mais la scène est toujours la même.

Quelqu’un ouvre un dashboard. Quelqu’un d’autre ouvre un autre dashboard. Les chiffres sont différents. Pas légèrement différents. Vraiment différents.

J’ai vécu cette scène dans une marketplace B2C à fort volume. La question posée en réunion était simple : combien de transactions avons-nous réalisées le mois dernier ? Quatre équipes dans la salle. Quatre chiffres différents.

Le produit comptait les commandes validées au moment du paiement. La finance comptait le revenu reconnu après expiration de la fenêtre de retour. L’équipe seller success comptait les commandes expédiées. Les opérations marketplace comptaient les transactions clôturées sans litige. Chaque équipe avait raison dans son référentiel. Mais l’organisation n’avait pas de référentiel commun.

La réunion qui était censée prendre une décision sur la roadmap est devenue une réunion sur les chiffres. La décision a été repoussée à la semaine suivante.

Ce n’est pas un problème de données. C’est un problème de définition.

Et ce problème a un coût que personne ne calcule. Chaque heure de réunion passée à débattre des chiffres est une heure de moins sur la stratégie. Chaque faux positif affiché dans un dashboard retarde une décision difficile que l’organisation aurait dû prendre. Chaque roadmap construite sur des métriques contestées aboutit à des arbitrages qui ne tiennent pas. Ce n’est pas un dysfonctionnement opérationnel. C’est une perte de capacité décisionnelle, semaine après semaine, invisible dans les comptes mais réelle dans les résultats.

Et derrière ce problème, il y a presque toujours la même cause racine : l’organisation a acheté des outils sans décider qui possède les définitions.

Ce qu’une source of truth est vraiment

Le terme est partout. Il figure dans les présentations de data teams, dans les appels d’offres pour des outils BI, dans les fiches de poste de Data Engineers. Et pourtant, la plupart des organisations n’en ont pas.

Une source of truth n’est pas un outil. Ce n’est pas Amplitude, ni Looker, ni BigQuery, ni Snowflake. Ces outils peuvent héberger une source of truth. Ils ne la créent pas.

Une source of truth est un ensemble de définitions partagées, assumées, et maintenues dans le temps. Elle répond à des questions qui semblent simples jusqu’au moment où vous essayez d’y répondre collectivement.

Qu’est-ce qu’un utilisateur actif dans votre produit ? Quelqu’un qui s’est connecté dans les 30 derniers jours ? Dans les 7 derniers jours ? Quelqu’un qui a réalisé au moins une action de valeur, et quelle action exactement ? Est-ce que deux comptes différents sur le même email comptent pour un ou pour deux ?

Qu’est-ce qu’une conversion ? Le moment où l’utilisateur crée un compte ? Le moment où il réalise sa première action de valeur ? Le moment où il passe en version payante ? Le moment où il atteint votre definition of activation ?

Qu’est-ce que votre MRR réel ? Est-ce que vous comptez les clients en période d’essai ? Les clients qui ont un contrat annuel payé en une fois ? Les clients sur des tarifs négociés hors grille ?

Ces questions ne sont pas techniques. Ce sont des questions de stratégie déguisées en questions opérationnelles. Et la réponse que vous y apportez, ou que vous n’y apportez pas, détermine ce que votre organisation est capable de voir, de mesurer, et donc de piloter.

Le piège du buy : vous achetez un outil, vous adoptez ses définitions

Quand une organisation achète un outil d’analytics produit, elle pense acheter de la visibilité sur son produit. Ce qu’elle achète en réalité, c’est un modèle de données préconçu avec des définitions embarquées qu’elle va progressivement adopter comme si c’étaient les siennes.

Prenons un cas concret.

Une plateforme e-commerce opérant dans 18 marchés gère 2 000 articles dans son Help Center via un outil acheté. Le vendor permet à chaque marché de maintenir sa propre version de chaque article. En apparence, c’est de la flexibilité. En réalité, c’est 3 600 versions à maintenir, aucune source of truth en anglais, et aucune visibilité sur les écarts de contenu entre marchés.

Quand l’organisation évalue une migration vers un nouveau vendor, la question n’est plus fonctionnelle. Elle est architecturale : quel outil supporte nativement une logique “one English source of truth + contenu conditionnel par marché” ? La réponse, après évaluation de plusieurs solutions, est : aucun ne le fait bien. Les dynamic content blocks ne sont pas dans les roadmaps.

À ce stade, l’organisation est face au vrai problème. Ce n’est pas un problème d’outil. C’est la conséquence de ne pas avoir défini l’architecture de sa source of truth avant d’acheter. Le vendor a absorbé la gouvernance du contenu par défaut. Et maintenant, changer de vendor sans traiter ce problème revient à migrer la fragmentation vers un nouvel endroit.

Ce n’est pas un problème d’outil. C’est la conséquence logique d’avoir acheté avant de définir.

Le vrai coût du buy n’est pas la licence annuelle. C’est le coût de la fragmentation décisionnelle qui suit. Chaque équipe optimise pour ses propres métriques, dans son propre outil, avec sa propre définition. Et quand il faut prendre une décision qui traverse ces équipes, personne ne s’accorde sur le point de départ.

Il y a un deuxième coût, plus insidieux. Quand vous adoptez les abstractions d’un outil tiers, vous commencez à penser dans ses catégories. Vous optimisez pour les métriques que l’outil sait bien mesurer, pas nécessairement pour celles qui comptent pour votre produit spécifique. Vous demandez “comment je configure ça dans Amplitude” au lieu de “qu’est-ce que je cherche vraiment à comprendre sur le comportement de mes utilisateurs”.

L’outil finit par définir les questions que vous posez. C’est l’inverse de ce que vous vouliez.

Qui définit la métrique définit la stratégie

C’est la chose que j’entends rarement formulée clairement dans les organisations, mais que tout le monde ressent confusément.

Définir ce qu’est un utilisateur actif, c’est définir pour qui vous construisez. Définir ce qu’est une conversion, c’est définir ce que vous considérez comme un succès. Définir ce qu’est votre DAU/MAU ratio, c’est définir le type d’usage que vous cherchez à créer.

Ces définitions sont des décisions stratégiques. Elles ne devraient pas être déléguées à un outil tiers, à une équipe data en silo, ou à l’inertie d’une implémentation faite dans l’urgence il y a trois ans.

Dans la même organisation, le système de rating des interactions support fonctionnait sur une logique binaire : utile ou pas utile. Simple à implémenter dans le vendor. Simple à mesurer. Et totalement insuffisant pour comprendre la qualité réelle de l’expérience.

Le projet de refonte vers une échelle Likert 1 à 5 aurait pu se résumer à changer un paramètre dans le vendor. L’organisation a fait un choix différent. Elle a conçu un objet de donnée structuré, la “STAR answer”, ancré sur un identifiant propre à chaque interaction support, enrichi par canal, type de problème, marché, et agent. Le stack de collecte restait acheté. Le data model, lui, appartenait à l’organisation.

C’est là que réside la distinction. Le vendor collecte. Votre modèle normalise, relie, et donne du sens. Quand le modèle vous appartient, vous pouvez changer de vendor sans perdre votre logique. Quand le modèle est dans le vendor, vous êtes captif.

Le cas pour le build : posséder sa logique, c’est posséder sa stratégie

Le build a mauvaise réputation dans les conversations sur les outils analytics. On entend souvent les mêmes objections : c’est long, c’est coûteux, c’est à maintenir, les outils existants font très bien le job.

Ces objections sont légitimes pour une partie du spectre. Mais elles confondent deux choses différentes : la couche de collecte et la couche de définition.

La couche de collecte, c’est l’infrastructure qui capte les événements, les stocke, les transforme. Acheter ici est souvent raisonnable. Segment, RudderStack, ou une implémentation directe sur BigQuery ou Snowflake font le travail sans qu’il soit utile de tout reconstruire.

La couche de définition, c’est là que réside la source of truth. C’est là que vous décidez ce que signifient vos données. Et c’est là que le build, au sens de posséder sa logique métier, devient un avantage stratégique.

Concrètement, ça ressemble à quoi ? Pensez-y comme au plan comptable de votre produit : un référentiel stable, auditable, que tout le monde utilise comme point de départ, et qui peut évoluer de manière contrôlée.

En pratique : des modèles de transformation qui contiennent vos définitions de métriques, versionées, documentées, revues comme du code. Un fichier qui dit explicitement “pour nous, un utilisateur actif est un utilisateur ayant réalisé au moins une action X dans les 14 derniers jours, hors comptes tests, hors comptes internes”. Une couche de sémantique qui fait que quand le Sales ouvre son CRM et que le Product ouvre son dashboard analytics, ils lisent tous les deux la même définition, calculée de la même manière.

Cette approche a trois avantages que les outils packagés ne donnent pas.

Premièrement, la définition est explicite et débattable. Elle existe sous forme lisible, versionnable, contestable. Quand une définition est enfouie dans la configuration d’un vendor, elle est souvent invisible et de facto immuable. Dans la même organisation, les catégories d’issues disponibles pour les clients étaient codées en dur dans la config du vendor support. Chaque modification nécessitait une intervention manuelle d’une équipe centrale. Personne ne connaissait l’historique des choix. Personne ne savait pourquoi certaines catégories existaient. Le projet de refonte a extrait cette logique dans une API interne formelle, avec une ownership claire par domaine métier. La source of truth est passée d’une config vendor opaque à un contrat d’API documenté et versionné.

Deuxièmement, elle traverse les outils. La même définition peut alimenter votre dashboard produit, votre reporting opérationnel, vos modèles financiers. Plus de réunions où les chiffres ne s’accordent pas parce que chaque équipe lit dans son propre vendor.

Troisièmement, elle appartient à l’organisation. Quand vous changez d’outil, vos définitions ne changent pas. Vous les importez dans le nouvel environnement. Pour une plateforme qui opère dans 18 marchés avec des stacks vendor qui évoluent, c’est la différence entre une migration et une reconstruction complète.

Ce que ça change pour un CPO ou un CEO

La décision buy vs build sur la couche de définition n’est pas une décision technique. C’est une décision de gouvernance.

Elle répond à cette question : qui dans l’organisation a l’autorité et la responsabilité de définir ce que vous mesurez, et donc ce que vous pilotez ?

Si cette réponse est floue, ou si elle est de facto déléguée à un outil tiers, vous avez un problème de gouvernance déguisé en problème technique. L’ajouter de la data et des outils ne le résoudra pas. Il l’aggravera en multipliant les surfaces de contradiction.

Si cette réponse est claire, le choix d’outil devient secondaire. Vous pouvez utiliser Amplitude, Mixpanel, Metabase ou construire votre propre couche de visualisation. Ce qui compte, c’est que la logique métier qui alimente ces outils est possédée, documentée, et maintenue par votre organisation.

Il existe un principe d’architecture qui résume bien la tension : “platform enables, domains own.” La plateforme fournit l’infrastructure, les APIs, les composants réutilisables. Les domaines métier possèdent la business logic et les règles de décision. Dans un monde buy-first, acheter l’infrastructure est souvent raisonnable. Déléguer la propriété des règles métier au vendor ne l’est pas. C’est pourtant ce qui arrive par défaut quand la question de la gouvernance n’est pas posée explicitement avant l’achat.

Dans une scale-up où j’ai accompagné la reconstruction de la couche de définition sur huit semaines, le temps passé à valider les chiffres en comité de pilotage a chuté de plus de 60%. Pas parce que les données étaient meilleures. Parce que tout le monde lisait la même réalité avant d’entrer dans la salle.

Pour un CPO, ça se traduit par une question à poser à son équipe data : si nous changeons d’outil analytics demain, combien de temps nous faut-il pour reconstruire nos définitions de métriques dans le nouvel environnement ? Si la réponse est “plusieurs mois” ou “on ne sait pas trop”, vous n’avez pas de source of truth. Vous avez des configurations d’outils.

Pour un CEO, ça se traduit par une question différente : quand mes équipes présentent des chiffres en board, est-ce qu’elles s’accordent sur les définitions avant de s’accorder sur les conclusions ? Si les débats sur les chiffres précèdent systématiquement les débats sur la stratégie, le problème n’est pas la qualité de vos équipes. C’est l’absence d’une définition partagée de la réalité.

Un cadre simple pour décider

La décision n’est pas binaire. Elle se fait sur trois couches, et chaque couche a une logique différente.

La couche de collecte (tracking des événements, ingestion, stockage brut) : achetez. Les outils existants font ça très bien. Construire sa propre infrastructure de collecte est rarement justifié sauf à très grande échelle.

La couche de transformation et de définition (modèles dbt, semantic layer, définition des métriques) : construisez la logique, même si vous utilisez des outils pour la gérer. C’est votre logique métier. Elle doit vous appartenir, être documentée, et être indépendante de votre stack de visualisation.

La couche de visualisation (dashboards, exploration, reporting) : achetez ou construisez selon votre contexte. Metabase sur une couche de données propre bat Looker sur une couche de données fragmentée. L’outil n’est que l’interface de quelque chose de plus profond.

La source of truth n’est pas un projet data. C’est une décision organisationnelle sur qui possède la définition de la réalité dans votre entreprise.

Tant que cette décision n’est pas prise explicitement, vous pouvez acheter tous les outils que vous voulez. Vous aurez plusieurs sources d’information bien packagées qui se contrediront en réunion de manière de plus en plus coûteuse.

Si vous êtes CEO ou CPO et que vous voulez savoir où vous en êtes, trois questions suffisent :

La première : si votre Head of Product et votre CFO calculent chacun de leur côté le nombre d’utilisateurs actifs ce mois-ci, obtiennent-ils le même chiffre ?

La deuxième : si vous changiez d’outil analytics demain, vos définitions de métriques survivraient-elles à la migration ?

La troisième : qui dans votre organisation a l’autorité explicite de dire “cette définition est la bonne, et c’est celle-là que tout le monde utilise” ?

Si l’une de ces réponses est floue, vous n’avez pas encore de source of truth. Vous avez des outils.

La maturité d’une organisation produit ne se mesure pas à la puissance de ses dashboards. Elle se mesure à la clarté de ses définitions communes.

Je m’appelle Julien Brionne. J’interviens dans des organisations produit qui ont grandi plus vite que leur capacité à décider. Depuis 10 ans, sur des produits B2B SaaS et B2C, j’accompagne des équipes qui livrent beaucoup mais pilotent dans le flou. C’est ce dont je parle dans cette newsletter.

Six mois plus tard, quelque chose ne tourne pas rond. Pas de raison évidente. Juste une impression que ça n’avance pas comme ça devrait. Que les décisions prennent du temps. Que les priorités bougent encore trop souvent.

La semaine dernière, j’intervenais chez Maestro devant une trentaine de personnes en reconversion Product Manager. Et j’ai mis un mot sur ce problème.

Ce n’est souvent pas un problème de PM. C’est un problème de contexte.

Le rôle PM est un conteneur

Voilà l’image que j’utilise depuis quelques années.

Le rôle de PM est un conteneur flexible. Chaque organisation le remplit avec ce dont elle manque le plus à un moment donné.

Dans une boîte très orientée sales, le PM passe son temps à gérer des demandes clients et à coordonner avec le commercial. Dans une organisation product-led, il travaille sur la discovery et l’expérimentation. Dans une scale-up en pleine croissance, il arbitre des dépendances entre équipes.

Même titre. Journées complètement différentes.

Le problème : la plupart des recrutements évaluent la compétence générale du PM, pas son adéquation avec le contexte précis de l’organisation au moment précis où elle recrute.

Vous avez peut-être recruté quelqu’un d’excellent pour un contexte product-led dans une organisation qui a besoin d’un PM capable de gérer des dépendances complexes entre dix équipes. Il n’est pas mauvais. Il est mal positionné.

Le piège du modèle copié

Ce pattern dépasse le recrutement.

Beaucoup d’organisations adoptent des modèles qui ont fonctionné ailleurs sans regarder si leur propre contexte s’y prête.

Le cas classique : le modèle Spotify. Squads, tribes, chapters, guilds. Propre sur le papier. Six mois plus tard, l’organisation est plus complexe qu’avant. Les décisions sont plus lentes. Personne ne sait vraiment qui est responsable de quoi.

Le modèle Spotify a été conçu pour résoudre les problèmes de Spotify, dans la culture de Spotify. Copier ce modèle sans comprendre le problème qu’il résout, c’est appliquer la solution de quelqu’un d’autre à un problème qui n’est pas le vôtre.

Votre PM fait probablement la même chose. Il applique ce qu’il a appris. Ce n’est pas le problème. Le problème, c’est que personne n’a clarifié quel problème il devait résoudre dans votre contexte précis.

Ce que ça change pour l’IA en ce moment

Ce pattern se répète aujourd’hui avec l’IA.

Des équipes entières adoptent des outils IA sans avoir clarifié leurs priorités. Sans avoir résolu leurs problèmes de décision de base. Elles espèrent que l’outil va compenser le flou.

Il ne le fait pas. Un système décisionnel clair absorbe bien l’IA. Un système saturé s’emballe avec elle.

L’outil n’est jamais le prérequis. Le contexte l’est toujours.

Les trois questions à poser avant, pas après

Quand j’arrive dans une organisation pour comprendre pourquoi le produit n’avance pas comme il devrait, je commence toujours par trois questions.

Où en est vraiment l’organisation aujourd’hui ? Pas sur un slide de board. Dans la réalité des décisions prises cette semaine.

Qu’est-ce que l’équipe attend concrètement du rôle PM, au-delà de la fiche de poste ?

Quel est le problème le plus important à résoudre maintenant, si on devait n’en choisir qu’un ?

Ces trois questions auraient dû être posées avant le recrutement. Elles peuvent encore être posées maintenant pour remettre le système en ordre.

Le bon PM dans le mauvais contexte produit des résultats médiocres.

Ce n’est pas une question de talent. C’est une question de clarté sur ce que vous attendez vraiment, dans votre situation précise, au moment où vous l’attendez.

Clarifier ça avant d’agir évite beaucoup d’erreurs coûteuses. En recrutement comme ailleurs.

Je m’appelle Julien Brionne. J’interviens dans des organisations produit qui ont grandi plus vite que leur capacité à décider. Depuis 10 ans, sur des produits B2B SaaS et B2C, j’aide des équipes à retrouver la clarté quand les frameworks ne suffisent plus. C’est ce dont je parle dans cette newsletter.

Ce n’est pas un caprice de branding. C’est une décision produit.

Et comme toute décision produit, elle raconte quelque chose sur le problème qu’on essaie de résoudre.

Le problème

“Product Copilot” est le nom de mon activité de studio. J’interviens dans des scale-ups SaaS quand l’alignement produit se fissure. J’aide à identifier le vrai problème, à trancher ce qui doit l’être, et à repartir avec un système de décision qui tient.

Mais cette newsletter n’est pas mon activité de consulting.

Ici, je ne vends rien. Je ne fais pas de diagnostic. Je ne propose pas d’accompagnement.

Ici, j’écris.

Sur ce que je vois en mission. Sur les patterns qui se répètent d’une orga à l’autre. Sur les décisions que tout le monde repousse. Sur les erreurs que je fais moi-même. Sur l’IA qui change le métier. Sur ce que ça veut dire de piloter un produit en 2026.

Et “Product Copilot” ne disait rien de tout ça.

Pourquoi “Produit sans Filtre”

Trois raisons.

La première : c’est ce que je fais. Chaque semaine, je partage un regard terrain sur le produit. Pas de théorie recopiée, pas de framework vendeur, pas de discours optimisé pour LinkedIn. Ce que j’observe. Ce que je pense. Parfois je me trompe. C’est le jeu.

La deuxième : c’est ce qui manque. La plupart du contenu produit tourne autour de “comment bien faire”. Moi, je préfère parler de pourquoi ça déraille. Parce que c’est là que se trouvent les vrais apprentissages. Dans les erreurs, les tensions, les arbitrages inconfortables.

La troisième : c’est une promesse au lecteur. Si tu t’abonnes, tu sais ce que tu recevras. Un regard direct. Pas de filtre. Pas de posture. Pas de langue de bois.

Ce qui change (et ce qui ne change pas)

Le nom change. L’URL change (produitsansfiltre.substack.com).

Le reste ne bouge pas.

Je continue d’écrire chaque semaine. Sur la dette de décision. Sur les PMs qui s’épuisent. Sur les roadmaps qui servent de refuge. Sur les produits qui grossissent sans créer plus de valeur.

Et je vais ouvrir le champ. Parler d’IA dans le produit. Partager des leçons plus personnelles. Documenter ce que c’est que d’être indépendant et d’intervenir dans des orgas en tension.

Le fil conducteur reste le même : nommer ce que personne ne nomme.

Ce que tu vas trouver ici

Chaque semaine, un article. 10 minutes de lecture.

Parfois un diagnostic terrain. Parfois un framework. Parfois une prise de position. Parfois un retour d’expérience brut.

Toujours : un regard honnête sur le produit tel qu’il se vit vraiment dans les scale-ups.

Si ça te parle, reste. Et si tu connais quelqu’un qui a besoin de lire ça, partage.

On y va.

Julien

Ça finit rarement bien.

Et quand ça s’écroule, on blâme souvent l’architecte.

Le problème de séquence

Un CEO intelligent voit que le produit s’essouffle.

Le churn monte.
La roadmap devient une liste de courses infinie.
Les PMs passent leurs journées à arbitrer des urgences contradictoires.

La décision semble logique :

“Il nous faut un CPO.”

Mais il y a souvent une erreur de séquence.

Un CPO est recruté pour construire :

une vision long terme,
une stratégie produit,
une organisation plus mature.

Mais pour construire, il faut un terrain lisible.

Or dans beaucoup de startups, les six derniers mois ont laissé derrière eux :

• des arbitrages jamais assumés

• des promesses commerciales impossibles à tenir

• des segments clients contradictoires

• des pivots à moitié faits

Autrement dit : une dette de décision produit.

Le CPO n’arrive pas pour construire.

Il arrive pour déminer.

La position impossible

Le drame se joue dans les 90 premiers jours.

Le nouveau CPO cartographie le système et comprend vite l’état réel des choses.

Pour avancer, il faut nommer les décisions passées qui ont créé la situation :

La feature sur-mesure pour un gros client qui a rendu le produit illisible.

Le pivot à moitié assumé qui force l’équipe technique à maintenir deux architectures.

L’absence de choix entre PME et Enterprise.

Mais pour nommer ces décisions, il faut challenger celui qui les a prises.

Le CEO.

C’est là que la position devient presque impossible.

Un CPO qui vient d’arriver a besoin de confiance pour opérer.

S’il commence par démonter des décisions stratégiques prises avant lui, il prend un risque politique énorme.

Alors il fait ce qui est raisonnable.

Il améliore les rituels.
Il structure les process.
Il clarifie la roadmap.

Mais il ne touche pas au fond.

La dette de décision continue de s’accumuler.

Simplement un étage plus haut.

Les signaux que votre terrain est miné

Avant de recruter, regardez trois choses.

1. Le poids du contractuel

Si une part significative de votre roadmap est dictée par des promesses commerciales, votre futur CPO ne fera pas de stratégie produit.

Il fera de la gestion de dette.

2. Les fantômes du backlog

Des fonctionnalités “en bêta” depuis un an.

Personne n’ose les tuer.

Personne n’ose les terminer.

Elles restent là, comme des décisions suspendues.

3. Le silence en réunion

Les mêmes discussions reviennent chaque semaine.

Les mêmes arbitrages.

Les mêmes tensions.

Mais personne ne tranche vraiment.

Le test de vérité

Pour un CEO :

Avant de signer le contrat de votre futur CPO, montrez-lui la pire décision produit que vous avez prise ces 12 derniers mois.

Expliquez-lui pourquoi vous l’avez prise.

S’il n’ose pas vous dire pourquoi c’était une erreur, ne l’embauchez pas.

Mais si vous n’osez pas lui montrer…

alors vous n’êtes peut-être pas prêt à être challengé.

Une réalité peu confortable

Beaucoup d’entreprises pensent recruter un leader produit.

En réalité, elles cherchent quelqu’un pour absorber des décisions qu’elles n’ont jamais vraiment prises.

Le problème n’est alors pas un manque de leadership produit.

C’est un système qui n’assume plus ses arbitrages.

Et aucun CPO, aussi brillant soit-il, ne peut construire sur un terrain où les décisions fondamentales restent politiquement impossibles.

Il y a un moment très particulier quand le churn commence à grimper.

Ce n’est pas la panique.

C’est une réunion calme.

Slides propres.
Hypothèses rationnelles.
Graphiques bien commentés.

Le Head of Product parle d’onboarding.
Le Head of CS parle d’accompagnement.
Le Head of Sales parle de mauvais fit.

Tout le monde a une explication cohérente.

Personne ne parle de la décision.

Et pourtant, le churn ne tombe jamais du ciel.

Le churn est un délai de six mois

Le churn ne mesure pas ce qui se passe aujourd’hui.

Il mesure ce que vous avez décidé il y a six à neuf mois.

Le deal signé “stratégique”.
La feature livrée en urgence.
Le segment accepté à titre exceptionnel.
La promesse faite en démo que le produit ne tenait qu’à moitié.

À l’époque, c’était rationnel.

Je l’ai fait moi-même.

Signer pour atteindre le target.
Accélérer un use case encore instable.
Dire oui parce que dire non aurait ralenti la dynamique.

On savait que ça créerait de la complexité.
On savait que ça diluerait la proposition de valeur.
On savait que ça introduirait une exception.

Mais personne ne voulait être celui qui bloque le plus gros deal du trimestre.

Alors on a décidé.

Le churn, lui, ne connaît pas les bonnes raisons.

Il enregistre simplement l’écart entre la promesse et l’expérience.

C’est une métrique froide.
Elle ne discute pas.
Elle constate.

L’erreur que je vois partout

Quand le churn monte, on agit là où ça se voit.

On renforce le CS.
On retravaille l’onboarding.
On lance une campagne de réactivation.
On ajoute des emails.
On améliore le NPS.

Ces actions peuvent faire baisser la courbe.

Temporairement.

Mais elles traitent la friction visible.

Pas la décision qui l’a créée.

Le vrai scénario

SaaS B2B.
Produit historiquement pensé pour des PME.

Un client enterprise arrive.
Gros logo.
Montant significatif.
Deal structurant.

Condition : une feature spécifique, hors positionnement initial.

On la build.

Six mois plus tard :

• Le produit est plus complexe pour tout le monde.

• Les PME commencent à décrocher.

• L’enterprise churn parce que le reste de l’expérience n’est pas au niveau attendu.

En réunion, on parle d’activation.

Le Sales dit : on doit mieux qualifier.
Le Product dit : on doit simplifier l’onboarding.
Le CS dit : on doit mieux accompagner.

Personne ne dit :
On n’aurait jamais dû construire ça.

Parce que remettre en cause la décision, c’est remettre en cause l’arbitrage passé.

Et parfois, celui qui l’a pris est encore dans la pièce.

Ce que je fais quand j’arrive

Quand une boîte m’appelle parce que le churn monte, je ne commence pas par ouvrir les dashboards.

Je pose trois questions.

Quel segment a le plus churné ces six derniers mois ?

Quelle promesse explicite ou implicite avons-nous faite à ce segment ?

Quand avons-nous décidé de le servir, et savions-nous déjà que c’était risqué ?

La troisième question change l’atmosphère.

Parce que la réponse est souvent :

Oui. On savait.

On savait que ça compliquerait le produit.
On savait que ça créerait une exception.
On savait que ça diluerait le positionnement.

Mais à court terme, c’était rationnel.

Le churn est rarement un problème d’exécution.

C’est une dette de décision qui arrive à échéance.

La différence entre les boîtes qui tiennent

Les entreprises avec un churn sain ne sont pas plus intelligentes.

Elles font quelque chose de plus difficile.

Elles ferment des options tôt.
Elles protègent la cohérence.
Elles acceptent de perdre un deal.
Elles disent non quand tout pousse à dire oui.

Elles arbitrent pour le produit, pas pour le trimestre.

La vraie question

Quand le churn monte, la question n’est pas :

Comment le faire baisser ?

C’est :

Quelle décision passée sommes-nous en train de payer ?

La prochaine fois que la courbe remonte, avant les slides et les hypothèses, pose une seule question :

Quelle décision avons-nous prise il y a six mois que nous n’aurions probablement pas dû prendre ?

Si la salle devient silencieuse, c’est bon signe.

Ça veut dire que vous venez d’arrêter de corriger un symptôme.

Et que vous êtes prêts à revisiter une décision.

C’est là que le vrai travail commence.

Abonnez-vous maintenant

La semaine prochaine :
Pourquoi recruter un CPO au mauvais moment peut aggraver exactement ce type de dette.

L’illusion Platform : Pourquoi les équipes Platform révèlent votre rapport au pouvoir

La plupart des équipes Platform sont créées pour absorber la complexité. Beaucoup finissent par concentrer le pouvoir.

Et ce n’est pas un problème technique. C’est un problème d’organisation.

Le moment où le système commence à craquer

Il existe un moment prévisible dans toute scale-up. On passe de 3 squads à 7 ou 8.

Les dépendances se multiplient. Les services partagés deviennent fragiles. La logique métier se diffuse dans plusieurs couches du produit.

Le billing touche l’onboarding. L’identité impacte les permissions. Une évolution d’API bloque une release critique.

La complexité dépasse la capacité d’absorption de l’organisation. Et quelqu’un dit :

“Il nous faut une équipe Platform.”

La décision paraît rationnelle. Mature. Structurée. Elle est souvent émotionnelle.

La centralisation est une réponse rassurante au chaos.

Le syndrome du CEO-goulot appliqué au Produit

On connaît tous ce mécanisme chez les fondateurs. Au début, le CEO garde toute la vision système dans sa tête. Il valide chaque décision. Il protège jalouseusement la cohérence globale.

À court terme, cela sécurise la boîte. À long terme, il devient le goulot d’étranglement de sa propre croissance.

Une équipe Platform mal conçue reproduit exactement cette dynamique. Au lieu de distribuer la compréhension du système, elle la confisque. Le PM Platform devient le “CEO de la tech” :

• Le propriétaire exclusif de la logique transverse.

• Le point de passage obligatoire pour toute évolution sensible.

• L’arbitre saturé entre plusieurs roadmaps.

• Le seul à “comprendre vraiment comment ça marche”.

Vous pensiez réduire la complexité. Vous avez juste recréé un CEO-goulot au milieu de votre architecture.

Cas réel : quand le billing devient un mini-gouvernement

Dans une scale-up B2B d’environ 90 personnes, le système de facturation a été extrait pour devenir un produit Platform. L’ambition était saine : Créer un moteur générique et réutilisable.

Six mois plus tard :

• 70 % de la roadmap Platform traitait des urgences des feature teams.

• Le lead time des projets transverses avait doublé.

• Les squads n’étaient pas autorisées à contribuer au core.

• Les incidents provoquaient des conflits ouverts entre équipes.

Les signaux faibles étaient clairs. En refinement : “Il faut demander à la Platform si l’API le permet.”

Dans les discussions produit : “C’est leur sujet, pas le nôtre.”

La Platform n’avait pas simplifié le système. Elle avait capté l’autorité. Pas par incompétence. Parce que le modèle de contribution et les règles d’arbitrage n’existaient pas.

Le malentendu central

Beaucoup pensent que Platform signifie centralisation. Une Platform saine ne centralise pas l’exécution.

Elle orchestre la décentralisation. C’est une différence structurelle.

Une équipe Platform n’est pas là pour faire à la place des autres. Elle est là pour définir :

• Les standards.

• Les interfaces.

• Les règles d’arbitrage.

• Les mécanismes de contribution.

Autrement dit : elle doit distribuer le pouvoir architectural, pas le capturer.

La matrice de diagnostic : Guichet vs. Orchestrateur

Pour savoir où vous en êtes, il suffit d’observer comment votre système se comporte face à une nouvelle demande.

❌ Le modèle “Guichet” (L’illusion du contrôle)

• Roadmap : Dictée par les urgences des autres squads.

• Posture : Le PM Platform agit comme un validateur (gatekeeper).

• Code : La contribution externe est interdite ou freinée.

• Métrique : Le succès se mesure au nombre de tickets traités.

• Diagnostic : Vous avez créé un goulot politique.

✅ Le modèle “Orchestrateur” (La vraie maturité)

• Roadmap : Pilotée par la robustesse et l’élégance du système.

• Posture : Le PM Platform est un concepteur de standards et d’outils.

• Code : Modèle de contribution ouvert et documenté (InnerSource).

• Métrique : Le succès se mesure par l’autonomie des autres squads.

• Diagnostic : Vous avez distribué le pouvoir opérationnel.

Le test de distribution du pouvoir

Regardez votre équipe Platform aujourd’hui. Si elle :

1. Valide chaque changement critique,

2. Possède seule la compréhension du système,

3. Décide des arbitrages sans règles explicites,

4. Empêche les autres squads de contribuer au core...

Alors vous n’avez pas créé une Platform. Vous avez créé un centre de pouvoir. Et tout centre de pouvoir finit par devenir un goulot.

La vraie question

La question n’est pas : “Faut-il une équipe Platform ?” La question est :

• Êtes-vous prêts à distribuer la compréhension du système ?

• Êtes-vous prêts à formaliser des règles d’arbitrage claires ?

• Êtes-vous prêts à accepter que plusieurs équipes modifient le core ?

Si la réponse est non, la Platform deviendra indispensable. Et l’indispensable ralentit toujours le scale.

Ce que cela révèle vraiment

La Platform n’est qu’un miroir. Elle révèle :

• Votre tolérance à la complexité.

• Votre rapport au contrôle.

• Votre capacité à formaliser des standards.

• Votre maturité dans la prise de décision distribuée.

Ce n’est pas un sujet d’architecture. C’est un sujet de gouvernance.

Pour ceux qui sont en phase de bascule

Si vous êtes en train de passer :

• De 3 à 8 squads

• Du product-market fit à la croissance structurée

• D’une organisation intuitive à une organisation formalisée

Alors cette tension apparaîtra inévitablement.

Quelqu’un parle depuis douze minutes.
La slide 42 s’affiche. Un schéma complexe. Des flèches dans tous les sens. Trois acronymes que personne n’ose redemander.

Et progressivement, les têtes commencent à bouger.

Haut.
Bas.

Un ballet silencieux d’alignement apparent.

À la fin, personne ne pose de question.
La décision est “validée”.
On passe au point suivant.

Le problème, c’est que personne n’a vraiment compris.

La tentation du blâme

La réaction instinctive consiste à pointer du doigt ceux qui acquiescent.

On pourrait dire :

• Ils manquent de courage.

• Ils évitent le conflit.

• Ils ont peur d’être “celui qui ralentit”.

• Ils ne veulent pas paraître incompétents.

C’est parfois vrai.

Mais ce n’est que la moitié du problème.

L’autre moitié est plus inconfortable :
et si le système produisait lui-même ce silence ?

Le cerveau ne décroche pas par lâcheté

Lorsque l’explication est trop dense, mal structurée, sans point d’atterrissage clair ni responsabilité définie, le cerveau décroche.

Non pas par paresse.
Par économie cognitive.

La surcharge informationnelle active un mécanisme simple : réduire l’effort.
On simule la compréhension pour préserver l’énergie mentale.

Ce n’est pas un mensonge conscient.
C’est une stratégie de survie.

Dans beaucoup d’organisations, les réunions ne sont pas conçues pour maximiser la compréhension, mais pour maximiser la transmission d’informations.
Or transmettre n’est pas faire comprendre.

Et expliquer n’est pas engager.

Le signal faible que tout le monde ignore

Un alignement parfait est souvent suspect.

Dans un groupe de dix personnes intelligentes, si personne ne questionne, deux hypothèses existent :

1. C’est du génie.

2. C’est du brouillard.

Statistiquement, ce n’est pas du génie.

Le désaccord intelligent est un indicateur de clarté.
L’absence totale de friction est parfois le symptôme inverse.

Le coût invisible de l’illusion d’alignement

Un “oui” mal compris ne fait pas de bruit.

Mais il coûte.

Il coûte :

• une semaine d’itérations inutiles ;

• plusieurs échanges Slack pour clarifier après coup ;

• des arbitrages contradictoires ;

• une tension diffuse dans l’équipe ;

• une perte de confiance silencieuse.

Le plus dangereux, c’est que le coût n’est pas immédiat.
Il apparaît plus tard, sous forme de complexité accumulée.

Multipliez cela par vingt décisions par mois.

Vous venez d’acheter de la dette organisationnelle.

À crédit.

Le vrai courage n’est pas individuel

On glorifie souvent la personne qui dit :
“Je n’ai pas compris.”

Mais dans beaucoup d’environnements, le coût social est réel :

• risque d’être perçu comme lent ;

• crainte d’exposer son ignorance ;

• peur de déranger le rythme ;

• fatigue d’être toujours celui qui questionne.

Le problème n’est donc pas seulement individuel.

La vraie question n’est pas :

Pourquoi les gens ne parlent-ils pas ?

Mais :

Pourquoi le système rend-il la parole coûteuse ?

Le pivot : la responsabilité du cadre

Si tout le monde acquiesce mécaniquement, le présentateur a aussi échoué.

Non pas parce qu’il est incompétent.

Mais parce qu’il a présenté une explication au lieu d’orchestrer une compréhension.

Il a optimisé la clarté perçue.
Pas la compréhension réelle.

Or la compréhension ne se mesure pas au silence.
Elle se mesure à la reformulation.

Un micro-framework simple : le “Right to Query”

Plutôt que d’attendre un acte héroïque, on peut modifier la règle du jeu.

Deux principes simples :

1. Toute décision doit être reformulée par quelqu’un d’autre.
   Si personne ne peut reformuler clairement, la décision n’existe pas encore.

2. Toute personne peut poser une “question de clarté” sans justification.
   Pas une objection.
   Pas une critique.
   Une question de clarté.

La nuance change tout.

Une objection crée une tension.
Une question de clarté crée un espace.

La reformulation comme test de réalité

Avant de conclure une discussion, poser simplement :

“Qui peut reformuler ce que nous venons de décider ?”

Puis attendre.

Le silence qui suit est révélateur.

S’il est long et inconfortable, ce n’est pas un problème.
C’est un diagnostic.

S’il est fluide et précis, l’alignement est réel.

Cette simple pratique ralentit légèrement la réunion.
Mais elle accélère tout le reste.

Ce dont les organisations meurent vraiment

Les organisations ne meurent pas du désaccord.

Elles meurent de l’illusion d’alignement.

Le désaccord explicite crée de la friction productive.
Le faux consensus crée de la dette invisible.

Et cette dette commence souvent par un geste banal, presque poli :

un hochement de tête.

Un modèle.
Un gros prompt.
Une démo qui fonctionne.

Les premiers résultats sont “assez bons”.
On ajoute quelques règles.
Puis quelques exceptions.
Puis quelques warnings.

Sans s’en rendre compte, le prompt devient un millefeuille.

Puis vient la mise en production.

Quand ça casse, on accuse le modèle.
On change de fournisseur.
On attend la “v1.5”.

Mais le problème n’est presque jamais le modèle.

Le problème, c’est qu’on n’a jamais décidé ce qu’il ne devait pas faire.

Le “One Big Prompt” est une illusion de contrôle

Un prompt unique donne l’impression qu’on maîtrise tout.

Tout est écrit au même endroit.
Donc on croit que tout est cadré.

En réalité, on accumule des intentions contradictoires :

• “Sois exhaustif, mais concis.”

• “Ne refuse jamais, sauf si c’est risqué.”

• “Sois autonome, mais respecte strictement la politique.”

Chaque nouvelle ligne est une correction locale.
Aucune n’est une décision structurelle.

On ne tranche pas.
On empile.

À force, personne ne sait vraiment ce que le système est censé faire.

Il essaie de tout faire.

Et c’est exactement là que la variabilité explose.

Le vrai glissement : déléguer la décision

L’IA peut exécuter.
Reformuler.
Classer.
Synthétiser.

Mais elle ne devrait pas arbitrer à ta place.

Quand un prompt devient monolithique, on finit par lui confier :

• l’analyse

• la décision

• la justification

• l’exécution

En une seule étape.

C’est l’équivalent organisationnel de dire à un stagiaire :

“Gère la croissance. Je reviens dans trois mois.”

Sans périmètre.
Sans règle claire d’escalade.
Sans responsabilité identifiée.

Ce n’est pas un problème technique.
C’est un problème de responsabilité.

Le symptôme du scale

À 10 utilisateurs, ça tient.

À 1 000, le système révèle sa nature.

Deux utilisateurs font la même demande.
Deux réponses divergent.

En réunion, ça donne :

“Chez moi ça marche.”
“Ah non, chez moi il a refusé.”

Et tout le monde regarde le prompt comme s’il allait trancher à la place de l’organisation.

Une règle interne change ?
Il faut retoucher tout le prompt.

Un incident survient ?
On ajoute une ligne.

Toujours une ligne de plus.

Le prompt devient le lieu où l’on compense les décisions jamais prises ailleurs.

Plus il grossit, plus le système devient fragile.

Scaler, c’est réduire l’ambiguïté

Scaler, ce n’est pas rendre l’IA plus intelligente.

C’est réduire l’espace dans lequel elle peut interpréter.

Cela suppose trois décisions simples :

1. Ce que l’IA fait.

2. Ce qu’elle ne fait pas.

3. Qui est responsable quand elle se trompe.

Un LLM n’est pas un outil déterministe.
Il interprète.
Il complète.
Il arbitre si tu lui laisses l’espace.

Si personne n’a décidé, le prompt décidera à votre place.

Ce n’est pas un sujet d’IA

C’est un sujet de maturité produit.

Un produit fragile essaie de tout couvrir.
Un système mature accepte de fermer des portes.

Le “One Big Prompt” est simplement la version IA :

• de la roadmap fourre-tout

• de la feature qui veut plaire à tout le monde

• de l’autonomie sans cadre

À petite échelle, ça passe.

À grande échelle, ça casse.

Question simple pour ton équipe cette semaine

Si ton prompt fait tout…

Est-ce que ton organisation a vraiment décidé quelque chose ?

Quand un produit devient bruyant,
le réflexe est souvent le même :
il faut “faire le ménage”.

Mais supprimer le bruit n’est pas un acte de force.
Ce n’est pas une démonstration d’autorité.
C’est un acte de précision.

La plupart des produits ne sont pas bruyants
parce qu’ils sont mal conçus.

Ils sont bruyants parce que
trop de décisions restent actives en même temps.

Fonctionnalités jamais clôturées.
Exceptions devenues permanentes.
Choix temporaires qui n’ont jamais été reconsidérés.

Avant de supprimer quoi que ce soit,
il faut comprendre une chose essentielle :

👉 le bruit n’est pas dans les features.
Il est dans le système.

Erreur n°1 : commencer par supprimer

Quand un produit devient lourd,
la question arrive très vite :

“Qu’est-ce qu’on enlève ?”

C’est la pire entrée possible.

Supprimer sans reclarifier :

• crée de la panique

• casse des usages invisibles

• déclenche des résistances politiques

Ce n’est pas la suppression qui casse.
C’est la suppression sans intention explicite.

Avant de retirer,
il faut d’abord réduire l’ambiguïté.

Étape 1 — Arrêter d’ajouter (vraiment)

On ne peut pas désengorger un système
pendant qu’il continue à grossir.

La première décision n’est pas de retirer.
C’est de geler l’expansion.

Pas définitivement.
Mais explicitement.

Tant que :

• de nouveaux paramètres apparaissent

• de nouvelles exceptions sont acceptées

• de nouvelles intégrations “one-off” passent par la fenêtre

toute tentative de simplification est cosmétique.

Arrêter d’ajouter,
c’est déjà supprimer du bruit futur.

Étape 2 — Regarder où la valeur ralentit, pas où elle disparaît

Le bruit ne se voit pas là où l’usage est faible.
Il se voit là où l’usage hésite.

Là où :

• les utilisateurs prennent plus de temps qu’avant

• les parcours se fragmentent

• les tickets “comment faire” se multiplient

Ce ne sont pas des bugs.
Ce sont des zones de surcharge décisionnelle.

Supprimer le bruit commence par identifier
où la valeur se bloque,
pas par compter des clics.

Étape 3 — Fermer des décisions, pas juste des features

Beaucoup de fonctionnalités existent
pour une raison simple :
elles compensent autre chose.

Une incohérence.
Une promesse floue.
Un arbitrage jamais assumé.

Les supprimer sans traiter la cause crée un vide.
Les garder empêche toute clarification.

Supprimer le bruit, c’est souvent :

• réduire des variantes

• standardiser des règles

• dire “voilà comment on fait maintenant”

Pas enlever des capacités.
Retirer la variabilité inutile.

Étape 4 — Rendre le retrait visible et explicable

Un retrait qui surprend est perçu comme une perte.
Un retrait expliqué est perçu comme une amélioration.

Avant de retirer quoi que ce soit,
il faut pouvoir dire clairement :

• ce que le produit fait mieux qu’avant

• ce qu’il ne fait plus

• et pourquoi c’est un progrès

Le silence crée de la défiance.
Le récit crée de la confiance.

Supprimer le bruit sans narration,
c’est remplacer une confusion par une autre.

Étape 5 — Supprimer progressivement… puis vraiment

La plupart des produits “retirent”
sans jamais supprimer.

Options cachées mais toujours actives.
Règles encore là “au cas où”.
Code mort jamais nettoyé.

Résultat :
le bruit visuel baisse,
la complexité systémique reste.

Supprimer le bruit, ce n’est pas masquer.
C’est clôturer.

Décider que quelque chose :

• n’existe plus

• ne sera plus maintenu

• ne reviendra pas par défaut

Sans clôture explicite,
la complexité revient toujours.

Ce que font les équipes qui y arrivent

Elles ne suppriment pas plus.
Elles suppriment mieux.

Elles traitent la simplification comme :

• un travail produit à part entière

• un sujet de leadership

• une responsabilité explicite

Elles acceptent qu’on ne puisse pas tout garder.
Et que chaque “oui” non refermé
finit toujours par devenir du bruit.

Supprimer le bruit n’est pas un projet

Ce n’est pas un grand nettoyage annuel.
Ce n’est pas une refonte héroïque.

C’est une discipline.

Une manière de piloter le produit dans le temps.
De fermer des boucles.
De protéger la clarté.

Les produits qui vieillissent bien
ne sont pas ceux qui ajoutent le plus.
Ce sont ceux qui savent ce qu’ils arrêtent.

Si tu es CEO ou CPO,
et que ton produit te paraît de plus en plus difficile à faire évoluer,
le problème n’est probablement pas technique.

C’est un problème de décisions non refermées.

Cette série n’était pas sur la soustraction.
Elle était sur la responsabilité.

Et c’est exactement là
que commence le vrai travail produit.

Mais dans beaucoup d’organisations,
elle sert à autre chose.

Elle sert à rassurer.
À calmer.
À donner l’impression que le système est sous contrôle.

La roadmap n’est plus un outil de pilotage.
C’est devenu un refuge psychologique.

Quand planifier remplace décider

Plus la situation est floue,
plus la roadmap se remplit.

On ajoute des items pour montrer qu’on agit.
On étale les initiatives pour ne pas trancher.
On empile des “on verra plus tard”
sous forme de tickets bien rangés.

La roadmap devient un espace où :

• tout est important

• rien n’est vraiment choisi

• personne n’est clairement responsable

On ne décide pas.
On organise l’évitement.

L’illusion du mouvement

Sur le papier, tout avance :

• les colonnes se remplissent

• les sprints tournent

• les livraisons s’enchaînent

Mais le produit, lui, stagne.

Pourquoi ?

Parce que l’énergie est consommée :

• à maintenir l’existant

• à gérer des exceptions

• à faire cohabiter des décisions jamais closes

La roadmap donne une illusion de progrès.
Alors que la valeur circule de moins en moins.

Ajouter pour ne pas retirer

Retirer oblige à dire non.
À assumer une perte visible.
À expliquer pourquoi quelque chose n’existera plus.

Ajouter évite tout ça.

Chaque nouvel item est :

• une promesse différée

• un compromis silencieux

• une manière élégante de ne pas arbitrer maintenant

Résultat :

• la roadmap grossit

• la clarté diminue

• la complexité gagne

Ce n’est pas un problème de priorisation.
C’est un problème de courage décisionnel.

La responsabilité diluée

Dans ces roadmaps-refuges,
personne ne décide vraiment.

Les décisions sont :

• “alignées” en comité

• “validées” collectivement

• “portées” par tout le monde

Donc assumées par personne.

Les PMs arbitrent en silence.
Les équipes compensent.
Le produit encaisse.

La roadmap protège l’organisation.
Pas le produit.

Le signal faible que tout a basculé

Il y a un moment précis
où la roadmap change de nature.

Ce moment où :

• retirer devient impensable

• chaque item a un défenseur

• plus rien ne peut disparaître

À partir de là,
la roadmap n’est plus un outil stratégique.
C’est un inventaire politique.

Et plus personne ne se demande :

“Qu’est-ce qui empêche aujourd’hui la valeur de circuler ?”

Ce que les bonnes roadmaps font vraiment

Une bonne roadmap ne montre pas seulement ce qui arrive.
Elle montre aussi ce qui s’arrête.

Elle rend visibles :

• les renoncements

• les arbitrages

• les simplifications assumées

Quand une roadmap ne sait qu’ajouter,
elle ne pilote plus.
Elle accumule.

Et maintenant ?

Si la roadmap est devenue un refuge,
la question n’est pas de mieux la remplir.

La vraie question est :
comment on enlève le bruit sans tout casser.

Pas en supprimant au hasard.
Pas en faisant table rase.
Mais en reprenant le pilotage du système.

C’est là que commence le vrai travail produit.
Pas celui qui ajoute.
Celui qui clarifie.

👉 Dans le prochain post, je rentrerai dans le comment :
comment supprimer le bruit
sans déclencher une guerre interne
et sans fragiliser le produit.

Si tu es CEO ou CPO
et que ta roadmap te rassure plus qu’elle ne t’aide à décider,
ce n’est probablement pas un problème d’outil.

C’est un problème de responsabilité encore trop diffuse.

J’écris ce Substack pour ceux qui vivent ces moments-là.
Pas quand tout va bien.
Quand décider devient inconfortable, mais nécessaire.

Ajouter crée peu de vagues.
Retirer oblige à assumer des pertes immédiates :

• des habitudes installées

• des exceptions chéries

• parfois des deals

Ajouter est discret.
Retirer laisse des traces.

Tout le monde le sent.
Personne ne veut être celui qui “casse”.

Et très souvent, ce “personne” a un nom, un rôle, et un pouvoir.

Dans beaucoup d’équipes, le diagnostic est partagé.
Le produit est devenu trop lourd.
Trop bruyant.
Trop lent.

Mais personne ne veut être celui qui déclenche l’alerte.
Parce que retirer ressemble à une destruction, pas à une amélioration.

C’est faux.
Mais c’est ce que le système raconte.

Le mythe du retrait risqué

La soustraction est souvent traitée comme une opération dangereuse.
Un acte irréversible.
Une prise de risque excessive.

En réalité, ce qui casse les produits n’est pas le retrait.
C’est l’indécision prolongée.

Les couches ajoutées “temporairement”.
Les exceptions qu’on garde “par prudence”.
Les fonctionnalités qu’on n’ose plus toucher.

Ce n’est pas le retrait qui crée le risque.
C’est l’accumulation non arbitrée — parce que personne n’a voulu trancher plus tôt.

Plus une décision est repoussée,
plus elle devient coûteuse.
Plus elle devient coûteuse,
plus elle paraît violente.

Alors on attend.
On compense.
On ajoute encore une couche.

Jusqu’au jour où tout paraît intouchable.

La mauvaise question

“Qu’est-ce qu’on peut supprimer ?”

Cette question est rassurante.
Elle fait croire qu’on cherche un détail, pas une direction.

La bonne question est plus inconfortable :

“Qu’est-ce qui ne mérite plus d’exister ?”

Parce qu’elle oblige à trancher sur :

• ce qui est normal

• ce qui est exceptionnel

• ce qui n’est plus acceptable

Et surtout :
qui est légitime pour répondre à cette question ?

Ce n’est pas une décision produit.
C’est une décision de leadership.

Retirer n’est pas supprimer

Retirer, ce n’est pas enlever.
C’est reclarifier.

La plupart des retraits ratés échouent pour la même raison.
Ils sont traités comme des suppressions techniques.

Alors que le vrai travail est ailleurs.

Avant de retirer, il faut pouvoir dire clairement :

• ce que le produit fait maintenant

• ce qu’il ne fait plus

• et pourquoi c’est une amélioration

Un retrait sans récit crée de la panique.
Un retrait assumé crée de la confiance.

Ce que les utilisateurs rejettent,
ce n’est pas la perte.
C’est l’arbitraire.

Le rôle irremplaçable du leadership

Ce travail ne peut pas être délégué :

• ni à la data seule

• ni à l’UX seule

• ni aux PMs isolément

Parce qu’il implique des renoncements visibles.
Et que tout renoncement est un acte de pouvoir.

Décider quoi retirer,
c’est décider ce qui compte vraiment.
Et accepter que tout ne puisse pas survivre.

Tant que cette responsabilité reste diffuse,
la complexité gagne toujours.

Le vrai risque

Le vrai risque n’est pas de retirer trop tôt.
C’est de retirer trop tard.

Quand le produit est déjà illisible.
Quand l’équipe est déjà épuisée.
Quand chaque changement est perçu comme une menace.

À ce stade, toute décision paraît violente.
Parce qu’elle arrive après des mois —
parfois des années —
d’évitement.

Retirer fait peur.
Parce que ça oblige à décider.
Et décider, c’est renoncer.

Mais ne pas renoncer,
c’est laisser la complexité décider à votre place.

Si tu es CEO ou CPO,
et que retirer des features te met mal à l’aise,
ce n’est probablement pas un problème de produit.

C’est un problème de responsabilité encore trop diffuse.

J’écris ce Substack pour ceux qui vivent ces moments-là.
Pas quand tout va bien.
Quand décider devient inconfortable, mais nécessaire.

Une roadmap ressemble souvent à une promesse implicite.
Rarement formulée, mais largement partagée :

“Ajouter = créer de la valeur.”

Ajouter une feature.
Ajouter une option.
Ajouter une intégration “pour débloquer un deal”.

Sur le moment, ça paraît rationnel.
Plus de besoins couverts, donc plus de valeur délivrée.

C’est aussi une addiction chimique.

Livrer une fonctionnalité déclenche une récompense immédiate :
c’est visible, coché, terminé.
Nettoyer, stabiliser ou retirer ne déclenche rien.
C’est de l’entretien. C’est invisible.

Nos organisations produit sont devenues des usines à dopamine, optimisées pour la gratification du ship plutôt que pour la résolution du problème.

Une illusion confortable.

Le mythe du manque

Quand un produit n’active pas, on parle de manque.
Quand l’adoption stagne, on parle de trous fonctionnels.
Quand la roadmap glisse, on parle de capacité.

Presque jamais de surcharge.

Pourtant, beaucoup de produits ne souffrent pas d’un déficit de fonctionnalités.
Ils souffrent d’un excès de complexité.

Le produit n’a pas faim.
Il est en surpoids.

La charge cognitive n’est pas une métaphore

La mémoire de travail humaine est un réservoir fini.
Chaque option inutile, chaque incohérence, chaque hésitation consomme de l’énergie mentale.

Le temps de décision n’augmente pas progressivement avec le nombre de choix.
Il explose.

À force d’ajouter des options pour “aider”, vous saturez la bande passante de l’utilisateur avant même qu’il ait trouvé de la valeur.

Vous ne lui offrez pas de liberté.
Vous lui infligez de la fatigue.

Le produit ne meurt pas de faim.
Il étouffe.

Ce que le cerveau ne peut pas encaisser (et que les roadmaps ignorent)

Ce dont on parle ici n’est pas une opinion produit.
C’est une contrainte biologique.

Le cerveau humain ne traite pas une infinité d’options en parallèle.
Il fonctionne avec une mémoire de travail limitée, conçue pour arbitrer vite dans des environnements simples — pas pour naviguer dans des systèmes saturés.

Chaque choix supplémentaire impose un coût mesurable :

• plus de temps pour décider

• plus d’énergie mentale consommée

• plus de risque d’abandon

Ce coût n’est pas linéaire.
Il est disproportionné.

Au-delà d’un certain seuil, ajouter un choix détruit la capacité de choisir.
C’est exactement ce que font beaucoup de produits matures :
ils transforment des parcours simples en successions de micro-arbitrages permanents.

L’utilisateur ne se dit pas :

“Ce produit est trop complexe.”

Son cerveau fait plus simple.
Il décroche.

Pas par rejet.
Par fatigue.

La fatigue décisionnelle est un tueur silencieux

Chaque hésitation, chaque “je verrai plus tard”, chaque parcours abandonné consomme une ressource rare : l’énergie cognitive.

Et cette énergie est partagée avec tout le reste :

• le travail réel de l’utilisateur

• ses urgences

• ses priorités

Quand un produit exige trop d’effort mental pour délivrer sa valeur, il perd.
Même s’il est objectivement “puissant”.

Beaucoup de problèmes d’activation ne sont pas des problèmes de compréhension.
Ce sont des problèmes de surcharge neurologique.

Trop d’options.
Trop d’exceptions.
Trop de chemins possibles.

Le cerveau ne négocie pas.
Il coupe.

La taxe de complexité

(Personne ne la vote. Tout le monde la paie.)

Chaque fonctionnalité ajoute bien plus que du code :

• de nouveaux états possibles

• des comportements implicites

• des cas limites

• des dépendances invisibles

Pris individuellement, le coût paraît marginal.
Collectivement, il devient exponentiel.

QA plus long.
Onboarding plus confus.
Support saturé de “comment faire”.
Delivery ralenti par la peur de casser.

Cette taxe n’apparaît dans aucun dashboard de roadmap.
Mais elle est payée à chaque release.

Le point de bascule : quand la valeur commence à décroître

Un produit peut continuer à livrer… tout en créant moins de valeur.

Les signaux sont discrets, puis persistants :

• le time-to-value s’allonge

• l’activation stagne malgré les ajouts

• les PMs gèrent des exceptions, pas des problèmes

• chaque décision coûte plus cher qu’avant

À ce stade, ajouter n’accélère plus.
Ça anesthésie temporairement.

La complexité progresse plus vite que la valeur.

Stabiliser n’est pas ralentir

C’est livrer.

On a appris à associer livraison et nouveauté.
Et à reléguer la stabilité au rang de dette optionnelle.

C’est une erreur stratégique.

Stabiliser, c’est livrer :

• de la lisibilité

• de la prévisibilité

• de la confiance

• de la vitesse réelle

Un produit stable n’est pas figé.
C’est un produit dont les règles sont claires, limitées, maîtrisées.

Quand la variabilité baisse, la valeur circule mieux.

Le rôle oublié du leadership produit

Le leadership produit ne consiste pas à empiler des réponses.
Il consiste à protéger le système.

Protéger :

• la compréhension utilisateur

• la capacité de l’équipe à livrer

• la cohérence dans le temps

Un produit sans soustraction devient bruyant.
Un produit bruyant devient lent.
Un produit lent finit par perdre.

L’obésité fonctionnelle n’est pas un accident.
C’est le résultat d’un enchaînement de “oui” non arbitrés.

Ajouter est facile.
C’est chimique.

Retirer est vital.
C’est systémique.

Et maintenant ?

Dans la plupart des produits, la complexité ne vient pas d’une mauvaise intention.
Elle vient d’une accumulation de décisions non tranchées :

• ce qu’on garde “au cas où”

• ce qu’on ne retire pas “par prudence”

• ce qu’on continue de livrer “par inertie”

Résultat :
le produit avance,
mais la valeur circule de moins en moins.

La vraie question n’est pas :

“Qu’est-ce qu’on pourrait encore ajouter ?”

Mais :

“Qu’est-ce qui empêche aujourd’hui la valeur de circuler ?”

Et surtout :

“Qu’avons-nous le courage d’arrêter ?”

Ce travail ne commence pas par une roadmap.
Il commence par une lecture lucide du système : usage réel, frictions, arbitrages implicites, signaux faibles.

Certaines équipes appellent ça “faire une pause”.
En réalité, c’est reprendre le pilotage.

Moins de bruit.
Moins d’inertie.
Plus d’impact.