Quand l'utilisateur dit « génial », ne monte pas sur ton nuage : douleur vs. démangeaison

Publié à l'origine sur X Articles.

Il y a une phrase qui trompe l'indie dev plus facilement que toute autre :

« Cette idée est géniale. »

Cette phrase fait plaisir à entendre, et en pratique elle vaut souvent rien. Que beaucoup de gens te complimentent ne veut pas dire qu'ils ont vraiment besoin du truc. Ils sont peut-être juste polis, peut-être que la direction a l'air bien sur le papier, peut-être qu'ils veulent simplement t'encourager.

Tu racontes ton histoire à cent à l'heure, et l'autre n'ose pas te jeter un seau d'eau froide, alors il te glisse au passage :

« Joli, ça a de la valeur. »

Et toi, tu montes.

Tu crois avoir validé un besoin ; en fait, tu n'as validé que la gentillesse de ton interlocuteur.

Un « génial » oral de l'utilisateur dit au mieux que ton idée ne sonne pas débile.

Ça ne prouve pas qu'il a un besoin, pas qu'il est prêt à migrer, pas qu'il utilisera ça tous les jours, et encore moins qu'il ouvrira son portefeuille.

L'approbation verbale, la plus blessante

Dans la recherche produit, ce qui blesse le plus, c'est l'approbation verbale.

• « Dis-moi quand ça sort. »
• « Une fois fait, je l'utilise à coup sûr. »
• « Ce créneau a du marché. »
• « Autour de moi, plein de gens en ont besoin. »

Toutes ces phrases ressemblent à des besoins ; la plupart ne sont que des lubrifiants sociaux. Elles te mettent à l'aise, te donnent confiance, te font croire que tu as déjà touché la douleur de l'utilisateur. Et quand tu as vraiment construit le truc et que tu envoies le lien, l'autre n'a même pas la flemme de s'inscrire.

C'est à ce moment que tu comprends : son « génial » de l'époque était juste une autre façon de dire « bonne chance ».

Un seul critère dur pour juger un besoin

Regarde ce que l'utilisateur est prêt à débourser.

L'argent est le signal le plus dur. S'il est prêt à payer, c'est que le problème le touche vraiment.

L'argent n'est pas le seul coût. Le temps, la migration des données, un essai actif, en parler à ses collègues, supporter une version grossière — tout ça compte comme des coûts.

Mais si un utilisateur ne veut débourser aucun coût et qu'il se contente de te complimenter deux, trois fois, c'est très probablement une simple démangeaison.

La douleur fait agir. La démangeaison fait seulement être poli.

Ne prends pas les encouragements de tes potes pour un marché

Beaucoup d'indie devs, au début, aiment parler de leur idée à leurs amis.

L'ami dit « sympa », tu te lances. Un internaute dit « j'aimerais tester », tu te lances. Quelqu'un répond « je suis chaud » sous un post, et tu crois que le marché est arrivé.

Le vrai marché, il est dans l'historique des paiements, dans les réservations de test, dans un utilisateur qui accepte de te montrer son Excel moche, dans un utilisateur qui te dit combien ce problème lui coûte chaque mois, dans un utilisateur qui supporte les bugs d'un semi-fini.

• Celui qui contourne un problème avec dix bidouillages accepte de souffrir : il a mal.
• Celui qui paie chaque mois une alternative : il a mal.
• Celui qui passe une demi-heure à te raconter son workflow : il a mal.
• Celui qui dit juste « l'idée est bonne », puis plus aucune action, ne mérite pas qu'on y prête trop attention.

Dans Standing in the Nail, il y a un jugement très juste :

Pour savoir si un utilisateur accepte un produit, on ne l'écoute pas seulement dire « bien » ou « pas bien » : il faut surtout voir ce qu'il est prêt à débourser pour ce produit. Il peut payer de l'argent, du temps, de l'attention, des coûts de migration, une autorisation organisationnelle, ou même un confort psychologique.

Parce que l'indie dev n'a pas autant de budget d'erreurs que les gros.

Tu ne peux pas brûler six mois sur « tout le monde dit que c'est bien ». Il te faut savoir vite si ce besoin est une vraie affaire ou pas.

Pose les questions plus concrètement

Ne demande pas : « Qu'est-ce que tu penses de ce produit ? »

Cette question donne trop facilement du blabla.

Demande :

• « Comment tu résous ce problème aujourd'hui ? »
• « Tu as déjà dépensé de l'argent pour ce problème ? »
• « Tu paierais un prix précoce dès maintenant ? »
• « Tu peux me montrer une capture de ton workflow actuel ? »
• « Je te prépare un MVP tout moche, tu le testes la semaine prochaine ? »

Après les questions, regarde les gestes.

Celui qui a vraiment mal te donne des détails. Il te parle du désordre actuel, des alternatives, du budget, de ce qu'il a essayé, de ce qui l'emmerde.

Celui qui n'a pas vraiment mal ne te donne que des opinions. Il dit « la direction est bonne », puis détourne les yeux vers son téléphone.

Les opinions ne valent rien. Les actes valent. Payer vaut encore plus.

Beaucoup de produits échouent parce qu'on a confondu « on m'a complimenté » avec « on m'achète ».

Il y a une grosse différence. Ceux qui te complimentent consomment ta présentation ; ceux qui achètent résolvent leur problème.

Tu peux écouter les compliments, mais ne prends pas de décision avec eux.

Tu peux collecter les retours positifs, mais ne les prends pas pour des commandes.

Tu peux croire en ta direction, mais il faut toujours revenir à une question :

Cette personne, qu'est-ce qu'elle est prête à débourser pour ce truc ?

Ce qui a l'air précieux, personne ne se précipite pour l'acheter

L'indie dev doit surtout craindre les produits « qui ont l'air précieux ».

Quand ça a l'air précieux, souvent tout le monde le comprend, tout le monde peut dire deux mots sympas — mais personne ne se précipite pour acheter.

Un vrai bon produit précoce n'est généralement pas si grandiose. Il résout peut-être un petit tracas pour une poignée de gens — mais ce tracas est assez énervant, assez fréquent, assez ruineux. Tu le sors, et l'autre ne dit pas « la direction est bonne » : il demande direct :

Combien ?

Quand c'est dispo ?

Tu peux me le faire essayer aujourd'hui ?

Ça, c'est un bon signal.

Quand l'utilisateur dit « génial », ne monte pas sur ton nuage.

Fais-le payer, fais-le tester, fais-le migrer, fais-lui débourser un peu de vrai coût.

Dès que le coût apparaît, le besoin se révèle.

Et la différence entre douleur et démangeaison se voit.

Référence : Standing in the Nail