I’ve been spending Monday mornings by going to a different location (normally I work from home) and spending a couple of hours planning for the coming week. Today I spent those hours in a nearby library. I do this because I find that being at a computer is far too distracting and I start executing on whatever’s in front of me instead of planning.
My current goal is to build up enough revenue from my startups that I can support myself without doing any unrelated work. This is sometimes called default-alive or ramen profitable. For me that would mean making around $1,500 USD from my startups each month. Currently I’m only making between $200 and $400 per month, which I’m grateful for, but means I still have a ways to go before I can work on my own projects full-time.
Currently I have three broad categories of tasks when it comes to my startup:
- Build and launch a Narthbugz MVP
- Continue new feature development on TaskRatchet
- Build up a solid marketing process for TaskRatchet
So far I’ve found it challenging to balance these tasks, since any one could easily take up all my time, especially since I’m only working on these tasks part-time.
One way to help the situation is to increase my efficiency at these tasks. A week ago I decided that one way I could do that would be to increase my release cadence. I find it easy to get sucked down rabbit holes when I’m coding, where one feature task suggests a refactor task which then requires a dependency update which then requires debugging, etc, etc. A supposedly simple project then becomes a weeks-long tangled mess of interlocking and sometimes mutually-exclusive tasks.
The way I decided to address this was to aim to deploy code to production on average every day. I also added CI checks on several of my GitHub repositories to fail if the pull request got to be too large.
I’m using Beeminder to ensure I make progress on this change with this new autodialed goal:
https://www.beeminder.com/narthur/merge
Whenever I merge to main on my primary product repositories, GitHub actions posts a datapoint to this goal.
These changes addressed the velocity portion of efficiency. However, I won’t be efficient if I do quickly tasks that shouldn’t be done at all. So this morning I spent my planning time thinking about how I could do better at choosing the tasks that would be most effective in helping me reach my goal.
The first thing I thought about was doing split testing. I spent quite a bit of time thinking about how I could implement split testing in my codebases.
As I was thinking about this, I started thinking more about some of the ideas from the book The Lean Startup I read a few years ago. One of the ideas from the book is this cycle:
I’ve been thinking about how I could expand this slightly by adding a prediction step:
I like this version better for two reasons:
- It explicitly incorporates prediction as a step to avoid some of the distortions that can occur when you only interpret the results after the fact.
- Using the term “execute” instead of " build" broadens the scope of applicability to, for example, marketing.
This also reminds me of Cal Newport’s system of career experiments–I can’t find where he’s talked about it right off. May have been from one of his books. But he talks about building a career by creating small public projects and then learning from the feedback he gets on them.
So this week I’d like to put into place a system to start increasing the quality of my learning as I build these services. My hope is that following this process will allow me to make better predictions and understand the problems I’m solving better.
Here are the steps I’m thinking to take:
- Create a Notion database and template for tracking each cycle.
I’m thinking that each cycle will have its own page in the database. The template will have a heading for each stage in the cycle–predict, execute, learn, and measure. Each page will also have properties to track which startup it relates to and my estimated progress through that cycle as a percentage or decimal between 0 and 1.
- Create a Beeminder goal called narthur/spins to ensure I stay consistent.
The goal will be autodialed, with a minimum rate of 0.1 per day. I’ll add data manually. Whenever I work on a cycle, I’ll update my progress property on the page. Then I’ll take the difference between the previous progress and new progress and add that as a decimal value datapoint on my spins goal.
We’ll see how things go!