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:
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 full formula works like this:
runway = cash on hand / burn rate
# iterations = runway / speed of each iteration
# 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.
0 comments:
welcome to my blog. please write some comment about this article ^_^