Le client qui crie le plus fort : signal ou bruit ?

Parfois, écouter le client le plus insistant est un trait de génie. Parfois, c'est le début de la dette fonctionnelle. Et sur le moment, il est presque impossible de savoir dans quel cas on est.

Cette réflexion est issue de l'article précédent que j'avais écrit sur le sujet des petits pas, car une politique de petits pas sans identifier les sujets qui méritent le prochain pas n'aurait pas de sens. Elle me renvoie directement à un accompagnement que je mène d'une équipe qui travaille sur la refonte d'un produit existant depuis plusieurs mois, et qui est impatiente d'enclencher une démarche produit complète et une amélioration du fonctionnel de ce produit.

Nous entrons dans une phase où cette équipe peut délivrer un bloc fonctionnel très important, mais sur un site pilote, avec un seul utilisateur qui nous fait des retours... Cette phase pilote ne concerne qu'un site sur vingt, et qu'un utilisateur sur plusieurs dizaines.

Entrer dès maintenant dans une phase d'amélioration de ce sous-périmètre fonctionnel est donc un risque important de ne répondre aux besoins que d'un utilisateur ou de passer du temps à faire de la discovery sur des problèmes non partagés, alors que pendant ce temps, il reste un certain nombre de pans fonctionnels à couvrir pour vraiment se débarrasser du legacy.

Au final, nous sommes dans un sujet de priorisation des besoins qui vont arriver — et ça me semble être un terreau assez fertile pour reprendre et lister les outils de priorisation, en mettant un peu de théorie et d'arguments autour de ces outils, et aussi de la contradiction, afin de vraiment valider les démarches.

C'est bien dans un contexte de recherche que je te propose cet article, pas de vérité, puisque cet accompagnement est toujours en cours. Je m'appuie donc aussi là-dessus pour faire ma propre recherche, pour valider ou confirmer mes connaissances.

Le prix du client qui crie le plus fort

Cette situation est finalement relativement bien documentée dans toute la littérature qui traite de product management et de démarche produit. Que ce soit se conformer à la vision d'un client parce que c'est notre unique client actuellement, céder à celui qui crie le plus fort, ou à la personne la plus payée dans la pièce : cela va générer de nombreux ajouts fonctionnels et encore plus de configurations possibles du produit — ce phénomène a même été nommé par Rich Mironov : le « product sprawl ». Il décrit ainsi le problème : *« fulfilling individual big-customer requests as sequenced by those big customers rarely converges on a reusable product »*¹.

Au final, nous nous concentrons sur les besoins d'un utilisateur, mais sans forcément faire attention à l'impact sur le coût de maintenance de cet ajout et surtout à la valeur globale que ça apporte au produit. Est-ce que c'est un sujet qui va pouvoir intéresser d'autres utilisateurs ? Est-ce que la solution proposée, si ce problème existe chez d'autres, va répondre globalement à nos utilisateurs, ou uniquement à l'utilisateur leader ?

Ça me rappelle d'ailleurs une autre situation que j'ai rencontrée il y a quelques années en accompagnant une start-up, où finalement la vente du produit était toujours conditionnée à l'ajout de fonctionnalités. Les clients potentiels semblaient intéressés par la valeur que nous apportions, mais il y avait toujours un « mais » : « on l'achète, mais il faut ça… ». Et ces sujets ne se rejoignant pas toujours, ils s'accumulaient dans le backlog ralentissant notre Delivery avec de nouvelles tâches prioritaires et les ventes ne se faisaient pas.

Au final, le risque là-dedans est de ne pas répondre au Jobs to Be Done (JTBD) — à ce qui est vraiment nécessaire à traiter. Christensen définit le JTBD² : un sujet peut être traité parce que nous nous sommes intéressés au problème sous-jacent et donc identifié un réel besoin utilisateur. En revanche, cela nécessite d'enclencher une démarche de Discovery sur beaucoup de sujets, et ça accumule forcément beaucoup de travail en amont du Delivery. Donc tout l'enjeu ici n'est pas d'alourdir le produit et son backlog, mais de se concentrer sur des fonctionnalités utiles et utilisées par les utilisateurs et les clients.

Rich Mironov donne d'ailleurs une idée de ce à quoi ça peut mener à grande échelle quand ce pattern se répète sans arbitrage : dans son propre produit, 18 feature flags peuvent être combinés de 262 144 manières différentes, et douze versions on-premise distinctes sont maintenues en parallèle chez vingt clients qui ne sont pas prêts à migrer¹.

Si on s'arrêtait là, la conclusion serait simple : on ignore le bruit isolé. Mais ce serait oublier un cas bien documenté où l'inverse est totalement vrai.

Et s'il avait raison avant tout le monde ?

« En même temps », est-ce que nous ne pourrions pas avoir des utilisateurs leaders sur lesquels s'appuyer, et dont les inputs nous permettraient de prendre de l'avance sur le marché ?

Eric von Hippel définit ce type d'utilisateur comme des « lead users », qui répondent à deux critères : ils vivent déjà un problème que le marché ne rencontrera que plus tard, et ils cherchent à tirer un réel bénéfice d'une solution qui y répond⁴. L'utilisateur moyen, lui, ne peut pas encore imaginer les besoins qu'il n'a pas rencontrés.

Von Hippel a vérifié ce mécanisme sur plusieurs secteurs industriels très éloignés du logiciel³ : dans l'instrumentation scientifique et les équipements de procédé pour semi-conducteurs, la majorité des innovations commercialement réussies ont été développées par les utilisateurs eux-mêmes, pas par les fabricants (à l'image d'IBM, qui a conçu en interne la première machine d'insertion de composants sur carte, avant d'en licencier le design à un fabricant devenu ensuite un acteur majeur du secteur). Ce n'est pas une loi universelle pour autant — dans les plastiques techniques ou les équipements d'attache de connecteurs, étudiés dans le même papier, l'innovation reste dominée par les fabricants.

Ces exemples vont à l'encontre d'une pratique que j'adore, le Lean Startup, où l'objectif est de valider les problèmes, les utilisateurs, les solutions, en passant par des phases d'hypothèses fortes à valider à chaque fois. Ici, le propos est de se concentrer sur les besoins d'un utilisateur leader auquel on fait confiance. Et nous venons de le voir, il existe des cas où ça fonctionne. Mais à quel prix ? Pour quel retour sur investissement ?

Ce que ce mécanisme de von Hippel explique, ce n'est pas que, parfois, un client a raison par hasard mais pourquoi certains signaux isolés sont plus fiables que la moyenne du marché : une avance de phase, pas un caprice personnel.

Pour reprendre notre comparaison au vécu dans la start-up, nous avons sans doute rencontré ce genre d'utilisateur. Le souci principal, ici, c'est comment l'identifier — surtout quand tous les utilisateurs remontent des sujets différents. Est-ce que l'utilisateur leader ne doit pas, justement, s'impliquer fortement dans le produit (temps, argent, ressources diverses...) et être au cœur de celui-ci — et donc ne pas se résumer à un utilisateur isolé, ou à la demande d'un utilisateur isolé ?

Pour conclure : Mironov et von Hippel ne se contredisent pas. Ils décrivent deux profils différents du client qui crie le plus fort. Le problème, c'est l'incapacité, sur le moment, à distinguer les deux.

Le test n'est pas le volume sonore

En ayant posé ce cadre théorique et argumenté, revenons à notre question initiale, par rapport à mon accompagnement en cours. Le socle a été défini avec une vraie discovery multi-persona, validée en recette par un utilisateur pilote — seul utilisateur à avoir accès à ce périmètre fonctionnel à ce stade. La question qui reste ouverte ne concerne donc pas les fonctionnalités du socle, déjà testées, mais les nouvelles demandes qui vont émerger de l'utilisation de cette nouvelle fonction en production. Quelles techniques pouvons-nous appliquer à ces choix ?

Le test de récurrence

Premier réflexe : le test de récurrence de Teresa Torres⁵. Le principe : ne considérer un signal comme un vrai sujet à traiter que lorsqu'il revient de façon indépendante chez plusieurs utilisateurs, pas dès la première remontée isolée. Sur le socle lui-même, il a déjà été appliqué correctement — la discovery multi-persona en amont, c'est exactement ça : ne pas construire sur la base d'un seul retour, mais chercher un signal qui revient chez plusieurs utilisateurs indépendants avant d'investir.

La limite apparaît pour les nouvelles demandes — celles qui vont arriver une fois que cet unique utilisateur se sert vraiment de la fonctionnalité au quotidien, en production. Avec un seul site en production à ce stade, impossible de tester leur récurrence avant que d'autres sites soient raccordés. Ce que Torres apporte ici, ce n'est donc pas « j'ai trouvé un signal récurrent », c'est la discipline inverse : reconnaître qu'on n'a pas encore le signal, et que la bonne décision est d'attendre d'avoir plus de sites en ligne avant d'investir au-delà du socle déjà validé — plutôt que d'extrapoler à partir d'une seule personne. Un outil peut aussi servir à dire « on ne sait pas encore », pas seulement à trancher.

La matrice fréquence × sévérité

Deuxième outil : une matrice fréquence × sévérité⁶, pour trier les nouvelles demandes au fil de l'eau plutôt que d'attendre d'avoir suffisamment de sites pour statuer sur tout. Le principe est simple : ce qui casse le socle déjà validé en recette — un bug, une régression — est bloquant et se corrige quel que soit le volume de retours. Ce qui l'enrichit au-delà de ce socle — une nouvelle demande de confort ou de fonctionnalité — devient un candidat à noter, probablement basse priorité tant que sa fréquence sur les autres sites reste inconnue. Ça évite de traiter chaque retour de la même façon, alors qu'ils n'appellent pas la même urgence.

Les critères qualitatifs

Troisième outil, hérité directement de von Hippel : pour chaque nouvelle demande, se demander si elle correspond à une tendance structurelle qui touchera probablement les autres sites — une contrainte réglementaire, un usage métier partagé, une caractéristique technique commune — ou si elle est propre aux habitudes de travail de cet utilisateur en particulier. Si c'est structurel, ça mérite d'être traité sérieusement même à partir d'un seul retour. Si c'est personnel, ça se classe en basse priorité, sans mauvaise conscience.

RICE

Quatrième outil : le framework RICE⁷ — Reach, Impact, Confidence, Effort. Même à ce stade précoce, nous pouvons scorer les nouvelles demandes : Reach, en estimant par similarité combien des vingt sites seraient concernés ; Impact ; Confidence, volontairement bas avec un échantillon d'une seule personne — et c'est une information en soi, pas un défaut de l'outil ; Effort. Ça donne une manière défendable de dire « pas maintenant » sans balayer le retour de l'utilisateur d'un revers de main.

Retour sur mon expérience en start-up

Au final, ces questions, nous devions nous les poser aussi à l'époque de la start-up, mais je n'avais pas les clés — ni la plupart de ces outils — pour pouvoir y répondre. Je commençais tout juste mon parcours au sein du Club Agile Rhône Alpes, et je n'étais pas allé chercher suffisamment ces informations. Avec du recul, ces pratiques auraient pu grandement m'aider :

• la matrice fréquence × sévérité nous aurait permis de lister les sujets qui remontaient et de les comparer les uns aux autres — les demandes des différents utilisateurs. Si les demandes n'étaient vraiment faites qu'une fois, c'était un cadre assez simple de priorisation ;
• pareil pour RICE, en ajoutant la notion d'effort, même relative, qui nous aurait permis de prioriser les sujets les uns par rapport aux autres ;
• sur le test de récurrence, nous aurions pu nous baser dessus pour valider, peut-être en amont, que la fonctionnalité du socle était déjà utile pour les utilisateurs — donc dans une phase de test d'avant-vente.

Ces outils nous donnent un cadre pour nous extraire d'une temporisation par un chiffre non vérifié — du type « 45 % des fonctionnalités ne sont jamais utilisées »⁸ — pour repousser une demande. Il ne nous donne pas une réponse automatique, il nous donne juste une manière de décider sans se faire dicter la roadmap par la voix la plus forte. Et il nous donne notre cadre de décision pour l'avenir.

Le test n'est pas le volume sonore, c'est la représentativité

Pour finaliser ma comparaison avec mon vécu actuel : ce sont des outils que nous avions déjà prévu d'utiliser dans le cadre dont je parle, et cet article permet de les remettre au centre avec l'argumentaire théorique.

Au final, le test n'est pas le volume sonore — à quel point le client insiste — mais bien la représentativité : est-ce que le problème qu'il décrit touche réellement les autres, ou seulement lui ? Et avec la discipline que nous avons formulée au-dessus — la validation d'un socle minimum, ne pas réagir à chaud sur un signal unique, utiliser des outils simples pour trancher les nouvelles demandes plutôt qu'une intuition ou la pression du moment — nous avons plusieurs outils pour décider, à l'avenir, si c'est un lead user ou juste une demande personnelle qui ne doit pas être traitée.