Patrik
Wise words of the week
“Productivity is not about doing more; it’s about doing what is meaningful.”
— Adapted from continuous improvement philosophies (or Seneca’s “To be everywhere is to be nowhere.”)
Journal
After a few weeks of fixing issues and core refactorings, it’s good to be back to feature development.
Prioritizing the features to implement is key and we have two powerful strategies for it.
First, our own high-level roadmap. It lets us bucket tasks in a very coarse way:
- v0.7, works for 2 users: all the features Marc and I need to use the tool, with a focus on the computation engine. UI was pretty much non-existent and consisted of importing the results into a spreadsheet, but it answered our questions and validated a few hypotheses about the product.
- v0.8, works for 20 users: this is whatever is needed to support 20 early users; lots of work on our side is still manual as we don’t want to build something nobody needs. We automated input and output through the spreadsheet with Google Apps Script. Yet due to the tool limitations and this being a (throw-away) prototype, there was still a lot of manual work due to missing documentation and missing features. The manual work here is acceptable: the number of users is limited and we need the high touch to collect as much feedback as possible.
- v0.9, works for 200 users: scaling up, this means that most of the key features are implemented and most of the workflow is automated. The key features here are a simple web UI instead of a spreadsheet, and automating the payment flow with Stripe. A big problem is the missing documentation, because it hits us with user support requests. Our solution here: I answer the technical questions; Marc collects the responses and uses them to generate the documentation.
- v1.0, works for 2000 users: fully scalable workflow without our interaction. All key features are implemented.
We are currently at v0.9.4. I’m working on the 5th iteration which will include more events as requested by our users, remove some sources of friction in the product, and add more automation.
The other strategy for prioritization is obviously user feedback. It’s a mix of handling blocking problems, features that everyone wants, and features that are obvious to implement because I’m already working on that part of the system.
And as I already said in FIP Journal #2, scarcity breeds clarity. Having limited time naturally forces some prioritization. Needless to say, everything takes at least twice as long as planned.
How did I use AI this week?
This week was a pure execution week, so I’m just using the tools as I already described. I kept using Cursor’s Plan mode extensively. I’m mostly happy with it, I can catch more issues in the plan than having to amend them in the code.
As the plans become larger, I need to be careful not to become too complacent and just wave through whatever the AI suggests without a good review, because this causes problems later when they are more costly to fix.
I already started having two levels of reviews. The core engine is important to me, so I review the code extra carefully, down to the coding idioms, because I’m on the hook to maintain it. For the frontend I’m much more relaxed for two reasons: this code is less critical and the UI seems to be doing better here, but also I think the frontend is probably more short-lived and after v1.0 we will probably look at some radical improvements in the UI. Also some previous experiment showed that I can ask the AI to re-generate the complete frontend and it actually works.
Friends and colleagues keep arguing about which model is the best, and a trustworthy friend described it like this: Claude is currently best for non-engineers, while Codex is better suited for people with an engineering mindset. Or Marc pointing at a podcast arguing that HTML will replace Markdown because it makes handling plans easier. But these are all problems I don’t want to care about: I just want to ship my product and I’m wondering why this is even a problem: AI is great at classification, so how come it cannot decide for me which model is best for my request?
Marc
The build
Now that Patrik finalized the AHV/AVS fixes and refactoring, I jumped back, full steam, into Discovery and Onboarding of waitlist members.
Discovery: as discussed in a previous Journal issue, I use the Jobs to Be Done (JTBD) framework for this part. It helps me uncover the forces behind people who subscribe to FI Planner, and those who hesitate or do nothing.
I wanted to have our final demo video available (see here on the homepage if you’re curious, it’s about 1min), as well as the last discovered bugs fixed, in order to deepen some discussions. In fact, some of them were expected to convert new clients. Which happened, so I’m glad we waited.
Most of the learnings we got around the product and pricing weren’t new, and reinforced what we learnt with previous users and clients. I’ll continue to gather those insights over the next months (making sure to fully understand the job to be done behind the request), before changing something too fast based only on 2-3 users. That said, we may get the same feedback on a feature or pricing, but for different reasons. Also, such feedback can come from a heavy user, or from a churned user. Again, different motivations.
Onboarding: we’ve invited 21 new waitlist members on Wednesday. Two did sign up (thanks!), and we wait for the weekend to see if more do. We know what our price tag is, and that it’s an investment in one’s own FI journey.
Our plan is now to onboard 20 new waitlist members every Wednesday, which allows us to keep gathering 1-1 feedback, all while remaining a Calm Company (read: not working nights and weekends!)
As always, if you’re really interested in using FI Planner, send Patrik or myself an email, and we will bump you up the list.
The edge
As I had more time to spend on FI Planner this week, I fully felt that startup mode that I love so much… but which is not that easy when you’re in the thick of it.
My brain looked like this last Wednesday:
- “OK, so I’ve about 20-30 emails to answer for our Discovery phase”…
- “But I also need to onboard 20 new waitlist users…”
- “Ah, and there is this new design idea that I wanna implement on the simulation results… well, that’s what, 10min…? Hmm but be honest Marc, you’ll also wanna tweak/test/iterate with Claude Design super powers, so that’s gonna end in a 4h session…”
- “Gosh, and I wanted to test a new pricing scheme with a specific potential client…”
- “And so on and so forth… argh!”
- “And what time is it by the way? Ah… already 6pm, kids time! ^^”
Note to a friend
Wanna prioritize product requests from users? Then use my mental model that resembles this:
- Job, not feature (aka regroup by struggling moment, not the requested solution)
- Who says it (aka regroup by segment)
- Behavior > Statement (aka, for pricing, ask for a real commitment before implementing this or that new payment scheme)
- Error cost (aka, if we were to implement it now, is it reversible or not? If not, gather more feedback. If yes, and seems smart, try it)
Tool of the week
I’m a big fan of productivity tools and frameworks. Think GTD or Things or Bullet Journal.
But nowadays, with AI, I feel I could merge all of this + my email + my calendar -> into a single system. And I’ve found 1-2 “courses” that offer this.
I know it may be the “new fancy system” that appeals to me, but after digging into it, it could revolutionize the way (and time!) I spend prioritizing and grooming my todos.
It’s just that I don’t have the time for it, and I fear it will have to wait until this summer, when I have more free time / holidays to play with it. Patience!