Comment sortir de la Feature Factory (85% des fonctionnalités ne servent à rien)

85%. Seuls 10-15% des fonctionnalités produisent des améliorations mesurables. Le reste ? Aucun effet, ou pire, un effet négatif.

Ce n'est pas une opinion — c'est une étude de Microsoft et Google sur des milliers de fonctionnalités lancées. La majeure partie de ce qu'on produit ne sert à rien.

Et on paie pour le faire.

Le chiffre vient d'une étude de Ronny Kohavi (ex-Microsoft, ex-Amazon) sur des milliers de fonctionnalités testées par expériences contrôlées. Sur Bing, seuls 10-15% des fonctionnalités ont produit des améliorations statistiquement significatives de la métrique cible. Un tiers n'a eu aucun effet mesurable. Et un tiers a empiré les choses. Google a confirmé des chiffres similaires en interne.

Maintenant pensez à votre entreprise. Si même 50% de ce qu'on produit ne génère pas de valeur — combien d'heures, combien d'argent, combien de personnes sont dédiées à des choses qui ne servent à rien ? Pour une PME à 2M€ avec 3 développeurs, 50% de gaspillage équivaut à environ 150K€/an de salaires brûlés sur des fonctionnalités que personne n'utilisera jamais.

Le terme "Feature Factory" a été inventé par John Cutler en 2016, dans un post devenu viral dans la communauté produit. Cutler, alors product evangelist chez Pendo, a identifié 12 signes indiquant si votre entreprise est une Feature Factory :

1. Aucune mesure du succès après le lancement
2. Aucun lien entre fonctionnalités et résultats business
3. Beaucoup de project management mais zéro product management
4. "Success theater" — livrer est le succès, personne ne demande si ça a marché
5. Les roadmaps sont des listes de fonctionnalités, pas des listes de problèmes à résoudre
6. Les équipes n'ont pas de contact direct avec les utilisateurs
7. Les décisions sont prises par des stakeholders éloignés du produit
8. Le backlog grossit plus vite qu'on ne livre
9. Aucune équipe n'a le pouvoir de dire "non" à une fonctionnalité demandée
10. Les rétrospectives portent sur le processus, jamais sur l'impact
11. Les designers sont des "pixel pushers" — ils reçoivent des spécifications, pas des problèmes
12. La vitesse de livraison est la seule métrique qui compte

Combien de ces points reconnaissez-vous dans votre entreprise ? Si la réponse est plus de 4, vous êtes dans une Feature Factory.

Marty Cagan, fondateur du Silicon Valley Product Group et auteur de "Inspired" et "Empowered", a tracé une distinction fondamentale : Feature Team vs Empowered Team.

Les Feature Teams reçoivent une liste de choses à construire. Ils exécutent. Ne demandent pas pourquoi. Ne mesurent pas l'impact. Le succès, c'est la livraison — tu as livré ? Bien. Ça a marché ? Pas ton problème.

Les Empowered Teams reçoivent un problème à résoudre et une métrique de succès. Comment ils le résolvent est leur responsabilité. Le succès n'est pas la livraison — c'est le résultat. On a construit quelque chose qui n'a pas fait bouger la métrique ? Ce n'est pas un succès. C'est une expérience ratée dont on tire des leçons.

La différence n'est pas dans les personnes. C'est dans le système. Les mêmes personnes, dans un Feature Team, produisent des fonctionnalités inutiles. Dans un Empowered Team, elles résolvent des problèmes réels. Comme dans le cas NUMMI de Toyota : ce n'étaient pas les personnes qui étaient cassées — c'était le système.

Henry Ford, 1913. La chaîne de montage réduit le temps de production du Model T de 12 heures à 93 minutes. Révolution industrielle.

Le principe : plus d'output = plus de valeur. Chaque unité produite crée de la valeur.

On l'a appliqué au logiciel, aux services, aux produits digitaux. Plus de fonctionnalités = plus de produit = plus de valeur. Faux.

Dans une usine, chaque pièce a de la valeur. Dans le logiciel et les services, les fonctionnalités embrouillent les utilisateurs, ralentissent le produit, ne sont jamais utilisées. On paie pour se saboter. C'est la même erreur que ceux qui copient les outils de Toyota sans le système de pensée.

Melissa Perri dans son livre "Escaping the Build Trap" (2018) a donné un nom à cette pathologie : la Build Trap. Les entreprises tombent dans le piège quand elles mesurent le succès par l'output (combien de choses on a produites) au lieu de l'outcome (quel impact elles ont eu). La Build Trap est insidieuse parce qu'elle ressemble à de la productivité — l'équipe est occupée, les releases sont fréquentes, la roadmap avance. Mais la valeur pour le client ne croît pas.

Le paradoxe : plus on ajoute de fonctionnalités à un produit digital, plus le produit se dégrade. Chaque fonctionnalité est un compromis — espace à l'écran, attention de l'utilisateur, complexité du code. Comme disait Antoine de Saint-Exupéry : "La perfection est atteinte non pas lorsqu'il n'y a plus rien à ajouter, mais lorsqu'il n'y a plus rien à retirer."

Chaque fonctionnalité ajoutée a un coût visible — heures de développement, design, tests. Mais le coût réel est celui qui est invisible.

Martin Fowler, chief scientist de ThoughtWorks, a formalisé le concept de Technical Debt — dette technique. Chaque fonctionnalité ajoutée crée un "intérêt" qu'on paie pour toujours :

• Charge cognitive pour les utilisateurs : chaque option en plus rend le produit plus difficile à utiliser. Loi de Hick : le temps de décision augmente logarithmiquement avec le nombre de choix. 10 options au lieu de 3 ne sont pas "mieux" — c'est la paralysie.
• Maintenance pour les développeurs : chaque fonctionnalité doit être maintenue, mise à jour, testée à chaque nouveau déploiement. Une app avec 100 fonctionnalités demande 10× le travail de maintenance d'une avec 10.
• Surface de test : chaque nouvelle fonctionnalité interagit avec toutes les autres. Les combinaisons croissent exponentiellement. Avec 50 fonctionnalités, les interactions possibles se comptent en milliers.
• Documentation et support : chaque fonctionnalité génère des tickets, des questions, des tutoriels, des FAQ. Le coût du support croît linéairement (ou pire) avec les fonctionnalités.

Les cas les plus célèbres de suppression de fonctionnalités comme stratégie de croissance :

Instagram en 2020 a supprimé l'onglet IGTV de la page d'accueil, simplifiant la navigation. L'engagement sur la plateforme a augmenté. Moins d'options, plus de focus, plus de temps passé.

Apple en 2016 a supprimé la prise jack de l'iPhone 7. Le monde est devenu fou. Les ventes n'en ont pas souffert. Apple a simplifié le design interne, amélioré la résistance à l'eau, et créé un marché de milliards (AirPods) — tout en supprimant une fonctionnalité.

Basecamp (ex 37signals) est l'exemple le plus radical : Jason Fried et David Heinemeier Hansson ont construit une entreprise de centaines de millions en refusant systématiquement d'ajouter des fonctionnalités que les clients demandaient. Leur livre "Getting Real" est un manifeste contre la Feature Factory : "Build half a product, not a half-assed product."

La question n'est pas "cette fonctionnalité est-elle utile ?" — la question est "cette fonctionnalité est-elle plus utile que tout ce à quoi on doit renoncer pour la construire et la maintenir ?" Presque toujours, la réponse est non.

Insight

Chaque fonctionnalité a un coût caché : charge cognitive, maintenance, tests, documentation. Parfois supprimer une fonctionnalité crée plus de valeur qu'en ajouter une.

2006. Netflix a un problème de rétention sur les DVD. Les gens s'inscrivent puis disparaissent.

Ils ont découvert que le nombre de DVD ajoutés à la file d'attente lors de la première session prédisait la rétention. Ceux qui en ajoutaient beaucoup revenaient. Ceux qui en ajoutaient peu disparaissaient.

Ils ont optimisé ce seul moment. La rétention a explosé.

Ils n'ont pas ajouté de fonctionnalités. N'ont pas amélioré le catalogue. Ont trouvé le moment qui comptait et l'ont rendu inévitable. Exactement comme les 7 amis de Facebook : un chiffre, une contrainte, des résultats exponentiels.

Slack a fait pareil. Stewart Butterfield a découvert que les équipes qui envoyaient 2 000+ messages dans les 30 premiers jours avaient un taux de conversion trial-to-paid de 93%. Les équipes sous 500 messages ? Quasi zéro. La métrique qui prédisait tout n'était pas une fonctionnalité — c'était un comportement. Slack a repensé l'onboarding pour maximiser les messages initiaux, pas pour montrer des fonctionnalités.

Ce principe s'appelle la North Star Metric — la métrique unique qui prédit le succès à long terme. Pour Spotify, c'est le temps d'écoute. Pour Airbnb, les nuits réservées. Pour votre entreprise, qu'est-ce que c'est ? Si on ne le sait pas, on construit des fonctionnalités à l'aveugle.

Insight

Netflix n'a pas amélioré le produit en ajoutant des fonctionnalités. Ils ont trouvé le seul moment qui prédisait la rétention — et ont rendu cette expérience immanquable.

Si la Feature Factory est le problème, l'expérimentation contrôlée est la solution. Et personne ne le fait mieux que Microsoft.

La plateforme ExP (Experimentation Platform) de Microsoft exécute plus de 30 000 expériences contrôlées par an. Chaque modification de Bing, Office, Teams, Azure est testée sur un échantillon avant d'être déployée pour tous. Ronny Kohavi, ex-VP de Microsoft et auteur de "Trustworthy Online Controlled Experiments", a estimé qu'ExP génère des centaines de millions de dollars de valeur annuelle — pas en construisant plus, mais en construisant mieux.

Un exemple concret : en 2012, un ingénieur de Bing a proposé un changement dans l'affichage des titres des annonces publicitaires. Ça semblait banal. Le test A/B a révélé un impact de +100 millions $ de revenu annuel. Sans le test, cette modification aurait été en file d'attente derrière 50 fonctionnalités "plus importantes" selon les stakeholders.

Booking.com pousse ce principe à l'extrême : chaque employé peut lancer une expérience sans demander la permission. L'entreprise exécute des milliers de tests simultanément. Le PDG a déclaré que 90% des expériences échouent — et c'est le point. Les 10% qui marchent génèrent des milliards.

Pour les PME, pas besoin de plateformes enterprise. Il faut trois principes :

1. Chaque fonctionnalité est une hypothèse. Pas "construisons X". Mais "on pense que X améliorera la métrique Y de Z%". Si on ne peut pas formuler l'hypothèse, on ne construit pas la fonctionnalité.
2. La métrique de succès se définit AVANT le lancement, pas après. 90% des entreprises définissent le succès rétroactivement — en sélectionnant la métrique qui a progressé. Ce n'est pas de l'expérimentation. C'est du biais de confirmation.
3. Minimum Viable Test (MVT). Quelle est la plus petite chose à construire pour tester l'hypothèse ? Pas le produit complet — la version la plus économique qui donne des données réelles. Un mockup cliquable. Une landing page. Un test manuel sur 10 clients. Comme dans le modèle Zara : petits lots, données réelles, on ne scale que les gagnants.

Le framework pratique pour une PME : avant le prochain déploiement, écrivez sur une feuille : "Si on lance [fonctionnalité], on s'attend à ce que [métrique] s'améliore de [X%] dans les [timeframe]." Si on ne peut pas remplir cette phrase, on n'est pas prêt à construire. On est prêt à mieux comprendre le problème.

Donnée

Microsoft exécute 30 000+ expériences contrôlées par an. 90% échouent. Les 10% qui marchent génèrent des centaines de millions. — Ronny Kohavi, "Trustworthy Online Controlled Experiments"

La solution n'est pas "produisez moins". C'est "produisez en sachant".

L'usine produit. Le scientifique expérimente.

La différence : chaque fonctionnalité, chaque service, chaque initiative part avec une hypothèse et une métrique de succès définies avant le lancement. Pas après.

Ford a inventé l'usine. Mais on ne construit pas de voitures. Et dans notre secteur, l'usine ne suffit pas. Il faut le laboratoire. Comme Zara qui lance 12 000 produits : petits lots, feedback réel, on ne scale que les gagnants.

Le template du laboratoire en 4 lignes :

1. Hypothèse : "On pense que [changement X] produira [résultat Y] pour [segment Z]."
2. Métrique : "On le mesurera via [métrique spécifique] dans les [timeframe]."
3. Seuil : "On considère comme succès une amélioration d'au moins [X%]."
4. Kill criteria : "Si après [timeframe] la métrique ne s'améliore pas de [X%], on supprime la fonctionnalité."

Les kill criteria sont la partie la plus difficile. Personne ne veut supprimer quelque chose qu'on a construit. Mais sans la discipline de tuer les fonctionnalités qui ne marchent pas, le produit devient un cimetière de bonnes intentions. Et chaque fonctionnalité morte mais non retirée consomme des ressources — pour toujours.