C'est l'expérience minimale qui permet de tester une hypothèse précise avec de vrais utilisateurs. Construire trop, trop tôt, c'est la première cause de gaspillage de runway dans les startups early-stage.
Le pattern est classique : une équipe technique passe 9 mois à construire un produit complet, avec authentification, dashboard, notifications, API, et une roadmap de 40 features. Au lancement, 12 utilisateurs s'inscrivent. Trois reviennent.
Ce n'est pas un problème d'exécution. C'est un problème de séquençage. La question n'était pas "comment construire ça ?" mais "est-ce que quelqu'un veut vraiment ça ?" — et cette question aurait pu être répondue en 3 semaines avec un prototype Figma et 10 entretiens utilisateurs.
Notre rôle est de vous aider à identifier la plus petite chose à construire pour apprendre le maximum — avant d'engager des mois de développement.
On liste toutes les hypothèses critiques de votre modèle — sur le problème, la solution, le marché, le canal. On les priorise par risque et par facilité de validation.
On identifie le strict minimum à construire pour tester l'hypothèse la plus risquée. Souvent, c'est beaucoup moins que ce que vous imaginez.
Avant d'écrire une ligne de code, on valide avec des maquettes. 10 entretiens utilisateurs bien conduits valent plus que 3 mois de développement.
On définit les métriques de succès avant de construire — pas après. Chaque sprint a un objectif d'apprentissage précis, pas seulement un objectif de livraison.
Ajouter des features "pour être prêt" avant de lancer. Chaque feature non testée est une hypothèse non validée.
Vos proches ne vous diront pas la vérité. Vous avez besoin de vrais inconnus avec le vrai problème.
Les inscriptions ne prouvent rien. La rétention à J7 et J30 prouve que votre produit crée de la valeur.
Un mauvais lancement ne signifie pas une mauvaise idée. Il faut distinguer un problème de produit d'un problème de distribution.
Un atelier de cadrage pour définir votre MVP, vos hypothèses critiques et votre plan de validation en 2 jours.