MVP ou MVP ?

“Notre MVP est une landing page pour tester l’intérêt des prospects... ”, dit l’un.

“Après 2 mois de cadrage et 6 mois de développement et recette, nous lancerons le MVP fin d’année ...”, dit l’autre.

Parlent-ils de la même chose ?

Minimum Viable Product, MVP. Dès que vous entendez ce mot , votre détecteur à buzzword doit s’allumer : attention de quoi parle-t-on exactement ?

Définissons les termes pour bien se comprendre (les auteurs clés du Lean Startup divergent eux-mêmes)

Mais surtout, rappelons l’originalité radicale d’un concept qui risque de s’enterrer sous le poids de son propre buzz.

Eric Ries introduit le concept de MVP par l’histoire de Zappos. En 1999, Nick Swinmurn a l’idée de vendre des chaussures par internet. Tout le monde l’en dissuade : les chaussures doivent être essayées avant d’être achetées. Conscient du risque, il poste sur un site artisanal des photos de chaussures de magasins de son quartier. A chaque commande, il descend les  acheter, les reconditionne, les expédie et gère lui-même le SAV. Le modèle n’est ni viable ni scalable. Cependant, après quelques semaines, il montre les ventes réalisées pour convaincre des investisseurs sceptiques de financer sa startup. Zappos sera la success story Lean Startup, rachetée 1 milliard de dollars par Amazon.

Notre définition : un MVP est la plus petite version du produit qui rend le service et conçue pour valider rapidement l’hypothèse de valeur utilisateur...

Votre MVP est-il un MVP : notre checklist

• Rend-il le coeur du service à l’utilisateur ?

Les clients recevaient vraiment des chaussures de Nick Swinmurn. Sinon, il s’agit d’une expérimentation (maquette, landing page, démonstrateur, …), fort utile, mais pas un MVP, pas un produit.

• Est-il minimal, frugal ?

Swinmurn a trouvé un moyen malin de tester le concept en quelques jours seul, pas en quelques mois avec une équipe. Vous-êtes vous challengé pour trouver ce genre de “hack” frugal ?

• a-t-il une hypothèse de valeur formalisée ?

sous un format du type “Nous pensons que les internautes sont prêts à acheter des chaussures sur internet, nous le saurons avec notre MVP si x clients achètent des chaussures en x jours”

• est-on vraiment prêt à abandonner ou pivoter radicalement ?

Sinon, ne l’appelez pas à tort “MVP”, apper le … “v1” tout simplement !

Osez le MVP nocode  !

Cherchez les “hacks” pour tester le service avec le minimum de code, voire sans. C’est ce que propose le mouvement “NoCode”.

Pas besoin d’être une startup américaine : même le Ministère de l’intérieur s’y est mis. Pour le nouveau service Candilib de réservation de place d’examen du permis de conduire, nous avons réalisé avec le Ministère un MVP en quelques jours en configurant un service Saas de gestion de rendez-vous. En quelques semaines, avec une centaine de candidats qui ont réellement passé le permis, nous avons pu mesurer l’impact positif sur les taux de réservation et de réussite..

Des idées d’outils pour tester sans code :

• Du contenu ?  WordPress, Wix, Weebly, Medium, ...
• Des services ? Cherchez les Saas : clicrdv, mailchimp, hubspot, zoho
• Un formulaire : google form, typeform, ...
• Une base de données : google spreadsheet, AirTable, ...
• Connectez-moi tout ça ! Zapier, IFTTT, ...
• Une appli sans code (ou presque): Caspio, PowerApps, bubble...
• et si on se passait d’un site ? le MVP par chat : chatfuel, facebook messenger, …

Osez le jetable !

Méfiez-vous de la réutilisation du MVP : on construit rapidement, on itère, on pivote, et ... on n’a pas le temps de refactorer (d’autant que le code va changer). Quelques mois plus tard, on accouche d’un nouveau “legacy” non maintenable !

Nous vous encourageons à assumer dès le départ que vous jeterez le MVP. Sur Candilib, les sponsors convaincus par le MVP ont accepté de financer une version pérenne en développement spécifique.

Les bénéfices du MVP jetable

“Life is too short to build something nobody wants” (Ash Maurya - Running Lean)

• Réduire le risque d’investir à perte.
• Etre réactif dans l’heure pour s’ajuster aux retours utilisateurs.
• Etre autonome pour tester maintenant sans attendre des développeurs disponibles.
• Convaincre les décideurs, financeurs, partenaires, et collaborateurs.
• Ne pas compromettre la qualité sur le produit futur (à condition d’assumer de jeter le MVP).
• Rester lucide sur les retours - souvent mitigés - des premiers utilisateurs : on ne risque pas de tomber amoureux d’un MVP jetable !