Le cimetière de features : ce qu'on a changé après avoir demandé à l'équipe ce qu'il fallait arrêter

Un jour, j'ai demandé à toute l'équipe : "C'est quoi la chose qu'on devrait arrêter de faire ?"

Je ne m'attendais pas à ce que la réponse me mette aussi mal à l'aise.

Ce n'était pas "les réunions du lundi". Pas "le reporting Jira". Pas "les daily trop longs". C'était : "construire des features que personne n'utilise."

Silence dans la pièce. Parce que tout le monde le savait. Et personne ne l'avait dit à voix haute avant ce jour-là.

Un problème de validation, pas de compétence

L'équipe avait passé des semaines à coder proprement, à livrer dans les délais, à respecter le process. Sur des features qui finissaient dans un coin du produit que les utilisateurs ne visitaient jamais.

Ce n'était pas un problème de compétence technique. C'était un problème de validation en amont.

On construisait ce qui était dans la roadmap, pas ce que les utilisateurs demandaient. La roadmap était bien rédigée, bien priorisée, bien présentée en comité. Elle était juste déconnectée du terrain.

C'est un piège classique et insidieux : chaque étape individuelle du process semble saine. Le PO a arbitré les priorités. Les devs ont livré du code propre, testé, dans les temps. Le comité a validé la direction. Et pourtant, le produit final ne répond à aucun besoin réel identifié.

Une roadmap qui s'appuie sur des convictions internes plutôt que sur des preuves d'usage finit toujours par produire ce résultat, tôt ou tard.

Ce que j'ai changé dès la semaine suivante

Aucune feature n'entre en sprint sans preuve de demande utilisateur

Un verbatim client, une donnée analytics, un retour terrain documenté. Pas une intuition d'équipe, pas une conviction interne partagée par plusieurs personnes dans la pièce - une preuve.

Ce filtre change immédiatement la nature des discussions de priorisation. Une feature portée par "je pense que ça serait utile" ne passe plus le premier tri. Une feature portée par "12 clients ont demandé ça dans les tickets support ce mois-ci" passe directement en haut de la liste.

Le cimetière de features

Un document simple : ce qu'on a construit, et ce que les métriques disent dessus 30 jours après la mise en production.

Inconfortable à lire. Certaines lignes montrent des semaines de travail pour un usage proche de zéro. Mais c'est exactement l'inconfort qui manquait avant - sans ce document, chaque feature ratée disparaissait silencieusement dans le backlog sans jamais être confrontée collectivement.

Le cimetière de features devient un outil de décision, pas seulement un bilan. Avant de lancer une nouvelle feature qui ressemble à une précédente, on va vérifier ce que le cimetière en dit.

Réduire le volume de features par sprint

On a réduit le volume de features par sprint de moitié.

Contre-intuitivement, la vélocité a augmenté. Parce que l'équipe arrêtait de disperser son énergie sur dix sujets à la fois pour en finir vraiment deux ou trois - avec un vrai travail de validation en amont plutôt qu'un enchaînement de tickets sans recul.

Pourquoi cette question est la plus difficile à poser en équipe

"Qu'est-ce qu'on devrait arrêter de faire" est une question inconfortable, parce que la réponse implique souvent que quelqu'un dans la pièce a pris de mauvaises décisions.

Parfois ce quelqu'un, c'est le PO. Parfois c'est le CTO. Parfois, c'est vous.

Un bon CTO hands-on ne se contente pas d'arbitrer la stack technique et l'architecture. Une partie du rôle consiste à challenger la roadmap elle-même quand elle s'éloigne du terrain - à créer l'espace où l'équipe peut dire "on construit des choses inutiles" sans que ça devienne un procès individuel, et à transformer cette réponse en process concret plutôt qu'en malaise ponctuel vite oublié.

FAQ : construire des features que personne n'utilise

Comment savoir si une équipe produit construit des features inutilisées ?

Le signal le plus fiable est un croisement entre l'effort de développement et les métriques d'usage réel 30 jours après la mise en production. Si une part significative des features livrées a un usage proche de zéro sans que personne ne l'analyse formellement, l'équipe construit probablement plus qu'elle ne valide.

Qu'est-ce qu'un "cimetière de features" en gestion de produit ?

C'est un document qui liste les features livrées et leurs métriques d'usage réel un mois après leur sortie. L'objectif n'est pas de sanctionner mais de créer une mémoire collective des décisions produit ratées, consultée avant de lancer une nouvelle feature au périmètre proche.

Comment exiger une preuve de demande utilisateur avant chaque feature sans ralentir l'équipe ?

En définissant à l'avance ce qui compte comme preuve valable : un verbatim client, une donnée analytics, un ticket support récurrent. Ce filtre élimine dès la discussion de priorisation les features portées uniquement par une conviction interne, ce qui accélère en réalité le tri plutôt que de le ralentir.

Pourquoi réduire le nombre de features par sprint augmente-t-il la vélocité ?

Parce que la dispersion sur de nombreux sujets simultanés dilue l'attention de l'équipe et empêche un vrai travail de validation en amont sur chacun. En concentrant l'effort sur deux ou trois features réellement priorisées et validées par la demande utilisateur, l'équipe livre moins de choses inutiles et retravaille moins après coup.

Qui est responsable quand une roadmap produit des features que personne n'utilise ?

Rarement une seule personne. C'est généralement un problème de process : absence de preuve de demande exigée avant l'entrée en sprint, absence de suivi des métriques après livraison, et absence d'espace pour remettre en question la roadmap une fois qu'elle est validée en comité. Corriger le process évite de transformer le sujet en recherche de responsable individuel.