Le cimetière des fonctionnalités : que deviennent celles que personne n’utilise ?

Tous les produits en ont.

Des fonctionnalités qui ont demandé des jours de travail.

Des fonctionnalités qui avaient l’air passionnantes en réunion de planification.

Des fonctionnalités dont tout le monde était sûr que les utilisateurs allaient les adorer.

Et puis…

Personne ne s’en est servi.

Elles restent là, sans bruit, dans le produit : elles prennent de la place, ajoutent de la complexité, et deviennent peu à peu quelque chose à quoi l’équipe ne pense plus.

Bienvenue au cimetière des fonctionnalités.

Chaque fonctionnalité a une raison d’exister

La plupart des fonctionnalités inutilisées ne sont pas de mauvaises idées.

C’est justement ce qui rend le problème intéressant.

En général, une équipe ne construit pas quelque chose sans raison.

Peut-être que des utilisateurs l’ont demandée.

Peut-être qu’un concurrent l’a lancée.

Peut-être que les données ont révélé une opportunité.

Peut-être que le fondateur pensait qu’elle rendrait le produit meilleur.

Ou peut-être que l’équipe était simplement convaincue :

« Les utilisateurs vont adorer. »

Alors elle la construit.

Elle la teste.

Elle la lance.

Et puis les chiffres tombent.

Presque personne ne clique dessus.

Construire est plus facile que supprimer

Une fois qu’une fonctionnalité existe, la supprimer peut donner l’impression d’avouer un échec.

Les discussions ressemblent souvent à ça :

• « Mais on a passé trois semaines à la développer. »
• « Et si les utilisateurs en ont besoin plus tard ? »
• « Les gens ne l’ont peut-être juste pas encore découverte. »
• « Gardons-la pour l’instant. »

Et la fonctionnalité reste.

Puis une autre est ajoutée.

Et encore une.

Et encore une.

Au bout d’un moment, le produit devient compliqué. Pas parce que quelqu’un l’a voulu, mais parce que rien n’est jamais retiré.

Le coût caché d’une fonctionnalité inutilisée

Une fonctionnalité inutilisée n’a pas besoin de générer une facture chaque fois que quelqu’un l’ignore.

Elle peut quand même coûter à l’équipe.

Elle peut :

• Rendre l’interface plus difficile à parcourir.
• Augmenter le travail de maintenance.
• Ajouter des tests à faire.
• Créer plus de documentation.
• Multiplier les questions au support.
• Rendre la prise en main plus confuse.
• Détourner l’attention de fonctionnalités plus importantes.

La fonctionnalité peut n’avoir quasiment aucun utilisateur et générer quand même du travail.

C’est l’une des bizarreries du logiciel.

Du code inutilisé peut quand même avoir un coût.

Plus de fonctionnalités ne veut pas toujours dire plus de valeur

Il est facile de mesurer les progrès au nombre de fonctionnalités livrées.

Cinq ce mois-ci.

Dix le mois prochain.

Vingt d’ici la fin de l’année.

On a l’impression d’être productif.

Mais les utilisateurs ne choisissent pas un produit parce qu’il a la plus longue liste de fonctionnalités.

Ils le choisissent parce qu’il les aide à faire quelque chose mieux, plus vite ou plus facilement.

Parfois, une fonctionnalité de plus améliore cette expérience.

Parfois, elle donne juste aux utilisateurs une chose de plus à comprendre.

Plus, ce n’est pas automatiquement mieux.

Parfois, c’est juste plus.

Et si les utilisateurs ne trouvaient tout simplement pas la fonctionnalité ?

C’est là que ça devient intéressant.

Une fonctionnalité peu utilisée n’est pas forcément une fonctionnalité inutile.

Peut-être que les utilisateurs ne savent simplement pas qu’elle existe.

La différence est importante.

Avant de supprimer quelque chose, demandez-vous :

« Les utilisateurs ignorent-ils cette fonctionnalité, ou est-ce qu’ils n’arrivent pas à la trouver ? »

Une fonctionnalité utile, enfouie dans un menu confus, peut avoir l’air complètement inutile dans vos statistiques.

Une meilleure prise en main pourrait aider.

Une navigation plus claire pourrait aider.

Un meilleur libellé pourrait aider.

Un petit message dans le produit pourrait aider.

Alors avant d’envoyer une fonctionnalité au cimetière, assurez-vous qu’elle mérite vraiment d’y aller.

Parlez aux utilisateurs qui s’en servent vraiment

Les statistiques peuvent vous dire ce qui se passe.

Les utilisateurs peuvent souvent vous dire pourquoi.

Si seulement 2 % des utilisateurs se servent d’une fonctionnalité, parlez à quelques-uns d’entre eux.

Demandez-leur :

• « Pourquoi l’utilisez-vous ? »
• « Quel problème vous résout-elle ? »
• « Que feriez-vous si cette fonctionnalité disparaissait demain ? »

Vous découvrirez peut-être que la fonctionnalité n’est pas populaire, mais qu’elle est extrêmement précieuse pour un petit groupe d’utilisateurs.

Et la nuance est importante.

Une fonctionnalité n’a pas besoin d’être populaire pour avoir de la valeur.

La question que chaque fonctionnalité finit par affronter

À un moment, chaque équipe produit devrait se demander :

« Si nous n’avions pas cette fonctionnalité aujourd’hui, la construirions-nous à nouveau ? »

Si la réponse est non, ça vaut le coup de creuser.

Peut-être que la fonctionnalité doit être repensée.

Peut-être qu’elle devrait être masquée pour la plupart des utilisateurs.

Peut-être qu’elle devrait être fusionnée avec autre chose.

Ou peut-être… qu’elle devrait être supprimée.

Le temps déjà passé à construire quelque chose ne devrait pas décider s’il mérite de rester.

Ça, c’est simplement le piège des coûts irrécupérables.

Supprimer une fonctionnalité, c’est aussi faire du produit

Supprimer quelque chose peut donner l’impression de reculer.

Ce n’est pas le cas.

Retirer de la complexité inutile, c’est aussi progresser.

Quand une fonctionnalité disparaît, le produit peut devenir :

• Plus facile à comprendre.
• Plus facile à maintenir.
• Plus facile à prendre en main.
• Plus facile à expliquer.
• Plus facile à parcourir.

Parfois, la meilleure mise à jour produit n’est pas :

« Nous avons ajouté quelque chose de nouveau. »

Mais :

« Nous avons simplifié le produit. »

Et les utilisateurs pourraient apprécier ça davantage qu’un bouton de plus dans l’interface.

Mais n’en faites pas une opération grand ménage

Il y a un autre piège ici.

Une équipe peut devenir obsédée par l’idée de supprimer tout ce qui n’affiche pas des chiffres d’utilisation énormes.

Ce n’est pas toujours malin.

Certaines fonctionnalités sont rarement utilisées mais deviennent extrêmement importantes le jour où quelqu’un en a besoin.

Prenez un bouton d’export.

La plupart des utilisateurs n’y toucheront peut-être jamais.

Mais ceux qui s’en servent en dépendent peut-être.

L’utilisation seule ne devrait donc pas décider du sort d’une fonctionnalité.

Regardez l’ensemble :

Utilisation + valeur + retours utilisateurs + coût de maintenance.

C’est une bien meilleure façon d’évaluer si quelque chose mérite de rester.

Construisez à partir d’une question, pas juste d’une fonctionnalité

Avant de construire quelque chose, demandez-vous :

Quel problème résolvons-nous ?

Puis :

Qui a réellement ce problème ?

Et enfin :

Comment saurons-nous que nous l’avons résolu ?

Ces questions paraissent simples.

Mais elles peuvent faire gagner des semaines de développement.

Au lieu de célébrer le nombre de fonctionnalités livrées par l’équipe, célébrez le nombre de vrais problèmes résolus.

C’est une bien meilleure mesure du progrès.

Le cimetière n’est pas toujours une mauvaise chose

Tout produit finira par avoir des fonctionnalités qui n’ont pas marché.

C’est normal.

Certaines idées échoueront.

Certaines expériences ne prendront pas.

Certaines fonctionnalités deviendront obsolètes.

Ça fait partie du développement logiciel.

Le but n’est pas d’éviter complètement le cimetière des fonctionnalités.

Le but, c’est d’apprendre de ce qui y finit.

Si cinq fonctionnalités échouent pour la même raison, c’est une information utile.

Si les utilisateurs ignorent systématiquement un certain type de fonctionnalité, c’est un signal.

Si supprimer quelque chose améliore réellement l’engagement, c’est une leçon.

L’échec devient précieux quand on y prête attention.

Pour conclure

Les bons produits ne se construisent pas en ajoutant sans fin.

Ils se construisent en comprenant ce qui mérite de rester.

Chaque fonctionnalité devrait mériter sa place. Pas parce que l’équipe a passé des semaines à la construire, mais parce qu’elle aide vraiment quelqu’un.

Parfois, ça veut dire construire quelque chose de nouveau.

Parfois, ça veut dire améliorer quelque chose qui existe déjà.

Et parfois…

ça veut dire ouvrir le cimetière des fonctionnalités et enfin laisser partir quelque chose.

Parce qu’en logiciel, moins n’est pas toujours mieux.

Mais l’inutile n’est jamais gratuit.