Innovation Deliver

Lean Startup

Lean startup is build, measure, learn: short cycles used to cut the risk of building something the market does not want.

The questionWhat is the cheapest way to find out whether anyone wants this, before we build all of it?

Process · Eric Ries, 2011

BuildThe smallest test, such as an MVP
MeasureWhat customers do, against a set threshold
LearnPersevere, pivot, or stop

Schematic of the build, measure, learn loop, repeated on one assumption at a time.

When to use it

A sponsor is asked to fund a new product or venture, and nobody has shown that a customer will pay for it.
A large company is building outside its existing business, and its stage-gate process demands forecasts the team cannot honestly produce.
A team has been building for months without customer contact, and the roadmap is mostly opinion.
The client needs a decision rule for continuing, redirecting, or stopping a project that does not depend on who argues best.

When to avoid it

Demand is already known and the work is a known type, such as replacing an existing system, doing regulated compliance work, or extending a product line. Ordinary project delivery is cheaper.
A failed experiment could hurt people or break a regulation, as in medical, safety, or financial products. The test has to be something other than releasing it and watching.
The client wants a polished launch and will not show anyone an early version. The method depends on putting something rough in front of customers.
The problem is defects or waste in a process that exists. Use PDCA or another improvement cycle.

Overview

Lean Startup treats a new product or venture as a set of unproven beliefs. The team tests the riskiest one first, with the cheapest experiment that gives a real answer from real customers. At each checkpoint it decides whether to continue, change a fundamental hypothesis, or stop.

The method fits when nobody knows who the customer is or whether they will pay, and it fits poorly where demand is established. Minimum viable product is the most misused term in it. It means the smallest thing that tests a hypothesis, which is sometimes a spreadsheet and a phone call, and it does not mean a rough first release. Support for the method is largely practitioner experience.

The working concepts

Leap-of-faith assumptions

The beliefs the venture depends on. The two that matter most are that customers have the problem and will pay to solve it, and that the business can find more customers. List them and test the riskiest first.

Minimum viable product

The least you can build, or fake, to get a real answer from real customers. It may be a landing page, a hand-run service, or a mock-up. Its purpose is to learn about demand, not to ship a smaller product.

Validated learning

Progress counted as what you have shown about customers, based on what they did, such as paying, returning, or referring someone, and not on what they said or on sign-up counts.

Innovation accounting

Metrics set up before an experiment runs, with a baseline, a target, and a sequence of milestones. It separates actionable measures, which show cause and effect, from vanity measures that only go up.

Pivot or persevere

A decision made at a scheduled point. If the numbers show the current approach moving toward its target, continue. If they do not, change one fundamental hypothesis about the customer, the problem, the solution, or the way you grow, and keep what you learned.

What it is not

A mandate to spend little and fail fast. A cheap experiment that tests nothing is still waste, and the method is about the process around the experiment.
A license to ship poor products. A minimum viable product is the smallest test of a hypothesis. If customers cannot tell what it is for because it is broken, you are measuring quality and not demand.
A synonym for agile. Agile practices help a team build software in short cycles. Lean Startup helps decide what is worth building, and a team can run tidy sprints on a product nobody wants.

The steps

List the leap-of-faith assumptions

Write down what must be true for the venture to work, in terms of who the customer is, what problem they have, what they would pay, and how you would reach more of them. Mark which are known, which are believed, and which are guesses.
Pick the riskiest and design the smallest test

Choose the assumption that would do the most damage if wrong. Decide which kind of minimum viable product tests it, who it goes to, and how long it runs. Write the success threshold before the test starts.
Run it with real customers and measure behavior

Put the test in front of people who match the target customer, not colleagues. Record what they do: sign-ups that lead to use, payment, repeat requests, referrals. Also talk to them, because the numbers show what happened and the conversation tells you why.
Decide at the scheduled checkpoint

Compare the result with the threshold. Persevere if the approach is moving toward its target, pivot by changing one fundamental hypothesis if it is not, or stop. Write the decision and the data behind it.
Repeat on the next assumption

Move to the next riskiest assumption and keep the log current. Invest in building at scale only once the assumptions that could sink the venture have survived tests.

In practice

The sponsor wanted a nine-month build budget approved for a freight-booking tool for small manufacturers. The consultant asked for the single belief the budget depended on. The team named it: small manufacturers book freight by email and phone today, and would switch for faster quotes. That became the first test. For two weeks, one analyst took quote requests from twelve manufacturers by hand, using a shared spreadsheet and calls to carriers. The target, written down beforehand, was that at least six of the twelve would ask for a second quote within the fortnight.

Five came back and one paid the fee. The team recorded a miss, not a failure, and used the follow-up calls to revise the hypothesis. Most of the manufacturers cared less about quote speed than about catching carrier invoice errors afterward. The next cycle was budgeted at a fraction of the original build, with its own target and a decision date in the calendar.

What you leave with

A ranked list of the assumptions the venture depends on, with the evidence so far for each.
An experiment record for each test: hypothesis, test, threshold, date, owner, and result.
A written decision at each checkpoint, either persevere, pivot, or stop, with the data behind it.
A learning log a sponsor can read to see what the spend has bought.

Failure points

Vanity metrics

Page views, sign-ups, and downloads go up while the business does not, because they cost the customer nothing. Pick measures tied to behavior that costs the customer something, such as money, time, or effort.

Thresholds set after the result

When the target is chosen afterward, the team can read almost any result as encouraging. The threshold has to be on paper before the test runs.

An MVP that tests quality, not demand

The first version is so rough that people leave because it is broken. The team concludes there is no demand, when the test could not have shown demand in either direction.

Pivoting on every setback

A pivot changes a fundamental hypothesis. If the team changes direction after every disappointing week, nothing is tested for long enough to learn from, and every cycle restarts from zero.

A sponsor who wants the plan, not the learning

Corporate governance still asks for a three-year forecast, and the team spends its time on the spreadsheet instead of on customers. Agree on what the sponsor will accept as evidence before the first cycle starts.

The failures above are usually Leverage & IP: it was used once, and nothing was left that makes the next engagement easier.

Origin

Eric Ries developed the method from his own experience at technology start-ups, including IMVU, where Steve Blank was an investor. Blank's customer development approach, described in his 2005 book The Four Steps to the Epiphany, told founders to find out what customers want before scaling a product. Ries combined it with ideas from lean manufacturing and the Toyota Production System, which supplied the word lean, and with iterative software practice. He wrote about the method from about 2008 and published the book in 2011.

The terms most consultants use, including validated learning, innovation accounting, and pivot, come from Ries's book. Early support for the method was mostly practitioner experience and case stories, not controlled studies, so weigh claims about its results accordingly.