Feature creep : le fondateur en est presque toujours la source

Un guide de terrain pour les fondateurs non techniques qui regardent leur produit gagner des features plus vite qu’il ne gagne des utilisateurs : ce qu’est vraiment le feature creep, pourquoi le conseil classique de « dire non » ne marche pas chez vous, et le diagnostic en trois sources plus le test d’une seule question qui l’arrête avant le prochain sprint.

Le CEO a ouvert son laptop et s’est mis à compter. Vingt-trois features livrées les six derniers mois. Trois ont servi. Les vingt autres ont été payées, designées, construites, testées, mises en production, et devaient maintenant être maintenues jusqu’à la mort de l’entreprise ou jusqu’à ce que quelqu’un prenne le temps de les supprimer.

Il a relevé la tête. « On en est à cent cinquante mille. Comment c’est arrivé ? »

Nous savions exactement comment c’était arrivé. Nous étions sur chacune de ces calls. L’investisseur qui suggérait « il vous faut un agent IA sur le dashboard ». Le client flagship qui demandait, en call de renouvellement, si l’export pouvait aussi pousser vers Slack. La PM revenue d’un événement avec un Notion intitulé « ce qu’on a appris ». Le fondateur lui-même, un dimanche soir, regardant la vidéo de lancement d’un concurrent et balançant un screenshot dans le Slack de l’équipe avec la légende : « il nous faut ça ».

Vingt-trois oui. Trois qui comptaient. Les vingt autres étaient du feature creep.

Ce qu’est le feature creep

Le feature creep est l’expansion lente, presque invisible, du périmètre d’un produit au-delà de ce qui était prévu, alimentée par une accumulation de décisions individuellement raisonnables. Chaque feature ajoutée, prise isolément, paraît inoffensive. C’est leur poids cumulé qui tue le produit, le budget, ou les deux.

Le terme remonte à la littérature de génie logiciel et de game design des années 70 et 80, quand les équipes ont commencé à nommer le pattern qui fait s’effondrer les systèmes ambitieux sous leur propre complexité. Frederick Brooks a écrit sur un cousin de ce pattern, le second-system effect, il y a cinquante ans. Le vocabulaire est vieux. La maladie n’a pas changé.

Ce qui a changé, c’est qui en est porteur. Dans l’ancienne version, le feature creep, c’était quelque chose qu’une équipe d’ingénierie se faisait à elle-même quand personne ne regardait. Dans la startup moderne, l’équipe d’ingénierie n’y est presque pour rien. C’est le fondateur qui valide les features. L’équipe ne fait qu’exécuter.

Si vous êtes fondateur non technique et que votre produit a plus de features que vos utilisateurs n’ont de cas d’usage, vous n’êtes pas victime du feature creep. Vous en êtes la source.

Feature creep vs scope creep : pourquoi la distinction compte

Les deux termes sont utilisés comme synonymes et ne devraient pas l’être. Le remède de l’un n’est pas le remède de l’autre.

Le scope creep est un problème contractuel. Vous avez signé un SOW avec un prestataire pour cinq features, et il y en a maintenant neuf dans le build. Quelqu’un a dit oui à quatre choses qui n’étaient pas dans l’accord initial. Vous, le plus souvent. Parfois le commercial. Parfois un chef de projet qui voulait être serviable. Le coût apparaît sur la facture. La solution est contractuelle : un avenant écrit, une réestimation, un prix renégocié. Le choix de forfait vs régie que vous avez fait au départ décide à quel point cette conversation va faire mal.

Le feature creep est un problème de produit. Le produit, sur des mois et des années, accumule des features pour lesquelles personne ne se bat et que personne ne retire. Il n’y a pas de moment unique où une ligne est franchie. Le coût apparaît à trois endroits, tous invisibles jusqu’à ce qu’ils ne le soient plus : des factures de maintenance qui se cumulent, une UI qui perd les nouveaux utilisateurs, et une équipe qui n’arrive de moins en moins à livrer la seule chose qui compterait vraiment, parce qu’elle est occupée à maintenir les vingt qui ne comptent pas.

Le scope creep est une bataille que vous pouvez perdre en une conversation. Le feature creep est une bataille que vous perdez en n’ayant pas la conversation. La première a un prestataire en face. La seconde n’a que vous.

Les trois sources du feature creep

Une fois que vous acceptez que vous en êtes la source, l’étape suivante est d’arrêter de penser au feature creep comme à une seule maladie. Il y en a trois. Vues depuis votre siège, elles se ressemblent. Toutes arrivent sous la forme « on devrait aussi construire X ». La bonne réponse dépend de laquelle vous regardez.

Source 1 : la traction client (parfois réelle)

Un client demande la feature. Il utilise votre produit, il se heurte à un mur, il veut que le mur tombe. C’est la seule source où la réponse est parfois un oui propre.

Le piège : un seul client n’est pas un signal. Nous avons vu des fondateurs livrer un build de six semaines pour une demande qui venait d’une seule call de renouvellement, où le client allait renouveler de toute façon, et où aucun autre client n’a jamais redemandé la même chose. La feature finit utilisée par personne pour le reste de sa vie et coûte à l’équipe un dev-mois à chaque fois que le framework sous-jacent change.

Le test n’est pas « est-ce qu’un client l’a demandée ». Le test est « est-ce que cinq autres clients vont churner ou refuser de s’onboarder sans ça ». Si oui, construisez. Si la réponse est « bon, ce client-là la veut vraiment », vous êtes en train de négocier une feature de contrat custom, pas une feature de produit. Faites payer différemment ou dites non.

Source 2 : l’appât commercial (presque jamais réel)

Un prospect en call de vente dit « si vous aviez X, on signait demain ». Votre head of sales remonte la demande à l’équipe produit comme un bloqueur de deal. Le fondateur, qui à ce stade est généralement aussi le head of sales, valide le build.

Le prospect ne signe jamais. Il ne signe jamais parce que X n’était pas vraiment la raison pour laquelle il ne signait pas. X était la version polie de « on n’est pas prêts », ou « votre prix est faux », ou « on utilise déjà un concurrent et changer fait mal ». La feature est construite, le deal ne ferme pas, et vous voilà propriétaire de X pour toujours.

Le test tient en une phrase : est-ce que le prospect signera un bon de commande payé aujourd’hui, conditionné à la livraison de X dans Y semaines, avec une clause écrite d’annulation si la livraison glisse. Si oui, vous avez un vrai signal, et vous avez un client payant qui finance le build. Si non, vous avez une objection polie déguisée en demande de feature. Nous avons fait passer ce test à des dizaines de features dites « bloqueur de deal ». Le taux de conversion entre « ils ont dit qu’ils signaient » et « ils ont signé quand on leur a présenté le contrat » est à un chiffre, en bas.

Source 3 : l’inquiétude du fondateur (la tueuse silencieuse)

Le fondateur veille tard. Il a une heure de calme. Il ouvre le produit, le regarde, et ressent cette insatisfaction basse intensité qu’on ressent à force de regarder son propre travail. Le produit paraît trop petit, trop plat, trop discret. Il ouvre le Slack de l’équipe et écrit : « on devrait aussi construire X ».

C’est la source qui livre le plus de features. Elle n’arrive pas déguisée en demande client. Elle arrive déguisée en goût. Le fondateur croit sincèrement que le produit a besoin de X pour être meilleur. Parfois il a raison. Le plus souvent, il s’ennuie, et l’antidote de l’ennui, c’est construire.

Le test pour cette source est le plus dur des trois. Attendez sept jours. Si la feature est toujours dans la tête du fondateur le septième jour, et qu’il peut nommer trois clients qui l’ont spécifiquement demandée la même semaine, construisez. Si l’une des deux conditions échoue, archivez la demande. Nous gardons un canal privé où ces demandes vont mourir. Quatre-vingts pour cent ne ressuscitent jamais. Le fondateur ne se souvient même pas d’avoir écrit le message d’origine.

Pourquoi le conseil classique (« il suffit de dire non ») ne marche pas pour un fondateur non technique

Tout autre article sur le feature creep finit par arriver à la même conclusion : l’équipe devrait dire non, le PM devrait défendre le backlog, le lead engineering devrait pousser en retour. Très bon conseil pour une entreprise avec un vrai PM et un lead engineering senior, tous deux suffisamment solides pour passer outre le fondateur.

Ce n’est pas l’entreprise qui signe les chèques ici. Le fondateur non technique est celui qui finance le build, qui prend les appels clients, qui valide la roadmap. L’équipe ne peut pas passer outre. L’équipe construit ce qu’on lui dit de construire. Si l’équipe est un partenaire externe ou un prestataire (ce qui est la majeure partie de notre monde), la dynamique est pire, parce que l’équipe a un intérêt commercial à dire oui. Chaque oui, c’est de l’heure facturable de plus.

Le conseil « dire non » est donc structurellement à l’envers. Vous, le fondateur, êtes le seul à pouvoir dire non. Personne ne va le faire à votre place. La défense contre le feature creep n’est pas un process que l’équipe fait tourner. C’est une discipline que le fondateur construit.

Cette discipline a un nom dans notre travail, et elle tient en une seule question.

Le test d’une seule question : le test des sept jours

Avant qu’une demande de feature entre dans la roadmap, le fondateur la fait passer par une question :

Est-ce que je peux nommer, par nom d’entreprise, trois clients actuels qui ont demandé cette feature dans les sept derniers jours, par écrit ou en call enregistrée ?

C’est tout. Trois clients. Par nom. Par écrit. En sept jours.

Si oui, la feature est candidate. Elle doit encore passer la conversation build, buy ou attendre, mais elle a gagné le droit d’avoir cette conversation.

Si non, la demande part dans le dossier mort. Pas dans le backlog. Pas dans la colonne « plus tard ». Le dossier mort. Le backlog, c’est l’endroit où les features vont pour être faites. Le dossier mort, c’est l’endroit où elles vont pour être oubliées.

Ce test fait cinq choses utiles en même temps. Il force le fondateur à ancrer la demande dans des clients réels, pas dans son propre goût ni dans la dérobade d’un prospect. Il met un filtre de récence sur la demande, donc les vieux enthousiasmes expirent tout seuls. Il exige une preuve dans un format que le fondateur peut montrer à son équipe, ce qui tue le pattern « faites-moi confiance, c’est ce qu’ils veulent ». Il traite l’appât commercial pour ce qu’il est : une objection polie de prospect n’est pas un client qui demande, par nom, par écrit, la dernière semaine. Et il rend l’inquiétude du fondateur visible, parce que le fondateur doit admettre, à voix haute, qu’aucun client n’attend la chose qu’il veut construire.

Le premier mois après qu’un fondateur adopte ce test, il tue typiquement soixante-dix pour cent des demandes qui seraient entrées dans la roadmap. Le deuxième mois, la vélocité de l’équipe sur les trente pour cent restants double. Au troisième mois, le produit commence à paraître plus petit, et les utilisateurs commencent à l’utiliser plus.

Comment éviter le feature creep quand l’équipe est externe

Le risque est le plus élevé quand l’équipe qui construit le produit n’est pas interne. Nous avons vécu ça des deux côtés : comme l’équipe qui reçoit le message Slack du dimanche soir, et comme l’opérateur qui les envoyait.

Les coups défensifs qui marchent :

• Un canal pour les demandes de feature, une cadence pour le triage. Si les demandes de feature peuvent tomber dans n’importe quelle conversation (DM Slack, e-mail, couloir, call de vente), elles pèsent toutes pareil, ce qui veut dire qu’aucune ne reçoit un vrai examen. Choisissez un canal. Triage hebdomadaire. Ce qui n’a pas survécu une semaine n’était probablement pas réel.
• Des briefs écrits, pas des messages Slack. Chaque feature qui survit au test des sept jours reçoit un brief d’une page avant d’être construite. Le brief oblige le fondateur à articuler le client, le cas d’usage, la métrique de succès, et le coût de ne pas construire. À peu près un quart des features qui survivent au test des sept jours ne survivent pas à l’écriture du brief.
• Une roadmap sur laquelle l’équipe a le droit de pousser en retour. Le fondateur reste propriétaire de la roadmap. Mais l’équipe gagne le droit de signaler les coûts de second ordre de chaque feature nouvelle : quelle capacité existante va ralentir, quel bug connu ne sera pas corrigé, quelle facture de maintenance est en train d’être signée. Le fondateur a le droit de passer outre le signal. Il n’a pas le droit de ne pas être au courant.
• Un item permanent de « suppression » dans la roadmap. Chaque trimestre, une part significative du temps de build part à retirer les features qui n’ont pas été utilisées les quatre-vingt-dix derniers jours. Le produit rétrécit exprès. C’est le seul contrepoids direct au poids cumulé de chaque oui antérieur. Personne n’aime construire ça. Tous les fondateurs qui l’ont fait nous ont remerciés après.

Le coût de ne pas faire ça

Nous rencontrons rarement un fondateur non technique dont le produit est trop petit. Nous en rencontrons beaucoup dont le produit est trop grand et dont l’entreprise est trop petite pour le maintenir.

Chaque feature livrée est une facture permanente de maintenance. Le framework se met à jour, l’API dont dépend la feature change, le service tiers déprécie un endpoint, le navigateur change sa règle de rendu. Chacun de ces événements est gratuit pour les features qui n’existent pas. Chacun est de l’heure facturable pour les features qui existent. Le calcul se cumule en silence. Deux ans plus tard, la moitié de la capacité de l’équipe part à maintenir le produit vivant au lieu de l’avancer, et le fondateur ne comprend pas pourquoi la vélocité s’est effondrée.

La vélocité s’est effondrée parce que le fondateur a passé deux ans à dire oui. L’équipe a fait exactement ce qu’on lui a demandé. Elle a construit. Maintenant elle est coincée à maintenir. À ce stade, le fondateur commence en général à entendre un mot différent de son équipe : rewrite. Cette conversation est presque toujours la mauvaise. La bonne est la conversation sur la suppression.

Le travail pour défaire ça est réel et sans glamour. Supprimer des features. Faire tourner le test des sept jours sur tout le nouveau. Écrire des briefs. Trier en cadence. Le produit rétrécit, la facture rétrécit, et l’entreprise se met à pouvoir livrer la une ou deux choses qui feraient bouger le business. C’est le type de travail le moins cher, et c’est le type que presque personne ne fait avant d’avoir déjà payé l’alternative une fois.

Le CEO de l’ouverture de cet article a fermé son laptop. Nous avons supprimé neuf des vingt features sans usage sur le trimestre suivant. L’équipe a livré la seule feature qui était enterrée dans la file depuis quatre mois — celle qui, quand nous avons regardé les données six semaines plus tard, avait fait bouger la rétention de onze points.

Le produit attendait juste qu’il arrête de construire.

FAQ

C’est quoi le feature creep, en termes simples ?
Le feature creep, c’est ce qui se passe quand un produit accumule des features lentement, au-delà du point où quelqu’un peut dire pourquoi chacune existe. Ce n’est pas une mauvaise décision. C’est des dizaines de décisions à l’air raisonnable qui, additionnées, donnent un produit trop cher à maintenir et trop confus pour les nouveaux utilisateurs.

Quelle est la différence entre scope creep et feature creep ?
Le scope creep est un problème contractuel : du travail en plus qui entre dans un build déjà acté par écrit. Le remède, c’est un avenant ou un SOW renégocié. Le feature creep est un problème produit : des features qui s’empilent dans la roadmap dans le temps, sans moment unique de décision. Le remède, c’est une discipline tenue par le fondateur, pas une clause de contrat.

Comment éviter le feature creep ?
Faites passer chaque demande de feature par une question avant tout : pouvez-vous nommer trois clients actuels qui l’ont demandée, par nom d’entreprise, par écrit, dans les sept derniers jours. Si non, la demande part dans le dossier mort, pas dans le backlog. Couplez ça avec un seul canal pour les demandes, un triage hebdomadaire, des briefs écrits avant tout build, et un item permanent de suppression dans la roadmap. C’est au fondateur d’imposer tout ça. Personne d’autre ne peut.

Pourquoi les fondateurs non techniques causent plus de feature creep que les techniques ?
Deux raisons. Premièrement, le fondateur non technique ne sent pas directement le coût de chaque feature nouvelle : la mise à jour du framework, le changement d’API, la garde d’astreinte. Le prix reste invisible jusqu’à ce qu’il soit énorme. Deuxièmement, construire paraît productif d’une manière que tailler ne paraît pas, donc le réflexe par défaut quand le fondateur s’inquiète est d’ajouter plutôt que de retirer. La combinaison est ce qui produit un produit avec quarante features et trois qui comptent.