Comment valider une idée de SaaS avant d'écrire la moindre ligne de code

La façon la plus coûteuse de savoir si les gens veulent votre logiciel, c'est de le construire. C'est pourtant exactement ce que font la plupart des fondateurs débutants : ils passent six mois et leurs économies à transformer une idée en code, le lancent dans le silence, et se demandent seulement alors si quelqu'un en avait besoin. La validation est la version bon marché de cette leçon. C'est ainsi que l'on achète la réponse avec quelques semaines de conversations plutôt qu'avec une année de sa vie.

J'ai vu beaucoup de gens intelligents tomber dans le même piège. Ils ont une observation réellement pertinente — une vraie contrariété dans un secteur qu'ils connaissent — et ils supposent que l'écart entre l'observation et le produit n'est qu'une question d'ingénierie. Il ne l'est pas. Cet écart est plein de questions sans réponse : quelqu'un d'autre ressent-il cette douleur assez fort pour payer ? Ces gens quitteront-ils ce qu'ils font aujourd'hui ? Pouvez-vous les atteindre sans brûler de l'argent ? On ne répond pas à ces questions en écrivant du code. On y répond en parlant aux gens et en observant ce qu'ils font vraiment.

Voici donc le guide que je donne aux fondateurs avant qu'ils ne recrutent qui que ce soit pour construire quoi que ce soit. Il ne s'agit pas de théâtre lean-startup ni de remplir un canevas. Il s'agit d'une poignée d'expériences honnêtes et peu coûteuses qui vous disent si votre idée a un pouls — et de la discipline de croire les résultats, même lorsqu'ils piquent.

Pourquoi construire d'abord paraît productif — et ne l'est presque jamais

Construire est séduisant car cela ressemble à un progrès que l'on peut voir. À la fin d'une session de code, il y a un écran qui fonctionne, un bouton qui fait quelque chose, une chose à montrer à son conjoint. Parler à des inconnus d'un problème ne produit aucun objet. C'est inconfortable, c'est lent, et à la fin vous n'avez que des notes. Alors les fondateurs se tournent vers le clavier, parce que le clavier les récompense plus vite.

L'ennui, c'est qu'un écran qui fonctionne ne vous dit presque rien sur la justesse de l'idée. Vous pouvez construire un produit magnifique et sans bug pour un problème que personne n'a, et il sera tout aussi mort qu'un produit laid. Le code est la réponse à « comment livrer cela ? » — pas à « est-ce que quelqu'un en veut ? ». Passer des mois sur la première question avant d'avoir répondu à la seconde, c'est ainsi que de bons ingénieurs bâtissent des solutions élégantes à des problèmes imaginaires.

La validation inverse l'ordre. Vous passez quelques semaines et très peu d'argent à prouver — ou à réfuter — l'hypothèse la plus risquée de votre idée avant de vous engager à construire. Si l'idée est solide, vous entrez en développement avec des preuves, un cahier des charges plus clair et vos premiers utilisateurs déjà en attente. Si elle est faible, vous le découvrez pour le prix de quelques cafés et d'une page de destination, pas pour celui d'un produit.

Trouvez l'unique hypothèse qui pourrait tout faire échouer

Toute idée de SaaS repose sur une pile de convictions, et elles ne sont pas également dangereuses. Certaines sont sûres : « les gens utilisent l'e-mail », « les petites entreprises n'aiment pas la paperasse ». D'autres sont des paris dont dépend tout votre projet et, si elles sont fausses, rien d'autre ne compte. Le rôle de la validation n'est pas de tout tester. C'est de trouver l'hypothèse la plus risquée et de s'attaquer d'abord à celle-là.

Pour la trouver, écrivez votre idée en une seule phrase : « [ces gens] ont [ce problème] assez fort pour payer [cette solution] au lieu de [ce qu'ils font aujourd'hui]. » Puis demandez-vous, sans concession : quel mot de cette phrase, s'il s'avérait faux, coulerait l'idée ? Ce n'est généralement pas la solution. C'est de savoir si le problème fait assez mal pour qu'on paie, ou si vous pouvez réellement atteindre ces gens à un coût abordable.

Cette séquence compte car le coût du test augmente à chaque étape. Un entretien sur le problème est gratuit. Un test de volonté de payer coûte une page de destination. Un test de la solution nécessite peut-être un prototype cliquable. Construire est le test le plus cher de tous. Vous voulez échouer à bas prix et tôt, pas cher et tard — alors vous placez les tests les moins chers et les plus létaux en premier.

Parlez aux gens — mais faites-le bien

La chose la plus utile que vous puissiez faire est de parler aux personnes que vous pensez avoir le problème. Pas vos amis, pas d'autres fondateurs — les vrais êtres humains qui s'en serviraient. Et voici le piège qui ruine la plupart des tentatives : les gens sont polis. Demandez « utiliseriez-vous un outil qui fait X ? » et presque tout le monde dira oui, parce que dire oui est gratuit et aimable. Ce oui ne vaut rien. Il a coulé plus de startups que n'importe quel échec technique.

La solution est de cesser d'interroger sur l'avenir et de commencer à interroger sur le passé. L'avenir est l'endroit où les gens mentent pour être gentils ; le passé est l'endroit où vit la vérité. Au lieu de « utiliseriez-vous ceci ? », demandez « racontez-moi la dernière fois où vous avez eu affaire à ce problème ». Qu'ont-ils fait ? Combien de temps cela a-t-il pris ? Combien cela leur a-t-il coûté ? Ont-ils cherché une solution ? En ont-ils payé une ? Le comportement réel l'emporte sur l'enthousiasme hypothétique à chaque fois.

Des questions qui obtiennent des réponses honnêtes

• « Décrivez-moi la dernière fois où c'est arrivé. » — fait remonter le flux de travail réel, pas une version idéalisée.
• « Qu'avez-vous fait à ce sujet ? » — révèle si cela leur importe vraiment ou s'ils s'en accommodent.
• « Combien de temps ou d'argent cela vous a-t-il coûté ? » — transforme une douleur vague en un chiffre.
• « Avez-vous déjà tenté de régler cela ? Que s'est-il passé ? » — vous indique s'il y a un budget et une intention.
• « Qu'est-ce qui, en ce moment, vous agace plus que cela ? » — vérifie si votre problème figure seulement dans leur top cinq.

Combien de conversations ? Moins que vous ne le pensez. Une fois que vous avez mené dix entretiens honnêtes et bien menés avec les bonnes personnes, le schéma est généralement évident. Soit trois ou quatre d'entre elles s'illuminent et décrivent la douleur dans un détail saisissant — soit elles sont toutes poliment tièdes, et aucun développement, si astucieux soit-il, ne corrigera cela. Douze à quinze suffisent largement pour prendre une décision à laquelle vous pouvez vous fier.

Des moyens peu coûteux de tester la demande réelle

Les conversations vous disent si le problème est réel. La question suivante est de savoir si les gens vont agir — et le seul moyen de le savoir est de demander un petit engagement avant que le produit existe. C'est là que la validation devient un peu inconfortable, et c'est aussi là qu'elle devient honnête. Parler ne coûte rien ; un clic, une adresse e-mail ou un acompte, si.

Vous n'avez rien à construire pour mener ces tests. Il vous faut une seule page qui décrit clairement la promesse et demande une action précise. L'action, c'est la donnée. Si les gens lisent votre pitch et ne font rien, c'est votre réponse, et c'est une réponse bien moins chère que de se lancer dans le vide six mois plus tard.

1. 1
   Mettez en ligne un pitch d'une page

   Décrivez le problème et votre solution dans un langage simple, avec un appel à l'action clair. Une page de destination simple suffit — sans aucun produit derrière pour l'instant.
2. 2
   Demandez un vrai signal

   Pas un « j'aime ». Demandez aux gens de rejoindre une liste d'attente avec leur e-mail, de précommander ou de réserver un appel. Plus dire oui leur coûte, plus le oui a de valeur.
3. 3
   Amenez un peu de trafic honnête

   Partagez-le là où votre vraie audience se trouve déjà — une communauté pertinente, une petite annonce, quelques messages directs. Vous voulez des inconnus, pas votre réseau bienveillant.
4. 4
   Lisez le taux de conversion, pas les compliments

   Parmi tous ceux qui ont réellement compris l'offre, combien ont accompli l'action ? Une poignée d'inscriptions réelles des bonnes personnes vaut mieux que mille vœux flous.

Le test de demande le plus puissant de tous, c'est de demander de l'argent d'avance. Une prévente, un pilote payant, un acompte pour un accès anticipé — tout ce qui fait ouvrir un portefeuille. Cela paraît agressif, et c'est la chose la plus honnête que vous puissiez faire pour vous-même. Quelqu'un qui remet ne serait-ce qu'une petite somme pour un produit qui n'existe pas encore vous dit quelque chose qu'aucun sondage ne pourrait. Si vous trouvez trois ou quatre de ces personnes, vous n'avez plus une idée. Vous avez une entreprise qui n'attend que d'être construite.

Vendez-le avant de le construire

Il existe une étape entre « les gens sont intéressés » et « les gens paieront chaque mois » qui mérite sa propre attention : livrer la valeur manuellement avant de l'automatiser. Si votre idée est, disons, un outil qui transforme des e-mails fournisseurs désordonnés en un rapport hebdomadaire soigné, faites-le d'abord à la main pour trois ou quatre clients. Vous devenez le logiciel. C'est lent et cela ne se met pas à l'échelle, et c'est tout l'intérêt — cela vous permet d'apprendre ce que le produit doit réellement faire avant de l'avoir figé dans le code.

Cela accomplit deux choses à la fois. Cela prouve que les gens paieront pour le résultat, pas seulement pour l'idée de celui-ci. Et cela vous enseigne le flux de travail réel — les cas limites, les exceptions, les détails qui comptent pour les clients et que vous n'auriez jamais devinés lors d'un entretien. Quand vous construirez enfin, vous ne devinerez pas le cahier des charges. Vous coderez un processus que vous avez déjà exécuté à la main et pour lequel vous avez été payé.

Lire les signaux honnêtement

Tout cela ne fonctionne que si vous êtes prêt à croire les résultats — et c'est plus difficile qu'il n'y paraît, car à ce stade vous êtes attaché à l'idée. Le danger, ce ne sont pas les mauvaises données ; c'est un fondateur qui interprète chaque signal comme un encouragement. Un intérêt tiède est mémorisé comme de l'enthousiasme. Une inscription polie à la liste d'attente devient une « forte demande ». Ici, vous devez lutter contre votre propre optimisme.

Il est utile de décider, à l'avance, à quoi ressemble une réussite. Avant de mener un test, notez le résultat qui vous ferait poursuivre et celui qui vous ferait arrêter. « Si moins de X de mes entretiens décrivent cela comme un problème réel et récurrent, j'abandonne. » Fixer la barre avant de voir les données est la seule défense fiable contre l'idée de se convaincre soi-même d'un développement qu'on ne devrait pas faire.

Et parfois la réponse honnête est non. Ce n'est pas un échec — c'est le système qui fonctionne. Un processus de validation qui ne peut jamais renvoyer « ne construisez pas cela » n'est pas de la validation, c'est de la recherche d'autorisation. Les fondateurs qui gagnent au fil d'une carrière ne sont pas ceux qui n'ont jamais de mauvaises idées. Ce sont ceux qui tuent les mauvaises idées en trois semaines pour quelques centaines d'euros au lieu de les couver pendant un an.

Quand vous êtes vraiment prêt à construire

Admettons que les signaux soient bons. Le problème est réel, les gens l'ont décrit avec émotion, quelques-uns ont mis de l'argent. Maintenant — et seulement maintenant — construire a du sens. Mais même ici, la retenue est payante. Le but de votre première version n'est pas d'être le produit que vous imaginez. C'est de livrer l'unique résultat central pour lequel vos clients validés paient, et rien d'autre pour l'instant.

C'est ici que la validation vous remet discrètement un cadeau : un cahier des charges net, étayé par des preuves. Vous savez à qui cela s'adresse, quelle est la tâche centrale, ce pour quoi les gens paieront et quelles fonctionnalités sont revenues sans cesse par rapport à celles qui ne tenaient à cœur qu'à vous. Cette clarté vaut plus que n'importe quelle quantité de conception préalable. C'est la différence entre construire la bonne petite chose et construire un tout hors de prix.

Questions fréquentes