Ce qu'un MVP doit prouver
Avant d'écrire une ligne de code, une question : qu'est-ce qu'on cherche à savoir ? Que des gens paient pour ça, qu'ils reviennent, qu'un partenaire accepte de s'y brancher. Cette question détermine tout le périmètre, et elle élimine la moitié des fonctionnalités qu'on croyait indispensables.
Choisir le périmètre du premier lot
L'erreur la plus fréquente et la plus coûteuse consiste à construire le produit complet avant de le montrer. La discipline utile est inverse : décider ce qui n'entre pas dans le premier lot, et l'écrire noir sur blanc.
- Un seul parcours utilisateur mené jusqu'au bout, plutôt que cinq esquissés
- L'administration réduite au strict nécessaire, souvent un accès direct aux données au départ
- Les cas limites rares traités à la main dans un premier temps
- Ce qui est reporté, listé explicitement, pour ne pas le redécouvrir en cours de route
Les raccourcis acceptables, et ceux qui coûtent cher
Tous les raccourcis ne se valent pas. Certains font gagner des semaines sans conséquence, d'autres se paient au premier vrai client.
- Acceptable : peu de design, peu d'automatisation, peu de back-office, des traitements manuels
- Acceptable : une seule langue, un seul mode de paiement, pas de version mobile native
- Coûteux : un modèle de données bâclé, qui contraindra toutes les évolutions
- Coûteux : l'absence d'authentification et de gestion des droits, très difficile à rattraper
- Coûteux : aucune trace ni mesure, on ne saura donc pas si le MVP a répondu à la question
MVP et premiers produits livrés
Une place de marché mettant en relation voyageurs et expéditeurs de colis, avec recherche, messagerie et paiement séquestré. Une plateforme de livraison partie d'une application coursier avant d'ouvrir sur le client et le restaurateur.
Voir les onze réalisations détaillées
Questions fréquentes
Le code du MVP sera-t-il à jeter ?
Non, et c'est un point sur lequel je ne fais pas de compromis. On réduit le périmètre fonctionnel, pas la qualité des fondations : modèle de données, authentification et déploiement sont faits correctement dès le départ.
Je n'ai pas de spécifications, est-ce bloquant ?
Non. Le cadrage fait partie du travail. Il est souvent plus utile de partir d'un problème bien décrit que d'un cahier des charges détaillé écrit trop tôt.
Que faire si le MVP ne trouve pas son marché ?
C'est un résultat, pas un échec, et c'est bien moins cher que de l'apprendre après avoir construit le produit complet. C'est exactement ce que la démarche sert à découvrir tôt.