Après le MVP : que construire ensuite, et que laisser de côté

Le jour du lancement ressemble à une ligne d'arrivée. C'est en réalité le début de la période où vous apprenez le plus. Un MVP (produit minimum viable, la plus petite version réelle de votre produit) existe pour répondre à une seule question : les gens vont-ils l'utiliser, et vont-ils payer ? Les semaines qui suivent le lancement vous donnent cette réponse. Ce sont aussi celles où l'on perd le plus facilement le cap, car chaque utilisateur, chaque investisseur et chaque ami a une idée de ce qu'il faudrait ajouter. Cet article vous propose un ordre de travail simple pour les premiers mois après le lancement.

Les premières semaines : quoi mesurer

Vous n'avez pas besoin d'un grand tableau de bord. Il vous faut quelques chiffres qui disent si le produit fait son travail. Avant le lancement, choisissez ceux que vous allez suivre, et notez-les.

• Les inscriptions. Combien de personnes créent un compte. Ce chiffre vous dit si votre message touche les bonnes personnes.
• L'activation. Combien d'entre elles vont au moins une fois au bout du parcours principal, par exemple réserver un premier cours ou envoyer une première facture. C'est souvent le chiffre le plus utile de tous.
• Le retour. Combien reviennent une semaine ou un mois plus tard et s'en servent à nouveau. Un produit utilisé une fois puis oublié n'a pas encore résolu leur problème.
• Le paiement. Combien paient, si vous faites payer. Et combien arrêtent de payer.
• L'endroit où les gens s'arrêtent. L'écran ou l'étape où la plupart des utilisateurs quittent le parcours principal.

Les chiffres disent ce qui se passe. Ils ne disent pas pourquoi. Parlez donc aussi à vos utilisateurs. Un court appel ou quelques questions écrites avec cinq ou dix d'entre eux expliquent l'essentiel de ce que montrent les chiffres. Surveillez aussi le suivi des erreurs, l'outil qui vous prévient quand quelque chose casse, pour être au courant des problèmes avant que les utilisateurs ne vous écrivent.

Soyez patient avec les petits chiffres. Avec quelques dizaines d'utilisateurs, une seule personne peut faire beaucoup varier un pourcentage. Cherchez des tendances sur plusieurs semaines, pas une bonne ou une mauvaise journée.

Corrigez d'abord ce qui freine les utilisateurs

Avant de construire quoi que ce soit de nouveau, regardez les endroits où les gens bloquent. Ce travail est moins excitant qu'une nouvelle fonctionnalité, mais il fait souvent bouger vos chiffres davantage.

• Les étapes où les gens partent. Si beaucoup d'utilisateurs s'arrêtent au même écran, quelque chose y est flou, trop long ou cassé.
• Les questions auxquelles vous répondez sans cesse. Si trois utilisateurs demandent comment faire la même chose, c'est au produit de l'expliquer, pas à vous.
• Les écrans lents. Vérifiez le parcours principal sur un téléphone ordinaire, avec une connexion ordinaire, pas seulement sur votre ordinateur.
• Les petits bugs. Un petit bug se pardonne facilement. Plusieurs font douter du produit tout entier.

Une bonne règle : rendez le parcours principal fluide avant d'agrandir le produit. Une nouvelle fonctionnalité posée sur un parcours que les gens abandonnent n'aidera pas beaucoup.

Comment choisir les fonctionnalités suivantes

Quand vous avez construit le MVP, vous avez sans doute écrit une liste d'idées pour plus tard, comme nous le conseillons dans que mettre dans un MVP. Cette liste est un bon point de départ, mais elle a été écrite avant d'avoir des utilisateurs. Vous disposez maintenant de meilleures informations. Servez-vous-en.

• Rassemblez toutes les demandes au même endroit. Une simple liste ou un tableau suffit. Notez qui a demandé, et ce que la personne essayait de faire.
• Cherchez les demandes qui reviennent. Une demande insistante est une anecdote. La même demande venant de nombreux utilisateurs est un signal.
• Demandez ce qu'ils essayaient de faire. Les utilisateurs demandent souvent une solution, par exemple un nouveau bouton. Le problème derrière peut avoir une réponse plus simple.
• Privilégiez ce qui aide le parcours principal. Une fonctionnalité qui fait aller plus de gens au bout du parcours, revenir ou payer passe avant une fonctionnalité pour un nouveau type d'utilisateur.
• Faites-le d'abord à la main. Si vous pouvez faire quelque chose à la main pour vos premiers utilisateurs, comme un e-mail de rappel, faites-le jusqu'à savoir que cela compte.
• Changez une chose à la fois. Si vous publiez cinq changements ensemble et que les chiffres bougent, vous ne savez pas lequel a joué.

Méfiez-vous de vos propres envies, et des demandes de personnes qui n'utilisent pas le produit. Ce peuvent être de bonnes idées. Mais ceux qui s'en servent chaque semaine sont ceux dont vous êtes payé pour résoudre les problèmes.

Les utilisateurs vous disent ce dont ils ont besoin par ce qu'ils font, plus que par ce qu'ils demandent.

Quand renforcer la stabilité et préparer la croissance

Un MVP bien construit peut accueillir bien plus d'utilisateurs qu'au premier jour. Inutile donc de vous préparer dès maintenant pour un million d'utilisateurs. Mais certains signes montrent qu'il est temps d'investir dans la base du produit, et pas seulement dans de nouvelles fonctionnalités :

• Les erreurs augmentent. Le suivi des erreurs montre plus de problèmes chaque semaine, ou le même problème revient sans cesse.
• Les écrans ralentissent quand les données grossissent. Une page rapide avec cinquante utilisateurs devient lente avec cinq mille fiches.
• Vous faites trop de choses à la main. Des tâches qui prenaient dix minutes par semaine prennent maintenant des heures.
• L'enjeu grandit. Plus d'argent passe par le produit, ou vous signez de plus gros clients qui demandent comment vous protégez leurs données.

Renforcer la stabilité, c'est par exemple des sauvegardes testées, des pages plus rapides, des alertes d'erreur plus claires, et une vérification de sécurité sur qui peut voir quelles données. Rien de tout cela ne se voit pour les utilisateurs. C'est pourtant ce qui leur permet de faire confiance au produit à mesure qu'il grandit.

Quand une version 2 ou une reconstruction a du sens

Une version 2 n'est pas une reconstruction. Une version 2 est une étape plus large sur la même base : un nouveau type d'utilisateur, une nouvelle formule payante, ou des applications iOS et Android une fois que la version web a prouvé l'idée. Elle a du sens quand les chiffres montrent que la première version fonctionne et que les utilisateurs demandent clairement l'étape suivante.

Une reconstruction consiste à remplacer la base elle-même. C'est rarement le bon premier geste après un MVP. Elle n'a de sens que si la base bloque la croissance : chaque correction en casse une autre, la façon dont les données sont stockées ne correspond plus au produit, ou des problèmes de sécurité sont inscrits dans les fondations. Nous expliquons comment trancher dans reconstruire ou réparer son application. Même dans ce cas, ce que vous avez appris de vos vrais utilisateurs n'est pas perdu. Cela devient le cahier des charges de la nouvelle base.

Gardez un petit budget pour le suivi

Un logiciel ne reste pas en bonne santé tout seul. Les bibliothèques de code sur lesquelles il repose reçoivent des mises à jour, souvent pour la sécurité. Les services extérieurs changent leur fonctionnement. Les téléphones et les navigateurs évoluent. De petits bugs apparaissent quand les utilisateurs font des choses que personne n'avait prévues.

Quand vous préparez votre budget après le lancement, ne le consacrez donc pas entièrement aux nouvelles fonctionnalités. Gardez une part fixe chaque mois pour le suivi : mises à jour, petites corrections et vérifications. Cela coûte bien moins cher qu'une urgence, et le produit reste prêt pour l'étape suivante. Beaucoup de studios, dont le nôtre, proposent ce suivi sous forme de contrat de maintenance après le lancement. Quel que soit votre choix, assurez-vous qu'une personne en a clairement la charge.

En résumé

Après le MVP, l'ordre de travail est simple. Mesurez quelques chiffres et parlez à vos utilisateurs. Corrigez ce qui les freine. Ajoutez les fonctionnalités suivantes d'après ce que font beaucoup d'utilisateurs, un changement à la fois. Renforcez la stabilité quand l'usage réel le demande, et gardez un petit budget pour le suivi. Pour voir comment le lancement et les étapes suivantes s'inscrivent dans un projet, lisez un MVP en six semaines, semaine par semaine, ou découvrez comment nous créons et faisons évoluer un MVP.