Trois lettres, et probablement le concept le plus mal appliqué du lot. Dans les faits, « MVP » sert le plus souvent à justifier un produit bâclé, alors que sa définition dit exactement l'inverse : petit, oui, mais complet sur ce qu'il promet.
La confusion coûte cher, parce qu'un produit incomplet ne donne aucune information exploitable. Vous ne saurez pas si les gens n'en veulent pas, ou s'ils n'ont pas réussi à s'en servir.
Définition
Le MVP, produit minimum viable, est la plus petite version d'un produit permettant de vérifier une hypothèse auprès de vrais utilisateurs, dans des conditions réelles, avec un vrai paiement lorsque c'est possible.
Chaque mot compte :
- Minimum désigne le périmètre, pas la qualité.
- Viable signifie que ce qui est livré fonctionne réellement pour le cas d'usage promis.
- Hypothèse impose de savoir ce qu'on cherche à vérifier avant de construire.
L'image classique : pour aller d'un point A à un point B, un skateboard est un MVP, une roue seule n'en est pas un. La roue est plus petite, mais elle ne transporte personne, donc elle n'apprend rien.
L'hypothèse d'abord, le produit ensuite
Un MVP sans hypothèse écrite est un prototype, pas une expérience. Avant de construire, formulez la phrase que vous cherchez à valider ou à invalider, et le seuil qui tranchera.
| Hypothèse | Le MVP à construire |
|---|---|
| Les gens ont ce problème | Aucun produit : dix entretiens suffisent |
| Ils paieraient pour le résoudre | Une Page de vente et un vrai bouton de paiement |
| Ma solution résout le problème | Le service rendu à la main, sans logiciel |
| Ça peut tourner sans moi | Là seulement, le produit automatisé |
La troisième ligne est celle qu'on saute le plus souvent, et c'est la plus rentable. Rendre le service manuellement à vingt clients vous apprend en trois semaines ce qu'un développement de six mois ne vous dira jamais, parce que vous voyez les cas particuliers.
Les trois façons de le rater
Livrer un produit cassé
Un utilisateur qui rencontre un bug ne vous informe pas sur votre hypothèse, il vous informe sur votre bug. Le périmètre doit être petit, l'exécution non.
Ne pas faire payer
La gratuité fausse tout. Un enthousiasme sans paiement est l'indicateur le moins fiable qui existe, parce qu'il ne coûte rien à celui qui l'exprime. Même un prix symbolique change radicalement la qualité de l'information.
Continuer après la réponse
Un MVP a une date de fin. S'il a répondu, on passe à l'hypothèse suivante. S'il a invalidé, on change de direction. Beaucoup continuent d'ajouter des fonctionnalités à un MVP qui a déjà dit non.
Questions fréquentes
Combien de temps pour construire un MVP ?
Si la réponse dépasse six semaines, le périmètre est trop large ou l'hypothèse est mal formulée. La contrainte de temps n'est pas une coquetterie : au-delà, le marché a bougé et vous avez cessé d'apprendre.
Combien d'utilisateurs pour conclure ?
Beaucoup moins qu'on croit pour invalider, beaucoup plus qu'on croit pour valider. Cinq entretiens révèlent la plupart des problèmes majeurs. En revanche, conclure qu'un produit marche demande de voir des gens revenir, donc plusieurs semaines de Rétention.
Faut-il communiquer sur un MVP ?
Oui, mais en le disant. Annoncer clairement l'état du produit protège votre réputation et attire précisément les utilisateurs indulgents et bavards dont vous avez besoin à ce stade.
MVP et Micro-SaaS, quel rapport ?
Le MVP est une étape, le micro-SaaS est une destination. Beaucoup de micro-SaaS rentables ressemblent encore à leur MVP deux ans plus tard, parce que leur périmètre étroit était le bon dès le départ. Notre formation Claude Code aborde ce découpage au moment de construire, là où la tentation d'ajouter une fonctionnalité de plus se joue vraiment.