Voir la source de Trouver de meilleurs problèmes qui valent la peine d'être résolus avec le Canevas des Forces du Client

[[Category:Ash Maurya]]
[[Category: Portail Startup]]
[[Category: Canevas]]
Auteur : Ash Maurya<br />
Source : [https://blog.leanstack.com/the-updated-problem-interview-script-and-a-new-canvas/ Find Better Problems Worth Solving with the Customer Forces Canvas]<br />
Date : 17/08/2017<br />
----
Traducteur : Fabrice Aimetti<br />
Date : 02/11/2022<br />
----
Traduction :<br />
<br />
Avant de pouvoir élaborer la "bonne" solution pour vos clients, vous devez comprendre le "bon" problème. Dans mon premier livre, [https://www.amazon.com/Running-Lean-Iterate-Works-OReilly/dp/1449305172 Running Lean], j'ai décrit un scénario d'entretien sur les problèmes pour découvrir les problèmes qui méritent d'être résolus. Dans cet article, je vais présenter un script réactualisé qui améliore le premier.<br/>
<br/>
Inspirée de la méthode scientifique, la recherche de l'adéquation problème/solution commence par la création d'un modèle, plus précisément d'un modèle économique à l'aide d'un Lean Canvas. Sur ce Lean Canvas, vous faites de votre mieux pour formuler une hypothèse sur le client et le problème. Vous sortez ensuite du bâtiment de l'entreprise et tentez de valider/invalider vos hypothèses à l'aide du métascript ci-dessous.<br/>
<br/>
[[Fichier:Problem-interview-script-deconstructed EN.png|border|link=]]<br/>
'''''Script 1.0 de l'entretien sur le problème'''''<br/>
<br/>
Le script commence par planter le décor et définir le contexte du problème, mais le cœur de l'entretien consiste à explorer la vision du monde de votre client, car c'est là que vous recueillez les preuves empiriques qui appuient ou réfutent vos arguments.<br/>
<br/>
La seule façon fiable de rassembler ces preuves est d'explorer '''ce que les clients ont fait dans le passé ou feront dans le présent'''. Leur demander ce qu'ils feront à l'avenir, par exemple "Utiliserez-vous...", vous place sur le terrain des biais et partis pris et doit être évité.<br/>
<br/>
Si vous recueillez des données qui confirment vos hypothèses sur le problème (validation), vous pouvez vous féliciter et passer à l'étape suivante, qui consiste à définir et à tester une solution grâce à un entretien sur la solution :<br/>
<br/>
[[Fichier:Solution-interview-script-deconstructed EN.png|border|link=]]<br/>
'''''Script de l'entretien sur la solution'''''<br/>
<br/>
En revanche, si vous ne trouvez pas de données qui confirment vos hypothèses (invalidation), vous devez creuser davantage pour trouver de nouveaux problèmes à résoudre. C'est là que les gens trébuchent.<br/>
<br/>
Voici quelques raisons :
* Premièrement, il est très difficile de deviner les "vrais" problèmes dès le départ, étant donné le biais/parti pris que nous avons pour notre solution (le biais de l'innovateur). La plupart d'entre nous formulent (ou simulent) inconsciemment des problèmes autour de la solution que nous voulons déjà construire, puis tentent de trouver juste assez de preuves pour se convaincre que nous sommes sur la bonne voie.
* Ensuite, si vous commencez par un non-problème, même si vous pouvez souvent constater l'invalidation assez rapidement pendant l'entretien, il n'est pas toujours facile de s'en remettre. Limiter le contexte du problème dès le départ limite votre marge de manœuvre et il est tout à fait possible de quitter l'entretien sans aucun problème à résoudre.
C'est pourquoi j'ai réactualisé le script de l'entretien sur les problèmes.<br/>

==Le script de l'entretien sur le problème mis à jour==
Voici ce que j'ai changé :<br/>
<br/>
[[Fichier:Problem-interview-script-deconstructed updated EN.png|border|link=]]<br/>
'''''Mises à jour du script de l'entretien sur le problème'''''<br/>
<br/>