Un minimum viable product (MVP) n'est pas destiné à créer un produit plus petit et moins cher mais à démarrer le processus d'apprentissage et à tester le business model. Dans son article, An MVP is not a Cheaper Product, It’s about Smart Learning, Steve Blank nous donne un exemple anecdotique d'une petite startup de Stanford qui a fait l'erreur de confondre l'objectif d'un MVP avec le besoin de créer un prototype cher.
Leur plan était d'être un fournisseur de services de données dans une entreprise émergente appelée "precision agriculture". Ils voulaient aller dans les champs d'agriculteurs, de manière hebdomadaire au départ, faire voler des drones, collecter et analyser les données et les fournir ensuite aux agriculteurs sous une forme facilement compréhensible.
L'équipe a fait ses recherches et ses découvertes et l'information qu'ils ont recueilli ont confirmé que les fermiers verraient théoriquement une valeur dans les données que ce projet pourrait offrir. L'équipe a ensuite énoncé les prochaines étapes : recueillir des fonds pour construire un MVP, comme Steve l'explique :
Ils pensaient que le nécessaire pour un MVP était de 1) démontrer un vol de drone, 2) s'assurer que leur logiciel pourrait assembler toutes les images d'un champ, puis 3) présenter les données à l'agriculteur de manière à ce qu'il puisse les utiliser. Et ils ont logiquement conclu que la façon de le faire était d'acheter un drone, acheter une caméra hyperspectrale, acheter le logiciel de traitement d'image, passer des mois de temps d'ingénierie à intégrer la caméra, la plate-forme et le logiciel ensemble, etc. Ils m'ont montré leur budget réduit à l'essentiel pour faire tout cela. Logique. Eh non.
L'équipe a confondu l'objectif du MVP (customer discovery), avec le processus de construction d'un prototype. Blank a proposé l'alternative suivante à l'équipe, moins chère et qui permettrait de mieux prouver le but de leur MVP : trouver des clients précurseurs qui paieraient pour les données :
Ne serait-il pas moins cher de louer une caméra et un avion ou un hélicoptère, et de survoler les champs d'agriculteurs, récupérer les données à la main et voir si les agriculteurs sont prêts à payer pour ? Ne pourriez-vous pas le faire en un jour ou deux, pour un dixième de l'argent que vous cherchez ? hein ...
La suggestion de Blank a poussé l'équipe à faire marche arrière et à repenser ce que doit tester le MVP ; ce qui a replacé leur attention de la construction d'un prototype à la compréhension de ce qu'il doivent en apprendre. Parce qu'ils se définissent comme une entreprise de services de données, ils ont besoin d'un MVP qui prouve que les données qu'ils offrent aux agriculteurs ont de la valeur avant de dépenser du temps et de l'argent :
"Cela signifie que tout le travail entre l'achat d'un drone, d'un appareil photo, des logiciels et le temps d'intégrer tout cela a été une perte de temps et d'efforts - maintenant. Ils n'avaient pas besoin de tester cela de suite. (Il y a beaucoup de preuves d'existence de drones équipés de caméras.) Ils ont défini le mauvais MVP au départ. Là où ils auraient dû passer du temps en premier, c'est de vérifier si les agriculteurs sont intéressés par des données."
En montrant l'exemple d'une équipe poursuivant ce que la plupart des gens considèrent être un MVP, Blank démontre l'idée fausse qui se cache derrière le MVP - le besoin de créer une version simplifiée du produit et de la soumettre à des clients potentiels. Par exemple, l'auteur John Burgstone cite dans son article dans Inc. :
Les principes du lean startup encouragent les entrepreneurs à lancer rapidement un produit sur le marché et à apprendre des retours utilisateurs. Cela leur semble intelligent car apprendre des utilisateurs est extrêmement important. Mais aller sur le marché avec un produit terne peut être insensé.
Néanmoins, comme le précise Eric Ries dans Lean Startup Principles, "La première étape est d'identifier le problème qui doit être résolu puis développer le produit minimum viable (MVP) pour démarrer le processus d'apprentissage aussi vite que possible." C'est un concept que beaucoup de startups ratent car elles font l'erreur de trop se concentrer sur la mise en oeuvre rapide d'un produit pour récupérer un retour utilisateur, au lieu de créer un MVP et commencer à apprendre. Au tout début de la phase d'apprentissage, vous ne devriez même pas avoir besoin d'écrire une seule ligne de code, comme Eric Ries l'explique dans son article sur TechCrunch sur comment DropBox a utilisé un MVP pour apprendre :
Le défi venait du fait qu'il était impossible de démontrer le fonctionnement du logiciel sous forme de prototype. Il était nécessaire que le produit surmonte des obstacles techniques importants ; il avait aussi besoin d'un service en ligne exigeant une grande fiabilité et disponibilité. Pour éviter de se réveiller un matin après des années de développement avec un produit dont personne ne veut, Drew a utilisé une technique inattendue et simple : il a fait une vidéo.
L'article de Blank conclut son exemple avec la redéfinition du MVP par l'équipe dans l'objectif d'apprendre s'ils ont un produit viable ou non et sans dépenser d'argent inutilement. Il conclut avec les principaux enseignements tirés de cette équipe :
- un MVP n'est pas toujours une version plus petite ou simplifiée de votre produit final
- pensez à des techniques simples et pas chères pour tester vos objectifs
- les bons fondateurs gardent leurs yeux sur le prix