Patrik
Mots de sagesse de la semaine
Si tu n’as pas honte de la première version de ton produit, c’est que tu l’as lancée trop tard. — Reid Hoffman (fondateur de LinkedIn)
Le mieux est l’ennemi du bien. — Voltaire
Journal
Encore une semaine d’exécution. On passe en revue les retours géniaux de nos premiers utilisateurs et on ajoute les fonctionnalités manquantes.
Notre workflow actuel est très rodé. Dès qu’un retour arrive, on l’enregistre dans Linear (notre système de suivi des tickets). Parfois il y a déjà une entrée pour ça, et parfois c’est nouveau et ça part au triage.
Une fois par semaine, pendant notre sync hebdo, on passe en revue l’avancement de haut niveau (est-ce qu’on est dans les temps pour cette release, est-ce qu’on doit faire passer certains tickets directement en développement), et on classe les tickets en trois groupes: avant le lancement public, suivi rapide après le lancement public, un jour.
L’ingénieur en moi adorerait avoir tout fini avant le lancement public, pour avoir un lancement parfait. Mais la réalité, c’est que le produit doit être suffisamment bon, pas parfait. On peut toujours prioriser les fonctionnalités qui gênent nos utilisateurs en se basant sur les retours qu’on reçoit. Et c’est plus sûr d’utiliser les retours pour ajuster notre travail et le rendre utile.
À quoi servirait un produit parfait si personne ne l’utilise? Alors autant qu’il soit suffisamment bon et utile, plutôt que parfait mais inutile.
Comment j’ai utilisé l’IA cette semaine?
Si tu te souviens des derniers posts, j’utilise beaucoup le mode Plan de Cursor. Après la phase de lune de miel initiale où il était meilleur que le mode agent, c’est l’heure de râler un peu.
Le mode Plan reste génial. Je dis ce que je veux et je demande à l’agent de créer un plan pour ce qui doit être fait. Après quelques itérations et corrections, le plan est en général en bon état.
À ce stade, je commence à exécuter le plan (en général 3-8 todos). Cursor exécute le todo, je relis les changements dans le code. Parfois c’est super et je l’accepte, parfois je veux quelques corrections.
Alors, où est le problème? Comme d’habitude, c’est l’humain dans la boucle, le fameux PEBCAK (le problème est entre la chaise et le clavier). Ça se présente sous deux formes:
L’ennui ou le manque de patience. Exécuter une étape prend 5 à 10 minutes. Qu’est-ce que je devrais faire pendant ce temps? Idéalement, je pourrais faire des pompes ou prendre une pause. En réalité, lire mes e-mails ou surfer est plus probable. Ça veut dire qu’une fois que l’agent a fini de coder, je dois affronter un changement de contexte brutal et essayer de me rappeler ce que je faisais. Comme j’ai perdu mon contexte, c’est là que les erreurs et les oublis peuvent arriver.
L’aveuglement ou la saturation. Les agents sont bons pour créer du code. Beaucoup de code. La verbosité est intégrée d’office. Parfois c’est “pourquoi t’as écrit ces 3 classes identiques, tu peux supprimer la duplication de code”. Mais souvent, c’est juste l’IA qui est bien plus maligne que moi et qui couvre tous les cas limites possibles en créant 5 fois plus de code que je n’en écrirais. (Sauf que parfois, elle vérifie aussi des choses déjà couvertes par l’invariant du code). Malheureusement, mon cerveau n’a pas 5 fois plus de place pour ça, et comme je relis les mêmes problèmes encore et encore, j’ai tendance à devenir aveugle ou saturé et je finis par les ignorer ou simplement ne plus les voir.
C’est devenu douloureusement évident en vérifiant du code et en tombant sur des fonctions dont je n’avais absolument aucun souvenir. Je n’ai juste pas encore de solution pour ces deux problèmes.
Marc
Côté produit
Cette semaine a été plutôt riche en nouveaux clients, ainsi qu’en découverte de besoins clients.
Nouveaux clients: à ce jour, dans notre dashboard Stripe, on a atteint CHF 4'498.92 de revenus récurrents annuels (ARR) (ouais! 🎉). Ça fait quelque chose de regarder ce chiffre grandir semaine après semaine, et encore plus depuis qu’on onboarde de nouveaux clients par lots de 20 chaque semaine maintenant.
Pour être plus précis: oui, c’est cool de le voir comme une somme d’argent, je ne vais pas le nier. Mais ce qui est encore plus cool pour moi, c’est que c’est la meilleure preuve qu’on apporte une valeur concrète à nos clients FI Planner. Je suis reconnaissant d’avoir l’opportunité de suivre un tel parcours entrepreneurial, alors merci à chacun d’entre vous.
Besoin client: je vais me répéter, mais garder un état d’esprit JTBD dans chacune de nos conversations, c’est une mine d’or quand tu lances une startup. Cette semaine, on a découvert un besoin dont je ne savais pas que je le voulais moi-même: les scénarios catastrophe.
Un client nous a dit que, pour être vraiment (vraiment!) rassuré sur le fait qu’il pouvait décrocher du travail pour être FI, il aurait besoin qu’on simule des scénarios catastrophe. Et la confirmation qu’ils ne le mettraient pas en faillite.
Deux exemples:
- Je deviens FI. Le mois suivant, un scénario catastrophe type COVID-bis se produit…
- Ou, je deviens FI, et l’année suivante j’attrape une maladie qui nécessite une opération de CHF 75'000.
Inutile de préciser que ça a filé directement dans notre backlog parmi les fonctionnalités prioritaires à venir ;-)
Ce qui tiraille
Après avoir publié notre dernier numéro du Journal #8, j’ai réalisé que la numérotation de version qu’on avait partagée créait de la confusion.
Pour le moment, on est dans la phase v0.9 (= fonctionne pour 200 utilisateurs = on fait monter en charge nos systèmes pour que tout soit automatisé). Mais, du point de vue d’un client, ça peut donner quelque chose comme:
Hé mais attends, t’es encore en mode bêta? Genre, ça devrait être v1.x sinon, non?
Et ce client aurait entièrement raison!
Parce que, dans un sens, on parle de deux choses différentes ici:
- v0.9 est effectivement là où on en est, du point de vue de la roadmap produit interne
- Mais on est plus proches d’une v1.1 ou dans ce genre, du point de vue externe d’un client
Pourquoi? Parce que FI Planner est entièrement fonctionnel si tu l’utilises. C’est juste pour nous, les cofondateurs, qu’il reste encore quelques tâches manuelles qu’on doit faire à la main (comme la synchronisation des tags Kit et du statut de paiement Stripe).
Mais c’est cool, parce que a. j’ai appris quelque chose, et b. on a pu se réaligner aujourd’hui pendant notre session hebdo avec Patrik.
Comment on va résoudre ça? En clôturant la v0.9 encore en juin, et en passant à la v1.0 juste après!
Note à un ami
J’utilise beaucoup Claude Opus 4.8 pour m’aider dans la recherche et la discovery client.
Mais au lieu de capturer un e-mail client et de le balancer à Claude en demandant une réponse, j’ai trouvé une astuce qui marche encore mieux:
- Je reçois un e-mail client
- J’envoie une capture d’écran à Claude
- Je demande à Claude de me fournir 3 analyses/angles différents (en suivant le framework JTBD)
Résultat (comparé au simple fait de demander un brouillon d’e-mail), j’obtiens des idées bien plus qualitatives, et ça m’aide à m’assurer que mon jugement humain reste éveillé tout du long (vs. être fainéant et juste copier-coller/glisser-déposer des trucs).
Outil de la semaine
Le connecteur certifié Claude d’IBKR! Je viens de le brancher et de jouer avec. C’est un peu limité, vu que par exemple tu ne peux pas encore récupérer des trucs comme ta performance annualisée depuis l’origine, mais c’est génial d’avoir ces données disponibles directement dans Claude. J’ai hâte qu’ils y ajoutent plus d’outils.
Et ça a aussi fait germer de nouvelles idées sur la façon dont FI Planner pourrait évoluer à l’avenir, aussi!