This is part of a series of posts about lean startup.

If you hang out in startup circles like I do, then you may have heard of the "Learn Startup" methodology. The most famous principle is probably the one that says one should validate an idea before building the product. Even if you haven't heard of it, you may have encountered bits and pieces of it, e.g. people who launch landing pages that describe a future product and then convince you to subscribe to their newsletter to stay up to date, or the principle of building things iteratively.

I am currently building out a new business idea, and I've found that it's quite challenging to organize my thoughts because of the sheer number of factors involved. In an effort to seek tools to help me organize my thoughts and to give me new insights, I decided to check out the Lean Startup methodology more closely.

Steve Blank's free course at Udacity

I've found that there are multiple variants of the methodology. I'm not so concerned about which one is the "one true" way (I don't believe in such a thing), what matters more is that one should fully understand the concept and adapt it to one's own situation and mental organization. So I picked a course that is low-cost and seems fun to enroll in: Steve Blank's free How to Build a Startup class at Udacity.

In this blog post I will summarize what I've learned, explain what new insights this class has given me, and talk about future research and blogging directions.

Why Learn Startup?

Most startups fail because they run out of money. The reason why that happens is most often because they fail to find product market fit. First come up with an idea, then build it, then launch it, then sell it. And then finding out that nobody is interested.

Many people build startups using traditional business building paradigms, e.g. the traditional MBA curriculum. Make a business plan, then execute it. But this traditional paradigm is meant for a time when consumer demand and competitors change a lot slower than they do nowadays. The paradigm is also meant for existing, large businesses. This latter point is very important.

A startup is not simply a smaller version of a large business. Whereas a large business executes an existing business model, a startup is a temporary organization that is in search of a scalable, repeatable and profitable business model. The strategies and tactics involved are very different. And a startup's goal is not to stay a startup forever, but to become a real business.

If you build it, they won't come

For startup founders it is tempting to come up with a "brilliant" idea, then build the "perfect" version of it and then launch it. But you don't know what customers truly want. Often times customers don't know that themselves either. Build-launch-sell is essentially the waterfall model, and we already know that that doesn't work because requirements change so often. Building a startup should be an incremental process, where you keep your eyes and ears open on what customers want.

It doesn't matter how well you build something, if you don't build the right thing. No business plan survives first contact with customers.

Structured, validated learning

Building incrementally is by itself not enough. The startup must also learn from customer feedback and mistakes. Unfortunately, many startups lack a structured process for learning, and so learning devolves into ad-hoc methods which are hard to repeat and hard to scale in the organization. Many startups also didn't prepare sufficiently, and so when things don't work out they have no idea what went wrong or what they can learn from it. The Lean Startup methodology describes a process for structured, validated learning.

Interesting key ideas

The methodology has many key ideas, but I find several of them especially worth mentioning before summarizing the actual methodology steps.

Customer discovery before validation

You may have heard of the need to validate customers and ideas. True, this is important, but turns out there is something before that: customer discovery.

Validation requires that one starts with a hypothesis that's reasonably close to the target. But if you're too far off, then you learn nothing from validation besides that it went wrong. To find that initial set of reasonably valid hypothesis, one must discover problems. See also: The Problem with Problems.

Talk to customers, don't use surveys, don't rely too much on statistics/data

Don't perform mental exercises and think too hard. Don't even stare too hard at statistics and data. There are no facts inside your building, only hypotheses. There is only one way to discover problems: get out and talk to customers, tons of them.

Interview customers instead of sending them surveys. Surveys are great if ask the right questions, but when starting out with customer discovery you probably don't know the right questions. Interviews give you a lot more freedom to discover and give you a lot more insights.

Do not build for the mainstream

Startups should not build for the mainstream.

In existing businesses, the traditional product management process is to collect requirements for all customers, then prioritize them and hand them to engineering. This process is rational, but should not be adopted by startups because startups lack resources. Even if you know the requirements for all customers, building a product using this process takes so long that the product will be obsolete on arrival.

The book Crossing the Chasm states that new products are are adopted by innovators and by early adopters (for the sake of convenience, let's refer to both groups as "early adopters"). The Lean Startup methodology states that in the beginning, you should focus only on the early adopters. You don't have the resources to build for the mainstream, and you don't know the mainstream well. But early adopters are the "crazy people" who buy into your vision and who are willing to accept your MVP.

Target early adopters because they give you the funds and intelligence necessary to target the mainstream later.

This idea is very important. I've been trying a while to collect information on what problems people have in order to validate my business idea. But I've found that a lot of people are reluctant to talk to me or even to refer me to the right people, unless I already have a product on the market. At this point it is tempting to just launch something just so I can talk to more people, but Lean Startup tells me to ignore these people (the mainstream) and to try harder to find people who are interested in helping me. It's okay if this group of early adopters are small because you're supposed to use them to reach the mainstream later.

What is an early adopter?

What are early adopters? They are people for which all of the following hold:

  1. They have a problem.
  2. They understand that they have a problem.
  3. They are actively searching for a solution.
  4. The problem is so painful that they've assembled a homegrown solution.
  5. They have a budget to acquire a solution.

I did not expect 4 to be part of the checklist. It makes sense because if they have a problem but haven't tried to solve it then evidently the problem isn't painful enough. But won't the homegrown solution compete with your product? Sometimes it might, but that's not necessarily a bad thing. This customer is happy with his homegrown solution but others may not be; not all customers are good at making solutions. If anything, the existance if a customer who has made a serious homegrown solution is evidence that a market exists, i.e. there are other fish you can go after. Steve Blank documented such a story on his blog.

See also Who Are Early Adopters by Customer Development Labs.

The Lean Startup methodology in a nutshell

The methodology consists of 4 phases:

  1. Customer discovery.

    Define a set of hypotheses about the market and the customers, and think about ways to prove or disprove them. Then talk to customers to test the hypotheses, to gain insights about the problems and to test whether the solution one had in mind is viable. Such sessions are aided by problem/solution presentations and lo-fi prototypes, but the emphasis is still on getting customers to talk to you. Adjust hypotheses as you gain more insights. At the end of this phase, one ends up with strong hypotheses and either decides to pivot or to proceed.

    I have written more about this phase in a dedicated blog post.

  2. Customer validation

    Having strong hypotheses is not enough. In this phase, one performs more rigorous tests of whether the strong hypotheses are true and whether the resulting business model is repeatable and scalable. This is done by selling a product pitch. In the process of doing so, one not only tests whether customers are serious, but one also gains insights about monetary issues (e.g. acceptable pricing, who controls the budget) as well as insights necessary for building a sales roadmap. Adjust hypotheses if necessary, and decide whether to pivot or to proceed.

  3. Customer creation

    This is the start of actual business model execution. Build the product, then use sales and marketing strategies to drive customers into your sales funnel.

  4. Company building.

    This is were the Lean Startup methodology ends and where we turn into a real company.

I will soon blog about each phase in more detail.

Resources

The information in this blog post was constructed from the following resources:

Future research and blogging directions

This is part of a series of posts about lean startup.