Qu'est-ce qu'un MVP : comment cadrer votre première version
Un MVP est le plus petit produit fonctionnel qui teste une idée auprès d'utilisateurs réels. Comment cadrer la première version et que laisser de côté.
Équipe rabbitclipPublié: 7 min de lecture
En bref
Un MVP, ou produit minimum viable, est le plus petit produit fonctionnel capable de montrer si de vraies personnes utiliseront votre idée. Son but n'est pas de livrer quelque chose avec moins de fonctionnalités. Il s'agit de tester l'hypothèse la plus risquée aussi vite et à un coût aussi faible que possible. Un bon MVP se compose d'un parcours complet qui résout le problème central de l'utilisateur du début à la fin, et tout le reste n'est ajouté qu'une fois ce parcours validé.
Le terme est souvent mal compris. Un MVP n'est pas un produit bâclé ou à moitié fini. Son périmètre est étroit, mais il est fiable, fonctionnel et utilisable. Imaginez une application de réservation pour un groupe de spas. Si la première version propose seulement la prise de rendez-vous et les rappels, et que ces deux fonctions marchent sans faille, c'est un MVP. Si elle contient aussi des abonnements, un programme de points et un écran de campagnes, mais que l'écran de réservation est défaillant, ce n'est pas un MVP. C'est un produit éparpillé.
À quoi sert un MVP, et à quoi ne sert-il pas ?
Un MVP est un outil d'apprentissage. Dans la plupart des idées de produit se cachent trois ou quatre hypothèses : les utilisateurs ont réellement ce problème, ils ont besoin de cette solution précise, et ils paieraient ou y consacreraient du temps. Le MVP montre laquelle de ces hypothèses est fausse avant que vous ayez construit le produit complet, c'est-à-dire au moment où l'apprendre coûte le moins cher.
Ce qu'un MVP ne peut pas faire, c'est gagner une course aux fonctionnalités contre un concurrent établi. Vouloir égaler dès la première version des années de fonctionnalités accumulées épuise à la fois le calendrier et le budget. La première version n'est pas là pour battre un rival. Elle est là pour donner à l'utilisateur une bonne raison de revenir.
Comment cadrer le périmètre d'une première version ?
Commencez par écrire la phrase unique qui décrit le problème que le produit résout. Si vous n'y arrivez pas, le périmètre n'est pas mûr. Listez ensuite les étapes que suit un utilisateur pour atteindre cette solution et ne retenez que les écrans que ces étapes exigent strictement.
Posez la même question pour chaque fonctionnalité : le premier utilisateur peut-il résoudre son problème sans elle ? Si la réponse est oui, la fonctionnalité appartient à la deuxième version. Gardez la décision aussi simple, et la liste se raccourcit d'elle-même.
- Identifiez le parcours principal unique qui résout le problème central de l'utilisateur.
- Classez chaque fonctionnalité en trois groupes : essentielle, utile et reportable.
- Ne retenez que le groupe essentiel pour la première version.
- N'automatisez pas ce qui peut se faire à la main ; menez vous-même le processus pour les premiers utilisateurs.
- Fixez tôt la date de lancement et adaptez le périmètre à la date, et non l'inverse.
Que faut-il laisser de côté dans la première version ?
Les candidats habituels sont les tableaux de bord d'administration détaillés, une interface multilingue, des rapports avancés, plusieurs moyens de paiement, des couches de rôles et d'autorisations, et des réglages de notifications élaborés. Rien de tout cela n'est sans valeur. Cela ne change simplement pas la réponse à la première question que vous posez.
Une autre manière de laisser des choses de côté consiste à faire le travail manuellement. Si l'on construit un portail pour un fabricant de revêtements de sol, un employé peut mettre à jour les stocks à la main pendant les premières semaines. L'intégration est écrite une fois que le produit a pris, de sorte que vous ne payez pas une automatisation que personne n'utilise encore.
Quand un MVP est-il inutile ou mal choisi ?
Lorsque le processus est bien connu, que les utilisateurs sont identifiés et que le problème est déjà démontré, une approche MVP peut être superflue. Si vous faites passer un processus interne existant en ligne, les besoins sont déjà clairs et la vraie tâche consiste à rédiger le périmètre avec exactitude.
Dans les domaines où une erreur a de lourdes conséquences, comme la sécurité, la santé ou les paiements, garder le MVP étroit ne doit pas signifier abaisser la qualité. Le périmètre se réduit, mais la sécurité et l'exactitude des données doivent être complètes dès le premier jour. Dans ces domaines, un MVP signifie moins de fonctionnalités, jamais moins de soin.
Quelles erreurs sont fréquentes avec les MVP ?
La première erreur consiste à prendre un MVP pour une liste de fonctionnalités raccourcie. La vraie mesure est de savoir si le problème de l'utilisateur est résolu, non le nombre de fonctionnalités. La deuxième est de développer le produit pendant des mois sans le montrer à personne. Un MVP qui n'attire aucun retour n'est qu'un petit produit.
La troisième erreur est d'écrire la première version comme un brouillon jetable, puis de vouloir construire dessus. Le code et la structure de données d'une première version doivent être assez propres pour permettre la croissance. La vitesse achetée en sacrifiant la qualité se rembourse avec intérêts dans la deuxième version.
- Lancer sans mesure : décidez à l'avance ce qui comptera comme un succès.
- Ne pas parler aux utilisateurs : une conversation avec les dix premiers utilisateurs vaut plus que la plupart des analyses.
- Ajouter chaque demande : les souhaits internes se confondent avec les besoins réels des utilisateurs.
- Sauter la conception : un produit simple n'est pas un produit désordonné.
Que mesure-t-on une fois le MVP en ligne, et que fait-on ensuite ?
Une fois la première version sortie, la question à poser est de savoir si les utilisateurs terminent le parcours principal. Combien ont commencé, combien sont arrivés au bout, et où les autres se sont-ils arrêtés. Ces trois réponses décident de ce qui sera construit au prochain sprint.
Après la mesure, vous prenez l'une de trois voies : le produit fonctionne et il est étendu, le produit fonctionne en partie et le parcours est corrigé, ou le produit ne fonctionne pas et l'idée est abandonnée ou modifiée. Le troisième résultat est aussi un succès, car vous l'avez appris sans dépenser le budget d'un produit complet.
Un MVP n'est pas l'art de livrer quelque chose de petit. C'est la discipline qui consiste à poser la bonne question de la manière la moins coûteuse possible. Un seul parcours principal, une mesure claire du succès et une date de lancement fixe suffisent à la plupart des projets. Si vous souhaitez cadrer avec quelqu'un la première version de votre propre idée, vous pouvez organiser un entretien de découverte avec rabbitclip.
Questions fréquentes
Un MVP est-il la même chose qu'un prototype ?
Non. Un prototype est une maquette qui montre l'apparence et le comportement d'une idée, et il n'est pas ouvert aux vrais utilisateurs. Un MVP est le premier produit en ligne, testé avec de vrais utilisateurs.
Combien de temps dure le développement d'un MVP ?
Cela dépend du périmètre, de la taille de l'équipe et du nombre d'intégrations. Lorsque le périmètre est réduit à un seul parcours principal, la durée raccourcit nettement, et l'approche la plus saine consiste à fixer une date de lancement et à y adapter le périmètre.
Un MVP doit-il être réécrit plus tard ?
Pas si la première version a été construite avec une structure propre, car on peut alors bâtir dessus. Le besoin de réécriture apparaît généralement lorsque la qualité et la structure de données ont été négligées dans la première version.
Quelles fonctionnalités sont essentielles dans un MVP ?
Celles qu'exige le parcours principal qui résout le problème central de l'utilisateur. La connexion, l'action centrale et un écran de résultat suffisent souvent, tandis que les interfaces d'administration et les rapports peuvent généralement attendre.
Une entreprise établie doit-elle commencer par un MVP ?
Si vous faites passer en ligne un processus bien connu, les besoins sont clairs et un MVP peut ne pas être nécessaire. Si vous servez un nouveau groupe de clients ou lancez un nouveau service, commencer par une première version étroite est plus sûr.
