Patrik
Mots de sagesse de la semaine
“La productivité, ce n’est pas faire plus; c’est faire ce qui a du sens.”
— Adapté des philosophies d’amélioration continue (ou Sénèque: “Être partout, c’est n’être nulle part.”)
Journal
Après quelques semaines à corriger des problèmes et à faire des refactorings de fond, ça fait du bien de retourner au développement de fonctionnalités.
Prioriser les fonctionnalités à implémenter, c’est essentiel, et on a deux stratégies puissantes pour ça.
D’abord, notre propre roadmap de haut niveau. Elle nous permet de regrouper les tâches de façon très grossière:
- v0.7, fonctionne pour 2 utilisateurs: toutes les fonctionnalités dont Marc et moi avons besoin pour utiliser l’outil, avec un focus sur le moteur de calcul. L’UI était quasi inexistante et consistait à importer les résultats dans un spreadsheet, mais elle répondait à nos questions et validait quelques hypothèses sur le produit.
- v0.8, fonctionne pour 20 utilisateurs: c’est tout ce qu’il faut pour prendre en charge nos 20 premiers utilisateurs; beaucoup de travail de notre côté est encore manuel, parce qu’on ne veut pas construire quelque chose dont personne n’a besoin. On a automatisé les entrées et les sorties via le spreadsheet avec Google Apps Script. Mais vu les limitations de l’outil et le fait que c’était un prototype (jetable), il y avait encore beaucoup de travail manuel à cause de la documentation et des fonctionnalités manquantes. Le travail manuel est acceptable ici: le nombre d’utilisateurs est limité et on a besoin de ce contact rapproché pour récolter un maximum de feedback.
- v0.9, fonctionne pour 200 utilisateurs: on monte en charge, ce qui veut dire que la plupart des fonctionnalités clés sont implémentées et que la majeure partie du workflow est automatisée. Les fonctionnalités clés ici, c’est une UI web simple à la place d’un spreadsheet, et l’automatisation du flux de paiement avec Stripe. Un gros problème, c’est la documentation manquante, parce que ça nous tombe dessus sous forme de demandes de support utilisateur. Notre solution ici: je réponds aux questions techniques; Marc récolte les réponses et les utilise pour générer la documentation.
- v1.0, fonctionne pour 2'000 utilisateurs: workflow entièrement scalable sans interaction de notre part. Toutes les fonctionnalités clés sont implémentées.
On est actuellement en v0.9.4. Je bosse sur la 5e itération, qui va inclure plus d’événements demandés par nos utilisateurs, supprimer certaines sources de friction dans le produit, et ajouter plus d’automatisation.
L’autre stratégie de priorisation, c’est évidemment le feedback des utilisateurs. C’est un mélange de problèmes bloquants à gérer, de fonctionnalités que tout le monde veut, et de fonctionnalités évidentes à implémenter parce que je bosse déjà sur cette partie du système.
Et comme je l’ai déjà dit dans FIP Journal #2, la rareté engendre la clarté. Avoir un temps limité force naturellement une certaine priorisation. Inutile de préciser que tout prend au moins deux fois plus de temps que prévu.
Comment j’ai utilisé l’IA cette semaine?
Cette semaine, c’était de la pure exécution, donc j’utilise juste les outils comme je l’ai déjà décrit. J’ai continué à utiliser le mode Plan de Cursor à fond. J’en suis plutôt content, je peux repérer plus de problèmes dans le plan que je n’aurais à en corriger dans le code.
Comme les plans deviennent plus grands, je dois faire attention à ne pas devenir trop complaisant et à ne pas juste laisser passer tout ce que l’IA suggère sans une bonne revue, parce que ça crée des problèmes plus tard, quand ils sont plus coûteux à corriger.
J’ai déjà commencé à avoir deux niveaux de revue. Le moteur de calcul est important pour moi, donc je relis le code avec un soin extrême, jusqu’aux idiomes de code, parce que c’est moi qui devrai le maintenir. Pour le frontend, je suis beaucoup plus détendu, pour deux raisons: ce code est moins critique et le rendu de l’UI semble meilleur ici, mais aussi je pense que le frontend est probablement plus éphémère et qu’après la v1.0, on regardera sûrement des améliorations radicales de l’UI. En plus, une expérience précédente a montré que je peux demander à l’IA de régénérer tout le frontend et que ça marche vraiment.
Des amis et des collègues n’arrêtent pas de débattre pour savoir quel modèle est le meilleur, et un ami de confiance a résumé ça comme ça: Claude est actuellement le meilleur pour les non-ingénieurs, tandis que Codex est mieux adapté aux gens avec un état d’esprit d’ingénieur. Ou Marc qui renvoie à un podcast soutenant que le HTML va remplacer le Markdown parce que ça rend la gestion des plans plus facile. Mais ce sont tous des problèmes dont je ne veux pas me soucier: je veux juste livrer mon produit, et je me demande pourquoi c’est même un problème: l’IA est super douée pour la classification, alors comment se fait-il qu’elle ne puisse pas décider pour moi quel modèle est le meilleur pour ma requête?
Marc
Côté produit
Maintenant que Patrik a finalisé les corrections et le refactoring de l’AVS/AHV, j’ai replongé à fond dans la Discovery et l’Onboarding des membres de la waitlist.
Discovery: comme évoqué dans un précédent numéro du Journal, j’utilise le framework Jobs to Be Done (JTBD) pour cette partie. Ça m’aide à comprendre les forces derrière les gens qui s’abonnent à FI Planner, et ceux qui hésitent ou ne font rien.
Je voulais que notre vidéo de démo finale soit dispo (regarde ici sur la page d’accueil si t’es curieux, ça dure environ 1min), ainsi que la correction des derniers bugs découverts, pour approfondir certaines discussions. En fait, certaines d’entre elles étaient censées convertir de nouveaux clients. Ce qui est arrivé, donc je suis content qu’on ait attendu.
La plupart des enseignements qu’on a tirés autour du produit et du pricing n’étaient pas nouveaux, et ont renforcé ce qu’on avait appris avec les utilisateurs et clients précédents. Je vais continuer à récolter ces insights au fil des prochains mois (en m’assurant de bien comprendre le job to be done derrière la demande), avant de changer quelque chose trop vite sur la base de seulement 2-3 utilisateurs. Cela dit, on peut recevoir le même feedback sur une fonctionnalité ou un prix, mais pour des raisons différentes. Et ce feedback peut venir d’un gros utilisateur, ou d’un utilisateur qui a résilié. Encore une fois, des motivations différentes.
Onboarding: on a invité 21 nouveaux membres de la waitlist mercredi. Deux se sont inscrits (merci!), et on attend le weekend pour voir si d’autres suivent. On sait ce que vaut notre prix, et que c’est un investissement dans son propre parcours vers la FI.
Notre plan, c’est maintenant d’onboarder 20 nouveaux membres de la waitlist chaque mercredi, ce qui nous permet de continuer à récolter du feedback en 1-1, tout en restant une Calm Company (comprendre: ne pas bosser les soirs et les weekends!)
Comme toujours, si t’es vraiment intéressé par FI Planner, envoie un e-mail à Patrik ou à moi, et on te fera remonter dans la liste.
Ce qui tiraille
Comme j’ai eu plus de temps à consacrer à FI Planner cette semaine, j’ai pleinement ressenti ce mode startup que j’adore tant… mais qui n’est pas si simple quand t’es en plein dedans.
Mon cerveau ressemblait à ça mercredi dernier:
- “OK, donc j’ai environ 20-30 e-mails auxquels répondre pour notre phase de Discovery”…
- “Mais je dois aussi onboarder 20 nouveaux utilisateurs de la waitlist…”
- “Ah, et il y a cette nouvelle idée de design que je veux implémenter sur les résultats de simulation… bon, c’est quoi, 10min…? Hmm mais sois honnête Marc, tu vas aussi vouloir bricoler/tester/itérer avec les super pouvoirs de Claude Design, donc ça va finir en session de 4h…”
- “Mince, et je voulais tester un nouveau schéma de pricing avec un client potentiel précis…”
- “Et ainsi de suite… argh!”
- “Et au fait, quelle heure il est? Ah… déjà 18h, l’heure des enfants! ^^”
Note à un ami
Tu veux prioriser les demandes produit des utilisateurs? Alors utilise mon modèle mental qui ressemble à ça:
- Job, pas fonctionnalité (en gros, regroupe par moment de galère, pas par la solution demandée)
- Qui le dit (en gros, regroupe par segment)
- Comportement > Déclaration (en gros, pour le pricing, demande un vrai engagement avant d’implémenter tel ou tel nouveau schéma de paiement)
- Coût de l’erreur (en gros, si on l’implémentait maintenant, est-ce réversible ou pas? Si non, récolte plus de feedback. Si oui, et que ça semble malin, essaie)
Outil de la semaine
Je suis un grand fan des outils et frameworks de productivité. Genre GTD ou Things ou Bullet Journal.
Mais de nos jours, avec l’IA, j’ai l’impression que je pourrais fusionner tout ça + mes e-mails + mon agenda -> en un seul système. Et j’ai trouvé 1-2 “cours” qui proposent ça.
Je sais que c’est peut-être le “nouveau système à la mode” qui m’attire, mais après avoir creusé, ça pourrait révolutionner la manière dont je priorise et fais le tri dans mes todos (et le temps que j’y passe!).
Le truc, c’est que je n’ai pas le temps pour ça, et j’ai peur que ça doive attendre cet été, quand j’aurai plus de temps libre / de vacances pour jouer avec ça. Patience!