Le produit marche, mais la décision ne se fait pas
À force de rencontrer ce type de situations, j’ai pu mettre des mots et des concepts à ces phénomènes . Les sciences de la décision parlent de rationalité limitée. Herbert A. Simon a montré que les individus ne cherchent pas à prendre la meilleure décision possible, mais une décision satisfaisante, avec peu d’informations, peu de temps, et peu de bande passante mentale. Certains travaux en neurosciences vont dans le même sens : lorsque les options et les informations s’accumulent, l’effort mental nécessaire pour arbitrer augmente, ce qui ralentit la décision. D’autres travaux résument ça par une idée simple : less is more. Plus on ajoute d’options ou d’informations, plus la décision devient lente et incertaine. L’intérêt de cette grille de lecture n’est pas de fournir une recette magique mais d’ aider à comprendre ce qui se joue dans l’hésitation. À distinguer un vrai problème de proposition de valeur d’un problème de charge cognitive. Dans le premier cas, simplifier ne suffira pas. Dans le second, ajouter aggrave souvent la situation.
En office hours avec des fondateurs early stage, il m’arrive parfois de rencontrer ce genre de situation. Le produit fonctionne. Les premiers utilisateurs comprennent la valeur. Les démos se passent bien. Et pourtant les décisions prennent du temps. Les « on revient vers vous » s’accumulent. Le réflexe est alors d’essayer d’en dire plus. Ajouter des fonctionnalités. Ajouter des explications. Ajouter des messages pour couvrir tous les cas. Avec le temps, et après quelques erreurs d’interprétation aussi, j’ai appris à regarder ce moment autrement. Dans certains cas, le problème n’est pas un manque de valeur. C’est que la décision d’adopter reste trop coûteuse mentalement. Les utilisateurs ne disent pas non. Ils hésitent. Et cette hésitation silencieuse, est en réalité un danger.
Pour être plus concret, prenons un cas rencontré en office hours. Une startup B2B disposait d’un produit techniquement solide, mais peinait à convertir ses premiers prospects. Les démonstrations se terminaient souvent de la même manière: un intérêt explicite, de nombreuses questions, puis un report de décision.En séance, nous avons repris mot à mot les échanges commerciaux. Une phrase revenait systématiquement: « On voit bien l’intérêt, mais on n’est pas sûrs que ce soit adapté à notre situation. »
Nous avons alors formulé l’hypothèse suivante: plus le discours entre dans le détail, plus le prospect cherche à adapter mentalement chaque élément à sa propre situation. Cet effort de projection accroît la charge cognitive et tend à repousser la décision. À partir de ce constat, le travail a consisté à épurer le pitch en supprimant les détails techniques secondaires, afin de recentrer le discours sur le principe de base du produit et sur ses limites fonctionnelles. Le fait d’indiquer clairement ce que le produit ne faisait pas s’est révélé déterminant. Cette clarification a permis de mieux positionner la solution, de limiter les projections erronées et, in fine, d’améliorer le filtrage des prospects.
Il est important de souligner que rien d’autre n’a changé. Aucun ajout de fonctionnalité, aucun ajustement de pricing, aucun storytelling supplémentaire. Les éléments techniques les plus pointus, destinés aux experts, ont été relégués en annexe, tandis que le message principal a été épuré de toute friction cognitive.Le nouveau pitch a ensuite été testé lors des rendez-vous suivants. Le signal a été clair: moins de questions générales, des échanges plus rapidement orientés vers les usages réels, et des décisions prises dans des délais plus courts.
La réduction de friction cognitive n’est pas une recette. Elle sert à comprendre pourquoi une décision bloque. Un produit peut être facile à utiliser, mais difficile à choisir.La friction est alors faible à l’usage et forte au moment de décider. Le test est simple : soit la décision avance, soit elle n’avance pas. Et dans les deux cas, on comprend mieux où est le problème. Ce type de situation est difficile à analyser seul. Les office hours peuvent parfois jouer ce rôle : un moment pour regarder le problème de côté, sans chercher à optimiser, mais à comprendre.