A Lasting Model for Change: How the Lean Startup Was Born

Revolutions start by overturning the status quo. By the end of the 20th century, case studies, business plans, and conventional wisdom on early stage–startup methodologies had reached an evolutionary dead end for entrepreneurs. Here’s why, and what we did about it.

When I wrote The Four Steps to the Epiphany (Blank, 2003), over 2 decades ago, I had no idea I would be starting the Lean Startup revolution. Newly retired, with time to reflect on what I had learned from my eight startups and 21 years as an entrepreneur, I was struggling to reconcile the reality of my experience with the then common advice about how to start a company. Alone in a ski cabin with the snow coming down outside, and my wife and daughters out on the slopes all day, I started collecting my thoughts by writing a series of “lessons learned” stories that I had hoped would become my memoirs.

Eighty some pages later I realized that (a) I had some great war stories as a good marketeer and CEO, (b) I’d have to pay my wife and kids to read them, (c) the three of them were probably the entire available market, and (d) when I looked at what I had done and what other entrepreneurs had done at their startups, that there was a pattern.

I began to detect something deeper than I had ever seen before; there seemed to be a pattern in the midst of the chaos. Arguments that I had heard at my own startups seem to be repeated at others. The same issues arose time and again: big company management styles versus entrepreneurs wanting to shoot from the hip, founders versus professional managers, engineering versus marketing, marketing versus sales, missed schedule issues, sales missing the plan, running out of money, raising new money. After sitting on public and private boards, I enjoyed seeing other startups from an outsider’s perspective. I began to gain an appreciation of how world-class venture capitalists develop pattern recognition for these common types of problems. “Oh yes, Company X, they’re having problem number 43. Here are the six likely ways that it will resolve, with these probabilities.” No one was actually quite that good, but some VCs had “golden guts” for these kinds of operating issues.

Something about this bothered me in the back of my mind. If great venture capitalists could recognize and sometimes predict the types of problems that were occurring, didn’t that mean that the problems were common across startups, not just management screwups in individual startups? Wasn’t something fundamentally wrong with the way everyone organizes and manages startups? Wasn’t it possible that the problems in every startup were somehow self-inflicted and could be ameliorated with a different structure? Yet, when I talked to my venture capital friends, they said, “Well, that’s just how startups work. We’ve managed startups like this forever; there is no other way to manage them.”

It dawned on me that the pattern I was seeing was that investors, venture capitalists, and educators were all teaching entrepreneurs to use the same processes used in an established company. To be successful, you wrote a plan, raised money, and then executed to the plan, all in a very linear direction—just like launching a product inside a successful corporation.

My experience suggested that they were all wrong.

I started by asking: What is it that makes some startups successful and leaves others selling off their furniture? It occurred to me that startups were not smaller versions of large companies. Yet, the processes that early-stage companies were using were identical to that of large corporations. Every startup bringing a new product to market used some form of the Product Development Model shown in Figure 1. We now realize that it was one the causes of early startup failure. The product-centric model described a process that evolved in manufacturing industries. It was adopted by the consumer-packaged goods industry in the 1950s and spread to the technology business in the last quarter of the 20th century. It had become an integral part of startup culture.

OPEN IN VIEWER

Figure 1

Product Development Diagram

At first glance, the diagram, which illustrates the process of getting a new product into the hands of waiting customers, appears helpful and benign. The model is a good fit when launching a new product into an existing, well-defined market, where the basis of competition is understood, and its customers are known.

But few startups fit these criteria. Few had a clue what their market was when they first started. Yet, the product development model was used in startups not only to manage product development, but as a road map for finding customers, timing the marketing launch, and forecasting sales revenue. The model became a catchall tool for all schedules, plans, and budgets. Investors used the product development diagram in board meetings to see if startups were “on plan” and “on schedule.”

The reality was that everyone—investors, CEOs, their management team—was using a road map that was designed for a very different location, and they were surprised when they ended up lost.

When I looked at the diagram in that ski cabin, I realized there was a fundamental question I couldn’t answer: If all startups follow that model, why is it that some companies are opening bottles of champagne at their IPO while others who followed the same rules are selling off their furniture? What was the difference here? Were all startups the same? Were startups failing because of product failures, or was there some other failure mode? Is there any way to predict success or failure? And, more importantly, was there any way to reduce risk in early-stage ventures?

That day, alone in the cabin, I knew I had to find the answer.

Looking at the pattern of startups that survived their first few tough years, it occurred to me that they did not follow the traditional product-centric launch model espoused by product managers or the venture capital community. These successful startup survivors, through trial and error, hiring and firing, all had independently invented a parallel process to product development. In particular, the winners invented and lived by a process of customer learning, discovery, and iterative product development. It was a process that did not exist in large companies, which had existing customers, known markets, and established distribution channels.

I realized that founders of new ventures lacked an accurate definition of what a startup was, and that lack of clarity was hindering their ability to manage their new venture. Once I defined a startup as “a temporary organization, designed to search for a repeatable and scalable business model” the role of the founding CEO became clearer: Their job was to search for that repeatable and scalable business model.

And how they searched for a business model started with the unique observation that “all you have on day one is a series of untested hypotheses about your business model.” This statement expanded into the observation that “there are no facts inside the building, so get the heck outside.” This was a unique and critical insight. In a large company, there are a series of knowns: known customers, known customer needs, known distribution channels, pricing, costs, etc. But a startup? A startup begins with a series of unknowns, yet entrepreneurs and their investors had fallen into the trap that once a business plan was funded the only job of the founding team was to execute the plan. Even in the 20th century, most investors would tell you that “no business plan survives first contact with customers”—but no one had clearly articulated the reason. In an existing corporation, a business plan more than likely contained facts and the team simply needed to execute the plan. But in a startup, a business plan just contained hypotheses, and the team needed to search for information to validate those hypotheses.

This search process did not have a language to formally describe it, nor was there a common toolset others could use to repeat it. Yet, it was life and death for a new venture. I called this process “Customer Development,” a sibling to “Product Development.” The “Customer Development” model was a paradox because it was followed by successful startups, yet at the time was articulated by no one. Its basic propositions were the antithesis of common wisdom, yet they were followed by those who succeeded. It was the path hidden in plain sight.

I spent several years formalizing the Customer Development process and the concepts of Market Types, Minimal Viable Products (MVPs), and the Pivot. While it seemed obvious to me that startups needed to build their own management toolsets for searching for a business model, it was a pretty lonely couple of years convincing others. Over time, necessity—not investors, educators, or academics—drove adoption of the customer development process. The emerging Web, mobile, and cloud apps, which were being built with small teams using agile development, needed a much faster process to acquire customer feedback. This new generation of entrepreneurs were rapid early adopters of customer development. It helped them reduce the odds of failing—by getting them out of the building to get early customer feedback—as they built their product incrementally and iteratively. Simultaneously, venture capitalists recovering from the excesses of the Dotcom crash were looking for ways to more efficiently build startups and reduce their infant mortality.

After The Four Steps to the Epiphany was published, I began teaching the Customer Development process as a full-semester course at the University of California, Berkeley. A student in my first Berkeley class, Eric Ries, became the first practitioner and tireless evangelist of the process at his startup (IMVU), iterating and testing the process as I sat on his board. His insight coupled customer development to the emerging agile engineering practice, and together the two methodologies helped IMVU founders rapidly iterate their products, guided by customer feedback. From his experiences, Eric wrote The Lean Startup (Ries, 2011), which gave the movement its name and greatly expanded awareness.

Around the same time, Osterwalder and Pigneur (2010) introduced their business model canvas, which provided the customer development process with a much needed front end to organize all of a startup’s hypotheses into a simple framework that serves as a baseline and a scorecard for teams as they move through customer development.

These new ideas have coalesced into what has today become the Lean Startup movement. I was invited to teach at Stanford, where I turned the Lean Startup methodology into a series of new capstone classes: Lean LaunchPad, Hacking for Defense, and I-Corps. I-Corps has become the standard for commercializing scientific research in the United States. Variations of these classes are now taught in most major universities and in thousands of entrepreneurial programs around the world. Hundreds of books later, the core ideas of Lean are the canonical model of how startups are built. From its humble beginnings as the disjointed thoughts of a retired entrepreneur, who would’ve thought?