Tool/Design and Human Factors/No. 0120
Build-Measure-Learn
Build-Measure-Learn is a cycle for testing product ideas through small experiments and using the results to guide the next step. Eric Ries popularized it in The Lean Startup. Teams build a test, measure how people respond, and learn which assumptions hold.
Also called Build-Measure-Learn Loop
- Evidence
- Useful, modest evidence
- Read
- 6 min
- Links
- 10 connections
01You've seen this when…
- at work
A team wants to automate customers’ monthly reports. Before building the pipeline, an analyst prepares two reports by hand and checks whether customers use them in their planning meetings.
- in life
You want to start a neighborhood supper club. You host one paid dinner, track the preparation time, and see how many guests book another.
- out in the world
A library tries Saturday evening hours for a month. Staff count visits and ask what brought people in before recommending a permanent schedule change.
02The idea
A product plan contains assumptions: customers have this problem, this solution helps, they will use it again, and someone will pay enough to sustain it. Build-Measure-Learn turns those assumptions into a sequence of tests.
Build something that lets people respond. Measure the behavior relevant to the assumption. Learn enough to choose the next move: continue, change direction, or stop. Each pass should reduce uncertainty about a decision that matters.
Although the name starts with building, planning runs backward. First identify what needs to be learned. Then choose the evidence that would answer it. Finally, decide what to build to produce that evidence. This keeps a team from shipping whatever is easiest and searching afterward for a reassuring metric.
The test might be a working feature, a manually delivered service, or a prototype. A minimum viable product is one possible test vehicle. The cycle also includes the assumption, measurement, and decision around it. A pretotype can help test demand before a usable product exists.
The useful output is a better-supported decision. Shipping five versions teaches little if every version leaves the central assumption untouched.
03How to use it
-
Name the decision and its risky assumption. Decide what evidence would change the next investment. For a scheduling tool, the crucial assumption might be that customers will let the system book appointments without reviewing every suggestion. Choose an assumption whose failure would force a substantial change.
-
Define an observable response. Translate the assumption into behavior: completing a booking, returning the following week, or paying for continued service. This is operationalization: specifying how an idea will be observed. Record the denominator too. Eight purchases mean different things among ten visitors and ten thousand.
-
Write a decision rule before testing. State the test period, the outcome that would justify continuing, and what an ambiguous result would require. A threshold can guide a small pilot without providing statistical proof. Writing it early reduces the room for confirmation bias.
-
Build the smallest test that can answer the question. Use a manual service to test whether people value an output. Use usability testing to see whether they can complete a task. Keep promises accurate and make limits clear. A sketch can reveal confusion; charging for a delivered service provides stronger evidence about payment.
-
Measure behavior and investigate the reasons. Keep a simple record of who was offered the test, who participated, and what happened. Interviews can explain an outcome, but stated enthusiasm alone gives weak evidence of repeated use. When comparing alternatives, an A/B test with adequate randomization and sample size can help separate their effects.
-
Make the decision and carry the lesson forward. Record what the evidence supports, what remains uncertain, and the next action. Change the product, test another assumption, or stop. Set a date for reviewing the next result so that measurement leads to a decision.
04A worked example
Consider an invented team planning a dashboard for freelance designers. Its first assumption is that designers will pay $15 a month for a weekly report of overdue invoices. Building integrations with accounting tools would take several weeks.
The team instead recruits ten freelancers who each send at least ten invoices a month. With their consent, it uses exported invoice data to prepare reports manually for two weeks. Before starting, the team sets a provisional rule: at least four of the ten invitees must pay for the following month to justify further development. That threshold is a business decision rule, with substantial uncertainty attached to such a small sample.
What it looks like A spreadsheet service with little software behind it. Six freelancers activate the trial, four open both reports, and one pays to continue.
What’s actually going on The team has tested payment for a specific offer. The result falls below its rule. Follow-up conversations reveal that four participants already get similar lists from their accounting software; two ask for help drafting payment reminders. Those requests suggest another assumption to test. They provide no evidence yet that the replacement service will sell.
What made it work The team chose its evidence before building integrations and made payment easy to observe. It delays the dashboard investment. Its next cycle tests a manually prepared reminder service, with customers approving each message. The first result narrows the next decision without settling the whole market.
05When to reach for it
06When it misleads
-
The metric rewards the wrong behavior. Sign-ups can rise because of a giveaway while paid use stays flat. Choose a measure close to the assumption, and check for side effects. Goodhart’s Law becomes relevant once people are rewarded for moving the number.
-
Every disappointing result gets a new explanation. Changing the target after seeing the outcome makes almost any experiment look encouraging. Keep the original rule in the record. Treat a revised explanation as a fresh hypothesis requiring another test.
-
The sample hides the market. Friends, enthusiasts, and existing customers may tolerate rough edges that other buyers reject. Record how participants were recruited. A small pilot can expose a failure or justify another test; estimating market-wide demand requires broader evidence.
-
Several things change at once. A new price, audience, feature, and sales channel make the outcome difficult to interpret. Separate changes when practical. Use a randomized experiment when a causal comparison matters and the setting supports one.
-
Short cycles miss delayed costs. Early clicks can conceal poor retention, support workload, or harm that appears months later. Keep longer-term measures running alongside quick tests. A manually delivered service also leaves open whether automation will preserve quality and whether the economics will work at scale.
-
The test puts people at avoidable risk. Set consent, privacy, and safety boundaries before launching. Healthcare and infrastructure experiments require safeguards appropriate to their consequences. A fast feedback cycle supplies no exemption from those obligations.
07Roots
At IMVU in the mid-2000s, Eric Ries helped build a chat service where people appeared as 3-D avatars. The team faced a familiar software problem: it could produce features faster than it could establish which features customers wanted. Ries described discarding work that had seemed essential after seeing how users responded.
Steve Blank’s customer-development approach helped give that frustration a method. Founders could take their assumptions to prospective customers and revise their plans through direct contact. Ries combined that approach with ideas from lean manufacturing and iterative software development: smaller batches, shorter feedback loops, and less effort committed before learning.
In The Lean Startup in 2011, Ries presented Build-Measure-Learn as a central loop for managing that uncertainty. The memorable sequence gave founders a way to connect product development to customer evidence. Its appeal traveled beyond startups because established product teams faced the same problem: a polished release could still rest on an assumption nobody had tested.
08How solid is this?
The framework draws on experimentation and hypothesis testing. Studies of scientific entrepreneurial decision-making examine related practices, but direct tests of the complete branded cycle are limited. They do not establish that faster iteration improves every product or raises startup success rates.
09Connections
- Helps counter Confirmation Bias
- Part ofOperationalization
- Includes A/B Testing, Randomized Experiment, Pretotyping, Usability Testing, Minimum Viable Product
- See also Goodhart’s Law, Gall’s Law, Jobs to Be Done
10Origin and sources
Eric Ries developed the approach through startup experience, including IMVU, drawing on Steve Blank’s customer development and lean methods. He popularized the named cycle in The Lean Startup (2011).
- [1]Ries, E. (2011). The Lean Startup: How Today's Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses. Crown Business.
- [2]Blank, S. (2013). Why the Lean Start-Up Changes Everything. Harvard Business Review, 91(5), 63–72.
- [3]Camuffo, A., Cordova, A., Gambardella, A., & Spina, C. (2020). A Scientific Approach to Entrepreneurial Decision Making: Evidence from a Randomized Control Trial. Management Science, 66(2), 564–586.
Suggest an edit· Updated 2026-10-02