
From the library
Eric Ries, 2011
In one paragraph
Eric Ries's methodology for developing businesses and products through Build-Measure-Learn feedback loops. Emphasizes rapid experimentation, validated learning, and iterative product releases to reduce market risks and avoid building products customers don't want. Has sold over 1 million copies worldwide.
Also tagged
Where this sits in the operating system
This is the operational engine of Continuous Improvement and Feedback Loops, and the clearest treatment of Feedback Loops in the library. Its specific contribution is making the loop short and instrumented: build, measure, learn, with the loop time itself as the metric to optimise. It carries Leading vs. Lagging Indicators through the attack on vanity metrics and the case for cohort analysis.
Systems Over Goals
Systems Over Goals
Continuous Improvement & Feedback Loops
What it does not cover
It is close to silent on what to build in the first place. Iteration finds local improvements and does not generate a thesis, and Ries has little to say about taste, vision or the cases where customers cannot tell you what they want. For that the framework routes to Mental Models and Decision Frameworks, and Zero to One is the direct rebuttal held in the same library.
Read it if
Skip it if
Before you read on
What is the single assumption in your current plan that, if false, makes everything after it worthless, and when will you know?
Key insights
The unit of progress is validated learning, not shipped features. Working software you had to build to learn nothing is waste.
Plan the loop backwards: decide what to learn, then what would measure it, then the smallest thing that produces the measurement.
Innovation accounting with cohorts is the part everyone skips. Without it vanity metrics let a failing product look like a growing one.
Recognise it early
The failure and the correction sit side by side deliberately. Read the left column asking whether any of it is already true of you.
Building products without validating customer demand first
Making decisions based on opinions rather than customer behavior
Perfectionism that delays customer feedback and learning
Using traditional metrics instead of innovation accounting
Avoiding experimentation due to failure fear
How it actually works
The central move is redefining progress. In a conventional plan, progress is execution against a schedule, which works when the plan is broadly right and is actively misleading when it is not. Ries substitutes validated learning: the unit of progress is a confirmed or falsified belief about customer behaviour, and everything else, including working software, is potentially waste. The build-measure-learn loop is designed to be run as fast as possible, because under real uncertainty the number of times you go round is a better predictor of survival than the quality of any single pass.
Name the value hypothesis and the growth hypothesis explicitly, before building. What must be true for this to work at all.
Without naming them the riskiest belief stays implicit and gets tested by the market after the money is spent.
The smallest thing that generates a real signal about that assumption. Often not a product. Sometimes a landing page, a manual service or a video.
Without the discipline the MVP becomes a small version of the finished product, which tests build capability rather than demand.
Cohort metrics and actionable numbers rather than cumulative totals. Establish the baseline, tune the engine, then decide.
Without it every chart goes up and to the right, and vanity metrics let a failing product look like a growing one for a year.
A scheduled, structured decision taken on the cohort data rather than on morale.
Without a fixed cadence the decision is made emotionally, usually late, usually after the runway makes it academic.
The loop is written build-measure-learn and must be planned in reverse. Decide what you need to learn, then what would measure it, then the smallest thing you could build to produce that measurement. Teams that plan in the written order build first, then look for something to measure, and reliably discover a metric that flatters what they already made.
Worked through
You have nine months of runway and a six-month plan to build a compliance dashboard that three prospects said they would probably buy.
Name the assumption that kills you
Not can we build it. It is whether teams will change their existing workflow for this, and whether probably buy converts to a signed order at a real price.
Design the cheapest thing that tests it
A concierge version: do the compliance reporting manually for two customers this month. It tests willingness to change and to pay, and it costs weeks rather than months.
State the number in advance
Two of three converting at the target price within four weeks means proceed. Written before the experiment, or the result gets reinterpreted afterwards.
Measure the behaviour, not the enthusiasm
Meetings taken and positive calls are vanity. Purchase orders, usage in week three and renewal intent are the actionable equivalents.
Book the pivot decision now
Put the date in the calendar while you are still optimistic. Made in month five under pressure, this decision is always persevere.
The same idea, argued differently
These books all treat uncertainty as the defining condition. They divide on whether the answer is to run more experiments or to hold a stronger thesis.
Masaaki Imai
Where it overreaches
Taking the book seriously means knowing where it is weakest.
The evidence is anecdotal and selected.
Successful companies described after the fact, with the method fitted to the outcome. Dropbox's video and Zappos's manual fulfilment are told as method and were largely improvisation, and the failures that ran the same loop do not appear.
MVP is the most misused term in the book.
Ries means the minimum artifact that produces a learning signal. It has been read industry-wide as a low-quality version one, and the book's framing did not do enough to prevent that.
Iteration cannot generate a vision.
Local optimisation improves whatever you already have. Nothing in the method takes you from a working product to a fundamentally better idea, which is Thiel's objection and it is not answered here.
It assumes cheap, fast, reversible experiments.
That describes consumer software and very little else. In hardware, healthcare, enterprise sales with eighteen-month cycles, or anything regulated, the loop time exceeds the decision horizon and the method quietly stops applying.
What the book still has that this page does not
Everything above is the transferable part. Here is what does not survive compression, so you can decide whether the full read is worth it to you.
The full case studies
IMVU, Intuit and the Grockit material carry the reasoning behind each pivot. The decision points are the transferable part and they compress badly into a diagram.
Innovation accounting worked through
The cohort tables are the least quoted and most practically valuable pages in the book. Everyone remembers the loop; almost nobody implements the accounting.
The taxonomy of pivots
Ries lists roughly ten distinct kinds. Knowing which one you are considering changes what you keep, and that granularity does not survive summarisation.
The full breakdown
Before you close this
Naming the specific moment you will act roughly doubles the odds you do.
Use this when a roadmap is being defended on the grounds of how much work has already gone into it.
Reference
We use cookies to enhance your experience, analyze site traffic, and personalize content. You can manage your preferences or learn more in our Privacy Policy.