Pourquoi nos utilisateurs avaient identifié le problème… mais refusaient notre solution

L'une des leçons les plus contre-intuitives que j'ai apprises chez Marion Livraison est la suivante : Identifier un problème utilisateur ne garantit pas l'adoption de votre solution. Sur le papier, notre proposition de valeur semblait pourtant évidente.

Nous permettons aux professionnels du BTP de se faire livrer leurs matériaux directement sur chantier.

Moins de déplacements.
Moins de temps perdu.
Plus de temps facturable.

Plutôt simple. Du moins, c'est ce que nous pensions.

Une hypothèse qui semblait logique

Lorsque nous avons commencé à travailler sur notre stratégie d'acquisition, nous avons identifié plusieurs Personas :

• les fournisseurs souhaitant proposer un service différenciant à leurs clients ;
• les entreprises du BTP ;
• les artisans indépendants ;
• les particuliers réalisant eux-mêmes leurs travaux.

Parmi ces segments, les artisans et les petites entreprises du BTP nous semblaient particulièrement intéressants. Notre raisonnement était simple.

Un artisan qui doit quitter son chantier pour aller récupérer des matériaux :

• perd du temps ;
• interrompt son travail ;
• immobilise parfois une équipe entière.

Nous étions convaincus qu'un service de livraison répondait à un point de peine bien identifié.

Les interviews ont confirmé le problème

Nous avons donc commencé à échanger avec des professionnels du secteur. Très rapidement, les entretiens ont confirmé notre intuition. Les utilisateurs nous expliquaient régulièrement qu'ils perdaient du temps à récupérer leurs matériaux.

Ils décrivaient :

• les allers-retours entre le chantier et le fournisseur;
• les interruptions de planning ;
• les retards potentiels générés par ces déplacements.

Le problème existait bel et bien. À ce stade, nous pensions avoir validé notre hypothèse. Puis nous avons commencé à parler de la solution.

Le paradoxe

Lorsque nous présentions notre service de livraison, une partie des utilisateurs réagissait de façon inattendue.

Ils reconnaissaient le problème. Ils reconnaissaient la perte de temps. Ils reconnaissaient même parfois le coût financier associé.

Mais malgré cela, beaucoup répondaient :

Je préfère continuer à gérer ça moi-même.

Cette réaction nous a surpris. Pourquoi quelqu'un continuerait-il à effectuer une tâche qu'il considère lui-même comme inefficace ?

Comprendre ce qui se cache derrière les habitudes

Avec le temps, nous avons compris que notre raisonnement était trop rationnel. Nous pensions :

Problème identifié + solution meilleure = adoption. La réalité est plus complexe.

Pour certains utilisateurs, récupérer eux-mêmes leurs matériaux leur permettait :

• de vérifier la commande ;
• de contrôler la qualité ;
• de conserver leurs habitudes ;
• de garder la maîtrise du processus.

Leur décision n'était pas uniquement guidée par le temps ou l'argent. Elle était également influencée par la confiance et la routine. Et ces éléments sont souvent plus puissants qu'un gain théorique de productivité.

Ce que les interviews nous ont réellement appris

Cette expérience a profondément changé ma façon d'interpréter les résultats d'une phase de discovery. Pendant longtemps, j'aurais considéré que la validation du problème suffisait. Aujourd'hui, je fais une distinction beaucoup plus claire entre deux questions : Le problème existe-t-il ? et Les utilisateurs sont-ils prêts à changer leur comportement pour adopter ma solution ?

Les deux réponses sont souvent très différentes. Une interview peut valider un besoin.

Elle ne valide pas automatiquement l'adoption.

Réduire le risque plutôt que convaincre

Face à cette situation, nous avons changé d'approche. Au lieu d'essayer de convaincre les utilisateurs avec des arguments rationnels, nous avons cherché à réduire le risque perçu. Nous avons mis en place une offre de test avec une première livraison offerte. L'objectif n'était plus de vendre. L'objectif était de permettre aux utilisateurs d'expérimenter le service dans leur quotidien.

Sans engagement.
Sans risque.
Sans changement définitif.

Cette approche s'est révélée beaucoup plus efficace que n'importe quel argument commercial.

Ce que je retiens aujourd'hui

Cette expérience m'a appris une leçon que j'applique désormais sur tous les produits.

Les utilisateurs n'adoptent pas une solution parce qu'elle est objectivement meilleure. Ils l'adoptent lorsqu'elle devient suffisamment simple pour remplacer une habitude existante.

En tant que Product Manager, il est donc essentiel de distinguer trois étapes :

1. Comprendre le problème.
2. Valider que la solution y répond.
3. Comprendre ce qui empêche l'utilisateur de changer son comportement.

La troisième étape est souvent la plus difficile.

Et c'est aussi celle qui fait la différence entre un produit utilisé et un produit ignoré.