The Flight of the Startup

Six months into my latest startup I was getting confused. I live on a farm so I have plenty of time each day to listen to podcasts while shoveling, well…, shoveling. Among many topics, I listen to podcasts about startups. I have discovered 1) there is an ocean of information out there about early stage companies and 2) some of the information if flatly contradictory.

One theme emerged from everything I read and heard: capital efficiency. Navigating the risks and uncertainties of a startup is much likelier to be successful if at every stage you can work frugally. Because there are so many unknowns in a startup, experimentation is the order of the day. The more experiments you can run for a dollar, the more chances you have to survive.

As I like making sense of things, I tried to reconcile the contradictory advice. What finally helped me was to think of startups as going through distinct phases. Practices, principles, technology, and even values shift with the phases. The advice I was listening to was not actually contradictory, it just applied to different phases lumped into the word “startup”. The phases mirror the phases of an airplane flight:

1. Taxi–get in position.
2. Takeoff–apply power in one general direction until airborne.
3. Climb–manage steep growth at full power.
4. Cruise–make steady progress towards clear goals.

In this post I will outline the phases. In a followup, I will describe the differences in development style that characterize each phase and discuss how to manage the transitions between them.

Taxi

The first phase is finding an actual need. You can taxi for years, the twitch of your nose telling you that something is generally a good idea, but not having a need precisely enough identified to be worth applying full power to.

Taxiing took eleven years with JUnit Max. People were happily writing and running tests. I knew there must be a business in there somewhere, though. I tried lots of experiments to see if anything “clicked”. It was December last year that I had finally identified a need that seemed urgent enough that people would pay to have it met: staying focused on coding by reducing the time to get feedback from tests. This is a genuine need if you rely on extensive unit testing while coding.

In the taxi phase, breadth, speed, and, above all, cost of experimentation is the key. Try out ideas related to lots of different needs. Precision of feedback during the taxi phase is less important than trying out lots of different kind of ideas. The risk during the taxi phase is that you won’t find a genuine need. Address this by reducing the cost of experiments and running many of them.

Takeoff

Once you have identified a genuine need it is time to apply full power. The wide experimentation of the taxi phase reduced the risk that you would try to meet a need that wasn’t really a need. Just because you have a need, though, doesn’t mean you necessarily have a business. The takeoff phase is where you find the customers and revenue that underlie a business. The wheels are off the ground, metaphorically speaking, when you have a sustainable flow of capital, either by bootstrapping or by attracting investment.

Even with a great idea in a ripe market, the features that will induce customers to pay need to be discovered.In the takeoff phase the emphasis shifts from rapidly exploring the widest possible variety of concepts shallowly to concretely exploring products addressing a given need. Each experiment ends when you either achieve revenue or are reasonably certain that you won’t achieve revenue.

The step from enthusiastic potential customer to actual paying customer is huge. You need to know you have a market. In the takeoff phase you are willing to give up some cycle time to be certain of your feedback. The cycle in the takeoff phase is to release the tiniest possible products someone might pay for to see if anyone will pay (this is the elusive Minimum Viable Product). Modern software development and modern marketing increase the capital efficiency of the takeoff phase enough so you can afford to lower risk by trying several products. The advice I followed with Max (and that I hadn’t followed with several earlier ventures) was, “If you’re not embarrassed by the product, you spent too much on the experiment.”

(There is a school of startup thinking that suggests scaling first and monetizing later. I’ve never had the capital or the right idea to do this. If you are in this position, substitute “usage” for “revenue” above. On the other hand, if you really are in a position to defer revenue, you probably don’t need my advice for how to run a startup.)

JUnit Max is currently in the takeoff phase. We have enough revenue to know that we are meeting a genuine need, but not enough to bootstrap further. We’ll continue experimenting with products around the same theme, though, since we’ve already validated the first set of risky assumptions.

Climb

Once you have the core of a product that can generate revenue, the next phase is to climb rapidly so that your products actually does generate revenue. The climb phase stresses the technical and business parts of the organization. A marketing organization that only had to deliver a hundred leads to test an idea now needs to deliver a hundred thousand. A sales organization that only had to close a handful of sales now needs to close thousands. A technical organization that only had to build software good enough for a handful of customers now needs to build software that is good enough for any number of customers. The whole team needs to learn to listen to feedback from thousands or millions of shallow conversations as well as a few deep conversations.

Every day in the climb phase brings a new problem. Being able to put one problem to bed and prepare for the next is the key skill (if you let the problems pile up they will overwhelm you).

Capital efficiency shifts during the climb phase. You will have either revenue or investment coming in. Spend money solving problems. Capital efficiency in the climb phase is measured by how well you can spend money instead of just how little money you can spend. You still have a limited budget. The less you can spend to scale to the next order of magnitude in customer base the faster you can get to the next order of magnitude in customer base.

Cruise

One day you come to work and there isn’t a new problem. There are the same old problems, but those are problems you’ve learned to cope with. This is the transition from climb to cruise. The goal in cruise is still capital efficiency, but in the pursuit of profit instead of scale.

In the cruise phase it makes sense to begin making long-term/short-term tradeoffs. The unknowns have settled down enough by this time that discounted cash flow is a reasonable business measure again instead of measuring all business decisions by option value.

Cost reduction drives profitability in the cruise phase. Practices like developer testing that were useful in moderation in the takeoff phase and became a matter of survival in the climb phase now help increase profitability by reducing cost.

Conclusion

Once a product has gotten to the cruise phase, new spinoff ideas will start appearing requiring the flight of new little startups. The practices, technology, principles, and values will need to shift back to the taxi phase to give these little buds the best chance of survival. Surprisingly (to me, anyway), the flight of the startup model is just as valid for projects inside big companies in general. But that’s a topic for another day.

(BTW, this reminds me. There is no perfect technology for the takeoff phase. I want something that combines the ease of adminstration of AppEngine with the flexibility and power of a Smalltalk image. It doesn’t need to scale very far, just enough to get those first few dollars flowing. But building such a product would be another startup and I’m already rather busy…)

The four phases make sense of apparently-contradictory advice about startups. Paper prototype or minimum viable product? Taxi or takeoff? Penury or rapid growth? Takeoff or climb? Furiously add features or mercilessly refactor? Takeoff or climb? Invest for tomorrow? Have you reached the cruise phase? None of the advice is wrong, it is just underspecified. Knowing where you are in the flight can help you make the right move. Happy flying.