Lean Startup is a method for creating and sustaining innovation in all kinds of organizations. It helps you get good at answering two critical questions:
- Should we build this new product or service?
- And how can we increase our odds of success in this new thing?
When you know those answers, you can reduce unnecessary failure and instead focus your time and money on ideas that have promise. The Lean Startup method is equally useful in brand-new companies, Fortune 500 enterprises, government agencies, educational institutions, and non-profit organizations. Although it has roots in the tech sector, it is not for tech alone and has been used profitably for nearly every kind of product or service you can imagine — from diesel turbines to middle-school math classes.
That sounds great, right? It is. But there’s a lot of confusion over what Lean Startup is, how it works, and how you can apply it. Herewith, a rundown of the essential ideas to clear things up and get you started. (From here on out, when I talk about products, I mean it as a catchphrase that includes products of all kinds — digital or physical — plus services or processes that an organization creates to sell to or serve customers. Those customers can include co-workers, or what people sometimes call internal customers.)
You say the method works for established organizations. Why is the method called Lean Startup?
The word “startup” often brings to mind an image of two people working in a garage in Silicon Valley. But there’s a more useful definition laid out by Eric Ries, who coined the term Lean Startup: “A startup is a human institution designed to create a new product or service under conditions of extreme uncertainty.” I’ve emphasized the last two words, because I want to underscore that in this definition, what determines a startup are the unknowns a new product faces — not the age, size, or sector of the company.
In other words, in Lean Startup terms, a startup is a group of people working on a risky new product, even if that group of people works for Exxon or the US Marine Corps.
With that definition in mind, there are three areas in which a startup typically faces a very high degree of uncertainty — or risk:
1. Technical risk, also known as product risk.
You could think of this as the question: Can we build this thing at all? For example, if you’re seeking a cure for cancer, there’s a big risk that you’ll fail to find it. If you do find it, you’ll certainly have customers, so there’s no market risk.
2. Customer risk, also known as market risk.
This is the question: If we build this thing, will people use or buy it? Put another way: Should we build this thing? The story of Webvan illustrates this risk: At the turn of the millennium, the company spent $1 billion to build a series of high-performance warehouses and trucking fleets on the assumption that people would buy groceries online. Although it was technically possible to offer groceries online and deliver them to homes, customers weren’t interested in the service at the time, and Webvan folded after a couple of years and a lot of investor dollars down the drain.
3. Business model risk.
This amounts to the question: Can we create a way for this thing to make us money? Strong business models aren’t always obvious. For example, you know Google as a company that makes a lot of money selling search-related ads. But when the Google website launched, it wasn’t obvious that ad sales would become the killer business model, and it took a number of years before they hit on that approach.
Want more product insights? Sign up for our newsletter
If you’re wondering which kind of risk you face, let me help you out: It’s customer risk. Nearly always, it’s the biggest question, because you simply don’t know the value, if any, your new product has for potential customers. When I say, “Nearly always,” I mean: This is so often the case, you should assume it’s true every time.
The tricky part is that commonly, product risk looks more urgent. After all, if you’ve hit on an exciting new idea that you’re pursuing, you’re doing so because you believe other people will be interested in it, too. And if you assume the demand will exist, you’ll be tempted to make sure you can build the product before you offer it to people. But that’s a very big assumption, and many, many startups have failed after building cool stuff, because they relied on a framework of inaccurate assumptions about how customers would behave. Good news: There’s no reason you should put time and money toward a belief you haven’t proven. Below, I’ll talk more about assumptions and how you can avoid repeating a doomed history like Webvan’s.
Note that when you think in terms of risk, rather than company history, it becomes clear that lots of existing organizations have startups within them. For instance, if you’re Gillette and you add a 5th blade to your iconic razor, you have no risks: the product, the market, and the business model are all known. But Gillette’s parent company, Procter & Gamble, has R&D teams looking at new methods for hair removal. For those new ideas, everything is unknown. Which means the teams working on them are startups.
Incidentally, the biggest company we know of that’s systematically applying Lean Startup methods is GE. One of the world’s largest companies, GE has trained 7,000 managers around the globe in Lean Startup principles and has used the method to improve outcomes on things like diesel engines and refrigerators.
What if I face product risk and customer risk?
Attack the customer risk first. When the founders of Litmotors learned that the vast majority of car trips involve one person going just a few miles from home, they set out to make a new kind of car that would be more efficient for these kinds of rides. Based on a two-wheeled motorcycle chassis, their prototype looked pretty funky and had a new technology that kept it stable. While they were testing the technology, the chief technology officer (CTO) had a personal emergency and had to leave the company for an extended period.
Unable to pursue the prototype tests without the CTO’s expertise and unable to replace him, the remaining team realized they could reduce their customer risk ahead of their product risk, so they finished a showroom model that didn’t actually run and offered it for presale. The results astonished them: Nearly 16 percent of people who came in to see the non-working model put down money to buy one — adding up to dozens of pre-orders in a very short time. Here’s CEO Danny Kim telling the story at the Lean Startup Conference.
That’s an encouraging story because the company was able to find customers. You can easily imagine a story in which they prove the technology works, then get the vehicle government-approved for sale, then build a terrific manufacturing and distribution system for it — each step of which takes months or years and great expense — and then discover that nobody wants to buy a two-wheeled car. (Indeed, that’s pretty much the story of Segway.)
By guiding you to answer the question, Should we build this?, the Lean Startup method helps you avoid the spectacular and unnecessary failure of building a perfect product that nobody buys.
Why Lean Startup? Is this method for small budgets only?
The word “lean” usually brings to mind cheap or bootstrapped (i.e. self-funded) companies — and possibly Lean Cuisine. So it can be daunting if you think you have to build something with tons of unknowns on a ridiculous shoestring budget, and maybe you have to eat frozen diet meals along the way. Good news: you can — and should — let go of those ideas. Lean is not about cheapness.
What lean actually refers to is Toyota’s lean manufacturing revolution. For Toyota, “lean” didn’t refer to the money available but instead to a narrow focus on producing value for customers and eliminating everything else. This is surprising, so I’ll repeat: Lean is about focus.
In manufacturing, the business Toyota is in, the value you can provide is fairly clear: Customers want a product that’s assembled correctly. But for most startups, as we discussed above, your value to customers is unknown.
When you marry a focus on customer value (the lean part) with an extreme uncertainty about customers (the startup part), it becomes clear that learning what customers want and will pay for is your biggest priority. It’s the thing you want to do most quickly and effectively.
What’s an MVP? I’ve heard the term, and it has a nice ring to it.
We’ve just established that learning quickly what customers want and will pay for is the key activity in startup 101. An MVP, or minimum viable product, is a tool that helps you do that. Specifically, an MVP is an experiment that helps you validate — or often invalidate — a theory you have about the potential for a new product or service. (Even though an MVP is often a stripped-down version of your product, it’s different from a prototype, which is intended to test a product itself and usually answers design or technical questions.)
The minimum concept is key because, in order to move quickly and definitively, you want your experiments to include only features that help you test your current theory (also known as a hypothesis — or what you think will happen when customers come into contact with your product). Everything else is not only a waste of time and money, but can also cloud your results. The viable concept is key, too, in that this thing has to actually produce test results you can learn from, which means it has to work on some meaningful level for customers. The classic example here is that if you’re trying to test the demand for a new service, you might do that by putting up a one-page website where people can pre-order the service before you’ve spent any time developing the actual thing or hiring people to make it happen. By the same token, if you’re testing a hypothesis around customer use of a new jet engine, then you have to make sure it will fly safely — in order for it to be truly viable, or feasible.
I’ve also heard the term customer development. Where does that fit in?
After you’ve identified your assumptions, the first test you run is often customer development — a term coined by serial entrepreneur Steve Blank — also known as talking to people. In other words, you do qualitative research by interviewing potential customers to learn more about their needs and behaviors in your product’s area. At this stage, you’ll likely discover, as startups commonly do, that your basic idea holds little appeal for your target customers, or that a key assumption about customers’ needs was simply wrong. Excellent. You’ve just saved yourself thousands of dollars and months of time. When you start consistently hearing the same thing from potential customers about their needs — and you have an idea about how to meet those needs — then it’s time to start running tests with a version of your product to validate (or invalidate) your idea.
For example, Fashion Metric had an idea for an app that would let clothing shoppers get feedback from a stylist on items they were thinking of buying. Before building even an MVP, the founding team went to stores in three cities and asked clothing shoppers about their greatest shopping problems. Not a single person mentioned a frustration that could be solved with Fashion Metric’s original idea. But the team did hear over and over that men had a hard time finding dress shirts that fit properly. Fashion Metric took that info and built a landing-page MVP to test a custom-shirt concept (a landing page), and then went from there. Here’s CEO Daina Burnes Linton telling the story at the Lean Startup Conference.
You use MVPs early and often to test out assumptions you have about your new product, thereby reducing the risk that you’ll spend time and money building the wrong thing. In the Lean Startup method, assumptions are unproven beliefs you have about why your plan will work — for instance, a belief that people will pay for your new product, or a belief that they’ll use it at all.
An MVP is central to what people call the build-measure-learn loop, which mimics the scientific method but tests business ideas rather than, say, theories of evolution. The process generally looks like this:
- Identify your assumptions
- Home in on the assumption that carries the biggest risk
- Determine how to test your assumption, often with a version of your product designed for this purpose — the MVP itself
- Figure out your hypothesis about the MVP
- Run the test
- Review the results
- Incorporate the results into your next test
- Iterate — also known as lather, rinse, repeat or, simply, do it all again — this time incorporating the new information you’ve collected
On the front lines of entrepreneurship, there’s a lot of haziness about what MVPs really are, how they work, or whether they work at all. Nearly all of the confusion stems from focusing on the MVP and ignoring the other steps in the build-measure-learn loop. You can rise above the fray and get useful results by making sure that your MVPs are embedded in the larger process.
For instance, if you make sheet-metal screws, and you suspect there’s demand for a new kind of wood screw you’ve designed, your biggest risk might be whether your wholesale distributors will sell it to retailers for you. You have a hypothesis that two out of three distributors will get on board — enough to get the screws to market. To test the theory, you create a brochure that your salespeople use in conversations with distributors (important: you do this before you’ve created the screws themselves). If your salespeople are able to close enough deals for the screws, you’ll have solid information saying you should actually develop the product. In discussing this case, a lot of people would focus on the MVP in the story, which is the brochure. But that undercuts the nature of the process, which is not meant to help you churn out printed marketing material but is instead meant to help you learn whether your assumptions about your distributors were right. If you keep that in mind when you’re slinging around MVP ideas in your company, and you include a lot of discussion of hypotheses, you’ll be miles ahead of your competitors. (Here’s some more info from Eric on MVPs.)
Speaking of hypotheses, the most effective ones are usually quantitative. That’s because they give you a clear way to see whether your assumptions were right (i.e., people will spend at least three minutes per page reading articles on our new site; or, one of ten sales calls in the next month will lead to a signed contract for our new product). The basic structure for a hypothesis looks like this: “I believe [customers like this] will [behave like this] in [this measurable way]. “Validating a hypothesis” means you’re running experiments that prove it true; “invalidating a hypothesis” means your experiments are proving it false. Ben Yoskovitz has a clear write-up on how to craft a useful hypothesis.
When you create a hypothesis, it can be around either the value potential or the growth potential for a product. A value hypothesis tests whether a product delivers value to customers once they’re using it, whereas a growth hypothesis tests how new customers discover a product. The usual mechanisms for growth are viral, sticky, and paid. We’ll discuss them in a future piece, but in the meantime, check out this post from Eric and this one from David Link.
Can you give me another MVP example?
Sure. If your publishing company is thinking of putting out a coffee table book in the United States about cooking with insects, you might reasonably identify a big risk: Will anybody buy this thing? You know you can produce such a volume; in fact, you can pretty much apply all of the processes you already use for publishing lavish books of themed cake recipes for minor holidays. But, despite a recent New York Times piece on the bright future for insect-based cuisine, you haven’t been able to find a community of bug-eaters to test your idea with.
Here’s one way to find out if enough people will buy the book for you to get past break-even costs: Go ahead and publish it. Commission the writer and photographer, assign an editor to develop the book with them, find people to test the recipes, get a copyeditor to review the final text, have production people layout the pages and correct the photos, hire a freelance indexer, get a pro to proofread the whole thing, and then ship it off to China for printing (and probably send a production expert to oversee the run). Oh, and your salespeople have to make sure bookstores will stock it, and your marketing and PR people will have to make sure readers know it exists. From the time you decide to find out if anybody will buy it to the time you’re able to actually test the idea using this approach is approximately two and a half to three years. Not to mention upwards of $200,000 in staff time and hard costs.
Or, you could MVP it with a full build-measure-learn loop. First, create a hypothesis. Based on your experience and any data you have available, make an educated guess at how many sales you’ll actually make on this book. Next, work with a writer to create a blog and attract a readership. Then, offer the book for pre-sale to those readers (which you can do before you’ve put even ten seconds of effort into creating a print volume), and thus test your hypothesis. Total time elapsed? Two to six months, and, as a bonus, the readers test the recipes for you. Note that this isn’t a free process. You may have to pay the writer and photographer, and perhaps you’ll spend some money on training the writer to use blogging software and social media tools that help them build a following. Generously, it might cost you $20,000. In other words, you could test ten book ideas for the cost of publishing one. And because you can run your tests simultaneously, you could learn in several months — rather than over the course of a decade — which ideas are worth investing more in.
What’s a pivot?
Let’s say you’re running lots of experiments, which is great. But your experiments are mostly invalidating your ideas, which is deflating. The good news is that in the Lean Startup method, you have a new move: You can pivot. A pivot is a change in strategy, based on what you’ve learned so far. They’re super-common in startups, even though the stories about them aren’t always well known. For example, YouTube started as a video-dating site. When the dating part didn’t take off, the company pivoted to focus on video sharing, which seemed to hold promise.
Pivots come in many forms. You might shift your product focus, as YouTube did, or you might realize that the product you’ve envisioned appeals to a very different set of customers than those you’d originally guessed. You might learn that the channel through which you’d planned to sell won’t work, but that another channel is a strong option. Etcetera, etcetera. This Forbes piece has a nice rundown of common kinds of pivots.
You can tell you’ve pivoted successfully when your new experiments are overall more productive than the old ones, which is a sign that you’re more closely aligned with your customers. Here, Eric discusses pivots in depth.
Where do metrics fit into this?
Glad you asked. First, let’s get clear that the word “metrics” is just a fancy term for measurements. Metrics often include things like the number of new customers in a certain time period, the number of customer visits (or other activity) per day or month, and the amount of revenue generated in a defined time period. Metrics are important because, as I noted earlier, quantitative information is key to really learning where you stand with customers. But not all metrics are created equal, and for startups, there are two kinds you need to know about: actionable metrics and vanity metrics.
Actionable metrics — those you can make meaningful decisions around — measure specific customer behaviors and patterns. For example, average revenue per customer tells you a lot about your value to customers. Even better, it lets you test features and other aspects of your product to determine whether what you do can increase the number. To really understand the impact of your actions on your customers, startups often measure them in groups, generally called a cohort analysis, in which you compare the behavior of a subset of your customers against another subset you’ve treated differently. Cohorts are most commonly defined by when they become your customers, so, for example, you might compare new customers from June and new customers from July — when you offered all new customers a coupon to try your premium service — to determine whether your average revenue per customer has gone up.
Vanity metrics, on the other hand, are broad measurements that are appealing to look at but don’t tell you anything meaningful about your value to customers. For example, it’s fun to watch your number of Twitter followers increase or to focus on how much total revenue you’ve taken in. But Twitter followers aren’t necessarily customers, and gross revenue without contextual information doesn’t tell you whether you’re looking at sustained growth, scattershot injections of cash, or customer behaviors you can affect.
One key way to home in on meaningful metrics is to recognize that, in a startup, your most important activity is gathering information to reduce unknowns — not meeting product-development deadlines or driving sales. For most of us, that’s a huge shift in focus, and it’s difficult. If you’re a leader, this idea is central, because you have to establish and look for appropriate signs that your new-product teams are learning about whether they’re providing value to customers and building on what they’ve learned. If you revert to deadlines and profit, which you’ll be tempted to do, you’ll sink your young ships.
For example, Facebook might not exist today if the company had tried to generate revenue at the outset. When the site first started, it was for college students, and it didn’t yet have ad sales. But the founders suspected they were onto something interesting because, each time they gave a new school access to the site, a spectacularly high percentage of students would sign up in a very short time. In addition, those students spent an unusually long time on the site, and they came back frequently. None of those metrics had to do with revenue initially, but they helped Facebook recognize that it was creating value for students and that it had ways to grow.
Metrics and learning milestones vary a lot based on your products and hypotheses, and we’ll talk more about them in future posts. In the meantime, here’s Eric’s cornerstone post on actionable vs. vanity metrics, and here are two ways to tell you’re moving in the right direction with any product:
- You cycle through the build-measure-learn loop much, much more rapidly over time. You go from six months to roll out one MVP and analyze it, to three months, to one month, to one week — and you learn more in the shorter rounds as you get better at formulating hypotheses.
- Your team starts to make decisions based on the data you gather, not on job titles.