Le fait d'avoir eu l'occasion de concevoir et de réaliser 6 MVPs en 30 jours m'a beaucoup appris sur les fonctionnalités à mettre en place lors d'un lancement.

Au cours des dernières années, le concept de lancement d'un MVP (Minimum Viable Product) a explosé en popularité et est désormais une pratique courante pour les startups et les entreprises technologiques établies. Mais comme c'est le cas avec la plupart des concepts qui atteignent le statut de buzz, il y a beaucoup de confusion. Il y a des partisans inconditionnels, des sceptiques acharnés et une tonne de personnes qui ne font que lancer le terme sans vraiment savoir ce qu'il signifie.

Revenons en arrière une seconde pour être sur la même longueur d'onde. L'idée générale d'un MVP est que vous devez construire la plus petite quantité de votre produit dont les gens tirent de la valeur, puis vous y ajoutez des fonctionnalités supplémentaires. Les partisans du MVP soutiennent que le fait de construire d'abord la plus petite quantité vous permet de découvrir les éléments supplémentaires que les gens veulent réellement, afin de ne pas perdre votre temps à construire un tas de fonctionnalités que personne n'utilise. Cependant, les sceptiques des MVP affirment qu'en réalité, les MVP finissent par être un ensemble de produits de mauvaise qualité qui n'ont pas assez de fonctionnalités pour être utiles ou appréciés. Ce débat a conduit les personnes des deux camps à inventer des acronymes encore plus amusants, tels que "Minimum Valuable Product", "Minimum Loveable Product", ou mon préféré, le RAT (identify your Riskiest Assumption and Test it).

Je suis ici pour dire que ce débat est plutôt inutile. Le concept de MVP n'est pas nouveau. En fait, il existe depuis... toujours. L'idée d'un MVP est en fait juste le concept d'évolution. Les choses commencent petit à petit et évoluent avec le temps. Par exemple, les écoles, les épiceries et les villes ont toutes commencé comme de petites MVP par rapport à ce qu'elles sont devenues aujourd'hui. La question de savoir si nous devons ou non commencer par créer une version initiale plus petite de notre produit, puis l'enrichir au fil du temps, ne devrait donc pas faire débat. Bien sûr, vous voulez améliorer votre produit après l'avoir lancé ! Nous devrions plutôt passer notre temps à essayer de comprendre la partie la plus difficile de tout ce concept :

Quelles sont les fonctionnalités qui doivent faire partie de notre version initiale et celles qui doivent attendre ?

Il est difficile de savoir quelles fonctionnalités les gens veulent avant de mettre votre produit entre leurs mains.

Il y a trois choses qui rendent cette question si difficile. 1) Nous ne savons pas quelles fonctionnalités nos clients vont vraiment aimer avant qu'ils ne commencent à utiliser le produit. 2) Les êtres humains sont naturellement impatients et veulent tout immédiatement. Donnez-moi toutes les fonctionnalités ! et 3) Nous n'avons pas beaucoup d'expérience dans ce domaine. Même les entrepreneurs et les concepteurs d'applications expérimentés ne déploient pas des MVPs tous les jours. Au contraire, ils se concentrent principalement sur l'amélioration de ce qu'ils ont déjà.

En tant que concepteur UX expérimenté, ce dernier point était vrai pour moi jusqu'à il y a environ un mois. Cependant, au cours des 30 derniers jours, j'ai fait un voyage incroyable. Mon cofondateur et moi avons pu concevoir et réaliser entièrement le MVP de 6 applications différentes, allant de petites applications pour startups à une application interne pour une grande entreprise. Et au cours de cette fête MVP au rythme effréné, nous avons mis au point un cadre pour décider des fonctionnalités à intégrer et de celles à supprimer. (Note annexe : je suis le cofondateur d'Adalo, une startup qui vous permet de créer rapidement des applications sans code).

Afin d'expliquer notre cadre, je vais utiliser l'une des applications sur lesquelles nous avons travaillé, appelée Tavolo. Tavolo est en fait la rencontre entre DoorDash et OpenTable. Sa mission est de "minimiser les aspects indésirables des repas" en permettant aux gens de réserver une table, de commander et de payer leur repas à l'avance. (Bravo à eux, c'est une idée géniale).

Tavolo est actuellement lancé à Minneapolis, donc si vous êtes là, n'oubliez pas d'aller les voir !

Étape 1 : Créez l'histoire de votre application.

Commencez par écrire le ou les principaux problèmes que votre application va résoudre, puis énumérez toutes les étapes qu'une personne doit franchir pour surmonter ces problèmes. Par exemple, l'histoire de Tavolo :

[Le principal problème que leur application résout]

Éliminez les tracas liés à la réservation d'une table et au paiement de votre repas.

[Une personne souffrant de Tavolo serait]

Ouvrez l'application → Choisissez un restaurant → Faites une réservation → Invitez leurs amis → Choisissez leurs articles alimentaires → Payez-les → Rendez-vous au restaurant → Enregistrez-vous → Dégustez leur nourriture !

[En outre, le restaurant devra]

Être notifié de la nouvelle réservation et de la commande → Vérifier l'entrée de la partie → Envoyer la commande à la cuisine→ Donner à la partie sa nourriture → Marquer la commande comme complète.

Étape 2 : Dresser la liste des informations utiles à chaque étape

Après avoir écrit le parcours sous la forme d'une série de points de décision, votre prochaine tâche consiste à trouver chaque élément d'information qui aiderait une personne à franchir l'étape suivante de son parcours. Par exemple, l'une des premières décisions sur Tavolo est de savoir à quel restaurant se rendre. Et à ce point de décision, il y a une tonne d'informations qui seraient utiles comme : le nom, l'emplacement, le prix, les plats du menu, les avis, si leurs amis y sont allés, etc.

Étape 3 : Créer une liste de toutes les caractéristiques possibles

À la fin des étapes 1 et 2, vous devriez disposer d'un long document (ou d'un tas de notes autocollantes) contenant un ensemble de points de décision et toutes les informations correspondantes dont les gens auraient besoin pour faciliter ces décisions. Ce document vous servira d'inspiration parfaite pour créer une liste de toutes les fonctionnalités possibles de votre application. Il vous suffit de transformer ces actions et ces informations en fonctionnalités spécifiques.

Étape 4 : Marquez les caractéristiques essentielles à la mission

Maintenant que vous disposez d'un ensemble complet de fonctionnalités (ou aussi complet que possible sans mettre votre application entre les mains de votre public), commencez par marquer celles qui sont essentielles. Cette fonctionnalité est-elle à 100 % nécessaire pour accomplir une étape du parcours ? Par exemple, pour choisir un restaurant, je dois connaître son nom et son emplacement, et je dois pouvoir le sélectionner. Tout le reste, comme la recherche et les évaluations, bien qu'utile, n'est techniquement pas nécessaire ici.

Étape 5 : Améliorez votre application avec les fonctions Easy Win

Une fois que vous avez décidé quelles sont les fonctionnalités 100% nécessaires, votre produit doit être au point où quelqu'un qui l'utilise peut au moins accomplir les principales tâches que votre application s'est fixée (bien que probablement d'une manière très inférieure). Maintenant, la partie amusante. Vous devez décider de toutes les fonctionnalités qui faciliteront cette expérience pour vos utilisateurs. Ces fonctionnalités seront directement liées aux informations utiles de l'étape 2 dont les utilisateurs ont besoin pour prendre leurs décisions.

Afin de choisir les plus délicats, posez-vous les questions suivantes :

  • Cette fonctionnalité est-elle facile à mettre en œuvre ?
  • Les gens l'utiliseront-ils vraiment si souvent ?
  • Est-ce que cela profite à vos premiers utilisateurs ou est-ce que cela n'est utile que lorsqu'il y a beaucoup d'utilisateurs ?

S'il y a des signaux d'alarme à l'une de ces questions, déplacez cette fonctionnalité dans une version ultérieure. Par exemple avec Tavolo :

[Caractéristiques qui n'ont pas été retenues]

  • Notifier aux utilisateurs les restaurants à proximité (la géolocalisation est difficile à construire)
  • Tableau de bord analytique pour les restaurants (utile, mais pas pour les premiers utilisateurs car il n'y aura pas encore beaucoup de données générées par les utilisateurs).
Début de la séquence d'allumage ... 6, 5, 4, 3, 2, 1, 0 ... Tous les moteurs sont en marche. Décollage ! Nous avons un décollage

C'est le moment de partir !

Une fois que vous avez terminé l'étape 5, vous devriez avoir une bonne idée des fonctionnalités que votre MVP devrait avoir et de celles qui devraient attendre pour l'avenir. Vous disposerez également d'une liste claire des fonctionnalités que vous pouvez ajouter pour faire passer facilement votre application d'un minimum viable à un minimum aimable. Le nombre de fonctionnalités que vous pouvez ajouter avant le lancement dépend de votre budget, de votre calendrier et de l'importance que vous et votre équipe accordez à la facilité d'utilisation.  

Mais il ne s'agit pas de se demander s'il faut appeler votre produit MVP ou MLP. L'important, c'est que vous disposez maintenant d'une excellente liste de fonctionnalités prioritaires qui devraient servir de modèle pour l'avenir. Vous ne faites pas seulement des fonctionnalités parce que vous pensez qu'elles sont cool. Vous créez la meilleure première version de votre produit qui attirera le plus grand nombre d'adopteurs précoces, créera une dynamique et vous donnera finalement les meilleures chances de succès.