Iteration = Time to Learn, Not Time to Build

My team at Kromatic and I originally published this post here on Grasshopper Herder, our lean startup blog. Kromatic's mission is to help companies get to market fast and reduce the cost of innovation. Subscribe to our newsletter or speak to one of our coaches to see if we can help you reach your innovation goals.

Burn rates are meaningless in isolation.

We should remind ourselves that iteration time is a critical aspect of starting a new business, and there are a few key misconceptions that we may have been guilty of:

• Our burn rate is the amount of money we’re spending each month.
• Iteration time is the amount of time it takes us to deploy a new version of our product.
• Runway = Cash on hand / Burn rate

These are just wrong. Or at the very least, not useful.

Ready for takeoff?

Traditionally our runway is the amount of time we have to get our company to positive cash flow, a.k.a. takeoff. Once we run out of money, the game is over.

Runway = Cash on hand / Burn rate

(This is a known formula, but I pulled this expression of it from Eric Ries’ excellent blog post, which makes all the points in this post much more eloquently.)

What is our actual burn rate?

Our burn rate is the amount of money the company is spending each month, but this is an inaccurate representation for many startups. Very often, we ignore the opportunity cost.

People need to eat. Personal expenses are part of our burn rate, regardless of whether or not we’re marking an IOU in the company books.

Furthermore, there’s a lot of money that we could be earning instead of working on our unpaid startup. Even if we’re funemployed, we could be earning loose change working at Burger King. Those are our opportunity costs.

When trying to make a decision as to how much effort we’re going to put into our company, the potential rewards of our company need to be weighed against the costs. If we are miscounting those costs, we might be sinking a lot of effort into a bad decision when we could be landing a cushy job pushing buttons in a box somewhere.

To be completely clear, even if our cash burn rate is $10 a month for hosting services our actual burn rate is much higher. Our time is valuable!

Similarly, our cash on hand is the cash from any source that we’re using against the burn rate. So if we’re burning savings, that’s our cash on hand even if that cash is not in the company bank account.

Don’t make bad decisions by ignoring money we’re investing month by month.

A better way to think of Runway is:

Runway = Time remaining / Iteration length

If we only have 30 days cash on hand but can iterate once per day, we’re in a far better position than a company with six months of cash that takes 6 months to build its product.

In fact, the company that has six months of cash on hand and just manages to build its product in that time has zero iterations because it has neglected to budget time to get users and feedback.

Time to learn

Iteration cycles are not just the amount of time it takes to deploy code to the server (or for a physical product, the amount of time to create a new version of that product).

The most important thing for a startup is to discover a repeatable business model, not deploy code or create products. So the point of our first few iterations is not necessarily to sell the most units (although that’s certainly a good sign), but to learn as much as possible about the business model in the least amount of time. Pushing code to the server is not learning.

In order to learn anything, we have to get the product in front of enough customers to get a meaningful amount of information. In addition, a decision must be made on what action to take for our next iteration.

In other words, we must complete the entire Build Measure Learn loop.

So, if we need statistical information about user behavior and push code to the server every day, but we only get 150 visitors a week, the iteration time is minimum eight days. Not one day.

Similarly, if we push code to the server every day and get 1,000 visitors a day but take two weeks to make a decision because the executive product management panel has to debate, then our iteration time is 15 days minimum.

Focus on bottlenecks

As a result of misinterpreting iteration time, we might focus on the wrong things at the wrong times.

The most typical example of this is spending six months building a product when there is no confirmed demand. After six months of building, not a single customer has seen the product. Iteration length? Infinite.

We might then go out and raise a seed round based on a prototype. (Note: Amazingly, this can sometimes be done without any evidence of customer demand, since there are no facts or metrics to prove that the product won’t work. Investors can be just as dumb as entrepreneurs; we shouldn’t take blind investment as a sign that we’re on the right track.)

Our startup now has enough cash to last another 6–12 months and hire another few engineers to speed up the iteration cycles. Why? Because a faster engineering team will get to market faster with the perfect product. Real iteration length? Still infinite.

A lack of metrics is the ultimate bottleneck

I have personally been involved in three startups that have failed to measure progress against objective reality. I have measured the wrong thing; I have not measured at all. It is beyond embarrassing.

Even when it’s a simple thing to do, sometimes metrics are an afterthought in the build process.

This is a killer.

Because even if we’re pushing to live customers daily and people are occasionally buying the product, we are learning nothing!

How do we know they like it? Are they using the product after they purchase it? Perhaps they buy it and then think it sucks. Or do they simply not know how to install it? We will never know unless we have metrics.

Quality counts

When searching for metrics, it’s important to realize that qualitative data is still data and can be turned into useful information. Customer development interviews can produce very valuable feedback even when there is no product.

One of our best successes with customer development was performing 51 iterations on our startupSQUARE site design using nothing but Photoshop. We don’t need to spend four months building an internal analytics system to get data. We don’t even need one line of code.

If we really want to reduce our iteration time, we should set an objective to get real customer feedback twice per day. Use real information and real text, and put mockups in front of real customers.

Check out these resources for additional information on gathering qualitative data through user research.

My team at Kromatic and I originally published this post here on Grasshopper Herder, our lean startup blog. Kromatic's mission is to help companies get to market fast and reduce the cost of innovation. Subscribe to our newsletter or speak to one of our coaches to see if we can help you reach your innovation goals.