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:
- The fundamental startup feedback loop: Implement/Measure/Learn (a version of the OODA Loop).
- Customer Development: a disciplined approach to finding out if there is a market for your product before it’s too late.
- Customer Development Engineering: techniques for accelerating your product development.
- Getting started with split-testing and the one-line split-test.
- A checklist of practices in the new Joel Test for Startups.
- Work in small batches.
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.
(Image source: chapelwoodstudents.com)
