Build-Measure-Learn and the MVP
Eric Ries's Lean Startup gave us two ideas that have been so thoroughly misused that I have to reclaim them before I can recommend them. The first is the Build-Measure-Learn loop. The second is the MVP. Both are about learning under uncertainty, and both get bastardized into "ship less stuff faster," which is not what either means.
#The loop runs backwards from how people read it
You read it left to right (Build, then Measure, then Learn) but you plan it right to left. Start from what you need to learn (the riskiest assumption), decide what you must measure to learn it, then build only the smallest thing that produces that measurement. People who run it front-to-back build something, then cast around for what to measure, then "learn" whatever the data happens to say. That's not the loop; that's shipping with a metrics dashboard bolted on.
Learn: what's the riskiest assumption? What do we need to know? Measure: what evidence would confirm or kill it? Build: the minimum artifact that generates that evidence. The goal of one turn of the loop is validated learning, and the metric of success is cycle time, meaning how fast you complete a loop, not how much you shipped.
#The MVP is an experiment, not a tiny product
An MVP is the smallest thing that tests your riskiest assumption, and its output is learning, not revenue and not a shippable v1. The near-universal misuse is treating "MVP" as "version one with the corners cut," then shipping a deliberately bad product to real customers and calling the resulting churn a "learning." That's not lean; it's just bad. A landing page, a concierge service done by hand, a Wizard-of-Oz mock where humans fake the backend: these are often better MVPs than any code, because they test the assumption faster and cheaper. If your MVP took a quarter to build, it probably wasn't minimum and you weren't testing the riskiest thing.
The clarifying question I ask every time someone proposes an "MVP": "What's the one thing we're trying to learn, and is this the cheapest way to learn it?" If the answer involves building most of the product, the assumption being tested isn't actually risky, or you haven't found the real risk yet.
| Term | What it actually is | The misuse |
|---|---|---|
| Build-Measure-Learn | A learning loop, planned in reverse | A build process with metrics |
| MVP | An experiment to test a risky assumption | A small/cheap v1 shipped to users |
| Validated learning | The real output of a loop | "We shipped it" |
#Where it fits
This is the engine under continuous discovery and the operating mode for the Strategic Initiatives quadrant: high-impact, low-likelihood bets you must de-risk before committing. It's the practical sibling of hypothesis-driven development (frame the assumption as a falsifiable hypothesis, then the MVP is your test) and it leans on experimentation for the rigorous measurement once you've got traffic. The throughline across all of them is the same conviction the Atlas keeps returning to: value risk is the assumption most likely to kill you, so test that first and cheapest.
The loop shines under genuine uncertainty. For a well-understood feature on a validated need, building straight is correct, and wrapping certainty in fake "experiments" is its own kind of theater. Reserve the loop for the bets where you genuinely don't know.
#Continue Reading
- Hypothesis-Driven Development for framing the risky assumption as a falsifiable hypothesis to test.
- Experimentation and A-B Testing for the rigorous "measure" step once you have traffic.
- Continuous Discovery for the ongoing practice this loop powers, week over week.
- The Four Big Product Risks for why value risk is usually the one to test first.
- The Frameworks Toolkit for the full index of tools and when each earns its place.