POLITIQUE & INSTITUTIONS — Politique

Carte blanche

Innovation: le client a-t-il toujours raison?


Retour au dossier

2_900x600_indiv-sylvain_chery-agile_partner.jpg

Les clients ne savent pas ce qu’ils veulent. Vous avez certainement en tête la citation d’Henry Ford: «Si j’avais demandé aux gens ce qu’ils voulaient, ils m’auraient répondu des chevaux plus rapides.» Effectivement, il nous est en général très difficile d’expliquer ce que nous voulons, d’autant plus s’il s’agit d’imaginer un nouveau produit ou service. De même, nous sommes assez mauvais pour prédire nos comportements futurs. Il est donc assez vain de demander à un client de quelle solution il a besoin ou ce qu’il ferait dans une situation hypothétique.

Citation Agile

Par contre, les clients peuvent expliquer leur problème. Ils savent décrire ce qui les gêne, ce qui les ennuie ou leur cause de l’inconfort et de l’insatisfaction. C’est par exemple pour cette raison que le design thinking préconise de commencer par entrer en empathie avec le client pour bien comprendre son problème. (exemple d’outil: la customer empathy map)

Customer empathy map

Customer empathy map

Dans un univers de solutions digitales, fait d’apps et d’objets connectés en tous genres, il est possible et très tentant de construire une solution rapidement. Mais attention à d’abord valider que l’on s’attache à résoudre un problème qui en vaut la peine.

Les clients sont également tout à fait capables de critiquer quelque chose et de vous donner du feed-back sur une proposition qui leur est faite. Steve Jobs disait: «C’est très dur de concevoir des produits avec des ‘focus groups’. Très souvent, les gens ne savent pas ce qu’ils veulent avant que vous leur montriez.» C’est d’ailleurs un des ingrédients-clés des méthodes agiles de développement logiciel qui ont émergé au début des années 1990: obtenir un feed-back rapide et fréquent des clients et utilisateurs pour découvrir et s’adapter à leurs besoins réels.

Citation Agile 2

L’approche expérimentale est la plus adaptée à la complexité et à l’incertitude inhérentes à tout projet d’innovation. La réalisation d’expérimentations concrètes va permettre d’obtenir un feed-back des clients et de vérifier si l’on est sur la bonne voie ou si l’on fait fausse route. Éric Ries a popularisé cette démarche d’innovation dès 2011 avec son livre «The Lean Startup» et le cycle «Build – Measure – Learn». Je la résumerais ainsi:

  • Formulez une hypothèse – Acceptez de remettre en cause vos certitudes et considérez que celles-ci ne sont pas toujours étayées de faits avérés, qu’elles ne sont en réalité que des suppositions qui doivent être vérifiées.
  • Mettez au point une expérimentation pour vérifier cette hypothèse – Celle-ci doit être limitée dans le temps (plutôt courte), avec un indicateur de mesure objectif et un seuil strictement défini qui permettra de conclure si l’expérimentation est un succès ou un échec.
  • Mesurez les résultats de l’expérimentation – Récoltez le feed-back du client, celui qu’il a exprimé explicitement bien sûr, mais aussi celui qui est plus indirect, par exemple son expression non verbale et surtout son comportement observable et mesurable. (A-t-il cliqué sur ce bouton? Quel choix a-t-il fait? Combien a-t-il accepté de payer?)
  • Interprétez les résultats pour en tirer des enseignements et adapter/améliorer votre proposition.

agile4

Des expérimentations peuvent être faites dès le stade de l’idée pour valider notre compréhension du problème et le concept de la solution envisagée. J’observe néanmoins que les entrepreneurs ont tendance à réaliser des expérimentations trop longues. Elles doivent plutôt être légères et rapides, par exemple parler avec un client, le questionner (attention à poser des questions non biaisées!), lui montrer une maquette, un story-board, une vidéo, lui mettre en main un prototype, le mettre en situation et l’observer.

Ne comptez pas sur votre client pour vous donner l’idée de votre prochaine innovation (...). À vous de lui proposer une solution originale!

Sylvain CherySylvain Chery, Directeur associé (Agile Partner)

D’autres expérimentations permettent de tester réellement la solution dès les premiers stades de développement – le fameux MVP, «minimum viable product». Cela peut et doit se faire beaucoup plus tôt que ce que nous avons tendance à le faire. Les «early adopters» sont plus indulgents et plutôt enclins à utiliser des versions bêta, ils sont également de très bonnes sources de feed-back.

Si vous n’êtes pas embarrassé par la première version de votre produit, c’est que vous l’avez lancé trop tard.

Reid Hoffman, fondateur de Linkedin.

Citation Agile 3

Conclusion, ne comptez pas sur votre client pour vous donner l’idée de votre prochaine innovation, mais apprenez à le connaître, créez une conversation approfondie avec lui et identifiez quels sont ses problèmes les plus importants, ceux qui valent la peine que vous investissiez vos efforts pour les résoudre. À vous alors de lui proposer une solution originale! Continuez la conversation avec lui pour obtenir son feed-back au travers d’expérimentations rapides et adaptez-vous en fonction des résultats. Si vous le faites assez tôt et rapidement, alors vous augmentez considérablement vos chances de rentabiliser vos efforts et de devancer vos concurrents. Les services de support à l’innovation d’Agile Partner sont conçus pour vous y aider, depuis la génération d’idées nouvelles jusqu’à leur concrétisation dans des produits/services opérationnels.