9 erreurs de développement SaaS qui coulent en silence les jeunes startups

Presque personne ne construit un produit SaaS de travers exprès. Les erreurs qui coulent les jeunes startups sont des décisions silencieuses, d'apparence raisonnable, prises par des gens intelligents sous pression — et sur le moment, elles semblent toutes justes. Nous avons vu les mêmes neuf se rejouer sur des dizaines de produits, dans les garages de fondateurs comme dans des équipes bien financées. La bonne nouvelle, c'est qu'elles sont prévisibles, donc évitables. C'est la liste que nous aurions aimé voir collée sur l'écran de chaque fondateur avant qu'il n'écrive sa première ligne de code.

Nous développons des logiciels pour les petites et moyennes entreprises, ce qui veut dire qu'on nous appelle à deux moments très différents. Parfois c'est le jour un, quand il n'y a rien qu'un croquis et une idée. Plus souvent, hélas, c'est le neuvième mois — quand un fondateur a dépensé ses économies, que le produit fonctionne techniquement, et que pourtant personne ne paie pour lui. Le second type d'appel est celui qui nous a enseigné cette liste. À chaque fois, l'autopsie révèle le même petit ensemble de blessures, infligées tôt et laissées s'envenimer.

Aucune de ces erreurs n'est une question de talent. Ceux qui les commettent sont en général capables et travailleurs. Le problème, c'est que construire du SaaS récompense un type très précis de retenue qui ne vient pas naturellement quand on est enthousiasmé par sa propre idée. Parcourons donc les neuf, à peu près dans l'ordre où elles ont tendance à mordre, et soyons honnêtes sur ce qui rend chacune si tentante.

1. Construire pendant six mois avant de parler à un seul client

C'est le péché originel, et le plus coûteux. Un fondateur est convaincu que l'idée est bonne — et elle l'est peut-être — alors il se tait, construit tête baissée pendant six mois et ressort avec un produit soigné que personne n'a demandé. Le marché ne récompense pas l'effort. Il récompense la résolution d'un problème pour la disparition duquel quelqu'un paiera.

La solution n'est pas compliquée, juste inconfortable : montrez quelque chose de brut à de vrais clients potentiels avant que ce soit prêt. Une maquette cliquable, une page d'atterrissage, voire une version manuelle du service réalisée à la main par e-mail. Chaque semaine passée à construire avant d'avoir confirmé que les gens le veulent est une semaine que vous passez peut-être à décorer une maison dans la mauvaise rue.

2. Construire pour un million d'utilisateurs que vous n'avez pas

La deuxième erreur revêt le costume du professionnalisme. Le fondateur, ou un ingénieur ambitieux du début, conçoit le système pour encaisser une échelle massive dès le jour un — microservices, Kubernetes, bases de données multi-régions, couches de cache élaborées. Cela semble responsable. C'est en réalité un piège. Vous dépensez votre ressource la plus rare — le temps — à vous prémunir contre un problème que vous seriez chanceux d'avoir.

Un ennuyeux monolithe à base de données unique vous portera confortablement jusqu'à vos premiers milliers d'utilisateurs et bien au-delà de votre premier chiffre d'affaires. Les décisions d'architecture qui comptent à grande échelle ne sont presque jamais celles que vous pouvez prévoir au départ, et la complexité prématurée rend le produit plus lent à changer — ce qui, aux débuts, est la seule chose qui vous tue vraiment. Construisez pour les dix prochains clients, pas pour le millionième imaginaire.

3. Un MVP qui n'est ni minimal, ni viable, ni un produit

Tout le monde est d'accord pour construire un MVP. Presque personne ne le fait vraiment. Ce qui est livré à la place, c'est une « version un » tentaculaire bourrée de chaque fonctionnalité que le fondateur a pu imaginer, parce que couper des fonctionnalités donne l'impression de couper dans l'ambition. Le résultat prend trois fois plus de temps, coûte trois fois plus cher et est plus difficile à analyser — car lorsqu'un produit boursouflé échoue, vous ne pouvez pas dire quelle partie était fausse.

Un vrai MVP fait une seule chose assez bien pour que quelqu'un paie pour elle. C'est tout. La discipline n'est pas de décider quoi inclure ; elle est de décider quoi laisser de côté, en sachant que chaque fonctionnalité « évidente » que vous reportez est une semaine que vous récupérez et une question à laquelle vous pourrez répondre avec de vrais utilisateurs plutôt que des suppositions.

Un rapide contrôle de périmètre

Avant qu'une fonctionnalité n'entre dans la première version, nous faisons répondre aux fondateurs une question à voix haute : « Si nous livrions sans ceci, un seul client payant refuserait-il d'utiliser le produit ? » Si la réponse honnête est non, elle attend. Vous serez étonné de voir combien de votre liste de fonctionnalités « essentielles » s'évapore sous cette seule phrase.

• Si une fonctionnalité existe pour impressionner les investisseurs, et non pour servir un utilisateur, elle attend.
• Si une fonctionnalité gère un cas limite que moins de 1 utilisateur sur 20 rencontrera, elle attend.
• Si vous construisez des réglages pour configurer un comportement que personne n'a encore demandé à changer, elle attend.
• Si « le concurrent l'a » est la seule raison de sa présence dans la liste, elle attend.
• Si la retirer n'empêcherait pas une seule vente, elle attend.

4. Traiter la facturation et l'accueil comme une réflexion après coup

Les fondateurs versent tout leur amour dans la fonctionnalité centrale, puis, deux semaines avant le lancement, se souviennent que les clients ont besoin d'un moyen de s'inscrire, de payer et de réellement commencer à utiliser la chose. La facturation est bricolée dans la panique. L'accueil, c'est un écran de connexion et un haussement d'épaules. Pourtant, le parcours du « visiteur intéressé » à l'« utilisateur payant et activé » est votre entreprise — et c'est là que la majeure partie de votre chiffre d'affaires fuit en silence.

Nous avons vu des produits à la fonctionnalité centrale réellement excellente perdre la majorité des inscriptions dans les cinq premières minutes parce que personne n'arrivait à comprendre quoi faire après l'inscription. Abonnements, essais, prorata, paiements échoués, résiliations, l'expérience d'état vide d'un compte tout neuf — ce n'est pas de la paperasse. C'est le produit réel, pour le client, au moment où il décide de rester ou non.

5. Rater la multi-location (ou la sauter)

C'est celle qui semble très bien aller jusqu'à devenir une catastrophe. Le SaaS, c'est plusieurs clients partageant un même système, et la façon dont vous séparez leurs données — la multi-location — est une décision fondatrice. Ratez-la et soit vous construisez quelque chose qui ne peut pas isoler correctement les clients, soit pire, vous livrez un bug où une entreprise peut voir les données d'une autre. Il n'y a pas de moyen plus rapide de perdre tous ses clients d'un coup qu'une fuite de données entre locataires.

Vous n'avez pas besoin d'une configuration exotique. Pour la plupart des produits en phase de démarrage, une seule base de données partagée avec un identifiant de locataire strictement appliqué sur chaque table et chaque requête est parfaitement suffisante — à condition que cette isolation soit intégrée aux fondations et testée, pas saupoudrée après coup. L'erreur n'est pas de choisir l'approche simple. L'erreur est de ne pas décider consciemment et de découvrir la faille quand elle est déjà en production.

6. Livrer dans le noir sans aucun moyen de voir ce que font les utilisateurs

Vous lancez. Les gens s'inscrivent. Et puis... silence. Vous n'avez aucune idée des fonctionnalités qu'ils touchent, de l'endroit où ils bloquent, ni de pourquoi ils partent. Alors vous devinez. Vous construisez la fonctionnalité suivante sur une intuition, ou sur l'e-mail client le plus bruyant, ou sur votre propre intuition — qui, après des mois passés à l'intérieur de votre propre produit, est l'instrument le moins fiable que vous possédiez.

Une analytique produit de base et un moyen simple de recueillir des retours ne sont pas un luxe de phase de croissance. C'est ainsi que vous barrez. Sans cela, vous ne dirigez pas une entreprise, vous dirigez une opinion coûteuse. Savoir une chose aussi simple que « 80 % des utilisateurs n'ouvrent jamais la fonctionnalité sur laquelle j'ai passé deux mois » vaut plus que deux mois de plus à construire à l'aveugle.

7. Remettre la sécurité et les sauvegardes à « plus tard »

La vitesse est la religion de la phase de démarrage, et c'est le plus souvent juste. Mais il existe un petit ensemble de choses catastrophiquement coûteuses à rajouter après coup, et la sécurité figure en tête de liste. Stocker les mots de passe correctement, verrouiller qui peut accéder à quoi et — s'il vous plaît — disposer de sauvegardes fonctionnelles et testées ne sont pas des fonctionnalités optionnelles qu'on ajoute quand on a le temps. C'est le sol sur lequel vous construisez.

Le cruel avec cette catégorie, c'est que ça passe — jusqu'à ce que ça ne passe plus. Tout va bien pendant un an, puis une intrusion, une suppression massive accidentelle, un matin de rançongiciel effacent la confiance et les données que vous avez passé cette année à bâtir. Nous ne demandons pas un département de sécurité. Nous demandons que les bases soient là dès le départ, car le coût de les ajouter après un incident se mesure en entreprises mortes.

8. Recruter le mauvais bâtisseur pour la mauvaise étape

Les fondateurs non techniques font face à un choix brutal : qui construit réellement ce truc ? Les deux erreurs classiques se font miroir. L'une est de recruter le freelance le moins cher possible, qui livre quelque chose qui a l'air correct mais tient avec du scotch, puis s'effondre à l'instant où vous devez le modifier. L'autre est le sur-recrutement — une équipe senior complète avec des salaires complets pour construire un produit qui ne s'est pas encore gagné un seul client.

La réponse honnête dépend entièrement de l'endroit où vous en êtes. Pour valider une idée, vous voulez une petite équipe senior et pragmatique qui a déjà construit des produits en phase de démarrage et sait exactement quoi laisser de côté. Pour faire passer à l'échelle un produit éprouvé, vous voulez des personnes différentes aux instincts différents. Faire correspondre le bâtisseur à l'étape est en soi une compétence — et se tromper gaspille plus d'argent que n'importe quelle décision technique de cette liste.

9. Traiter le lancement comme la ligne d'arrivée

La dernière erreur est la plus triste, car elle survient après tant de travail acharné. L'équipe traite le jour du lancement comme l'objectif, jette tout pour y arriver, et débarque épuisée, sans plan, sans budget et sans énergie pour ce qui vient ensuite. Mais le lancement n'est pas la ligne d'arrivée. C'est le début de la seule phase qui compte : apprendre de vrais utilisateurs et s'améliorer, semaine après semaine.

Un produit SaaS n'est jamais « terminé ». La première version est une hypothèse, et les mois suivant le lancement sont ceux où vous découvrez à quel point elle était fausse — dans le bon sens. Les fondateurs qui planifient cela, qui gardent un peu de marge et beaucoup de curiosité en réserve, sont ceux qui transforment un lancement bancal en une vraie entreprise. Ceux qui ont tout dépensé pour atteindre la ligne de départ ont tendance à ne pas aller beaucoup plus loin.

Comment réellement éviter les neuf

Lire une liste d'erreurs est facile. Les éviter sous la pression des délais, avec votre propre argent en jeu et votre propre idée au cœur, est véritablement difficile. Voici donc la version courte de la façon dont opèrent les fondateurs qui réussissent — non comme des règles, mais comme des habitudes qui valent la peine d'être volées.

1. 1
   Valider avant de construire

   Mettez quelque chose de brut devant de vrais clients potentiels et confirmez qu'ils paieront, avant d'écrire du code sérieux. Peu coûteux à faire, brutal à sauter.
2. 2
   Choisir le plus petit produit réel

   Définissez la seule chose que votre produit doit faire, et reportez impitoyablement tout le reste. Notez ce que la « version un » exclut délibérément.
3. 3
   Construire ennuyeux et isoler les locataires

   Utilisez l'architecture la plus simple qui fonctionne, mais faites de la séparation des données entre clients une décision fondatrice et testée dès le jour un.
4. 4
   Concevoir tôt le parcours de l'argent

   Traitez l'inscription, l'accueil et la facturation comme du produit central, pas de la paperasse. Les cinq premières minutes décident si le reste sera vu.
5. 5
   L'instrumenter, puis lancer pour apprendre

   Livrez avec une analytique et des retours de base en place, gardez de la marge pour la phase d'après-lancement, et traitez la première version comme une question, pas une réponse.

Remarquez que presque rien de tout cela ne concerne le talent de codage. Il s'agit de jugement — savoir quoi construire, quoi sauter, et quand. C'est précisément pourquoi tant d'équipes techniquement compétentes produisent malgré tout des produits qui échouent : la partie difficile du SaaS n'a jamais été l'ingénierie. C'était la retenue.

Questions fréquentes