Build – Measure – Learn
Build-Measure-Learn cycle was coined by Eric Ries in his book Lean Startup, and like many other concepts from Lean Startup it has been widely misunderstood. But, it is important that you understand this.
Build, doesn’t necessarily mean software or physical product.
Credits: Eric Ries
The basic rule here is: the type of build, the kind of measures and the quantity of learning will depend on two factors: the stage in the product life cycle you are in and the amount of money you have.
Some people prefer to draw this feedback loop like follows:
Credits: Steve Blank
- Hypothesis: a problem your customers have, an underserved need of your customers or a risk in your business model
- Design: the best way to test the hypothesis
- Test: expose artifact to customers
- Validated learning: what did you learn and what was the impact on any metrics. They can be qualitative (WHY) and/or quantitative (WHAT, HOW, HOW MUCH, WHEN)
The benefit of the second approach is that it reduces the chance you falling into the build trap. But, it doesn’t really matter, as long as you use it properly.
This build-measure-learn cycle goes on forever. It is the engine of Lean Startup.
For some teams this cycle will last a few days, others will take a whole week or two weeks. It depends on the stage of your product lifecycle you are currently in.
As an example, a Design Sprint shoves the whole cycle in 4-5 days to work on a single challenge. You can use a Design Sprint to create the delivery backlog for the next few agile iterations in order to solve a particular problem, tackle a specific goal or design your first Minimum Viable Product (MVP).