The Lean Startup: Build-Measure-Learn Methodology

Created by Eric Ries - https://theleanstartup.com/

Overview

The Lean Startup is Eric Ries's method for building a new product or business when nobody yet knows whether customers want it. Ries defines a startup as "a human institution designed to create a new product or service under conditions of extreme uncertainty" (The Lean Startup principles), and the definition covers a team inside a large company as much as a founder in a garage. The lean startup methodology treats a business plan as a set of guesses. The team finds the guesses the business most depends on, tests them with real customers as cheaply as possible, and uses what it learns to decide whether to keep going or change course.

Ries first wrote about the idea on his blog in a post titled "The lean startup" in September 2008, then set it out in his book The Lean Startup, published in September 2011 (Wikipedia). He built it from his own startups. At IMVU, which he co-founded, investor Steve Blank insisted that the executives audit Blank's entrepreneurship class at UC Berkeley. Ries combined Blank's customer development process with ideas from lean manufacturing and lean software development (Eric Ries on Wikipedia). The 2008 post names agile development and "ferocious customer-centric rapid iteration, as exemplified by the Customer Development process" among its ingredients.

The engine of the method is the Build-Measure-Learn feedback loop. A team turns an idea into a product, measures how customers respond, and decides whether to pivot or persevere (principles). The product in the loop is usually a minimum viable product, which Ries defines as "that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort" (Minimum Viable Product guide). He stresses in the same post that an MVP is "not about creating minimal products" and that choosing one "requires judgment."

Progress is measured in validated learning, which Ries calls "a rigorous method for demonstrating progress when one is embedded in the soil of extreme uncertainty" (principles). Features shipped, hours worked and total signups can all rise while the business learns nothing. Innovation accounting is the discipline that keeps the team honest: pick actionable metrics, set a baseline, run experiments to move it, and judge each experiment against the baseline. Ries warns against vanity metrics, which he describes as numbers that "look good on paper but aren't action oriented," such as website hits or message volume (Beware of vanity metrics).

When the evidence says the current strategy is not working, the team pivots. Ries's definition is a "structured course correction designed to test a new fundamental hypothesis about the product, strategy, and engine of growth" (Wikipedia). A pivot keeps what has been learned. In his 2009 post he wrote that successful startups "keep one foot in the past and place one foot in a new possible future," while unsuccessful ones jump to a different vision and throw away the learning (Pivot, don't jump).

The method spread well beyond startups. Blank argued in the Harvard Business Review in May 2013 that it was beginning to replace the write-a-business-plan formula, and in 2012 the US Federal Chief Information Officer described taking a "lean-startup approach to government" (Wikipedia). Ries's book The Startup Way, released in October 2017, applies the same principles inside large companies. Some evidence supports it: a randomized trial with 116 Italian startups found that founders taught to form and test hypotheses performed better and were more likely to pivot.

The method has real limits. A review in The Conversation summarizes research showing that market experiments are expensive in fields like biotech, that showing an early product can disclose strategy where intellectual property is weak, that more validation is not always better, and that founders without market knowledge struggle to interpret the feedback. Teams that use it well treat it as one tool for high uncertainty. For teams that keep their method in Hamster, each skill below reads the hypotheses, experiments and decisions from one shared record.

Core Principles

Entrepreneurship Is Management

Ries lists "Entrepreneurship Is Management" as a principle because a startup needs a management system of its own (principles). Plans, forecasts and milestones built for a known business break when the customer and the product are both unknown. The lean startup replaces them with a routine of hypotheses, experiments and scheduled decisions. Without that routine, uncertainty turns into either chaos or false precision.

Validated Learning Is the Unit of Progress

A team makes progress when it has evidence from real customer behavior that a specific assumption is true or false. Ries calls this validated learning and defines it as a rigorous method for demonstrating progress under extreme uncertainty (principles). Shipping a feature counts only if it taught the team something about customers. This principle is what lets a team call a failed experiment a productive week.

Test the Leap-of-Faith Assumptions First

Every plan rests on a few assumptions that, if false, sink the business. Ries calls them leap-of-faith assumptions and makes testing them the purpose of an MVP (The Lean Startup). Dropbox's MVP was a short video of the product working, which tested whether people wanted seamless file sync before the hard engineering was finished (Ries on TechCrunch). Start with the assumption that would hurt most to be wrong about.

Plan the Loop Backward

The loop runs Build, Measure, Learn, but Ries plans it in reverse: "we figure out what we need to learn," then what to measure, then what product will produce that measurement (Ries quote). Planning backward stops the team from building something and then hunting for a lesson in the data. It also keeps each build as small as the question allows.

Measure With Actionable Metrics

Metrics should show cause and effect and lead to a decision. Ries's three A's say metrics must be actionable, accessible and auditable (Beware of vanity metrics). In practice that means cohort analysis, split tests and per-customer numbers in place of cumulative totals (Vanity Metrics vs. Actionable Metrics). A cumulative chart almost always goes up and to the right, so it cannot tell you whether the last change helped.

Pivot or Persevere on a Schedule

The decision to change strategy is emotional, so Ries recommends making it at a regular meeting. He writes that "less than a few weeks between meetings is too often and more than a few months is too infrequent" (Pivot or Persevere?). The meeting asks one question: is there enough progress to believe the current strategic hypothesis? A startup that never asks can end up in what he calls "the land of the living dead," neither growing nor dying.

Shorten the Time Through the Loop

Ries's slides put it plainly: minimize total time through the loop (RailsConf 2011 slides). It helps to count runway in learning cycles as well as in months, because each cycle is a chance to find a model that works. Anything that slows a cycle, from big releases to long approval chains, reduces the number of chances. Ries's pivot post makes the same point: faster iteration "increases the runway without additional cash" (Pivot, don't jump).

Steps

1. Write down the leap-of-faith assumptions Turn the vision into a list of statements that must be true for the business to work, covering who the customer is, what problem they have, what they will pay and how they will hear about you. Mark the one or two that are both most important and least supported by evidence. Ries calls these leap-of-faith assumptions and treats them as the first things to test (The Lean Startup). A one-page canvas can help, but the output is a short ranked list. Everything later in the method refers back to it.

2. Get out of the building Before building anything, talk to the people you think have the problem. Steve Blank's line is that there are no facts inside the building, and his classes require students to talk to 100 customers in 10 weeks (Blank on customer discovery). Ask about what people did the last time they had the problem, and keep your idea out of the conversation until late. The output is evidence that the problem is real, plus the words customers use for it. Assumptions that fail here are cheap to drop.

3. Turn assumptions into testable hypotheses Rewrite the riskiest assumption as a statement that a specific result could prove wrong. Strategyzer's Test Card uses four lines: "We believe that," "To verify that, we will," "And measure," and "We are right if" (Test Card). Write the pass mark before the test runs. If nobody can say which result would count as a failure, the hypothesis is not ready.

4. Choose and build the MVP Pick the cheapest artifact that can produce the evidence the hypothesis needs. That might be a landing page, a video, a service run by hand for a few customers, or one working feature (CRV on MVP types). Zappos began by photographing shoes in local stores and buying them at full price only after a sale (Wikipedia). Build only what the test needs, and give it a firm timebox.

5. Measure against a baseline Run the MVP with real customers and record the metrics you chose before the test. Ries's innovation accounting starts by establishing a baseline, then runs experiments to "tune the engine" toward the target (RailsConf 2011 slides). Use cohorts and split tests so you can tell whether a change caused the movement. Run split tests in parallel, because a serial test lets outside events change behavior between the two periods (Wikipedia).

6. Learn and record the result Compare the result with the pass mark you wrote in step 3 and say plainly whether the hypothesis held. Write down what you learned, what surprised you and which assumption is now the riskiest. Share the record with everyone who works on the product. A result that nobody wrote down tends to be reinterpreted later to fit whatever the team wants to do next.

7. Decide to pivot or persevere At a scheduled meeting, look at the trend across experiments. If each round moves the key metrics toward the model's targets, persevere. If the numbers stay near the baseline after several rounds of tuning, pick a pivot that keeps what you learned: Ries's book describes ten types, among them zoom-in, customer segment, customer need and channel pivots (Bajwa et al.). Then return to step 1 with the new assumptions.

Lean Startup and Its Neighbors

The lean startup borrows from several older methods and is often confused with them. The table shows what each contributes, with a source per row.

When to Use

• You are starting a new product and do not know whether customers want it. The method exists for this case: it spends small amounts of money to answer the questions that decide whether to spend large amounts.
• A team inside an established company is launching something new. Ries wrote The Startup Way for this situation, and the scheduled pivot-or-persevere meeting gives sponsors a way to fund learning in stages.
• Your product has users but growth has stalled and the team disagrees about why. Actionable metrics and explicit hypotheses turn the argument into experiments.
• You can put something in front of customers quickly and cheaply, as with software, services and many consumer products. The shorter the loop, the more of it you get.
• You are considering a change of direction. The pivot catalog helps the team keep what it learned and change one element at a time.

When Not to Use

• The problem and the solution are already well understood, such as rebuilding a known internal system. Experiments add delay without reducing much uncertainty.
• Each test is very expensive or slow, as in biotech, where the review in The Conversation notes that fixed costs make repeated test iterations unfeasible.
• Showing an early version would give away a strategy that competitors could copy easily, especially where intellectual property protection is weak.
• The team has no knowledge of the market yet. The same review cites research finding that founders without it are less able to make sense of experiment feedback, so learn the domain first.