Build–Measure–Learn
Treat each product idea as a hypothesis: build the smallest thing that tests it, measure what people actually do, and decide whether to pivot or persevere.
“The fundamental activity of a startup is to turn ideas into products, measure how customers respond, and then learn whether to pivot or persevere.”
To an executive
Every new product is a set of guesses. Testing the riskiest guess cheaply, then deciding to pivot or persevere, wastes far less money than building everything first.
To an engineer
Build the minimum needed to learn, instrument it, and decide on evidence. Keep the experiment cheap and disposable, and harden only what the evidence says will stay.
The idea
Eric Ries, in The Lean Startup (2011), described a startup as an organisation working under extreme uncertainty, and argued that its unit of progress is validated learning: evidence, from real customer behaviour, about what creates value. Ideas move through a loop of build, measure, learn. You turn an idea into something people can use, measure how they respond, and learn whether your assumptions held.
The thing you build is a minimum viable product (MVP): the smallest version that lets you run the full loop and learn. It may be a landing page, a manual service behind a simple front end, or a narrow slice of the real product. After each turn of the loop you decide to pivot, changing a core assumption while keeping what you learned, or persevere with the current strategy. Ries built on Steve Blank's customer development work, and the aim is to shorten the loop so you learn faster than you spend.
Why it works
Most product assumptions are wrong. Building the full solution before testing them turns each wrong guess into months of wasted work and code to maintain.
Behaviour beats opinion. People say they would use things they never touch. Measuring what they do gives evidence that a steering committee cannot.
Short loops compound. A team that runs a cheap experiment every two weeks learns more in a quarter than one that ships a big release at the end of it.
Where it applies
- New products and platforms, where demand and usage patterns are uncertain.
- Architecture choices under uncertainty, deciding how much to invest in scale, resilience and generality before you know the product will stick.
- Internal platforms, testing whether teams will adopt a capability before building it out.
- Portfolio funding, releasing money in stages as evidence arrives rather than in one upfront business case.
How to apply
- Name the leap-of-faith assumptions. Usually one about value (will they use it?) and one about growth (how will it spread?).
- Design the cheapest test. Choose the smallest build that produces real behaviour, and agree in advance what result would count as failure.
- Instrument before launch. Decide the measures, prefer per-cohort behaviour over totals, and make sure the data will arrive.
- Decide explicitly. At a set date, pivot or persevere, and record why.
- Harden what survives. Treat MVP code as disposable; once the evidence is in, invest in the parts that will last.
Example scenario
A retailer wanted a subscription service for household goods and the first plan was a full platform: a new billing engine, a recommendation service and integration with every warehouse. The estimate was nine months before any customer saw it.
The architect proposed testing the riskiest assumption first: would existing customers sign up and stay past the second delivery? The team built a sign-up page on the existing shop, charged through the current payment provider and fulfilled orders from one warehouse with a manual daily export. Within weeks they found people signed up readily but cancelled when they could not skip a month. They added skipping before anything else, and only then designed the billing engine, now shaped by real usage.
Questions to ask
- What is the riskiest assumption here, and what is the smallest thing we could build to test it?
- Which measure would tell us we were wrong, and have we agreed it before we start?
- Which parts of this MVP are we prepared to throw away, and which must be built to last?
When not to use it
- Safety-critical or regulated systems, where an "MVP" cannot be released to learn from failures.
- Well-understood replacements, where the requirements are known and the risk is in delivery, not demand.
How it misleads you
"MVP" is often used to excuse shipping something poor, or to cut quality from a product whose demand is already proven. The opposite failure is endless experiments with no decision. And disposable code has a way of staying: agree up front what will be thrown away, and budget to rebuild it if the idea survives.
In the wild
Further reading
Last reviewed · Suggest an improvement