Startup Mom
A blog based on my experiences building ParentScheduler and Frever

How I iterate

About how I spend my time as a solo technical founder

17 Nov 2020, 4.5 minutes read

There is such a huge gap between theory and life. Even that understanding on it’s own is something that deepens and changes as you live it. If I may borrow from one of the greatest movies of my generation - there’s a difference between knowing the path and walking the path.

Reality has a quality that no thought or fantasy will ever have.

But on a more practical note - I thought it might be helpful if I described how I iterate. How I spend my time as a solo technical founder.


I’ve been working in Agile for many years. When it just started spreading, we got a short book about it at the team I was working on at the time. We each read it, wrote notes, shared and talked, and started implementing our own version. We really did build it from the ground up. Long before Scrum and Canban and all the other systems and flavours were around. And I have worked in several startups since. But oddly it is only now, working on my startup, that I feel I really understand it.

It might surprise some but if I think about it honestly I spend only about 20% of my time programming. What do I do the rest of the time? Decide what I should build next. How do I decide what to build? Do I have a road map (as I’ve been asked this week)? Not really. I found having a huge list of features and being set in my direction is actually not a great way for me to maneuver the startup. I have a vision. I have a clear goal. I have a starting point. From here I’m trying to learn as much as I can about what users want, as I described in my previous post, and based on these learnings I decide on the next step.

So loosely I can break it down to these steps. While I number them, this is a cycle and every iteration is rooted in the one before it. My cadence has naturally evolved to be about two weeks for a cycle, perhaps because I used to work in two weeks cycles as part of an agile team. They look a little bit like this:

  1. Build a feature. I try to keep in mind the question Adora Cheung mentions in this great talk about prioritizing your time - what is the thing that will have the most impact in moving the needle for my startup. I’m focusing on retention - what is the biggest reason users are not using my product today. Most features take me about two days to complete. More for the hard ones, less for the easy, and you don’t always know in advance which is which!
  2. Small marketing effort. I repeat - small. I am not looking to reach millions at this moment. I think this is a point that trips a lot of startups. You don’t want huge amounts of press before you know you built something people love. If I get a million downloads today it would be a waste. In order to learn I just need a dozen. Lean startup and then the YCombinator approach basically divides startups to 3 phases:
    1. Pre-launch - where you’re focusing on market research and defining your vision as well as your initial product you will launch.
    2. Looking for product market fit (this is where I’m at) - where you validate you have actually built something people want.
    3. Growth - where you want to start growing and become a successful company.
    Being in this phase means for me that I aim to get up to 10 new downloads a week and closely track engagement and retention. Which leads me to
  3. Hear what users are saying and track what they are doing. How many of my new users added the other parent or created a task \ activity? How many of them came in again the same week? How about the week after? You get the point. I use this data and feedback to find hints into what is the next thing I need to focus on. What is the important feature I should build next. See how we’re back at one?

At the beginning I tried to have more of a roadmap like we used when I was leading a team in GoDaddy. But it wasn’t right for my startup. The pace is so quick and if I’m too set on my idea it is harder for me to listen to what my users are saying and what the data shows they are actually doing. Like I described before, I try not to drift based on a random whim expressed by a user, but to keep a delicate balance of having a vision and finding a path to reach that goal. A little bit like hiking trying to find a path to the mountain top.

So here you have it. My very loose version of Agile and how I iterate. I’m sure it will change dramatically if and when the company grows. But this is what works for me for now.

Water is fluid, soft, and yielding. But water will wear away rock, which is rigid and cannot yield. As a rule, whatever is fluid, soft, and yielding will overcome whatever is rigid and hard. This is another paradox: what is soft is strong. —Tao Te Ching

Share on: