Qu'est-ce qu'un MVP ? Comment définir le périmètre de la première version ?
Un MVP n'est pas un produit inachevé ; c'est le moyen de tester une hypothèse avec le moins d'effort possible. Comment décider de ce qui entre, ou non, dans la première version ?
Alp3 min de lecture
Le MVP (Minimum Viable Product), en français « produit minimum viable », est la première version qui permet de tester l'hypothèse fondamentale d'une idée de produit auprès d'utilisateurs réels, avec le moins d'effort possible. Le concept s'est répandu avec l'approche « Lean Startup » d'Eric Ries, et son objectif n'est pas de vendre, mais d'apprendre.
Ce qu'un MVP n'est pas
- Ce n'est pas un produit à moitié fini. Il a peu de fonctions, mais celles qu'il possède, il les assure de bout en bout et correctement.
- Ce n'est pas un prototype. Un prototype sert à montrer une idée ; un MVP accomplit le travail réel d'utilisateurs réels.
- Ce n'est pas une version réduite du produit final. Plutôt qu'une version contenant un peu de chaque module, c'est une version qui apporte pleinement une seule valeur.
Cinq étapes pour définir le périmètre
1. Écrivez l'hypothèse
Complétez la phrase : « Tel groupe d'utilisateurs utilise notre produit pour résoudre tel problème. » La seule mission du MVP est de montrer si cette phrase est vraie ou non.
2. Choisissez un seul parcours principal
Identifiez le chemin le plus court par lequel l'utilisateur tire de la valeur du produit. Pour un produit de réservation, il s'agit de voir un créneau disponible, de le choisir et de recevoir une confirmation. Tout ce qui se trouve en dehors de ce parcours est candidat, et non obligatoire.
3. Priorisez les demandes
Une méthode courante consiste à répartir les demandes en quatre groupes : ce qui est indispensable, ce qui devrait y figurer, ce qui pourrait y figurer et ce qui ne figurera pas dans cette version. Seul le premier groupe entre dans la première version. Raccourcir la liste est difficile ; mais chaque fonction supplémentaire retarde l'apprentissage.
4. Fixez le critère de succès dès le départ
Qu'est-ce qui, une fois observé, vous fera considérer l'hypothèse comme validée ? La part des inscrits qui vont au bout du parcours principal, et le fait qu'ils reviennent ou non une semaine plus tard, sont de bons critères de départ pour la plupart des produits.
5. N'automatisez pas ce qui peut être fait à la main
Pour les premiers utilisateurs, des tâches comme l'émission des factures, les validations ou la préparation des rapports peuvent être effectuées à la main pendant un temps. Il est plus sûr d'investir dans l'automatisation une fois constaté que la demande est réelle.
Ce qui peut être reporté et ce qui ne doit pas l'être
| Peut être reporté | Ne doit pas être reporté |
|---|---|
| Rapports et tableaux de bord avancés | Sessions sécurisées et gestion des droits d'accès |
| Options multilingues et de thèmes | Modèle de données correctement conçu |
| Paramètres rarement utilisés | Sauvegardes et suivi des erreurs |
| Interface d'administration détaillée | Mesure de base de l'utilisation |
| Intégrations nombreuses | Exigences légales relatives aux données personnelles |
Les sujets de la colonne de droite sont des fondations coûteuses à ajouter après coup. Y renoncer pour sortir vite peut signifier une réécriture lorsque le produit grandira.
Erreurs fréquentes
- Ajouter une fonction parce que les concurrents l'ont,
- Mettre en production sans avoir mis en place de mesure, et ne pas pouvoir interpréter les résultats,
- Ajouter chaque demande à la liste au lieu de changer de cap dès les premiers retours,
- Considérer le MVP comme « provisoire » et négliger totalement la qualité.
Un bon MVP n'est pas la réponse à la question « que pouvons-nous encore ajouter ? », mais à la question « que pouvons-nous retirer sans qu'il cesse d'être utile ? ».
Si vous envisagez un produit fondé sur l'abonnement, vous pouvez voir sur notre page Développement de produits SaaS comment nous construisons le chemin qui mène du MVP au produit évolutif.