Coder au lieu de vendre, c'est la procrastination la plus convaincante qu'un fondateur puisse s'offrir, parce qu'elle laisse quelque chose de concret derrière elle. Vous ajoutez une fonctionnalité, l'application est vraiment meilleure, et vous avez le sentiment d'avoir travaillé. Mais si personne n'a utilisé les cinq dernières choses que vous avez construites, la sixième n'est pas du travail sur le produit.
C'est de la fuite, avec un historique de commits. Le signe qui ne trompe pas est simple : vous continuez d'améliorer un produit que presque personne n'a vu.
Ajouter des fonctionnalités ou trouver des clients ?
Si vous devez poser la question, vous connaissez déjà la réponse. Ce qui vous trahit, ce n'est pas la question, c'est votre réflexe dès que la prospection devient pénible. La demande de fonctionnalité paraît urgente, la roadmap semble en retard, et coder la suite a l'air d'être la chose raisonnable à faire. Rien de tout ça ne concerne le client.
Tout ça, c'est parce que vous êtes plus à l'aise dans votre éditeur que dans la boîte de réception de quelqu'un.
Pour le dire simplement : tant que de vraies personnes n'ont pas utilisé ce que vous avez, ajouter des fonctionnalités ne peut rien vous apprendre. Vous apportez des réponses à des questions que personne n'a encore posées. La seule information qui compte au début vient de quelqu'un d'autre que vous qui essaie le produit, puis qui reste ou qui part.
Tant que ça n'arrive pas, chaque fonctionnalité est une hypothèse posée sur une autre hypothèse.
Fuite ou vrai travail sur le produit : comment faire la différence ?
Le vrai travail sur le produit part d'une personne réelle. Quelqu'un a utilisé le produit, s'est heurté à un mur, vous l'a dit ou vous l'a montré par son comportement, et vous corrigez ce mur précis. La fuite part de personnes imaginaires. Vous imaginez un utilisateur qui voudrait ça, et vous codez pour lui.
Toute la différence : pouvoir nommer la personne à qui la fonctionnalité est destinée, et montrer le moment où elle en a eu besoin. Si la réponse est hypothétique (« un utilisateur pourrait vouloir exporter en CSV »), c'est une supposition.
Si la réponse est concrète (« trois des sept personnes qui l'ont essayé ont demandé le CSV la même semaine »), c'est du travail. Sept personnes, c'est assez pour agir. Zéro personne, ce n'est pas une version réduite de sept. C'est une autre catégorie, et tout le code du monde n'y changera rien.
Une fonctionnalité que personne n'a demandée n'est pas un progrès. C'est un pari posé sur la table avant que le moindre joueur s'y soit assis.
Empiler les fonctionnalités sans avoir d'utilisateurs
Empiler les fonctionnalités quand on a des utilisateurs, c'est un problème de discipline. Les empiler sans utilisateurs, c'est une façon de se cacher, et c'est pire, parce que ça ressemble à tout sauf à ça. Vous produisez. Le dépôt est actif. Le changelog est long.
Et pendant tout ce temps, le vrai point de blocage, amener un inconnu à regarder le produit, reste en plan, parce que c'est la seule tâche où il n'y a pas de code à écrire ni de moment net où c'est fini.
J'ai déjà refait une page de paramètres pour éviter d'envoyer cinq messages. Les messages m'auraient appris quelque chose. La page de paramètres ne m'a rien appris, sinon que je suis doué pour éviter d'envoyer des messages.
Si vous avez déjà réorganisé votre schéma de base de données un jour où vous vous étiez promis de prospecter, vous connaissez exactement cette sensation, et vous savez que ce n'est pas de la vertu.
Arrêter de coder, commencer à vendre : la règle qui tient
La volonté ne réglera pas ça, parce que coder fait vraiment du bien et vendre fait vraiment mal. Il vous faut une règle qui décide à votre place. Voici la mienne. Elle ne tient qu'en une ligne, et c'est voulu.
Aucune nouvelle fonctionnalité tant que N personnes du bon profil n'ont pas vu la version actuelle.
C'est toute la règle. Comment l'appliquer :
- Choisissez N et la personne. Petit et concret. Par exemple « vingt fondateurs solo qui font leur prospection eux-mêmes ». Pas un marché, une personne que vous arrivez à vous représenter. Si vous n'y arrivez pas, vous ne pourrez pas la compter.
- « Vu » veut dire utilisé, pas visité. Une page vue n'est pas une personne. Elle s'est inscrite, elle a cliqué partout, ou elle vous a regardé faire la démo pour elle. Ça, c'est un « vu ».
- La fonctionnalité actuelle est gelée tant que vous n'avez pas atteint N. Corriger les bugs qui empêchent de s'en servir, oui. Les finitions, les nouveaux écrans, la chose que vous brûlez d'envie de coder, tout est verrouillé.
- Quand vous atteignez N, vous lisez ce qui s'est passé avant de construire. Ce qu'ils ont fait, où ils ont calé, ce qu'ils ont demandé deux fois. Vous avez maintenant une liste de priorités qui ne sort pas de votre tête.
- Ensuite, et seulement ensuite, vous codez le premier élément de la liste. Et le compteur repart à zéro. La prochaine fonctionnalité attend le prochain N.
La règle marche parce qu'elle fait de la tâche inconfortable la seule tâche déverrouillée. Vous voulez construire, et le seul chemin pour y revenir passe tout droit par la prospection que vous évitiez. Ce n'est plus une question de volonté, c'est un verrou.
Là où un outil aide, et là où il n'aide pas
Vous pouvez appliquer cette règle dès aujourd'hui avec un simple tableur et votre boîte de réception, et vous devriez le faire, au moins jusqu'à ce que faire voir le produit soit la seule étape qui coince encore. Si votre problème, c'est que vous continuez de coder au lieu de livrer, aucun logiciel ne réglera ça. Le verrou ci-dessus est gratuit, et c'est toute la solution.
Le seul endroit où un outil sert vraiment, c'est l'étape deux, où « vu » doit vouloir dire que N vraies personnes ont réellement regardé. À la main, ça ne tient pas le volume. Une vraie démo pour une personne, c'est dix minutes, et vingt, c'est votre semaine entière. Alors ça tourne peu à peu à l'envoi générique que personne ne regarde.
C'est pour ce mur que j'ai construit Personade, ce qui en fait, oui, une chose de plus que j'ai construite au lieu de vendre. La différence, c'est qu'il existe pour vous remettre à l'envoi.
Il gère votre prospection sur LinkedIn : l'invitation, le message et les relances, envoyés depuis votre propre compte, et tout s'arrête dès que quelqu'un répond. Si votre message, c'est une démo, une option vidéo en plus donne à chaque prospect sa propre version, avec une introduction faite pour lui seul, et vous dit qui l'a regardée. C'est le signal « vu », compté pour vous.
Ce qu'il ne fera pas, c'est écrire la prospection, choisir votre N, ou transformer un produit dont personne ne veut en produit que les gens veulent. Ça, c'est toujours à vous de le faire.
Si vous voulez comprendre d'où vient ce changement, j'ai écrit sur pourquoi construire est devenu gratuit et vendre non, et si le problème de fond, c'est que vous avez complètement sauté la distribution, commencez plutôt par là.
Questions fréquentes
Faut-il ajouter des fonctionnalités ou se concentrer sur la recherche de clients ? Trouvez d'abord des clients, presque toujours. Une fonctionnalité ne vous apprend quelque chose qu'une fois que de vraies personnes ont utilisé le produit et vous ont montré où il casse. Sans utilisateurs, une nouvelle fonctionnalité est une supposition que rien ne vient vérifier. Fixez-vous une règle que vous pouvez tenir : aucune nouvelle fonctionnalité tant qu'un nombre défini de personnes du bon profil n'a pas réellement utilisé la version actuelle.
Comment savoir si je code pour éviter de vendre ? Posez deux questions sur la fonctionnalité. Pour qui est-elle, et quand cette personne s'est-elle heurtée au mur qu'elle corrige. Si vous pouvez nommer de vraies personnes et le moment exact, c'est du travail produit. Si l'utilisateur est hypothétique et que le moment est « un jour », c'est de la fuite. Un dépôt actif et un long changelog donnent l'impression d'avancer, mais ne mesurent rien tant que personne n'a vu le produit.
Quelle règle pour arrêter d'empiler les fonctionnalités sans utilisateurs ? Gelez le produit tant qu'un nombre fixe de personnes du bon profil n'a pas utilisé ce que vous avez déjà construit. Choisissez un chiffre petit et concret, comme vingt. « Utilisé » veut dire qu'elles se sont inscrites et ont cliqué partout, pas qu'elles ont visité une page. C'est seulement une fois le chiffre atteint que vous lisez ce qu'elles ont fait et que vous construisez la demande principale. Puis le compteur repart à zéro, et vous recommencez.
Les fonctionnalités dont vous êtes fier sont invisibles pour tout le monde sauf vous, tant que personne d'autre n'a de raison d'y toucher. Ce n'est pas un problème de code, et le code, vous savez déjà faire.
C'est la seule tâche sans moment net où c'est fini, et c'est exactement pour ça qu'elle perd à chaque fois contre celle qui en a un. Posez ce verrou cette semaine, et laissez-le décider.