Qu’est-ce qu’un MVP : le produit minimum viable expliqué avec des exemples réels et ses limites

Un produit minimum viable est une expérience, pas un petit produit

Ceux qui demandent qu’est-ce qu’un MVP attendent souvent un type de produit : une petite application, un premier jet. C’est plutôt une expérience accompagnée d’un produit. Wikipédia en anglais définit le produit minimum viable comme une version dotée de juste assez de fonctions pour que les premiers clients l’utilisent et donnent leur avis pour la suite. Un café qui teste la commande à l’avance avec un simple formulaire pour ses habitués, avant de payer une application, en a déjà construit un.

Selon le même article, le terme a été inventé et défini en 2001 par Frank Robinson, puis popularisé par Steve Blank et Eric Ries. On doit à Ries la formule que citent les fondateurs : en août 2009, sur son blog Startup Lessons Learned, il le décrit comme la version d’un nouveau produit qui permet à une équipe de recueillir le maximum d’apprentissage validé sur les clients avec le moins d’effort. L’apprentissage est le résultat, l’effort le coût.

Ce qu’un MVP n’est pas : brouillon, prototype, démo pour investisseurs

Le nom trompe, et Ries le dit lui-même : le MVP, malgré son nom, ne consiste pas à créer des produits minimaux. Dans l’extrait de son livre The Lean Startup publié par TechCrunch en 2011, il ajoute que ce n’est pas forcément le plus petit produit imaginable et que, contrairement à un prototype, son but est de tester des hypothèses commerciales fondamentales, pas seulement des questions de conception ou de technique. Un prototype montre qu’une chose peut fonctionner. Un MVP montre si de vrais clients en veulent.

Ce n’est pas non plus un permis de livrer un produit cassé. L’article de Wikipédia rapporte la critique : les produits sous le niveau de qualité minimal attendu perdent face aux concurrents arrivés avec une exigence plus élevée, et les retours négatifs sur une sortie précoce peuvent nuire à la réputation. Une démo pour investisseurs est autre chose encore : elle montre ce qui pourrait exister à des gens qui ne s’en serviront jamais. Le peu que fait un MVP doit fonctionner correctement.

La question posée au MVP et l’hypothèse écrite avant le code

Le site The Lean Startup résume l’objectif en une ligne. La question n’est pas de savoir si ce produit peut être construit, mais s’il devrait l’être et si l’on peut bâtir une activité durable autour de lui. Une équipe compétente finit par construire presque n’importe quoi. Que des inconnus changent une habitude et paient pour le résultat reste une inconnue tant que personne n’a essayé.

Wikipédia donne un exemple. En 2015, des spécialistes de l’université de Sydney ont conçu le robot Rippa pour automatiser les travaux agricoles et le désherbage. L’hypothèse technique, que le robot distingue les mauvaises herbes des cultures, était déjà prouvée ; pas l’hypothèse commerciale, celle d’un outil viable dans une ferme en activité. Une petite entreprise écrit la même distinction en une phrase avant tout code : qui est le client, comment il règle le problème aujourd’hui, ce qu’il fera du produit et quel chiffre à quelle date vaudra un oui.

Trois types de MVP, chacun avec un exemple documenté

Le type le plus léger ne contient aucun produit. Ries raconte l’histoire de Dropbox dans l’extrait de TechCrunch : le logiciel ne pouvait pas être montré sous forme de prototype, alors son PDG, Drew Houston, a tourné une simple vidéo de trois minutes pour un public de primo-adoptants. D’après Houston, la liste d’attente de la bêta est passée de 5 000 à 75 000 personnes littéralement du jour au lendemain. Ici, conclut Ries, la vidéo était le produit minimum viable. Une page qui recueille des inscriptions fonctionne de même.

Le deuxième type est une landing page qui demande un peu plus qu’un e-mail. Joel Gascoigne, fondateur de Buffer, a décrit la sienne sur le blog de l’entreprise en février 2011. La première version tenait en deux pages, pour vérifier si les gens envisageraient seulement d’utiliser l’application. Il a ensuite intercalé une page de tarifs pour voir quelle offre les visiteurs choisissaient, et quelques-uns ont cliqué sur les offres payantes. Alors seulement il a construit le produit, et le premier client payant est arrivé dans les quatre jours suivant le lancement.

Le troisième type est un service rendu à la main derrière une simple vitrine. L’article de Wikipédia sur le lean startup, citant Ries, décrit comment Nick Swinmurn, fondateur de Zappos, a vérifié si les clients achèteraient des chaussures en ligne. Il a photographié le stock de chausseurs locaux, publié les photos, acheté les chaussures au prix fort une fois la vente conclue, puis les a expédiées au client. Le plus simple est une seule fonction bien faite : Gascoigne voulait prendre la programmation des publications des applications Twitter et la rendre excellente.

Réduire le périmètre : un utilisateur, un scénario, un résultat

La plupart des premières versions dérapent sur le périmètre, et aucune formule ne tranche. Ries l’admet dans son guide : il faut du jugement pour déterminer, dans un contexte donné, quel MVP a du sens. Choisissez un type d’utilisateur, celui qui rencontre le problème le plus souvent. Choisissez un scénario, le chemin entre l’ouverture du produit et ce qu’il est venu chercher. Choisissez un résultat que l’utilisateur peut voir et que vous pouvez compter.

Gascoigne avait annoncé la première version en une semaine ; elle en a pris sept, et il a pourtant dû renoncer à l’inscription guidée pas à pas qu’il avait prévue. Les coupes se ressemblent d’un projet à l’autre : un second rôle d’utilisateur, les réglages, un panneau d’administration qu’un tableur remplace pendant un mois, les intégrations, une application mobile à côté du web. Aucune n’est une mauvaise idée. Chacune répond à une question que personne n’a encore posée.

Quoi mesurer après le lancement et ce qui vaut réponse

Le jour du lancement produit des chiffres, et la plupart flattent. Wikipédia, dans sa page consacrée au lean startup, en distingue deux sortes. Les indicateurs de vanité donnent l’image la plus rose possible sans refléter ce qui fait tourner l’activité ; l’exemple type est le nombre de nouveaux utilisateurs par jour. Si acquérir chaque utilisateur par une publicité coûteuse revient nettement plus cher que le revenu qu’il rapporte, en gagner davantage pourrait vite mener à la faillite. Les indicateurs exploitables sont ceux qui mènent à une décision d’affaires éclairée.

Pour une première version, les chiffres exploitables sont rares. Combien de ceux qui ont vu l’offre ont essayé le produit, combien sont revenus sans relance, combien ont payé. Gascoigne a donné les siens : environ deux mois et demi après le lancement, plus de 500 utilisateurs et autour de 4 % passant à une offre payante. Une réponse exige aussi un seuil fixé à l’avance, sinon tout résultat se lit comme un encouragement. Le site The Lean Startup nomme la décision qui suit : quand les moteurs du modèle économique ne bougent pas, il est temps de pivoter ou de corriger structurellement la trajectoire.

Trois erreurs : un an de construction, aucun chiffre, un intérêt poli

La première erreur est le chantier interminable. Le site The Lean Startup le décrit ainsi : trop de startups partent d’un produit qu’elles pensent attendu, puis passent des mois, parfois des années, à le perfectionner sans jamais le montrer, même sous une forme très rudimentaire, à un client potentiel. Quand les clients font enfin savoir, par leur indifférence, que l’idée ne les intéresse pas, la startup échoue. Ries s’applique la même sévérité : dans son guide, il se souvient de deux semaines consacrées à une fonction dont absolument personne ne voulait et juge cela trop long.

La deuxième erreur est de lancer sans rien à mesurer : ni seuil ni compteur sur la seule action qui compte, et chaque issue ressemble à un progrès. La troisième est de prendre la politesse pour de la demande. Les amis trouvent l’idée formidable, les visiteurs laissent un e-mail, et cela ne leur coûte rien ; la page de tarifs de Gascoigne faisait coûter à l’intérêt un clic de plus. La méthode a sa limite : Wikipédia cite des recherches selon lesquelles une sortie précoce peut nuire plus qu’aider si un concurrent peut imiter le produit, faute d’autre barrière.

Que préparer avant de commander un MVP à un studio

Certains de ces tests se passent de développeur. Une page avec une offre et un formulaire, une courte vidéo, un service rendu à la main aux dix premiers clients : un dirigeant peut les mener seul avant de payer un logiciel. Commander a du sens quand seul un produit qui fonctionne peut répondre à la question : comptes utilisateurs, paiements, données à ne pas perdre, scénario trop long pour être simulé à la main. Même alors, le brief est l’hypothèse, pas une liste d’écrans.

Apportez donc une feuille : l’utilisateur unique, le scénario unique, le résultat qu’il doit obtenir, le chiffre et la date qui vaudront un oui, et ce que les tests moins chers vous ont déjà appris. VITON13 Studio construit des MVP d’applications web à partir de tels briefs ; le périmètre et le coût sont détaillés dans le guide et sur la page du service en lien. Avec cette feuille, la question de savoir qu’est-ce qu’un MVP devient pratique : quelle est la plus petite version capable de prouver que vous avez tort.