Le MVP (produit minimum viable) est souvent mal compris. Ce n'est pas « la version 1 avec moins de fonctionnalités », mais le moyen le plus rapide et le moins cher de vérifier une hypothèse : est-ce que des gens veulent vraiment ce que vous imaginez ?
Jours 1 à 4 : choisir l'hypothèse et couper
Écrivez une phrase : « Nous pensons que [tel client] a [tel problème] et paierait pour [telle solution]. » Tout le travail qui suit sert à tester cette phrase, et rien d'autre.
Listez ensuite toutes les fonctionnalités imaginées, puis rayez celles qui ne servent pas le test. En général, il reste :
- un parcours principal, du début à la fin ;
- un moyen de mesurer si les gens l'utilisent ;
- un moyen de les contacter.
Si vous n'avez pas un peu honte de votre première version, vous l'avez sortie trop tard.
Jours 5 à 11 : construire
Utilisez l'existant : outils sans code, modèles, services de paiement ou d'authentification tout faits. Faites à la main ce qui peut l'être : un traitement « automatique » peut, au début, être réalisé par vous en coulisse.
L'IA accélère énormément le prototypage, comme on l'explique dans l'IA change la vitesse des fondateurs. Un hackathon est d'ailleurs un excellent format pour ce sprint.
Jours 12 à 14 : tester avec de vrais utilisateurs
Montrez le MVP à une dizaine d'utilisateurs cibles et observez-les sans les aider. Notez où ils bloquent, ce qu'ils ignorent et ce qu'ils demandent.
Trois issues sont possibles : l'hypothèse tient, elle tient à moitié et il faut ajuster, ou elle ne tient pas. Dans ce dernier cas, tant mieux : vous l'avez appris en deux semaines et non en deux ans.
Conclusion
Un bon MVP teste une seule hypothèse, s'appuie sur l'existant et se confronte vite à de vrais utilisateurs. Deux semaines suffisent souvent pour savoir si l'idée mérite qu'on continue.
Si l'hypothèse tient, cherchez les signaux du product-market fit. Quelle est la phrase que votre MVP devrait tester dès lundi ?
