Faut-il supprimer des fonctionnalités ?

Pourquoi supprimer des fonctionnalités produit ?
À première vue cette idée va à contre courant de la vision du product owner.

En temps normal, votre mission est de créer de nouvelles fonctionnalités produit pour répondre aux attentes du marché.

Cependant sauf si vous lancez un nouveau produit, vous êtes tous certainement confrontés au trop plein de fonctionnalités.

Soyons clair, toutes les fonctionnalités ne se valent pas. Certaines sont primordiales d’autres sont ignorées par vos utilisateurs.

Plutôt que de faire toujours plus, j’aborde aujourd’hui une étape importante de la vie d’un product owner :

• Comment savoir s’il faut supprimer des fonctionnalités  ?
• Comment être certain de prendre les bonnes décisions ?
• Quels sont les bénéfices?

Si ça fait plus de 2 ans que vous travaillez sur le même produit et que vous n’avez jamais supprimé des fonctionnalités, lisez ce post attentivement. 

Je vous explique pourquoi la suppression de fonctionnalités est peut être votre prochaine priorité. 

LES SIGNES AVANT-COUREURS :

Quand on à la tête dans le guidon et que l’on court sprint après sprint pour améliorer le produit, on oublie parfois de se poser et de regarder en arrière.

A l’instar d’une rétrospective sur le sprint, il est parfois bon de prendre un moment est de faire une rétrospective plus générale sur le produit.

Cette notion est nécessaire pour savoir si ce que l’on a batit jusqu’à présent est cohérent.

Pour faire cette rétrospective produit, je vous propose de checker 2 points essentiels.

Signe 1 : L’ignorance

A part pour un produit ultra minimaliste, personne n’utilise 100% des fonctionnalités.
C’est très rare.

En revanche, si de votre point vue, certaines fonctionnalités primordiales sont sous-utilisées, il y a quelque chose qui cloche :

En général, voici les 2 causes principales :

• Vos utilisateurs n’ont pas remarqué que cette fonctionnalité existait 
• Ils savent qu’elle existe mais l’ignore complètement.

Dans le cas 1, il peut s’agir simplement d’un problème d’expérience utilisateur.

Dans ce genre de cas, la solution est souvent d’optimiser le flow utilisateur et/ou de clarifier votre contenu.

Mettez cette fonctionnalité en avant, communiquez ses bénéfices à travers un channel de communication et voyez si le comportement utilisateur change.

Dans le cas 2, il y a danger.

En tant que product owner, rien n’est plus horrible que l’ignorance des utilisateurs.

Mieux vaut être détesté qu’être ignoré.  

Si les gens détestent quelque chose sur votre produit, c’est que vous avait touché à un point sensible.

Cela veut dire que vous avez trouvé un besoin mais que votre réponse pour le résoudre n’est pas la bonne. Si cela vous arrive, vous avez une marge de manoeuvre pour rectifier le tir.

En revanche, si personne n’utilise une fonctionnalité, personne ne s’en plaint, et pourtant la majorité savent qu’elle est disponible alors cela signifie que vous avez répondu à un besoin qui n’existe pas.

Signe 2 : La dette technique

L’autre point est souvent révélé en interne.
En écoutant les développeurs, il vous arrive d’entendre que la dette technique s’accumule.

Si vous avez déjà entendu ça, prêtez l’oreille. Il peut s’agir d’une grosse alerte.

Encore une fois, il y a 2 causes principales à ce problème :

1. La dette invisible pour l’utilisateur.

Il s’agit de lignes de code inutilisées dans les fonctionnalités produit mais qui alourdissent le code.

Ce problème peut diminuer les performances de votre application ou de votre site 

• Chargement des pages
• Téléchargement de fichiers

En général le code mort énerve également les développeurs car cela freine leur productivité 

• Manque de lisibilité du code qui augmente le temps de prise en main
• Longueur des compilations 
• Etc…

Bref tout le monde se plaint et si votre code mort s’accumule, il est peut être temps de faire un nettoyage de printemps.

Pour cela, organisez un sprint où vous consacrez l’essentiel du travail sur des tâches qui allègent la dette technique.
Sur le long terme, vous allez optimiser la productivité de votre équipe (et diminuer les plaintes).

2. Un produit devenu trop complexe

La deuxième cause qui amène les développeurs à parler de dette technique est ce que j’appelle le syndrome de la boîte à outils.

Dans ce cas de figure, votre solution dispose de dizaines de fonctionnalités toutes plus importantes les unes que les autres (soi disant).

A chaque fois que vous ajoutez quelque chose dans le code, vous devez vous assurer que cela ne fasse pas bugger les autres features.

Avec autant de fonctionnalités vous avez des dépendances à tous les étages.

Si vous avez un doute à ce sujet, ce syndrome se vérifie avec vos autres collaborateurs.

• Vos designers ne savent plus où ajouter un bouton ou une catégorie sur les pages de votre site ou application. Ils sont à cours d’idées
• Les commerciaux ou les marketeurs ne savent plus quoi mettre en avant pour promouvoir votre solution.
  Cela se conclut par une page de bénéfices longue comme le bras sur votre landing page que personne ne lit.

A force, votre entreprise doit investir un lourd budget pour promouvoir des vidéos tutorielles, une page FAQ ou aide.

Parfois même, il faut mettre en place des webinars ou recruter une équipe support client pour organiser des démos.

In fine, ce trop plein de fonctionnalités vous coûte cher.

Ca coûte cher en maintenance et ca coûte cher en communication et marketing car le produit devient trop complexe à expliquer.

COMMENT DECIDER ?

Vous avez désormais conclu à un trop plein de fonctionnalités ou conclu que certaines fonctionnalités sont ignorées par vos utilisateurs.

OK mais qu’est ce qu’on fait maintenant ?
On ouvre l’éditeur de code, on fait CTRL A et on supprime tout ?

Non calmez-vous, n’y allez pas en mode bulldozer, ce n’est pas aussi simple que ça.

1. Faites des business cases

Même si tout indique qu’il faille supprimer certaines fonctionnalités représentant un coût technique irréaliste par rapport à l’usage réel, il vous manque un paramètre pour décider.
Ce paramètre c’est la valeur business de cette fonctionnalité.

Par exemple,

• Imaginez que vous travaillez dans une entreprise BtoB: 
• Vous avez 100 clients
• Seulement 5 clients utilisent une fonctionnalité précise
• Vous pouvez conclure que vous n’allez pas gardez cette fonctionnalité pour seulement 5% de vos clients.

Oui mais:

• En creusant dans la partie business, vous apprenez que 90% de vos clients sont des TPE /PME et 10% sont des grands comptes
• Au niveau revenus, les grands comptes représentent 50% des revenus annuels.
• Vous apprenez que vos 5 clients qui utilisent cette fonctionnalité sont tous des grands comptes uniquement
• Tout à coup, les 5 clients qui utilisent cette fonctionnalité représente 25% de vos revenus annuels

Etes-vous toujours certains de supprimer cette fonctionnalité malgré 5% d’usage et des développeurs qui se plaignent ?

Un autre business case :

Vous êtes dans le même cas de figure mais cette fois ci, le peu de clients qui utilisent cette fonctionnalité ne vous rapporte pas de revenus importants directement.

En revanche, votre service commercial ou marketing vous garantit que cette fonctionnalité a un gros impact sur l’acquisition de clients.

• Cette fonctionnalité est un basique de l’argumentaire commercial.
• Tout le monde la veut même si presque personne ne l’utilise.

Cela semble bizarre mais cela arrive plus souvent que l’on imagine.

Prenons l’exemple de l’iPhone

A chaque nouvelle mise à jour d’iOS, Apple délivre toujours plus d’applications maison pré-installées sur le téléphone.

Plus de la moitié d’entres elles ne sont pas utilisées par la majorité des utilisateurs.

Pourquoi Apple s’entête autant à vos avis ?

• Est ce que Apple gagne de l’argent avec ces fonctionnalités ?

Non, la plupart des applications pré-installés (mails, calendrier…) sont livrées gratuitement et sans abonnement utilisateurs (à l’exception de Music, news et book).

Toutes ont plusieurs concurrents que l’on peut trouver sur l’AppStore.
Apple aurait plus vite fait de se débarrasser de certaines de ces applis et laisser les utilisateurs installer leurs applications préférés via l’App store.

D’un point de vue technique cela parait logique.

Pourquoi mobiliser des ressources pour mettre à jour chaque année des applications sous-utilisées et sans business model.

Seulement, en faisant ça, l’iPhone devient une coquille presque vide et perd son titre de Smartphone.

Et oui, cela semble ridicule mais les apps pré-installées sont un basique de la proposition commerciale de l’iPhone.

Sans elles, le smartphone perd de sa superbe. Il faut justifier son prix.

Pour conclure sur les business cases, voici une petite cheat sheet à avoir pour évaluer la valeur business d’une fonctionnalité.

1. Est ce que la fonctionnalité est premium ?
   Si oui, quel pourcentage du CA représente t-elle ?
2. Est ce que la fonctionnalité génère de l’acquisition client ?
   Si oui, faites une estimation du pourcentage de la userbase sur une période mensuelle
3. Autres bénéfices apportés : Satisfaction client, argument commercial etc…

2. Sondez les utilisateurs

Un autre checkpoint pour évaluer si vous devez supprimer une fonctionnalité ou non est de se tourner directement vers les utilisateurs / clients.

La façon la plus simple est de faire une enquête de satisfaction ou un mini sondage que vous envoyez à vos utilisateurs par email.

Si vous n’avez pas d’outils de sondage en place, je vous conseille un outil très simple comme Typeform que j’utilise régulièrement.
C’est un outil très facile à prendre en main et gratuit.

Dans le même genre vous avez Google Forms. Personnellement je préfère Typeform car l’expérience utilisateur est vraiment meilleure.

Posez juste quelques questions du type :

• Utilisez-vous la fonctionnalité XXX
• Sur une échelle de 1 à 10, quelle note lui donneriez-vous ?
• Avez vous des suggestions à nous apporter pour améliorer cette fonctionnalité ? (champs libre)

Cela prend une heure à faire et à envoyer au maximum.
Attendez 48 heures pour collecter tous les avis (en général 90% des gens répondent sous ce délai).

Avec ceci vous allez pouvoir évaluer le besoin de la fonctionnalité auprès des utilisateurs facilement.

NB:
Prévoyez d’envoyer ce mini questionnaire à une grosse base d’utilisateurs car le taux de réponse sur ce genre de sondage est très faible (5% en moyenne).

Si vous n’avez pas assez de feedback, vos données ne seront pas représentatives de l’opinion générale.

Au cas où vous opérez dans le secteur du BtoB, sonder les utilisateurs peut s’avérer un peu plus fastidieux.

Il faut parfois organiser des appels téléphoniques ou visio conférence. 
Ce genre de méthode prend du temps à planifier.

Idéalement, vous avez des UX researchers dans votre boîte qui peuvent se charger de la tâche (je dis bien.. idéalement).

Comparez les données

Une fois que vous avez récolté les données qualitatives, comparez les avec les données quantitatives.

Ce que j’entends pas données quantitatives, ce sont toutes les données récoltées avec vos outils d’analyses tels que Google Analytics, Mixpanel, Amplitude…

J’espère pour vous que vous trackez ces fonctionnalités avec ce genre d’outils. Si non, vous êtes mal.
SPOILER: J’en parle dans mon prochain article

En théorie, les données quantitatives doivent coller avec les données qualitatives.
Dans ce cas de figure, vous avez un indice de poid pour décider de supprimer la / les fonctionnalités ou non.

Dans le cas où les données quantitatives ne collent pas avec les données qualitatives, il va falloir creuser un peu plus.

Voici les deux cas possibles:  

CAS 1 :
Les utilisateurs vous disent qu’ils ont absolument besoin de cette fonctionnalité ou qu’ils en sont satisfait et pourtant personne ne l’utilisent.

• Imaginez que vous gérez un site e-commerce.
• Une des fonctionnalités basique est de pouvoir éditer son adresse postale.
• Ce genre de fonctionnalité n’est pas utilisée à chaque connexion d’un utilisateur.
• Pourtant, le jour où l’un de vos clients change d’adresse, sans cette fonctionnalité, il ne peut plus utiliser votre service et recevoir ses commandes à son nouveau domicile.

Important:  Évaluez la fréquence moyenne d’utilisation d’une fonctionnalité avant de conclure qu’elle est sous-utilisée.

CAS 2 :
Les utilisateurs vous disent qu’ils n’ont pas besoin de cette fonctionnalité et pourtant son usage est fort.

C’est un faux problème.

Si vous avez un gros usage d’une fonctionnalité, vous ne devriez même pas vous poser la question de savoir si vous devez la supprimer ou non.

La question ici est plutôt de comprendre ce qu’il manque aux utilisateurs.

3. Faites des estimations techniques

Enfin, la 3eme phase d’évaluation concerne l’effort technique à fournir pour supprimer cette fonctionnalité.

Imaginez que tous les voyants sont au vert pour supprimer des fonctionnalités.

• Pas de valeur business
• Pas d’usage
• Zéro besoin utilisateur

La seule question à se poser désormais est d’estimer le temps que cela va prendre pour virer cette fonctionnalité du code.

Cela paraît simple en apparence, mais souvent les fonctionnalités produits sont dépendantes les unes des autres.

En virant un bout de code, il va falloir s’assurer qu’il n’y a pas de régressions produit. 

Pour cela il faut faire une analyse technique au niveau de l’architecture produit et planifier un effort de test.

À titre personnel, j’ai récemment été confronté à ce genre de problème.

• Mon équipe et moi avions décidé de supprimer la fonctionnalité avatar dans le produit sur lequel nous travaillions.
• Cette fonctionnalité permettait à l’utilisateur d’ajouter un avatar de type emoticon pour personnaliser son profil.
• L’utilisateur avait le choix entre plusieurs avatars féminins et masculins, mais nous nous étions rendu compte que personne n’utilisait cette fonction.
  La majorité des utilisateurs avait l’avatar par défaut.
• En voulant supprimer cette fonction, nous nous sommes vite rendu compte que le temps à investir était disproportionné par rapport au gain envisageable.
• En effet, la fonction avatar était rattaché au module d’onboarding (pendant l’inscription) et au profil utilisateur. Par ailleurs, l’avatar apparaissait également dans divers endroits de l’application (header, sidebar…) ce qui nous demandait de toucher à plusieurs fichiers CSS en profondeur.
• L’estimation minimum était d’un sprint de 2 semaines pour 2 développeurs et 4 jours de tests pour un ingénieur Q/A. 
  Inutile de vous dire que nous avons fait machine arrière et que nous nous sommes re-concentrer sur quelque chose de plus important.

Ce genre de situation est très frustrante mais le calcul est vite fait.

Comme pour l’implémentation d’une fonctionnalité, estimez toujours l’effort de suppression. 

SOYEZ PRÊTS POUR LE GRAND SAUT

Une fois que vous avez complété toutes les phases d’évaluation et que tout semble bon de votre côté, il reste un dernier effort important : Faire face aux résistances.

L’impact interne

Supprimer des fonctionnalités, c’est aussi lutter contre des forces internes

Ce que j’entends par des forces internes, ce sont des collaborateurs qui vont lutter pour vous empêcher de supprimer des fonctionnalités

Ces forces peuvent venir de toutes parts :

• Cela peut être un fondateur qui est attaché à une fonctionnalité qui est là depuis les premiers jours.
• Cela peut être votre prédécesseur qui travaille encore dans la boite et qui a implémenté lui même cette fonctionnalité.
• Le département Marketing ou commercial qui pense qu’en enlevant une fonctionnalité, vous allez tout droit au fond du gouffre.

Supprimer une fonctionnalité est comme un deuil pour certains collaborateurs.
Ne négligez pas l’attachement émotionnel de vos collaborateurs à l’historique du produit.

Ces freins psychologiques peuvent représenter de vrais blocages dans votre stratégie.

Vous êtes le product owner, c’est à vous de décider de la vision produit.

Cependant, faites attention de ne pas froisser des collaborateurs qui ont un poid dans l’entreprise.

Présentez vos arguments

Comme pour l’introduction d’une nouvelle fonctionnalité, montrer les bénéfices apportés.

• Partagez vos business cases
• Faite un rapport de vos évaluations  

Normalement, les faits et les chiffres parlent d’eux mêmes.
Si votre raisonnement et votre évaluation sont bonnes, les gens se rangeront de votre côté.

Malgré tout, si certains continuent de s’obstiner et refusent de faire appel à leur bon sens, ne rentrez pas dans une zone de conflit.

Si vous êtes dans une startup par exemple et que c’est le CEO qui vous bloque, abandonnez.

C’est frustrant mais ne démarrez pas une guérilla pour une fonctionnalité sans importance.

Gardez vos cartouches pour plus tard.

L’impact utilisateurs

En théorie, si vous avez bien analysé les conséquences de la suppression d’une fonctionnalité sur votre base utilisateur, il n’y a rien à craindre.

En réalité, il y a toujours quelque chose à craindre.

Dans certains cas, les utilisateurs se rebellent

Il suffit d’une poignée. Certains ont remarqué que vous avez supprimé une fonctionnalité qu’ils n’utilisent même pas, et vous le font savoir.

• Ils postent des commentaires négatifs  sur les réseaux sociaux
• Ils vous donnent de mauvaises notes sur l’App Store ou le Google Play
• Des utilisateurs contactent directement votre service client pour se plaindre

En général ce genre de réactions est souvent attaché à un produit consumer plutôt grand public. 

C’est totalement normal et ca passera avec le temps.

Il y aura toujours des “haters” quoique vous fassiez.

Préparez un plan de communication : 

Afin d’éviter d’être pris au dépourvu par des plaintes venues de toutes parts, préparer une communication adaptée.

• Avertissez votre community Manager en avance et préparer une réponse tout faite pour les gens qui vont vous contacter sur les réseaux sociaux
• De la même manière, avertissez le service clientèle. Préparez un pitch à envoyer par email au cas où des utilisateurs vous contactent.

Encore une fois, la fonctionnalité que vous avez supprimé ne devrait pas avoir de gros impact business.
Surveillez le volume de réponses.  Si quelque chose d’anormal se produit et que vous recevez beaucoup plus de réactions que prévu, il va falloir réagir.

Si vous êtes dans ce cas, ne paniquez pas.

Vous vous êtes peut etre trompé sur la valeur de la fonctionnalité mais vous avez découvert quelque chose d’important.

Soyez prêt à faire machine arrière.

La méthode la plus sûre pour ne pas se tromper : 

Si malgré toutes les précautions prises, vous avez un doute avant de supprimer des fonctionnalités, il existe une méthode infaillible.

Préparez un test A/B.

Lancez une version produit avec la fonctionnalité que vous voulez supprimer et une version sans.

De cette manière vous pouvez comparer tous les impacts et être sûr de prendre la bonne décision.

Cette méthode nécessite plus de travail de développement mais vous encourage à lancer plus vite.

Que ce soit pour ajouter ou supprimer des fonctionnalités, je suis un très grand fan des tests A/B.

Ils permettent de prendre plus de risques et d’avoir des certitudes terrain.

CONCLUSION : 

Quand on débute dans le rôle de product owner, on veut toujours bien faire.
On se voit un peu comme un architecte qui imagine et construit de belles fonctionnalités.

On pense toujours plus, plus, plus.

Cependant, un produit, ce n’est pas une série de fonctionnalités toutes plus importantes les unes que les autres.

Etre product owner c’est devoir penser à un produit cohérent et logique.

Pour concevoir un produit cohérent il est normal d’ajouter mais aussi d’enlever des éléments en cours de route.
Ayez toujours un recul sur votre produit. Posez-vous les questions :

• Est ce que cette fonctionnalité est utilisée?
• Pourquoi cette fonctionnalité existe ?

Par expérience, je sais qu’il est plus facile de faire que de défaire.

• Il faut du courage pour renoncer à quelque chose que l’on a conçu soi même.
• Il faut en avoir pour affronter des utilisateurs et des collaborateurs et leur dire que l’on va se séparer d’une fonctionnalité.

Prenez le temps de faire une rétrospective produit et voyez si la suppression de fonctionnalités est une priorité.