Dans CustDev, il y a un concept appelé "feature-value gap"

C'est quand on parle apparemment de valeur, mais en réalité, on glisse vers une liste de souhaits de fonctionnalités.

Et ensuite, l'équipe développe encore 7 boutons. Mais l'argent n'augmente pas.

Par exemple,

Lors d'un entretien, le client dit :
"Il faut une intégration avec X"

Et tu notes cela comme une valeur.

Alors que la valeur pourrait être complètement différente. Disons,

"...pour que les données ne voyagent pas manuellement entre les systèmes, car à cause de cela, on fait souvent des erreurs et on perd de l'argent"


Ton produit n'est qu'un des moyens possibles d'apporter de la valeur.

(parfois pas le meilleur)

Le feature-value gap peut survenir pour plusieurs raisons

1. Les clients, en général, pensent souvent en termes de fonctionnalités

Parce que c'est plus simple à dire.

Pour la valeur, il faut se souvenir des cas, calculer le temps/les risques, reconnaître le problème.

Alors qu'une fonctionnalité est facile à nommer : "Ce serait cool si on pouvait faire ceci"


2. Nous provoquons nous-mêmes avec nos questions

"De quelles fonctionnalités avez-vous besoin ?"
"Que manque-t-il dans le produit ?"

Ces formulations donnent presque à coup sûr un backlog de souhaits, pas de la valeur


3. Les clients confondent "pratique" avec "important"

Quelqu'un peut sincèrement vouloir un beau tableau de bord. Parce que c'est agréable.

Mais il paiera pour ce qui réduit le risque, augmente l'argent, fait gagner du temps, aide à passer la conformité, etc.


4. Nous ne prenons pas en compte les différents rôles

L'utilisateur dira "je veux un bouton".

Mais son responsable paiera pour "le contrôle, le risque, la vitesse, l'économie".

Si l'entretien n'a lieu qu'avec les utilisateurs, il est facile de rester bloqué sur les fonctionnalités.


Je pense que tu rencontreras forcément certains de ces points dans tes entretiens.

Et si c'est le cas..

Quelques règles tirées de l'expérience pour éviter cela plus souvent

Règle 1 : Commencer non pas par le produit, mais par la situation réelle

Au lieu de "de quoi avez-vous besoin ?" demande "quand cela s'est-il produit pour la dernière fois ?"

Qu'est-ce qui a été le plus désagréable/coûteux dans cette situation ? Comment cela s'est-il terminé ? Combien d'argent (temps, nerfs) a-t-on dépensé ?


Ton objectif est d'extraire le contexte + les conséquences

Règle 2 : "Je veux une fonctionnalité" se traduit toujours par "et pourquoi ?"

La bonne vieille "échelle des pourquoi"..

Besoin d'une intégration ? Super ! Et pourquoi ?

Qu'est-ce qui serait différent si elle existait ? Et si elle n'existe pas, qu'est-ce qui casse ? Qui en souffre ?


Après 3-4 "pourquoi", la vraie valeur émerge généralement

Règle 3 : Fixer la valeur sous forme de "résultat", pas de "solution"

Mauvaise formulation d'insight : besoin d'une exportation en PDF

Bonne : besoin de compiler un rapport pour le client en X minutes sans correction manuelle, sinon on rate les délais et on reçoit des amendes


La fonctionnalité peut être un PDF.
Ou un lien
Ou une API, un modèle, un envoi automatique

L'important est le résultat.

Règle 4 : Vérifier l'importance de la valeur via le coût de l'erreur

Si ce n'est pas résolu dans les 3 prochains mois, que se passera-t-il ?

Et le pire scénario ? Et combien cela coûte-t-il (approximativement) ?


Si tu entends en réponse "c'est désagréable mais on survivra", il s'agit probablement d'un confort, pas d'une valeur.

Et pour finir..

Souviens-toi que après le 100e entretien, les choses deviendront un peu plus claires

Je te souhaite de superbes insights !

#recherche_de_valeur