Supprimer une fonctionnalité chaque trimestre :moins, mieux

Supprimer une fonctionnalité chaque trimestre : à chaque trimestre, dépréciez une fonctionnalité — celle qui est la moins utilisée de votre produit. La plupart des produits traînent une longue queue de fonctionnalités que moins de dix pour cent des utilisateurs touchent dans un mois ordinaire, et chacune d'elles taxe tous les changements futurs que vous ferez. En supprimer une par trimestre est la discipline qui garde un produit conçu en solo assez resserré pour évoluer pendant des années.

Voici pourquoi le surpoids coûte plus que vous ne le pensez, comment fonctionne le rituel trimestriel, pourquoi il est pénible, et comment distinguer une fonctionnalité morte d'une entreprise morte.

Le coût caché des fonctionnalités que personne n'utilise

Regardez l'usage des fonctionnalités dans votre tableau de bord. Pour chaque fonctionnalité de votre produit, quel pourcentage d'utilisateurs s'en sert réellement dans un mois ordinaire ? Faites ce calcul une fois et vous trouverez la longue queue : des fonctionnalités que moins de dix pour cent des utilisateurs touchent.

Ces fonctionnalités semblent gratuites. Elles sont construites ; elles sont livrées ; elles sont là. Mais elles vous coûtent en continu, car chaque fois que vous modifiez autre chose dans le produit, vous devez vous assurer de ne pas avoir cassé les fonctionnalités de la longue queue — et cette maintenance s'accumule sur toute la vie du code. Chaque fonctionnalité morte est une taxe permanente sur chaque fonctionnalité vivante.

Pour un fondateur solo, la taxe est pire que pour une équipe, parce que vous êtes tout le service de maintenance. Une heure passée à maintenir en vie une fonctionnalité utilisée à cinq pour cent est une heure non consacrée à l'expérience qui fait croître le revenu.

Supprimer une fonctionnalité chaque trimestre : le rituel

La discipline est assez simple pour tenir en un paragraphe. Chaque trimestre : choisissez la fonctionnalité la moins utilisée. Annoncez la dépréciation au petit nombre d'utilisateurs qui s'y fiaient. Supprimez-la.

Les résultats sont immédiats et cumulatifs. Le code se simplifie. Le produit s'affûte. La charge de maintenance baisse. Et la prochaine fonctionnalité que vous construisez atterrit dans un système plus petit et plus propre — ce qui veut dire qu'elle est livrée plus vite et casse moins.

Mettez-le au calendrier comme la revue des indicateurs du lundi : quatre suppressions par an, planifiées, non négociables. Si vous attendez qu'une fonctionnalité soit « évidemment » morte, vous attendrez toujours, car aucune fonctionnalité n'annonce ses propres funérailles.

Le livreThe Solopreneur RevolutionLuis Gonçalves sur la création d'une activité de solopreneur avec l'IA, sans quitter son emploi.Obtenir le livre →

Pourquoi supprimer des fonctionnalités est psychologiquement difficile

Ce n'est pas un problème technique. C'est un problème émotionnel. Vous avez passé du temps sur cette fonctionnalité. Vous vous souvenez de la semaine où vous l'avez construite et du client qui l'a demandée. Et quelque part, un utilisateur se plaint chaque fois que vous retirez quoi que ce soit.

Voici l'asymétrie qui piège les fondateurs : les plaintes dues au retrait paraissent plus vives que celles dues au surpoids, alors même que le surpoids fait plus de dégâts cumulés. Le retrait produit un e-mail furieux aujourd'hui ; le surpoids produit un produit plus lent, des livraisons plus lentes et un code que personne ne veut refactoriser — réparti de façon invisible sur les trois prochaines années.

Supprimez quand même. Les fondateurs qui savent supprimer leurs propres fonctionnalités sont ceux qui gardent leur produit assez resserré pour évoluer. Ceux qui n'y arrivent pas voient leur produit devenir un musée de décisions historiques. Un musée est un endroit agréable à visiter. C'est un endroit terrible à entretenir seul.

Pivoter ou patienter : quand ce n'est pas une fonctionnalité, c'est l'entreprise

Parfois, les données d'usage soulèvent une question plus grande que « quelle fonctionnalité meurt ce trimestre ». Parfois, elles suggèrent que l'entreprise telle qu'elle est constituée ne fonctionne pas. Supprimer une fonctionnalité et supprimer la direction sont deux décisions différentes, et les données vous disent laquelle vous affrontez :

La discipline consiste à regarder honnêtement. La tentation est de continuer à pousser sur l'existant parce que vous y avez investi du temps et que changer de direction ressemble à un échec. Les données se moquent des coûts irrécupérables. Et un pivot n'est pas un échec — c'est l'application de tout ce que vous avez appris à une version plus affûtée du pari. La plupart des entreprises à succès ont pivoté au moins une fois au début, parce que la première idée est rarement la bonne, même validée. La validation vous dit que le problème est réel ; construire vous dit si votre solution est la bonne. La même honnêteté s'applique avant de construire quoi que ce soit — c'est quand abandonner une idée d'entreprise.

La discipline inverse compte tout autant : savoir quand ne pas pivoter. Les fondateurs qui pivotent tous les trois mois ne construisent rien. Un plateau avec une activation cassée et un churn élevé déclenche le pivot ; un plateau avec des fondamentaux sains déclenche la patience. Si vous ne savez pas ce que vous avez, menez le diagnostic sous forme d'expériences structurées — des corrections d'accueil répétées qui ne font jamais bouger l'activation sont elles-mêmes la donnée.

12 semainesVotre carrière en entreprise n'a jamais été le planPostulez au Solopreneur Accelerator.Postuler →

Questions fréquentes

Comment décider quelle fonctionnalité supprimer ?

Par l'usage, pas par le sentiment. Mesurez quel pourcentage d'utilisateurs touche chaque fonctionnalité dans un mois ordinaire, triez par ordre croissant et dépréciez le bas de la liste. La plupart des produits ont une longue queue sous dix pour cent d'usage — cette queue est votre file de suppressions pour les prochains trimestres.

Et si des clients se plaignent quand je retire une fonctionnalité ?

Certains le feront — quelqu'un se plaint chaque fois que vous retirez quoi que ce soit. Annoncez la dépréciation directement au petit nombre qui s'y fiait, laissez-leur un préavis, puis passez à l'acte. Les plaintes dues au retrait paraissent plus vives que celles dues au surpoids, mais le surpoids fait plus de dégâts cumulés ; un e-mail aujourd'hui vaut mieux qu'un produit stagnant dans un an.

À quelle fréquence retirer des fonctionnalités de mon SaaS ?

Une par trimestre. Planifiée, comme votre revue des indicateurs du lundi. Quatre suppressions par an suffisent pour que la charge de maintenance continue de baisser pendant que le produit évolue — et c'est assez rare pour que les utilisateurs fidèles ne sentent jamais le sol bouger sous leurs pieds.

Comment savoir si je devrais plutôt pivoter ?

Un problème de fonctionnalité est local : une fonctionnalité peu utilisée au sein d'indicateurs sains. Un déclencheur de pivot est systémique : faible activation persistante malgré des corrections répétées de l'accueil, churn qui ne réagit pas au travail de rétention, retours pointant un problème que votre produit ne peut pas résoudre, ou marché plus petit que prévu. Et rappelez-vous le contrepoids — les fondateurs qui pivotent tous les trois mois ne construisent rien.