Si je te demande "où en est ton projet ?", 7 personnes sur 10 me répondent "j'ai besoin d'un MVP". Sauf que quand on creuse un peu, ce qu'elles décrivent c'est soit un POC, soit une V1 complète - rarement un vrai MVP.
Ce n'est pas un reproche. Ce vocabulaire a été tellement dévoyé par le monde de la tech et des startups qu'il ne veut plus grand-chose dire. Des agences web vendent des "MVP" à 80 000 €. Des freelances livrent des "POC" qu'ils appellent V1. Et toi tu es perdu au milieu.
Donc voilà. Une définition claire de chaque étape, ce qu'elle produit, et surtout comment savoir qu'on est prêt à passer à la suivante.
La question : est-ce que c'est techniquement faisable ?
Un POC, c'est un prototype interne. Il sert à valider une hypothèse technique, pas à montrer à des utilisateurs. Il est souvent moche, fragile, pas scalable. C'est fait pour tester, pas pour tenir.
Un produit qu'on montre à des clients. Un livrable qu'on déploie en prod. Une raison de lever des fonds.
On a prouvé que le truc marche techniquement. On sait quelle stack on va utiliser. On a une idée du coût de développement.
La question : est-ce que des gens en ont vraiment besoin ?
Le MVP n'est pas "le minimum pour être fier de son produit". C'est le minimum pour apprendre quelque chose d'utile sur ton marché. Il peut même ne pas être une app. Une landing page avec un formulaire d'inscription, c'est déjà un MVP si ça valide une demande réelle.
Un produit complet avec toutes les features. Un truc "presque" fini qu'on peaufine encore. Une V1 avec juste un peu moins de fonctionnalités.
De vrais inconnus ont testé le produit. Ils en redemandent ou ils ont payé. T'as des retours concrets - pas des "c'est bien comme concept".
La question : comment des utilisateurs réels l'utilisent-ils vraiment ?
La beta, c'est le produit qui rencontre ses premiers vrais utilisateurs réguliers. Pas des testeurs ponctuels - des gens qui l'intègrent dans leur vie ou leur travail. C'est là qu'on mesure la rétention, les frictions, le parcours. C'est là que les hypothèses se confrontent à la réalité.
Un produit qu'on n'ose pas montrer. Un truc réservé à ses amis et sa famille qui vont dire que c'est super de toute façon.
Les metrics montrent de la rétention. Tu sais quelles features sont vraiment utilisées. Tu as un début de modèle économique qui tient la route.
La question : comment on scale ce qui fonctionne ?
Une V1, c'est un produit qui a survécu au contact avec des utilisateurs réels, dont les métriques ont été validées, et dont le modèle économique tient. Ce n'est pas la première version complète - c'est la version fondée sur des preuves.
Une idée bien développée. Un produit qu'on construit "en attendant d'avoir des users". La première chose qu'on sort avant d'avoir validé quoi que ce soit.
Tu sais précisément qui utilisera la V1, pourquoi, et combien tu vas leur facturer. Le reste, c'est de l'exécution.
Avant de parler V1, on s'assure que tu as les bonnes fondations. Ça ne veut pas dire ralentir - ça veut dire ne pas courir dans la mauvaise direction.
Étude de marché terrain, landing page d'accès anticipé, interviews d'inconnus. On cherche la preuve que le besoin est réel avant d'écrire une ligne de code.
Un MVP fonctionnel, sur une seule plateforme, avec les fonctionnalités strictement nécessaires pour apprendre. Pas sexy, mais efficace - et beaucoup moins cher.
On regarde les vrais chiffres. Rétention, conversion, feedback. Quand les preuves sont là, là on parle V1 - et on la construit sur des bases solides.
De l'idée au produit, étape par étape. Reality check, terrain, MVP, itération. Comment on travaille et combien ça coûte.
Lire l'articlePas de stats INSEE, pas de sondage Google Forms. Comment faire une vraie étude de marché terrain, en allant parler à des inconnus.
Lire l'article30 minutes, gratuit, sans engagement. On parle de ton projet - où t'en es, ce qui te bloque, si ça peut matcher.
Réserver un créneau