Mon article en bref
Une feature factory est une organisation produit qui livre fonctionnalité après fonctionnalité sans jamais mesurer leur effet. L’équipe est évaluée sur ce qu’elle produit et sur le respect des dates, jamais sur le problème qu’elle résout.
Voici les points essentiels à retenir :
- Définition : une équipe mesurée sur son débit de livraison plutôt que sur l’impact obtenu.
- Le symptôme central : personne ne sait dire si la dernière fonctionnalité livrée a servi à quelque chose.
- Signe révélateur : la roadmap est une liste de fonctionnalités datées, pas une liste de problèmes à résoudre.
- Cause principale : elle est organisationnelle, pas individuelle — c’est le système d’évaluation qui produit le comportement.
- Premier levier : reformuler un élément de roadmap en problème et en résultat attendu.
- Ce n’est pas une question de vitesse : une feature factory peut être très rapide, c’est même souvent le cas.
Une feature factory, ou « usine à fonctionnalités », désigne une organisation dans laquelle les équipes produit enchaînent les livraisons sans vérifier qu’elles produisent un effet. Le travail y est évalué sur sa quantité et sur le respect du calendrier — combien de fonctionnalités, livrées quand — et non sur le problème résolu pour l’utilisateur ou pour l’entreprise.
L’expression a été popularisée par John Cutler, dont la liste de signes révélateurs a durablement marqué la communauté produit. Elle décrit une situation extrêmement répandue, et rarement identifiée comme un problème par ceux qui la vivent : de l’intérieur, une feature factory ressemble simplement à une équipe très occupée. Voyons ce qui la caractérise, comment la reconnaître, d’où elle vient et par quoi commencer pour en sortir.
Sommaire
Qu’est-ce qu’une feature factory ? Définition
La feature factory se définit par ce qu’elle mesure. Dans une organisation saine, une équipe produit se demande quel problème elle cherche à résoudre et à quoi elle saura qu’il l’est. Dans une feature factory, la question est remplacée par une autre : combien d’éléments seront livrés d’ici la fin du trimestre, et à quelles dates.
Le glissement paraît anodin. Il change pourtant toute la chaîne de décision. Une fonctionnalité livrée devient une réussite par le seul fait d’avoir été livrée. Personne n’a de raison de revenir dessus, puisque le succès a déjà été constaté au moment de la mise en production. Le produit accumule ainsi des fonctionnalités dont plus personne ne connaît l’usage réel.
Une feature factory n’est pas une équipe lente. C’est souvent une équipe très rapide, qui court dans une direction que personne ne vérifie.
Équipe de fonctionnalités ou équipe produit
Marty Cagan formule la même distinction en opposant les feature teams et product teams : les premières reçoivent une liste de fonctionnalités à construire, les secondes reçoivent des problèmes à résoudre et restent responsables du résultat. La différence ne tient ni aux compétences ni à l’outillage, mais au mandat donné à l’équipe.
Les signes qui ne trompent pas
La feature factory se diagnostique moins par le discours que par les pratiques. La liste de John Cutler, 12 signs you’re working in a feature factory, reste la référence sur le sujet. Voici les signes que je retrouve le plus souvent sur le terrain :
- Aucun suivi après la mise en production — l’équipe passe à la fonctionnalité suivante le lendemain de la livraison. Le meilleur test consiste à demander l’usage de la dernière fonctionnalité livrée : le silence est éloquent.
- La roadmap est une liste de fonctionnalités datées — et non une liste de problèmes assortis de résultats attendus.
- Le succès se mesure en livraisons — nombre de tickets terminés, respect des dates, vélocité érigée en objectif.
- Personne ne dit jamais non — toute demande entre dans le backlog, la priorisation se réduit à un ordre de passage.
- L’équipe ne rencontre pas les utilisateurs — le besoin arrive reformulé par un tiers, jamais observé directement.
- Aucune fonctionnalité n’est jamais retirée — le produit ne fait que grossir, ce qui trahit l’absence de mesure d’usage.
💡 Le test en une question — demandez à l’équipe ce que la dernière fonctionnalité livrée a changé, chiffres à l’appui. Si la réponse décrit ce qui a été construit plutôt que ce qui a bougé, le diagnostic est posé.
Pourquoi les organisations y tombent
Point essentiel, et qui conditionne tout remède : la feature factory n’est presque jamais le fait des équipes elles-mêmes. Elle est produite par le système dans lequel elles évoluent. Aucun product manager ne décide un matin d’arrêter de mesurer l’impact de son travail ; il s’adapte à ce sur quoi on l’évalue.
- Le budget est alloué par projet — financer une liste de fonctionnalités oblige à s’engager sur cette liste avant de savoir si elle résout le problème.
- L’engagement précède l’apprentissage — les dates sont promises aux parties prenantes en début d’année, ce qui interdit de changer d’avis en cours de route.
- La mesure d’impact est coûteuse — instrumenter, attendre, analyser demande du temps que la pression de livraison ne laisse pas.
- Le delivery est visible, la valeur ne l’est pas — une démonstration se montre en réunion, un problème évité ne se voit pas.
C’est pourquoi les tentatives de correction internes à l’équipe échouent presque toujours. Introduire de la discovery dans une organisation qui continue d’évaluer sur le débit de livraison revient à ajouter du travail sans retirer la contrainte : l’équipe s’épuise et revient à ses habitudes en quelques semaines.
Comment sortir d’une feature factory
La sortie est progressive et commence petit. Vouloir transformer l’organisation d’un coup produit surtout de la résistance ; obtenir un premier résultat mesurable convainc plus sûrement qu’un plaidoyer.
- Reformuler un seul élément de roadmap — transformer « livrer le module de recommandation » en « augmenter la part de commandes contenant un article suggéré ». Le mandat de l’équipe change sans que rien d’autre ne bouge.
- Instrumenter avant de livrer — décider de l’indicateur et de sa mesure au moment de la spécification, pas après. Instrumenter a posteriori ne se fait jamais.
- Rendre le résultat visible — présenter en revue l’effet observé des livraisons précédentes, pas seulement les nouveautés du sprint.
- Assumer un abandon — retirer ou ne pas poursuivre une fonctionnalité sans usage. C’est l’acte qui prouve que la mesure sert vraiment à décider.
⚠️ L’erreur classique — croire que le problème se règle en changeant de méthode. Passer de Scrum à autre chose ne modifie pas ce sur quoi l’équipe est évaluée. Tant que la question posée en comité de pilotage reste « où en êtes-vous des livrables ? », l’usine tourne.
Le levier décisif se situe donc au-dessus de l’équipe : dans la façon dont les budgets sont alloués et dont les objectifs sont formulés. Une organisation qui pilote par OKR bien posés — des résultats attendus, pas des listes de livrables — retire mécaniquement à la feature factory son carburant.
FAQ — Tout savoir sur la feature factory
Feature factory : que veut dire cette expression ?
Littéralement « usine à fonctionnalités ». Elle désigne une organisation produit qui enchaîne les livraisons sans mesurer leur effet, et qui évalue ses équipes sur la quantité livrée et le respect des dates plutôt que sur les problèmes résolus.
Comment savoir si mon équipe est une feature factory ?
Demandez ce que la dernière fonctionnalité livrée a changé, chiffres à l’appui. Si la réponse décrit ce qui a été construit plutôt que ce qui a bougé, et si la roadmap est une liste de fonctionnalités datées plutôt que de problèmes à résoudre, le diagnostic est établi.
Est-ce la faute du product manager ?
Rarement. Le phénomène est produit par le système d’évaluation et de financement : budgets alloués par projet, engagements pris avant l’apprentissage, pilotage sur le débit de livraison. Le product manager s’adapte à ce sur quoi on le juge.
Quelle différence entre feature team et product team ?
Une feature team reçoit une liste de fonctionnalités à construire ; une product team reçoit des problèmes à résoudre et demeure responsable du résultat obtenu. La différence tient au mandat confié à l’équipe, pas à ses compétences ni à ses outils.
Par quoi commencer pour en sortir ?
Par un seul élément de roadmap reformulé en problème et en résultat attendu, avec son indicateur défini dès la spécification. Un premier résultat mesuré convainc plus efficacement qu’une transformation annoncée à l’échelle de l’organisation.
Une feature factory livre-t-elle lentement ?
Au contraire, elle est souvent très rapide : c’est précisément ce qui la rend difficile à remettre en cause. Le problème n’est pas la vitesse d’exécution mais l’absence de vérification de la direction prise.
