Un MVP est une expérience, pas une version réduite du produit final
Le MVP sert à apprendre si une hypothèse de venture résiste au comportement réel. Il ne récompense pas la fin d’un business plan et n’est pas nécessairement une application. Un service manuel, un prototype cliquable, une landing page, un workflow concierge ou un pilote payé peuvent parfois produire la preuve attendue plus vite.
Commencez par écrire la décision que le MVP doit éclairer : continuer, changer de segment, redessiner la proposition de valeur, tester un autre canal, préparer l’exploitation ou arrêter. Si l’équipe ne sait pas quelle preuve ferait évoluer cette décision, le périmètre de build est prématuré.
Agartha distingue la preuve de découverte de la sortie de build. Le but n’est pas de supprimer l’incertitude, mais de réduire l’incertitude la plus coûteuse avant de créer le prochain coût irréversible.
Les six questions qui doivent devenir testables
Il n’existe ni nombre universel d’interviews ni score de validation automatique. La qualité de la preuve dépend de la décision, du marché, du processus d’achat et du coût de l’erreur. Les six gates rendent la preuve manquante visible.
| Gate | Question | Preuve plus forte |
|---|---|---|
| Problème | Qui vit quelle situation douloureuse, quand et pourquoi ? | Comportement observé, contournement récurrent et conséquence |
| Demande | Un acheteur défini donne-t-il temps, données, accès ou argent ? | Précommande, test payé, pilote signé ou engagement qualifié |
| Alternative | Que font les personnes aujourd’hui et pourquoi le tolèrent-elles ? | Coût actuel, friction de changement et critères de décision |
| Solution | Quel mécanisme doit fonctionner pour créer la valeur ? | Tâche réussie sur prototype ou résultat concierge |
| Canal | L’équipe peut-elle atteindre acheteur et utilisateur de manière répétée ? | Route nommée, étapes de conversion et contrainte d’acquisition |
| Économie | La venture peut-elle livrer sans masquer ses coûts essentiels ? | Test de prix, coût direct, capacité et direction de marge |
Écouter les comportements, puis demander un engagement
L’étude de marché doit combiner sources existantes et recherche directe. La U.S. Small Business Administration distingue les données existantes des méthodes directes comme enquêtes, questionnaires, focus groups et interviews approfondies. Pour un fondateur, la question utile n’est pas de savoir si les personnes aiment l’idée, mais ce qu’elles font aujourd’hui, ce que le problème leur coûte et ce qui les ferait changer.
Une interview positive reste une preuve faible si aucun comportement ne change. Les signaux plus forts mobilisent une ressource rare : temps d’un décideur, accès à un workflow, autorisation d’observer des données, précommande, expérience payée ou pilote signé. Une lettre d’intention clarifie une intention mais demeure non contraignante sauf disposition contraire.
- Interviewer séparément utilisateurs, acheteurs et prescripteurs lorsqu’ils diffèrent.
- Questionner le dernier cas réel, pas une préférence future hypothétique.
- Consigner alternatives, contournements, coûts de changement et détenteur du budget.
- Distinguer enthousiasme, intention qualifiée, engagement contractuel et paiement.
Tester le mécanisme le plus risqué avant l’expérience complète
Une liste de fonctionnalités mélange des hypothèses de désirabilité, utilisabilité, faisabilité technique et capacité opérationnelle. Classez-les selon leur conséquence et leur incertitude, puis concevez le test crédible le moins coûteux de la première.
Un prototype teste compréhension et parcours. Un test concierge vérifie si le résultat promis compte. Un spike technique teste une intégration difficile. Un pilote payé teste l’achat et la livraison. Aucun ne prouve seul le product-market fit ; chacun résout une question plus étroite.
Le brief de build doit inclure utilisateur cible, situation déclenchante, job central, fonctionnalités exclues, limites data, critères d’acceptation, instrumentation, support, population de test, budget et date de décision.
Valider l’accès, la faisabilité et la direction économique
Un prototype prometteur peut échouer parce que l’acheteur reste inaccessible, l’implémentation trop lourde, les données régulées inutilisables, les intégrations indisponibles ou le prix incapable de couvrir la livraison. Ce sont des risques de venture, pas des détails pour après le lancement.
Avant de coder, cartographiez acheteur, approbateur, utilisateur et bloqueur, canal d’accès, coûts directs et tiers, travail humain caché derrière l’interface, ainsi que toute revue juridique, data, sécurité ou sectorielle. Modélisez une plage plutôt qu’une prévision optimiste unique.
| Ligne du modèle | Question minimale | Ne pas supposer |
|---|---|---|
| Prix | Qu’a accepté ou refusé un acheteur qualifié ? | La volonté déclarée équivaut au paiement |
| Coût direct | Qu’est-ce qui augmente avec chaque client ou transaction ? | Le travail fondateur reste gratuit |
| Capacité | Combien de clients le processus actuel peut-il servir ? | Le logiciel supprime chaque étape manuelle |
| Acquisition | Comment l’acheteur découvre, évalue et approuve ? | Un grand marché crée un canal |
| Rétention | Quel événement récurrent ramène l’utilisateur ? | La curiosité initiale devient une habitude |
| Conformité | Quelle revue est réellement requise ici ? | Incorporation ou hébergement prouvent la conformité |
Utiliser un gate de build avec exclusions explicites
Poursuivez lorsque l’équipe peut nommer segment et situation, montrer une preuve crédible du problème, identifier payeur et canal, isoler le mécanisme le plus risqué, accéder aux inputs requis et définir la décision que le MVP soutiendra.
Choisissez PREPARE lorsqu’une dépendance peut être fermée par recherche, accès ou travail technique. Choisissez REDESIGN si le périmètre est trop large ou si le produit proposé ne teste pas l’hypothèse la plus risquée. Choisissez STOP lorsque la preuve ne justifie plus coût, risque ou temps fondateur.
Une décision de build ne garantit ni traction, ni financement, ni approbation réglementaire, ni succès commercial. Elle n’autorise qu’une expérience bornée avec responsable, budget, calendrier et gate de revue.