Que mettre dans un MVP (et que laisser de côté) ?

Tout fondateur commence avec une longue liste de fonctionnalités. C'est normal : vous pensez à votre idée depuis des mois. Le plus difficile n'est pas de trouver des idées, c'est de choisir les quelques-unes qui iront dans la première version. Cet article vous donne une méthode simple pour choisir, la courte liste de ce dont tout MVP a besoin même quand il est petit, et un exemple complet à reprendre.

À quoi sert un MVP ?

Un MVP (produit minimum viable) est la plus petite version de votre produit que de vraies personnes peuvent utiliser, et dont vous pouvez tirer des leçons. Son rôle est de répondre à une question : les gens vont-ils l'utiliser, et vont-ils payer ?

Un MVP n'est donc pas une copie réduite de votre vision complète. C'est une partie de cette vision, terminée. Chaque fonctionnalité ajoutée rend le projet plus long et plus cher, et elle rend aussi la réponse moins claire. Si votre produit fait dix choses et que les gens arrêtent de l'utiliser, vous ne savez pas laquelle des dix posait problème.

Partez d'un utilisateur, d'un problème, d'un parcours principal

Avant de regarder la moindre fonctionnalité, écrivez trois phrases courtes.

• Un utilisateur. Pour qui est la première version, exactement ? « Les petites entreprises », c'est trop large. « Les gérants d'un studio de yoga avec une seule salle », c'est clair.
• Un problème. Quelle est la chose qui coûte du temps ou de l'argent à cette personne aujourd'hui ? S'il vous faut le mot « et » pour le décrire, vous avez deux problèmes. Gardez-en un.
• Un parcours principal. Quelles sont les étapes que suit cette personne, de l'ouverture de votre produit jusqu'au résultat ? Ce parcours est le cœur du MVP. Il doit bien fonctionner, à chaque fois.

Ces trois phrases sont votre filtre. Chaque fonctionnalité de votre liste aide cet utilisateur à régler ce problème sur ce parcours, ou elle ne l'aide pas.

Comment trier : indispensable, plus tard, jamais ?

Prenez votre liste complète et rangez chaque fonctionnalité dans l'un de ces trois groupes. Pour chacune, posez une question simple : l'utilisateur peut-il aller au bout du parcours principal sans elle ?

• Indispensable. Sans elle, le parcours principal est cassé, ou personne ne ferait confiance au produit. Ces fonctionnalités vont dans le MVP. La liste doit rester courte.
• Plus tard. Utile, mais le parcours principal fonctionne sans. Elle attend la version deux. Notez-la, pour que personne n'ait à la défendre de nouveau à chaque réunion.
• Jamais (pour l'instant). Les idées qui servent un autre utilisateur ou un autre problème. Ce sont peut-être de bonnes idées. Elles n'ont pas encore leur place dans ce produit.

Un bon test pour le groupe « plus tard » : pourriez-vous le faire à la main pour vos vingt premiers utilisateurs ? Si vous pouvez envoyer un rappel vous-même par e-mail, vous n'avez pas besoin de rappels automatiques le premier jour.

De quoi tout MVP a-t-il besoin, même petit ?

Un petit périmètre ne veut pas dire un produit pas fini. Certains éléments ne sont pas des fonctionnalités que vos utilisateurs demandent, mais un vrai produit ne peut pas être mis en ligne sans eux.

• La connexion et les comptes. Si les gens enregistrent quelque chose de personnel, il leur faut un compte sécurisé, et les données de chacun doivent rester séparées de celles des autres.
• Le paiement, si vous faites payer. Si le but est de savoir si les gens paient, le paiement doit être réel : règlement, reçus et paiements refusés gérés correctement.
• Des statistiques d'usage (analytics). Vous devez voir ce que font les gens : combien s'inscrivent, combien vont au bout du parcours principal, et où ils s'arrêtent. Sans cela, vous lancez le produit et vous n'apprenez rien.
• Un moyen de recevoir des retours. Un lien de contact bien visible ou un court formulaire suffit. Vos premiers utilisateurs vous diront quoi construire ensuite, si vous leur rendez la chose facile.
• Les bases d'un produit en ligne. Votre nom de domaine, les e-mails que le produit envoie tout seul (confirmation d'inscription, reçu, mot de passe oublié) et un suivi des erreurs, pour être prévenu d'un problème avant que les utilisateurs vous écrivent.

Ce sont les éléments que les prototypes rapides laissent en général de côté. Ce sont aussi ceux qui donnent assez confiance pour utiliser un nouveau produit pour de vrai. Ils font partie de chaque MVP que nous construisons.

Un bon MVP n'est pas une petite version de tout. C'est une seule chose, assez bien faite pour que les gens puissent compter dessus.

Un exemple complet : une app de réservation pour un studio de yoga

Voici un exemple inventé. Imaginez que vous vouliez créer une application de réservation pour les petits studios de yoga.

L'utilisateur : un élève régulier d'un studio. Le problème : réserver un cours demande des messages et des appels, et le professeur tient sa liste à la main. Le parcours principal : l'élève voit les cours de la semaine, réserve une place, paie et reçoit une confirmation.

• Indispensable. Le planning de la semaine. La réservation, avec un nombre de places limité par cours. Le paiement en ligne d'un cours. Un e-mail de confirmation. La possibilité d'annuler une réservation. Une page simple où le professeur ajoute ses cours et voit qui vient. Les comptes des élèves.
• Plus tard. Les carnets de cours et les abonnements mensuels. Une liste d'attente pour les cours complets. Les rappels automatiques. Plusieurs professeurs ou plusieurs adresses. Une app iOS et Android.
• Jamais (pour l'instant). Une vidéothèque de cours. Une boutique de tapis et de vêtements. Un fil social pour les élèves. Des notes pour les professeurs.

Regardez le résultat. La première version, c'est un parcours clair pour l'élève et une page pour le professeur. Elle est assez petite pour être construite comme un MVP web ciblé, et elle répond quand même à la vraie question : les élèves réservent-ils et paient-ils en ligne quand ils le peuvent ?

Que faut-il laisser de côté ?

Certaines choses reviennent sur presque toutes les premières listes. Dans la plupart des cas, elles peuvent attendre.

• Un deuxième type d'utilisateur. Chaque nouveau type d'utilisateur ajoute ses écrans, ses règles et ses tests. Servez d'abord un seul groupe.
• Les apps mobiles dès le premier jour. Une application web est en général le moyen le plus rapide de toucher des utilisateurs et d'apprendre. Les apps iOS et Android peuvent venir ensuite, à partir du même code.
• Les fonctionnalités pour les cas rares. Si cela arrive une fois par mois, gérez-le à la main jusqu'à savoir si c'est important.

Laisser des choses de côté protège aussi votre budget. Le périmètre est ce qui pèse le plus sur le prix, comme nous l'expliquons dans notre guide sur le coût d'un MVP.

Comment savoir si le périmètre est assez petit ?

• Vous pouvez décrire le produit en une phrase. « Les élèves d'un studio de yoga réservent et paient un cours en ligne. »
• Vous pouvez dessiner le parcours principal sur une page. Quelques écrans, dans l'ordre, sans embranchement.
• Votre liste « plus tard » est plus longue que votre liste « indispensable ». Si c'est l'inverse, refaites le tri.
• Vous savez ce que vous allez mesurer. Par exemple : combien d'inscrits vont au bout du parcours principal pendant leur première semaine.

En résumé

Décider ce qu'on laisse de côté, c'est le vrai travail d'un MVP. Un utilisateur, un problème, un parcours principal, plus les quelques bases qui rendent un produit sûr à utiliser. Tout le reste va sur une liste écrite, pour plus tard. Dans notre méthode, ce tri occupe la première semaine du projet, comme vous pouvez le voir dans un MVP en six semaines, semaine par semaine. Si vous voulez de l'aide pour réduire votre propre liste, parlez-nous de votre idée.