The Lean Startup method: build, measure, learn unpacked

Executive overview

Most teams claim to run build-measure-learn but treat it as a single multi-year loop. The real value is in maximising the number of short loops, each focused on testing the highest-priority unknown.

The framework reframes the sequence as learn, build, measure — start by asking what you need to know, build only the minimal instrument to test it, then measure a pre-declared success criterion.

The core insight: speed through the loop is a discipline, not a side effect — and every element of experiment design (assumptions, instruments, calls to action) exists to force that discipline.

Why teams misrun build-measure-learn

• "Lean washing" is common: teams say they do it, but the build phase takes years
• The loop is not a single end-to-end workflow from idea to launch; teams should complete many loops before reaching each milestone
• Starting with "build" is the wrong mental model; the real entry point is "what do we need to learn next?"
• Without a shift in the definition of success — from outputs delivered to recommendations backed by evidence — teams have no reason to run the loop properly

Capturing and prioritising assumptions

• Assumptions are structured guesses; "leap of faith assumptions" are the most important and most uncertain ones
• Start every assumption with "we believe" — it enforces stating something falsifiable
• Write assumptions about customer behaviour, not product features; customer-framed assumptions are more testable
• The assumption map uses two axes: importance to project success (vertical) and degree of uncertainty (horizontal)
• Top-right quadrant = leap of faith assumptions; these are the ones to test next
• Milestone focus narrows the assumption set: if you are at the customer hypothesis stage, only customer assumptions are in scope
• Assumption mapping surfaces hidden disagreement within teams — engineers who think there is "nothing to map" often discover they hold opposite views

Designing experiments: instrument, channel, call to action

• An experiment has three design elements: instrument (what you apply to the customer), experiment channel (how it reaches them), and call to action (what you ask them to do)
• The instrument may or may not be an MVP; all MVPs are instruments, but not all instruments are MVPs
• Brainstorm multiple experiment options before committing — there is rarely only one way to test a given assumption
• The call to action determines strength of evidence, not the type of experiment
• A Wizard of Oz experiment with a "did you like it?" question is low-strength evidence; the same experiment ending with "enter your credit card" is high-strength

The strength of evidence curve

• The horizontal axis runs from prediction (what people say) to observation (what people do)
• Early-stage experiments generate say data — opinions, survey responses, interview answers; useful for probing and directing the next loop, not for go/no-go decisions
• Later-stage experiments push toward do data — pre-registration, signing terms and conditions, letter of intent, purchase
• B2C and B2B calls to action differ: a letter of intent is a meaningful commitment in B2B but meaningless to a consumer
• Interviews are a great place to start but a bad place to end — low-strength evidence that should give way to behavioural tests over time
• "MVP as a state of mind": there is no single MVP; the minimal bar rises with each loop as knowledge accumulates

Defining and measuring success

• Success criteria must be declared before running the experiment, not inferred after
• Express success as a concrete threshold: e.g. four out of ten customers take the call to action
• Hitting the threshold is not the only valuable outcome — zero out of ten with a consistent failure reason is highly actionable
• Vague metrics ("we feel good about it") allow each team member to apply a different standard; hard thresholds do not
• Failure to hit criteria is information about the opportunity, not a verdict on the team
• Confirm during execution that the experiment is being run as designed: are you actually reaching the target customer profile?

AI tools and vibe coding

• Generative AI dramatically compresses the build phase — a working prototype can now be produced in minutes
• The risk is skipping the earlier steps that inform what should be in that prototype
• The assumption map, call-to-action design, and milestone framing are the inputs that should drive the AI prompt, not a replacement for them
• The right balance between "build fast with AI" and "do the prior learning work" is still being worked out