Le problème
La culture startup glorifie la créativité et traite l’abandon comme un échec personnel. Résultat : des roadmaps qui portent des dizaines d’initiatives “intéressantes”, des équipes épuisées par le contexte switching, et des clients qui reçoivent des demi-produits jamais finis. Le vrai problème n’est pas le manque d’idées, c’est l’absence de discipline pour les tuer. Sans critères explicites de désinvestissement, chaque idée vivante consomme du design, du support, et de la dette cognitive. Les fondateurs gardent des projets zombies parce qu’ils ont investi émotionnellement, parce qu’un investisseur a aimé le slide, ou parce qu’une équipe a peur d’admettre que le signal marché était faible. Les tableaux de bord montrent parfois de l’activité sans impact : features peu utilisées, segments marginaux servis au prix du cœur de métier. Pire, la peur de tuer nourrit le consensus : on “met en pause” sans jamais fermer, ce qui laisse croire que la reprise est imminente. Le marché récompense la concentration ; une culture qui ne sait pas tuer les idées dilue la valeur perçue et ralentit tout ce qui compte vraiment. Les équipes support finissent par porter le coût des idées non tuées : tickets étranges, edge cases documentés nulle part, et promesses commerciales orales qui deviennent de la dette morale. Le marketing produit hérite souvent d’une narration trop large : trop d’histoires, pas assez de preuves, et des pages pricing qui promettent implicitement des capacités maintenues à la peine. Les symptômes se voient dans les démos où l’on saute des écrans “en travaux” et dans les SLA impossibles à tenir parce que la surface a explosé.
Pourquoi ça échoue
Tuer des idées est un métier parce que la rareté stratégique est le carburant de l’exécution. Chaque idée survivante doit mériter l’attention qu’on lui retire aux autres. La capacité à arrêter vite préserve le runway et la morale : mieux vaut un arrêt clair qu’une lente agonie. Pour les clients, moins de surface mais plus de qualité renforce la confiance : ils comprennent où vous allez. Pour les équipes, un rituel de kill listé réduit la politique : ce ne sont pas les personnes qu’on rejette, ce sont les hypothèses invalidées. C’est aussi un signal de maturité auprès des boards : montrer ce que vous ne ferez pas prouve que vous protégez le focus. Enfin, tuer une idée libère des données : on documente pourquoi elle a été écartée, ce qui évite de la ressusciter sans nouvelles preuves. Une organisation qui célèbre les arrêts intelligents apprend plus vite qu’une organisation qui célèbre seulement les lancements bruyants. Le “non” productif est une compétence rare ; il mérite la même préparation qu’un “go”. Le kill bien mené évite aussi l’illusion du progrès : des roadmaps colorées qui bougent sans jamais livrer une expérience cohérente pour un segment cible clairement défini. Il protège la cohérence de marque : chaque surface supplémentaire est un endroit où défendre le ton, la posture sécurité, et les attentes de service. Les boards ne demandent pas souvent combien d’idées vous portent ; ils l’infèrent de la vélocité, de la marge, et des histoires de churn. Un portfolio maigre est plus simple à expliquer et à opérer au quotidien.
Méthode concrète
Faire du “kill” un métier
Critères de survie publics — Traction, willingness to pay, coût de service, alignement stratégique, risque. Si une idée ne passe pas un minimum sur deux axes, elle est candidate à l’arrêt.
Kill review régulière — Mensuel ou trimestriel, agenda dédié : liste des initiatives actives, données récentes, décision explicite continuer / pivoter / arrêter.
Budget de fin de vie — Prévoir le coût d’arrêt propre : communication client, migration, documentation, désactivation technique. Un kill brouillon coûte plus cher qu’un kill planifié.
Règle du “un remplace un” — Nouvelle idée majeure seulement si une autre sort du portfolio. Cela force la conversation sur la valeur relative.
Zombie hunt — Traquer ce qui consomme du support ou de l’infra avec peu d’usage : sunsetting programmé plutôt que maintien éternel.
Cimetière d’idées — Journal court des idées tuées avec raison et date de réouverture éventuelle. Empêche les débats éternels sur les vieux fantômes.
Responsabilité du décideur — Le kill doit avoir un nom, pas “l’équipe a décidé”. Cela clarifie la chaîne de responsabilité.
Anti-patterns
“On met en pause”, roadmaps sans capacité réelle, et features maintenues pour un seul client bruyant sans contrat reflétant le coût.
Politique “petit hack” — Toute demande ad hoc passe les critères de survie ou est refusée avec une alternative standardisée ; sinon le produit devient un patchwork de exceptions.
Modèle de score léger — Même vocabulaire pour les PM : traction, coût, risque, alignement ; évite les débats incomparables.
Sunsetting dans la roadmap — Nommez les fins de vie comme des livrables, pas comme une surprise de blog.
Exemple
Une équipe SaaS garde un module “IA expérimentale” ouvert aux beta testeurs pendant dix-huit mois. L’usage est faible, le support explose, la roadmap principale souffre. Un kill review impose des seuils : adoption active, tickets par compte, marge après coûts de succès client. Le module ne passe pas ; l’équipe annonce un sunset avec migration guidée et crédit pour les early adopters. Morale en hausse : moins de bruit, plus de focus sur le cœur facturé. Un second cas : une marketplace poursuit trois verticales en parallèle faute de vouloir décevoir des partenaires. Le CEO applique “un remplace un” : deux verticales sont gelées, ressources doublées sur celle qui montre la répétition d’usage la plus forte. Les partenaires mécontents reçoivent une explication honnête et un calendrier ; la croissance accélère car l’équipe livre enfin une expérience complète sur un segment. Un troisième exemple : une fonctionnalité existe pour un client enterprise unique ; le kill est remplacé par un contrat de services explicite plutôt que par une dette produit cachée. Le “métier” du kill ici est financier autant que stratégique. Après l’arrêt, l’équipe observe moins d’escalades et des commentaires NPS plus clairs : les clients ne tombent plus sur des recoins à demi maintenus. Le cimetière d’idées empêche aussi qu’un même concept raté revienne chaque saison budgétaire sous un nouveau nom. Former le support et les ventes sur la différence entre contournement temporaire et promesse produit permanente réduit les promesses implicites qui ressuscitent les zombies.
Ce qu'il faut faire maintenant
Listez cinq idées ou initiatives actives qui ne tiennent pas un test de survie simple : usage récent, lien au revenu ou à la rétention, coût marginal. Pour chacune, choisissez continuer, pivoter, ou tuer avec une date et un propriétaire. Programmez un kill review dans les quatorze prochains jours ; invitez finance et succès client pour éviter l’angle purement produit. Écrivez une entrée dans votre cimetière d’idées pour tout arrêt, avec la métrique qui a tranché. Si vous utilisez Lumor ou un pair exigeant, demandez : “Que feriez-vous si vous deviez couper 30 % de surface produit demain ?” — utilisez la réponse pour prioriser les kills réels plutôt que théoriques. Communiquez en interne un kill comme une libération de capacité, pas comme une punition. Revenez dans trente jours : le bon indicateur n’est pas le nombre d’idées lancées, mais le nombre d’hypothèses invalidées proprement. Ajoutez une règle d’équipe : toute nouvelle epic doit citer quoi elle remplace ou pourquoi le portfolio s’élargit malgré la contrainte de capacité. Mesurez le temps passé en réunions de suivi sur des initiatives à faible signal : si ce temps dépasse celui consacré au cœur, votre culture favorise encore la survie des idées faibles. Associez chaque kill à une déclaration de capacité : heures par semaine rendues au travail sur le cœur, pas seulement un optimisme vague. Vérifiez que votre instrumentation mesure réellement l’usage des features débattues : beaucoup de disputes de kill viennent de définitions analytics non partagées. Avant le prochain cycle de planification, imprimez les critères de survie et scorez le backlog en public : l’inconfort immédiat évite une dérive coûteuse le trimestre suivant.
Pour aller plus loin
Lumor confronte votre idée à 13 rôles IA pour stress-tester vos hypothèses, révéler les angles morts et livrer un verdict, des scores et un plan d’exécution.