A three-stage feedback loop from Eric Ries's Lean Startup methodology that moves a team from an unvalidated assumption to a documented learning in the shortest possible cycle.
What is the smallest experiment we can run to test this assumption, and what will we do with the result?
Build-Measure-Learn is the core feedback loop of the Lean Startup methodology. It moves a team from an unvalidated assumptionAssumptionStrategyA belief taken as true that underpins a strategyView reference → to a tested learningLearningValidationAn insight gained from an experimentView reference → in the shortest possible cycle, by insisting that building, measuring, and learning happen as a tight sequence and not as separate, occasional activities.
Eric Ries introduced Build-Measure-Learn in The Lean Startup (2011), but the loop draws on a longer lineage. Ries studied under Steve Blank, whose customer development methodology established the idea that startups should test their assumptions about customers before building product. The loop also reflects the Plan-Do-Check-Act (PDCA) cycle from lean manufacturing, formalised by W. Edwards Deming and embedded in Toyota's production system. Ries synthesised these influences into a feedback model suited to software product teams, naming it through his experience as CTO at IMVU, where he had watched expensive engineering work fail to generate validated learning. The key contribution of The Lean Startup was the argument that cycle time through the loop is a leading indicator of team velocity: the faster you complete a cycle, the faster you learn.
The loop has three phases, and the discipline is in running them in order.
Build. Identify the riskiest assumption the team currently holds and frame it as a falsifiable hypothesisHypothesisValidationA testable belief about a solutionView reference → with a numeric expectation: if we change X, Y will move by Z. Design the minimum viable product (MVP) that would test that hypothesis and nothing else. The MVP is not a scaled-down version of the final product; it is the smallest artefact that can generate a signal.
Measure. Define success criteria before you build, not after. Ries distinguishes actionable metricsMetricStrategyA unified metric that measures progress, health, or behaviour across the productView reference → (which change in response to specific actions and can inform a decisionDecisionStrategyA recorded decision with context, rationale, and consequencesView reference →) from vanity metrics (which rise over time regardless of what you do, and tell you nothing). Page views and registered users are often vanity metrics. Activation rate or time-to-first-value is usually actionable.
Learn. Read the data honestly. The binary outcomeOutcomeStrategyA desired business or user outcomeView reference → is: the hypothesis is supported (persevere) or it is not (consider a pivot). Document the learning explicitly as a node in the team's record, not just a slide in a post-mortem deck. An experimentExperimentValidationA test designed to validate a hypothesisView reference → with no documented learning is a closed loop with no memory.
A worked example. A team believes that users abandon their onboarding flow because the first screen asks for too much information. They hypothesise that reducing the first screen to one field will lift completion by 15%. They build a single-field variantVariantGrowthA variant in an A/B testView reference →, ship it to 20% of new sign-ups, measure completion against the baseline for two weeks, and record the result. If completion rises by 15% or more, they persevere. If not, they examine what the data does tell them about abandonment and frame the next hypothesis.
Build-Measure-Learn suits any team making decisions on opinion when evidenceEvidenceValidationData supporting or refuting a hypothesisView reference → is available. It is at its most valuable when assumptions are stacking up faster than they are being tested, when product debates run long because no one can settle them with data, or when a team has just entered a new problem space and the riskiest unknowns have not yet been touched.
The loop earns less when the cost of building the MVP is so high that the learning from one cycle does not justify the investment, which happens when technical complexity or regulatory requirements make minimum viable anything expensive. It also earns less when the team is in execution mode on a well-validated idea and the remaining questions are about implementation quality. In those situations, lean product experiments give way to engineering craft and delivery discipline.
Common failure modes: designing experiments that cannot falsify the hypothesis (no failure mode means no learning); building the actual product when a much simpler artefact would suffice; setting up measurement only at the end of a long cycle, after the build is done; and treating a failed experiment as a setback, when it is a successful piece of learning.
Build-Measure-Learn is a flow framework in the validation category. The three stages map directly onto distinct entity types, which means a cycle through the loop leaves a structured trail in the graph.
prototypemetriclearningModelling the loop this way means a learningmetricflow pattern reflects the directional, sequential nature of the cycle: each stage feeds the next, and the end of one cycle becomes the starting point of the one that follows.