Reactify Solutions
HandbooksLean startup methodBuild, measure, learn

Build, measure, learn

How to run one cycle. Plan it backwards, build only enough to get the measurement, and finish with a decision rather than a release.

Product teams and foundersLast reviewed September 5, 2026
In one minute
  • Plan backwards, run forwards. Start from what you need to learn rather than from what you could build.
  • The number to improve is total time through the loop, not the speed of any single step.
  • Each cycle ends with a decision: pivot, or keep going.
  • Small releases every sprint beat one big release, because a loop you run once teaches you once.

The cycle

Execute forwards, plan backwards
1Build
An MVP
The smallest thing that tests the idea
2Measure
Data
Split tests and cohorts, not totals
3Learn
A decision
Pivot, or keep going
What you learn feeds the next build. Each pass ends with a decision, not a release.
Plan in reverse · decide what you need to learn, work out what to measure to learn it, then build only enough to get that measurement.
The goal · shorten total time through the loop. That is the number to improve, not the speed of any one step.

Build

Build the least you can get away with. The question is never "is this a good product?" but "is this enough to answer the question?"

Two habits make this workable:

  • Work in small increments. Short cycles with something shippable at the end. Extreme Programming and similar approaches exist for this, and the specific method matters less than the increment size.
  • Write it as user stories. A story keeps the unit of work attached to a person and an outcome, which makes it harder to build infrastructure nobody asked for.
The most common failure

Building more than the experiment needs, because the extra part felt obvious. Every unused line is waste, and it also slows the next loop.

Measure

You need numbers that tell you whether the guess held. Totals do not do this. Cohorts and split tests do.

Metrics that are not lies covers the three A's and split testing.

Learn

The cycle is not finished when the feature ships. It is finished when you have decided something.

Ask three questions:

  1. What did we expect to happen?
  2. What happened?
  3. Does that change our direction?

If the answer to the third is yes, pivot. If no, run the next loop.

Speed is about the whole loop

Teams tend to improve the step they are best at. Engineers ship faster. Analysts build better dashboards. Neither helps if the bottleneck is the two weeks it takes to agree on what the data means.

Time the whole loop, from "we want to learn X" to "we decided Y". Cut that number.

Check it worked.

Time your last full cycle. If you cannot point to the date you decided something, the loop did not close.

Last reviewed September 5, 2026 · verified against The Lean Startup, Eric Ries, 2011