Friday, March 27, 2009

Cash is not king

Cash on hand is just one important variable in a startup’s life, but it’s not necessarily the most important. What matters most is the number of iterations the company has left. While some cost-cutting measures reduce that number, others increase it. In lean times, it’s most important to focus on cutting costs in ways that speed you up, not slow you down. Otherwise, cutting costs just leads to going out of business a little slower.

The full formula works like this:

runway = cash on hand / burn rate

# iterations = runway / speed of each iteration

Very few successful companies ended up in the same exact business that the founders thought they'd be in (see Founders at Work for dozens of examples). Some aspects of the vision remain, but often in a significantly modified form. Unfortunately for the current crop of founders, there is intense pressure to engage in selective memory when companies tell the story of their founding. Journalists, PR firms, investors, and the public at large love a scrappy come-from-behind story about two guys in a garage who figured out how to take down Goliath. But the story usually features visionary protagonists who had it figured out from the start. Explaining that half of what these visionaries thought in their early years bordered on delusion tends to be a hard sell.

These successful startups managed to have enough tries to get it right. As a member of a startup, your incentive is to do everything possible to maximize the number of iterations you have left. What counts as an iteration? I believe it is a full, company-wide turn through the OODA loop (for a software business, see especially Ideas-Code-Learn). Minor experiments and variations don't count, although they are helpful. The key is to be able to refute as many major hypotheses as you can. We're talking PayPal-sized variations.

To increase the number of iterations you have left, you can either increase cash on hand (by raising money or increasing revenues), reduce burn rate, or increase the speed of each iteration. The most powerful changes you can make affect the speed of iteration. Even more powerful are costs that currently slow you down – by cutting those you can get the double-whammy benefit of lowering burn and increasing speed.

The key is to examine every cost through the lens of its effect on each stage of your learning feedback loop. Even if it helps optimize one stage, if it slows you down somewhere else, it might not be a net win.

The hardest costs to cut are those that are embodied in sacred cows. For example: we have to have strong documentation for our internal API's, else we might not be able to have third parties use them in the future; we can't afford to ship a low-quality product to our customers, because it might diminish our startup's brand image; we can't charge for our product until it contains Essential Feature X; we have to have a dozen managers sign off on every proposed feature, to protect the integrity of our product. Each of these might be good policies, at least for one stage of the feedback loop. Once they attain sacred status, they are rarely questioned. A crisis is sometimes needed to force that reexamination. In fact, every single lean transformation documented in books like Lean Thinking took place in the midst of serious external threats.

You cannot become a lean startup by willpower alone, any more than you can lose weight by going on a willpower-based diet. You need a process for systematically reviewing your costs and eliminating those that slow you down. In fact, the essence of many of the practices I have learned is to take systematic advantage of the power of crisis to spur creative thinking. This is why I constantly stress the need to set specific, actionable targets for new product initiatives or new feature split-tests. You cannot learn if you cannot be wrong, and vague goals are exceptionally easy to rationalize as success.

So how many iterations do you have left? What could you do to squeeze out one more, just in case your current plans don't pan out? For some specific suggestions, I recommend:
And, of course, there's the Lean Startup session at the upcoming Web 2.0 Expo, for those that are interested in discussing these topics in depth. As a reminder, you can come to the session (and a lot more) for free, courtesy of web2open.

9 comments:

  1. This comment has been removed by a blog administrator.

    ReplyDelete
  2. Thomas J. Watson Sr. was famously quoted by Charles Westrill as saying "Would you like the formula for success? Double your rate of failure." Until you did the math in this post I hadn't connected the dots between runway and rate of experimentation.

    I think it also applies to competitive situation where you have positive cashflow: you have to learn faster than your competitor(s) and that means shorter focused experimentation

    ReplyDelete
  3. great observation & summary. however, i think it's useful to contrast MAJOR iterations which may consist of non-intuitive leaps in product or marketing strategy from MINOR iterations which focus primarily on optimization of existing conceptual models.

    PayPal was fortunate to make several BIG leaps & changes in their models, one of which eventually resulted in runaway success (email & web e-commerce payments, primarily on the eBay marketplace). however contrary to the lean startup thesis you propose (which i tend to agree with a lot), i don't know that this success came from a philosophy of incremental & consistent iteration, but perhaps more of a random happening upon this model (combined with a lot of very smart people working extremely hard, and who also built very successful fraud models).

    in other words: i think your lesson is correct, but not sure the primary example you cite is necessarily a great example of the lesson.

    ReplyDelete
  4. @Dave - completely agree. My point with PayPal is not that they were a lean startup (I wasn't there; I do appreciate your account) but that they are an example of needing to do those big mountain-hopping iterations.

    Sometimes when people hear me talk about "built to learn" and continuous iteration, they think I mean linear optimization. Far from it. Linear optimization is a tactic, incremental improvements are a tactic, even mountain-hopping is a tactic. Lean startup is a strategy for deciding when, how, and what to do on the next iteration as fast as possible.

    Thanks for the thoughtful comment.

    ReplyDelete
  5. thanks for clarification & understood :)

    ReplyDelete
  6. But are you trying to maximize or minimize the number of major iterations? Too few represents stagnation. Too many represents frenetic activity. Most startups I've seen suffer from the latter, rather than the former. The pressure to innovate and try new things often overcomes the sober desire to execute to plan.

    ReplyDelete
  7. eric: if you haven't already read it, you may enjoy Throughput Accounting by Thomas Corbett. it's a bit of a dry read, but it serves as an excellent formalization of similar ideas through the lens accounting principles and the Theory of Constraints.

    ReplyDelete
  8. Great post and awfully hard to do. I am thinking of the Toyota system and adjusting the "big cogs" in the wheel and its relevance to enterprise software and services (i.e. what is/are the big changes that would signal that this is another iteration?).

    ReplyDelete
  9. oy, my nerd colors are showing...

    My first thought was: "Why did he comment out the 2nd formula?"

    # iterations = runway / speed of each iteration

    ReplyDelete