Exemples de produit minimum viable (et pourquoi ils ont fonctionné)

La plupart des fondateurs lisent sur les MVP et construisent quand même trop. La raison est que « produit minimum viable » a été déformé jusqu’à signifier « petite version du produit final », ce que cela n’a jamais voulu dire. Un vrai MVP est la chose la plus petite, souvent embarrassante, qui vous permet de tester l’hypothèse la plus risquée de votre entreprise — et de nombreuses entreprises célèbres ont commencé avec quelque chose qui tenait à peine du produit.

Ce qui suit présente des exemples concrets de MVP qui ont fonctionné, ce que chacun testait, et ce que vous pouvez reprendre sans copier. Le schéma est le même dans tous les cas : choisissez l’hypothèse qui tuerait l’entreprise si elle était fausse, et testez-la avec la chose la moins coûteuse qui produise une preuve honnête.

Airbnb : un site de trois pages et un matelas gonflable

La première version d’Airbnb était un site web monté en un week-end qui proposait trois matelas gonflables sur le sol de l’appartement des fondateurs pendant une conférence de design à San Francisco. Il n’y avait pas de système de réservation, pas de paiements, pas d’avis, et aucun inventaire au-delà de ce que les fondateurs possédaient personnellement. Trois personnes ont payé quatre-vingts dollars chacune.

Ce qu’ils testaient, c’était l’hypothèse la plus risquée : des inconnus paieraient-ils pour dormir chez un inconnu ? Tout le reste — paiements, échelle, offre, confiance — pouvait être résolu plus tard si, et seulement si, la réponse était oui. Cette discipline, c’est ce qui manque à la plupart des MVP ; ils construisent les parties faciles et sautent le test de la partie difficile.

Dropbox : une vidéo de trois minutes

Le premier MVP de Dropbox n’était pas du logiciel du tout. C’était une vidéo de trois minutes enregistrée à l’écran montrant à quel point la synchronisation de fichiers serait fluide, racontée par le fondateur et remplie de références que le public cible (les premiers utilisateurs de Digg et Hacker News) reconnaîtrait. La liste d’attente est passée de cinq mille à soixante-quinze mille en une nuit.

L’hypothèse testée était de savoir si suffisamment de personnes voulaient cette expérience pour justifier de construire l’ingénierie complexe en dessous. La vidéo a coûté un week-end ; l’ingénierie aurait coûté un an. Inverser cet ordre aurait été un désastre si la demande n’avait pas été là.

Zappos : des chaussures du magasin d’en face

Avant de construire des stocks, un entrepôt ou de la logistique, le fondateur de Zappos allait dans des magasins de chaussures locaux, photographiait des chaussures et les listait sur un site web basique. Quand quelqu’un commandait, il retournait au magasin, achetait les chaussures au détail, puis les expédiait. Il perdait un peu d’argent sur chaque vente et apprenait énormément sur la demande.

Le MVP testait si les gens achèteraient des chaussures en ligne tout court — à une époque où le bon sens disait que non. L’infrastructure qui a fini par définir l’entreprise a été repoussée jusqu’à ce que la demande soit démontrée. La faiblesse du coût du test était le but, pas une limitation.

Buffer : une expérience de landing page en deux pages

Le MVP de Buffer était un test en deux pages. La première page décrivait le produit et trois niveaux de tarification ; l’appel à l’action menait à une deuxième page indiquant que le produit n’était pas encore prêt et demandant au visiteur de laisser son e-mail. L’expérience mesurait deux choses : si quelqu’un cliquait sur les tarifs, et quel niveau de prix il choisissait.

Ce n’est qu’après que la page de tarification a généré des inscriptions significatives que le fondateur a écrit la première ligne de code. Cette séquence — valider la volonté de payer avant de construire — est le schéma le plus sous-utilisé dans le travail produit des premières phases.

Stripe : installer en sept lignes

Le tout premier MVP de Stripe n’était ni un tableau de bord soigné ni un site marketing. C’était un extrait destiné aux développeurs qui promettait des paiements en sept lignes de code, installé à la main par les fondateurs pour les premiers utilisateurs. Ils s’asseyaient littéralement à côté des développeurs et intégraient l’API pour eux — un service déguisé en produit.

L’hypothèse testée était que l’expérience de paiement existante était si pénible que les développeurs adopteraient n’importe quoi de nettement plus simple. Installer manuellement la solution pour la douzaine de premiers utilisateurs a donné aux fondateurs une compréhension incomparable de chaque friction d’intégration. Cette intuition a façonné le produit bien plus que n’importe quelle feuille de route.

Schémas courants que vous pouvez reprendre

À travers ces exemples — et des dizaines d’autres similaires — quelques schémas reviennent. Notez qu’aucun d’eux n’est une « petite version du produit final ». Ce sont des tests de la croyance la plus risquée concernant le client, livrés sous la forme la moins chère possible.

• Identifiez l’unique hypothèse qui tuerait l’entreprise si elle était fausse ; testez seulement celle-ci.
• Préférez un service manuel à un logiciel lorsque la question porte sur la demande, et non sur la technologie.
• Faites payer de l’argent réel, ou mesurez un engagement réel, dès le premier test — pas après avoir peaufiné.
• Utilisez des vidéos, des maquettes ou des landing pages lorsque le coût de développement dépasse le coût d’avoir tort.
• Assumez le côté embarrassant de la première version — le polissage masque le signal que vous devez voir.

Concevoir votre propre MVP

Notez en une phrase la croyance la plus risquée de votre entreprise. Puis demandez-vous : quelle est la chose la moins chère, la plus rapide et la plus embarrassante qui me dirait si cette croyance est vraie ou fausse ? Cette chose — quelle qu’elle soit — est votre MVP. Si vous pouvez livrer le résultat à la main, faites-le. Si une vidéo suffit, réalisez la vidéo. Si une landing page suffit, publiez la landing page.

Le MVP réussit lorsque vous apprenez quelque chose qui change votre plan, et non lorsque vous lancez quelque chose de joli. Considérez le premier produit comme un instrument de collecte de preuves, et non comme une ébauche du produit final, et vous dépenserez une fraction de ce que la plupart des fondateurs gaspillent avant d’atteindre l’adéquation produit-marché.