Contexte
Lorsque l’on débute un projet, c’est une initiative qui est lancée sur la base d’une idée. On espère cette idée bénéfique pour l’utilisateur et rentable pour l’entreprise.
Le produit résultant du projet n’existe pas encore. Mais on émet déjà l’hypothèse que l’idée est assez intéressante pour mériter un investissement en temps, moyens, formations, efforts, sueur….
Je vois des hypothèses partout !
Au lancement d’un projet, nous travaillons avec de très nombreuses hypothèses dans un environnement complexe et incertain. Il faut ici avoir conscience de l’incertitude qui nous entoure. Ainsi, on évitera de plonger dans un biais d’excès de confiance qui nous ferait prendre des suppositions pour des certitudes, même après de longues analyses du contexte. Imaginons que l’on soit très confiant, par exemple à 90% sur chaque hypothèse, et qu’on identifie initialement quelques dizaines d’hypothèses. Cela fait quand même pas mal de chance pour que les choses ne se passent globalement pas comme prévues !
La question à laquelle la « Courbe de Vérité » nous aide à répondre est celle consistant à équilibrer l’investissement en regard de la solidité des faits dont on dispose.
Truth Curve selon Giff Constable. HiPPOs = Highest-Paid Person’s Opinion = Opinion de la personne la mieux payée (Cf. https://www.lamobilery.fr/blog/danger-effet-hippo-reunion )
Nos hypothèses peuvent être plus ou moins risquées, avec un gain escompté plus ou moins important. Il est primordial de lever les hypothèses à la fois les plus intéressantes et risquées rapidement avant de faire de gros investissements. Cela peut se faire progressivement et en se basant sur les apprentissages réalisés. On sort alors d’une logique binaire GO/NO GO.
Refermer la boucle
La démarche Lean UX nous apporte de nombreux outils pour valider de manière itérative et incrémentale nos hypothèses. Cela est heureusement réalisable bien plus rapidement qu’en développant et livrant un logiciel dans les mains de l’utilisateur. On parle alors d’« Apprentissage Validé » (Validated Learning).
Il est important ici de comprendre que pour minimiser les gaspillages, le fameux MVP sera bien plus petit qu’une « première version » du produit. En effet, cette première version met souvent plusieurs semaines voire des mois à arriver dans les mains de l’utilisateur final.
Les techniques les plus légères vont être de simples entretiens et enquêtes auprès d’une poignée d’utilisateurs supposés bien ciblés. Il est ainsi possible de refermer des boucles de feedback avant même d’avoir livré un incrément du produit utilisable par l’utilisateur.
En quelques heures, si nos premières enquêtes nous invitent à continuer les investissements, on pourra plus tard présenter à ces utilisateurs des maquettes d’une solution en basse-fidélité puis haute-fidélité élaborées en quelques jours.
Dans le cas contraire, on aura appris que nos hypothèses étaient erronées et qu’il est plus intéressant de pivoter sur d’autres idées ou d’arrêter après un investissement faible.
Nous obtenons un Apprentissage Validé, avec un temps d’apprentissage (Time to Learn) record, sans même avoir fabriqué d’incrément « Terminé ».
Saluons au passage les expériences qui invalident nos hypothèses car ce sont celles qui nous font le plus apprendre. En effet, elles nous prouvent que nous risquions de continuer sur une fausse route ! Pour faciliter cette acceptation et pour éviter de rentrer dans des biais cognitifs de confirmation, il est primordial que l’investissement et donc la prise de risque délibérée soit les plus petits possibles.
Stop ou encore ?
Après nous être ainsi assurés rapidement de la véracité de nos hypothèses les plus risquées et que la solution mérite au moins partiellement d’être bâtie, nous pourrons commencer à tester notre capacité à fabriquer un produit utilisable et de grande qualité. La fabrication du produit se fait par accumulation d’incréments « terminés », en l’enrichissant progressivement, semaines après semaines, en fonction de l’efficacité avérée de notre solution.
En même temps que cette fabrication incrémentale, d’autres hypothèses sont testées, si possible sur le terrain avec les utilisateurs, par la même équipe pour continuer à découvrir des solutions. L’équipe est bien responsable de résoudre des problèmes complexes de manière émergente et non seulement de fabriquer un produit.
La boucle de feedback de notre « Apprentissage Validé » se referme alors au-delà de la livraison des incréments « terminés », par collecte de données sur le terrain. On observe alors un « Time to Learn » qui va au-delà du « Time to Market », que l’on cherchera à minimiser avec des petites livraisons très fréquentes et très ciblées pour faciliter la récolte de données.
Conclusion
Sur votre produit, quels sont les travaux dont la valeur n’est pas certaine à 100 % ? Quel est le principal problème que vous cherchez à résoudre ? Quelles sont vos hypothèses de travail ?
Si vous souhaitez explorer plus en détail ces concepts, n’hésitez pas à nous contacter pour vous inscrire aux prochaines sessions de formation « Professional Scrum with UX ».
Vous y découvrirez comment exprimer vos hypothèses (problématique business ; impact business ; bénéfices utilisateurs…) ainsi que la manière de les exploiter pour maximiser la valeur de votre solution pour l’utilisateur.