La plupart des recherches utilisateur avant lancement sont du théâtre, et le pire, c'est que les deux parties connaissent leur texte. Vous demandez « utiliseriez-vous quelque chose comme ça », et la personne au bout de l'appel — qui est polie, qui n'a rien en jeu, qui imagine un produit qui n'existe pas — répond oui. Vous notez ça comme une validation. Ce n'en est pas une. C'est un inconnu qui se montre poli à propos d'une hypothèse.
J'avais l'habitude de mener ces entretiens religieusement, parce que tous les livres de stratégie produit le recommandent. Parlez à cinquante utilisateurs avant d'écrire une ligne de code. Trouvez le point de douleur. Validez le problème avant la solution. Ça sonne discipliné, et ça photographie bien sur un tableau blanc. Mais le résultat réel de dix appels de découverte, c'est dix personnes qui vous disent ce qu'elles pensent que vous voulez entendre, filtré par leur propre souvenir vague d'un problème auquel elles n'avaient plus pensé depuis le début de l'appel. Personne ne vous ment volontairement. Ils n'ont simplement pas encore l'information — parce que l'information n'existe pas tant que la chose n'existe pas.
Ce que les entretiens ne peuvent pas produire
Ce que vous devez vraiment savoir avant de construire est comportemental, pas déclaratif : une personne va-t-elle rouvrir cette appli une seconde fois, va-t-elle payer pour elle, va-t-elle rester bloquée au troisième écran et abandonner. Rien de tout cela n'apparaît dans une conversation. Cela apparaît dans une relecture de session, un graphique d'abandon, un ticket support. Un utilisateur peut vous dire avec une sincérité totale que l'onboarding « a du sens », puis l'abandonner quarante secondes plus tard, parce que l'auto-évaluation et le comportement sont deux instruments différents mesurant deux choses différentes.
Les considérations économiques imposaient de toute façon l'ordre entretien-d'abord. Si construire la chose prend huit semaines et trois ingénieurs, vous ne pouvez pas vous permettre de découvrir que c'est faux après l'avoir lancée — donc vous transférez le risque en amont vers des conversations peu coûteuses en espérant qu'elles interceptent les erreurs coûteuses. Ce compromis avait du sens quand la construction était le goulot d'étranglement. Ce n'est plus le cas. Un prototype fonctionnel — vraie authentification, vraie base de données, une interface qu'on peut réellement parcourir — est désormais quelque chose que vous construisez en un après-midi avec les bons outils, dont les miens. Une fois que le coût d'une première version chute à ce point, l'entretien cesse d'être une réduction de risque bon marché et devient l'étape coûteuse. Vous payez des semaines de calendrier pour éviter une construction qui vous coûterait un week-end.
Ce que je fais à la place
Construisez la plus petite version réelle de l'idée, mettez-la devant trois à cinq personnes réelles qui ont le problème, et observez, ne demandez pas. Pas « qu'en avez-vous pensé » — mais où votre curseur a-t-il hésité, sur quoi avez-vous cliqué sans que rien ne se passe, qu'avez-vous essayé de faire que le produit ne prenait pas du tout en charge. Ce dernier point, c'est l'or : ce qu'ils ont tenté sans y être invités est un signal plus fiable que tout ce qu'ils vous auraient dit dans un entretien hypothétique, parce que c'est une préférence révélée plutôt qu'une préférence déclarée.
Cela inverse l'entonnoir de recherche traditionnel, et il vaut la peine d'être explicite sur ce qui change :
| Entretien d'abord | Construction d'abord | |
|---|---|---|
| Ce que vous mesurez | L'intention déclarée (« je l'utiliserais probablement ») | Le comportement révélé (ils l'ont ouverte trois fois cette semaine, ou non) |
| Coût d'une erreur | Faible par cycle, mais vous pouvez vous tromper pendant des mois à travers des dizaines d'entretiens | Un seul cycle de construction, puis les données vous corrigent rapidement |
| Meilleure question à poser | « Qu'est-ce qui est frustrant dans la façon dont vous faites ça aujourd'hui ? » | « Montrez-moi la dernière fois que vous avez essayé de faire X ici » |
| Ce que ça permet de découvrir | Si un problème existe réellement | Si votre solution spécifique à ce problème fonctionne |
| Mode d'échec | Tout le monde est poli, personne n'est honnête, vous construisez la mauvaise chose en toute confiance | Vous livrez quelque chose de brut avant d'avoir gagné la confiance, et cela donne une mauvaise première impression |
Remarquez que les deux lignes ne s'annulent pas — elles répondent à des questions différentes. Les entretiens sont plutôt bons pour confirmer qu'un problème est réel. Ils sont mauvais pour vous dire si votre solution spécifique est la bonne, parce que votre solution spécifique n'existe pas encore pour que quiconque puisse y réagir honnêtement. C'est la distinction que la plupart des conseils du type « parlez aux utilisateurs » omettent : c'est généralement un bon conseil pour la découverte de problème, et un mauvais conseil pour la validation de solution, et les gens l'appliquent aux deux.
Une fondatrice que je connais a mené quatorze entretiens pour un outil de planification destiné aux salons de coiffure. Treize ont dit que le problème des doubles réservations était réel et douloureux. Elle l'a construit. L'adoption a stagné. Il s'est avéré que les propriétaires de salons détestaient les doubles réservations dans l'abstrait, mais avaient déjà mis en place des solutions de contournement fragiles auxquelles ils ne voulaient pas renoncer — quelque chose qu'aucun d'eux n'a mentionné, parce que personne ne pense à décrire son mécanisme d'adaptation à moins qu'on ne lui montre un remplacement et qu'on ne le regarde le refuser.
Là où les critiques ont raison
Cela ne tient pas partout, et je survendrais l'idée si je prétendais le contraire. Si la construction est réellement coûteuse à annuler — du matériel, un flux médical réglementé, tout ce qui implique une révision de conformité à chaque changement — alors le calcul « entretiens d'abord » revient en force, parce que l'asymétrie de coût qui rend le « construire d'abord » bon marché n'est tout simplement pas vraie ici. Un prototype qu'on peut jeter en un après-midi est une bête différente d'un appareil pour lequel on a usiné un moule.
L'autre endroit où la recherche se justifie, c'est la vente entreprise avec un long cycle. Si votre acheteur est un comité d'achats et que votre cycle de vente dure quatre mois, vous ne pouvez pas « juste livrer et observer » jusqu'à un contrat signé — vous devez savoir avant la construction si le produit passe même une revue de sécurité, car un accord rejeté au bout de six mois coûte bien plus cher que n'importe quel entretien. Et la pure découverte de problème, faite tôt et à moindre coût — s'asseoir avec quelqu'un pendant qu'il fait son travail réel, sans lui demander d'imaginer un futur produit — est vraiment sous-utilisée et vraiment utile. Je ne suis pas contre le fait de parler aux gens. Je suis contre le fait de traiter une conversation hypothétique polie comme une preuve, alors qu'une construction réelle et brute posée devant la même personne pendant dix minutes vous dirait la vérité à la place.
