De l'idée au MVP SaaS : le guide pas à pas du fondateur

Presque tous les articles sur la création d'un SaaS sont en réalité écrits pour quelqu'un qui a déjà levé des fonds. Ils supposent une équipe, une trésorerie, une feuille de route et la sérénité de savoir qu'on peut se permettre de se tromper pendant un an. Si vous êtes un fondateur avec une vraie idée, un emploi et une épargne dont vous avez réellement besoin, ce conseil est sournoisement dangereux. Il vous dit de construire grand et vite, ce qui est exactement la façon dont la plupart des premiers produits meurent avant que quiconque n'ait payé un centime.

Cela fait plus de dix ans que j'aide des gens à transformer des idées en logiciels qui fonctionnent, et les fondateurs dont je me souviens le mieux ne sont pas ceux aux plans les plus audacieux. Ce sont ceux qui ont commencé petit et sont restés honnêtes. Une kinésithérapeute qui a créé un outil de prise de rendez-vous pour son propre cabinet et a fini par le vendre à quarante autres. Un répartiteur logistique qui a automatisé sa propre paperasse et a réalisé que la moitié du secteur avait le même problème. Aucun n'a démarré avec une grande plateforme. Ils ont commencé avec une tâche pénible et la volonté de facturer sa résolution.

Voici donc le guide que j'aurais aimé qu'on remette à ces personnes dès le premier jour. Pas de théâtre de levée de fonds, pas d'architecture à la mode, pas de prétention que la première version doive impressionner. Juste un chemin serein, d'une intuition dans votre tête jusqu'à un premier client payant, et le discernement de savoir quoi laisser de côté en chemin.

Ce qu'est vraiment un MVP (et ce qu'il n'est pas)

Le terme produit minimum viable a été tellement étiré qu'il ne veut presque plus rien dire. Certains fondateurs entendent « minimum » et livrent quelque chose d'embarrassant que personne ne peut utiliser. D'autres entendent « produit » et passent huit mois à bâtir une plateforme soignée avec des paliers tarifaires, un panneau d'administration et un mode sombre, avant qu'un seul être humain n'ait confirmé qu'il paierait pour cela. Les deux sont des erreurs, et c'est la même erreur sous des habits différents : construire avant d'avoir rien appris.

Un MVP utile, c'est la plus petite chose que vous pouvez mettre devant un utilisateur réel et qui prouve que votre idée centrale mérite qu'on paie pour elle. Pas la plus petite chose que vous pouvez construire, mais la plus petite qui vous apprend quelque chose de vrai. Si votre idée est « un outil qui permet aux dentistes d'envoyer automatiquement des rappels de contrôle », le MVP, c'est le moteur de rappels et rien d'autre. Pas de portail patient, pas de tableau de bord analytique, pas de comptes d'équipe. Ce sont des réponses à des questions que vous n'avez pas encore méritées.

La raison pour laquelle cela compte tant, c'est le coût. Chaque fonctionnalité que vous construisez avant la validation est un pari placé à l'aveugle. Réduisez le MVP à son cœur et vous avez placé un petit pari récupérable. Construisez la vision entière et vous avez parié l'épargne, sur une supposition. La discipline du « minimum » n'est pas une affaire d'économie. C'est rester en vie assez longtemps pour avoir raison.

Validez l'idée avant d'écrire une seule ligne de code

Voici la vérité inconfortable que personne qui vous vend du développement ne veut dire : la plupart des idées de SaaS sont fausses sur un point important, et vous pouvez le découvrir pour presque rien. L'instinct est de construire d'abord et de demander ensuite. Inversez-le. La version la moins chère de votre produit est une conversation, et la deuxième la moins chère est une page d'atterrissage.

Avant de construire quoi que ce soit, vous voulez la preuve de deux choses. D'abord, que le problème est réel et assez douloureux pour que les gens y consacrent déjà du temps ou de l'argent, maladroitement, avec des tableurs, des notes autocollantes et un outil qu'ils détestent. Ensuite, qu'ils paieraient vraiment pour le faire disparaître. « C'est une belle idée » n'est pas une preuve. « Je l'utiliserais » n'est pas une preuve. « Combien ça coûte, et je peux commencer lundi ? » voilà une preuve.

Une page d'atterrissage avec une promesse claire et un bouton « rejoindre la liste d'attente » ou « réserver une démo » est l'étape suivante. Si vous n'arrivez pas à amener une poignée d'inconnus à laisser un e-mail pour ce que vous décrivez, ce n'est pas un problème de marketing à régler plus tard : c'est un signal maintenant, tant qu'il est encore bon marché de l'entendre. La validation n'est pas une phase qu'on bâcle pour atteindre la partie amusante. Pour un fondateur qui dépense son propre argent, elle est la partie amusante : c'est là que vous évitez l'erreur coûteuse.

Trouvez la seule fonctionnalité sans laquelle votre produit ne peut pas vivre

Toute idée de SaaS, quand vous la décrivez pour la première fois, arrive enveloppée d'une douzaine de fonctionnalités. Il y a ce qu'elle fait, puis la constellation d'options agréables que votre cerveau y a déjà attachée : rapports, intégrations, applis mobiles, rôles et autorisations, une API publique. La compétence la plus précieuse pour passer de l'idée au MVP est d'apprendre à tout retirer et trouver la seule fonctionnalité qui, si elle disparaissait, rendrait l'ensemble inutile.

Cette fonctionnalité centrale est votre MVP. Tout le reste est une hypothèse que vous testerez plus tard, une fois que les gens utilisent le cœur et vous disent ce qui leur manque vraiment. Les fondateurs s'y prennent systématiquement à l'envers : ils construisent d'abord les seconds rôles parce que cela rassure, et ils manquent de temps et d'argent avant que la seule chose qui compte ne soit jamais livrée.

Le test de la phrase unique

Essayez de décrire ce que fait votre produit en une seule phrase sans aucun « et ». « Il permet aux cabinets d'envoyer des rappels de rendez-vous automatiques. » « Il transforme la photo d'un reçu en écriture comptable. » « Il suit les devis qu'un artisan a envoyés et lui rappelle de relancer. » S'il vous faut un « et » pour décrire la valeur, vous avez sans doute deux produits qui se battent dans un seul MVP, et vous devriez livrer d'abord la moitié la plus douloureuse.

• Notez tout ce que vous imaginez que le produit fait : sortez tout, ne filtrez pas.
• Pour chaque élément, demandez-vous : si cela n'existait pas, quelqu'un paierait-il quand même ? Barrez chaque « oui ».
• Ce qui reste après les ratures, c'est votre cœur. C'est le MVP.
• Prenez les éléments barrés les plus forts et mettez-les sur une liste « plus tard » : pas supprimés, juste pas maintenant.
• Résistez à l'envie de les rajouter. La liste « plus tard » est l'endroit où les bonnes idées attendent de mériter leur place, pas l'endroit où les MVP vont mourir.

Construire, acheter ou simuler : comment réaliser le MVP

Une fois que vous connaissez votre seule fonctionnalité centrale, vous avez un choix que les fondateurs font rarement consciemment : quelle part devez-vous réellement construire de zéro ? La réponse honnête, pour une première version, est généralement « moins que vous ne le pensez ». Il existe trois grandes voies, et le bon coup est souvent un mélange.

La voie no-code / assemblage

Pour certains MVP, vous pouvez relier des outils existants — un formulaire, une base de données, une couche d'automatisation, un service d'e-mail — et valider l'idée sans écrire le moindre code sur mesure. C'est brillant pour tester si les gens utiliseront le flux de travail et paieront pour lui. C'est rapide et bon marché. Ses limites apparaissent plus tard : quand vous avez besoin d'une vraie expérience produit, de votre propre modèle de données ou de quelque chose de réellement unique, l'assemblage commence à craquer. C'est un bon problème : cela signifie qu'il est temps de construire pour de vrai, avec des utilisateurs payants déjà en main.

La voie du développement sur mesure

Quand votre fonctionnalité centrale est l'élément différenciant — la véritable raison pour laquelle les clients vous choisissent —, cette partie mérite un vrai logiciel sur mesure. L'erreur est de tout construire sur mesure autour d'elle. Vous n'avez pas besoin d'écrire votre propre authentification, votre gestion des paiements ou votre infrastructure d'e-mail ; ce sont des problèmes résolus que vous devriez louer. Construisez la partie qui n'appartient qu'à vous, louez le reste, et vous gardez le coût et le calendrier honnêtes.

La plupart des MVP réussis que j'ai vus sont un mélange délibéré : des briques louées pour la plomberie ennuyeuse mais nécessaire, et un développement sur mesure ciblé sur la seule chose qui rend le produit digne d'être payé. Savoir ce qui est quoi — quoi construire face à quoi acheter — est exactement le genre de décision qui mérite un deuxième avis avant de dépenser quoi que ce soit.

Ce que vous pouvez laisser de côté sans risque dans la version un

Savoir quoi laisser de côté est aussi important que savoir quoi construire, et c'est là que les fondateurs ont le plus besoin de permission. Alors la voici : vous avez la permission de laisser de côté presque tout. La première version existe pour apprendre, pas pour impressionner, et presque rien de ce qui fait qu'un produit semble « fini » ne vous aide réellement à apprendre.

• Plusieurs paliers tarifaires : choisissez un seul prix, ou facturez même à la main par facture au début.
• Un parcours d'inscription en libre-service : accueillir vos dix premiers clients à la main vous apprend plus que n'importe quel tunnel automatisé.
• Un tableau de bord d'administration avec graphiques : tant qu'il y a dix utilisateurs, vous pouvez lire la base de données directement.
• Les applis mobiles, si le web fonctionne bien sur un téléphone pour l'instant.
• Rôles, autorisations et comptes d'équipe, jusqu'à ce qu'un vrai client soit bloqué sans eux.
• Réglages soignés, personnalisation des thèmes et chaque cas limite : traitez d'abord le chemin courant, le reste quand quelqu'un le rencontre.

Un chemin réaliste de l'idée au premier client

Voici la séquence que je ferais suivre à presque tout fondateur. Elle est volontairement lente au début et rapide une fois que vous construisez, car les erreurs coûteuses vivent toutes dans les premières étapes, celles que les fondateurs sont le plus tentés de sauter.

1. 1
   Écrivez le problème en une phrase

   Pas la solution : le problème. « Les cabinets perdent de l'argent à cause des absences parce que les rappels sont manuels. » Si vous ne savez pas énoncer le problème proprement, vous n'êtes pas prêt à le résoudre.
2. 2
   Ayez dix vraies conversations

   Parlez à des gens qui ont le problème. Écoutez la douleur et l'argent déjà dépensé. Ajustez ou abandonnez l'idée selon ce que vous entendez, pas selon ce que vous espériez.
3. 3
   Mettez en ligne une page d'atterrissage et un prix

   Décrivez la promesse simplement, annoncez un prix et demandez un e-mail ou la réservation d'une démo. Voyez si les inconnus s'y intéressent. Voilà une validation à laquelle vous pouvez vous fier.
4. 4
   Définissez la seule fonctionnalité centrale

   Réduisez l'idée à la seule chose dont l'absence la rend inutile. Écrivez la description d'une phrase sans « et ». C'est votre périmètre de construction.
5. 5
   Décidez construire ou acheter pour chaque pièce

   Ne construisez sur mesure que l'élément différenciant. Louez la connexion, les paiements, l'e-mail et l'hébergement. Réussissez cette carte avant que quiconque n'écrive du code : elle fixe tout votre budget.
6. 6
   Construisez la plus petite version fonctionnelle

   Visez des semaines, pas des mois. Si la seule fonctionnalité centrale prend plus de deux mois, le périmètre est encore trop large : coupez de nouveau.
7. 7
   Accueillez vos premiers clients à la main

   Guidez-les personnellement. Observez où ils trébuchent. Les dix premiers utilisateurs sont votre meilleure équipe produit, et votre premier chiffre d'affaires.
8. 8
   Améliorez selon l'usage, pas selon l'opinion

   Changez ce que l'usage réel vous dit de changer. Ce n'est que maintenant que vous commencez à retirer des éléments de la liste « plus tard », mérités par la demande, pas ajoutés par supposition.

Ce que cela coûte vraiment : en argent et en temps

Les fondateurs posent toujours d'abord la question du coût, et la réponse honnête est « cela dépend, et vous en contrôlez l'essentiel ». Le plus grand facteur de coût, de loin, est le périmètre : combien vous avez décidé de construire avant de décider d'apprendre. Un MVP resserré avec une fonctionnalité centrale et la plomberie louée est un projet modeste et bien défini. La même idée construite comme une plateforme complète avec tout activé est un univers de coût différent et a une probabilité bien plus élevée d'échouer avant le lancement.

Le coût que la plupart des gens oublient, c'est le temps : le vôtre. Chaque mois passé à construire quelque chose que personne n'a confirmé vouloir acheter est un mois de votre vie et de votre épargne dépensé sur une supposition. Voilà le véritable argument pour commencer petit : non pas que petit soit bon marché, mais que petit est rapide, et rapide signifie que vous apprenez si vous avez raison tant que le pari est encore récupérable. Un fondateur qui atteint un client payant en trois mois avec un outil restreint est dans une position bien plus solide que celui qui peaufine encore une grande plateforme un an plus tard.

Il y a aussi un coût plus discret : chaque fonctionnalité que vous livrez est quelque chose que vous devez désormais maintenir, prendre en charge et expliquer. Un petit produit qui fait une chose de manière fiable est moins cher à exploiter, plus facile à vendre et plus simple à améliorer qu'un produit tentaculaire qui fait dix choses à moitié. La retenue n'est pas seulement votre façon de survivre à la construction : c'est votre façon de garder l'entreprise vivable ensuite.

Questions fréquentes