Developing for the Flight of the Startup
I recently described the Flight of the Startup, dividing startups into four phases, modeled on the phases of an airplane flight:
- Taxi–discover a genuine need by cheaply and quickly experimenting with concepts
- Takeoff–discover a market by cheaply and quickly experimenting with concrete micro-products achieving real revenue (substitute “usage” for “revenue” if working a “scale then profit” strategy)
- Climb–scale the organization and technology to attract and serve a large customer base
- Cruise-scale profits by reducing costs while expanding the market
One implication of the model is that startups in different phases require different development practices, principles, and technologies. This post outlines the practices implied by the business needs of each phase.
Taxi
The startup begins by identifying a real need. Ideas are cheap. The assumption that someone wants what you want to build, is the biggest and riskiest the startup will face. Test it first. Test it by iterating rapidly with a wide variety of concepts. Collect rough feedback. At this point you just need to know if anyone is interested at all.
Capital efficiency dictates that the experiments are dirt cheap. Most will fail (that is, produce the positive result that no, this isn’t a product people are interested in). Save every cent you can to expand your portfolio of experiments.
The best development in the taxi phase is no development at all. Paper prototypes, index cards, compelling story telling–all of these trump slinging code for capital efficiency and cycle time. All the clever tricks with AdWords come to the fore in the taxi phase. For $100 you can find out which of different sets of keywords spur people to action. If you can run a hundred AdWords experiments in the time it would take to code one prototype, you are that much more likely to survive.
I read Bill Buxton’s Sketching User Experiences and Alan Cooper’s About Face with a bit of puzzlement. “Why are they so afraid of code?” I asked myself. The Flight of the Startup model helped me make sense of their advice. Rapid paper prototyping makes perfect sense when you are taxiing. Cooper, in particular, suggests staying strictly on paper much longer than I think is wise for capital efficiency, but in the taxi phase both books provide valuable suggestions.
Takeoff
Once you have identified a need, it is time to identify a market. Who is going to pay for what? While a successful taxi phase results in a genuine need, only some of those prospects who said, “Sure, what a great idea! I love it! When can I have one?” will actually pay for what you can imagine building. Here’s another one of those vital assumptions–is the percentage 50%, 10%, 0%? Will they pay by the month, the transaction, or just once? How much? The only way to know for sure is to make products that actually meet a bit of their need and charge them for it.
Developing during the takeoff phase requires thoughtful speed. The products have to be good enough to provide real value to pioneering customers so they can give you genuine feedback. In the takeoff phase, any more engineering than necessary to close the feedback loop, though, is waste. Careful construction of a feature so it can be maintained for decades doesn’t make sense when 90% of features don’t last a week. Sometimes tests and refactoring help speed the feedback loop, but sometimes not. You will have to exercise judgement in your engineering practices to maximize capital efficiency.
Climb
A successful takeoff phase results in a small but promising revenue stream. Now the organization has to learn how to attract and serve an exponentially growing user base while remaining capital efficient. Part of the changes are organizational–you will likely need more people and a wider variety of skills. Part of the changes are to the product–increasing virality, for example, is capital efficient marketing.
As a programmer, though, I will talk about the development changes needed for a successful climb. The climb phase puts stress on all aspects of development. Servers overload. Deployment stalls. A growing development organization loses the ability to coordinate its activities.
The automated tests that were only employed if they sped the takeoff feedback loop become a matter of survival in the climb phase. Activities that were infrequent enough to be done manually now need the speed and consistency of automation. Refactoring to isolate and address bottlenecks becomes essential. Since the external world is supplying so many surprises, climb development needs to focus on eliminating all possible sources of variation under the control of development.
The extreme financial constraints of the first two phases relax slightly in the climb phase. You still don’t have the money to engineer far in advance of your actual needs, but you can now make financial tradeoffs. Would a little more investment stabilize the servers? Would a consultant be able to quickly address an issue? Buying tools (a topic dear to my heart) becomes sensible in the climb phase.
Cruise
One day, and it does eventually happen, the organization finds itself dealing with the same old problems instead of scary new problems. This initiates the cruise phase. The goal of the cruise phase is to increase profits by steadily decreasing costs while still expanding revenue. Here is where the entire panoply of XP principles and practices shines.
Long-term/short-term tradeoffs make sense in the cruise phase. Should you write an automated test in the cruise phase? If it will reduce the cost of maintenance, then sure. Should you refactor to increase modularity and reduce defects another 10%? Sure.
Transitions
There is a whole book to be written about transitioning between the phases. I’ll outline what I’ve observed briefly for now.
The basic problem is attachment. You learn to trust whatever made you successful in a phase. “Paper prototyping attracted our initial team and prospects? I know what to do next: more paper prototyping.” The principles and practices essential for success in each phase are fatal in future phases. Paper prototypes that don’t confirm actual revenue leave the startup exposed to the risk of having no paying market. Rapidfire feature introduction during the climb phases can destabilitze systems already near their breaking point. Continued expansion after growth slows endangers profits.
I differentiated the phases to be able to decide effectively which practices to use. “Yes, this is a really good thing to do, but not right now.” The topic that stimulated this whole line of thinking for me was the question of automated testing. I blogged about how some tests didn’t meet business needs in the takeoff phase. Much sound-biting ensued, “Kent Beck says ‘no’ to testing” (BTW, if you are writing a sound bite, go for accuracy first, brevity second). I didn’t say don’t write tests. I said write tests in the takeoff phase only when they increase your rate of experimentation. The fundamental principle is to match the development style to the business needs. One day you won’t need many automated tests, the next day you won’t survive without them.
Challenging hidden (sometimes cherished) assumptions is part of the romance of engineering in a startup. Far from spoiling engineers by turning them into “cowboy coders” or “bean counters”, startup survival requires a broader view of engineering, an understand of where technology decisions fall in the stream of value, a flexibility in applying basic principles in novel circumstances to address critical business needs. Sounds like fun to me!
This is a great analogy and I have enjoyed both articles here. Thank you for your insights.
My question is what does “Developing during the takeoff phase requires thoughtful speed” really mean? You advocated that building features optimized to maintainability of decades is wasteful because 90% of those features won’t survive, but was is an acceptable level of maintainability? Do you have a metric for measuring that or is it completely dependent on each project and therefore relies upon the experience of the team and their judgment?
My concern is that the debt list from corners cut during the take off phase could become so cumbersome during the transition to the climb phase that it could risk killing the viability of the product. How much time would you give to the transition phase and perhaps that could be a metric for measuring to meter the amount of debt incurred?
Appropriate engineering for takeoff is a tough thing to pin down. If your product really takes off you’ll have money during climb to pay off the technical debt. If your product is only moderately successful, then climb isn’t so stressful and you’ll have time to pay off the technical debt. If your product fails to take off, then you don’t have the problem at all.
The fundamental question is whether your engineering style is meeting the business needs of the current phase. If it is, you’re good. For now. When the time comes to transition, though, you need to transition. That’s the failure mode I see out there–cowboys keep slamming all kinds of features during climb. The resulting instability kills the product, not because of legacy code, but because of ongoing changes made with inappropriate engineering principles and practices. I’d like to hear stories to the contrary, though.
Thanks for blogging on this topic, Kent. I’m in the taxi stage of a startup right now and your posts are helping me sort through the experience.
David,
I’m glad you are finding it helpful. I invite you to come back and comment later about your experiences.
[...] off, Kent Beck has been exploring the phases in the life of a startup. The earliest stage is proving the idea. He later asserted that when you’re doing stuff like [...]
[...] Max, just not in the same way that is appropriate for more mature products. Just as there are different engineering principles and practices for products at different stages, there are different marketing principles [...]
[...] a technology. But skipping the writing of tests to drive my design was pretty helpful. Consider Kent Beck’s flight metaphor. Doing a Rails Rumble is just like the taxi-ing phase. Or a minimum valuable product. Either way, [...]
I manage a self-help organization for boostrapping startups called Agile Entrepreneurs.
Your model of Taxi, Takeoff, Climb & Cruise mirrors our analogy of Freshman, Sophomore, Junior & Senior – and better yet, your definition matches almost exactly with ours!
Very refreshing to see your blog on this subject. I feel it validates our chosen model for the pursuit of entrepreneurship
1. Freshman (Validation) : get VALIDATION of the Product / Business Model
2. Sophomore (Launch) : Launch the Product and get live customers/users using it
3. Junior (Cash Flow & User Acquisition) : User Acquisition while maintaining positive Cash Flow (either organically through revenues or via external investment)
4. Senior (Profits & Growth) : Growth in Customers/Users and Revenues – while remaining Profitable
Hi Kent!
I admire your ability to tackle any side of development and come up with some extremely interesting insights. Thanks for making them public!
I have helped teams into agile practices for the last couple of years. Over the past 18 months I have been fortunate to coach 15-20 teams in a large organization going Agile. When I read your blog about the phases of a startup and the analogy with flight, I realized it was also the answer to one of the things I have been thinking about.
Considering a particular team as a startup, or rather applying the analogy to a team or an organisation, helped me understand some of the phenomenons I saw there. E.g. increasing the frequency of pair rotation did not always help. In some cases it was detrimental to the evolution of the team. Such a team could sometimes show better progress if pairs where not rotated at all.
There’s the Shu Ha Ri and the Dreyfuss models, and we talk about Learning Organisations. But probably organisations can’t learn, they can only perform, though on different levels. Only people can learn. So when we transition an organisation, the key is to help the people learn and change.
I think there is a whole story, or even a book, about what works and what doesn’t, and why, in the taxiing, taking off, climbing and cruising phases of an agile team or organisation.
Do you mind if I borrow this analogy when I speak, blog, coach, write and teach Agile?
You are absolutely welcome to use the flight model. I hope it, whatever the vocabulary, becomes part of the common understanding of software development.