Build Measure Learn

The Build-Measure-Learn loop is a concept coined by Eric Ries in The Lean Startup  (Affiliate link) to capture the feedback loop startups use to convert ideas into products.

The Build-Measure-Learn loop is an application of the Plan-Do-Study- Act (PDSA) cycle, originally created by Walter Shewhart and advocated by W. Edwards Deming. Organizations have used the PDSA cycle for several decades in their continuous improvement efforts.

The Build-Measure-Learn loop builds upon PDSA with an emphasis on getting through the cycle as quickly as possible in order to validate assumptions and test hypotheses about solutions, reinforcing the tie between the activities of a startup and experiments.

It’s important to validate assumptions early on in your project so that you can determine if you have identified the right solution to the right problem.

Asking your stakeholders for feedback is helpful, but due to the influence of cognitive biases, they can sometimes give you misleading information. That’s where the Build-Measure-Learn loop comes in. It provides a way to validate assumptions in conjunction with talking to your stake- holders. It also encapsulates the overall approach to building and getting feedback, which is a key aspect of the guiding principle to reflect and adapt.

Quick cycles through the Build-Measure-Learn loop also help your team reduce the uncertainty that often comes along with IT projects. Rapid trips through the Build-Measure-Learn loop to validate assumptions reduce the uncertainty bit by bit. You want to start by tackling the biggest or riskiest assumptions first.

Eric Ries calls those the “leap-of-faith assumptions,” but it may be easier to think of them as the assumptions that, if proved wrong, can really hose the chances of the project being successful. Here’s a closer look at each step in the Build-Measure-Learn loop.

Idea

Your stakeholders have a need. You understand that need and you think you’ve identified a solution that may satisfy that need. In other words, a desired outcome is based on a bunch of assumptions that you should validate in some way. You need to identify some form of metric based on your overall goal that you can use later on as a measuring stick to tell whether you are successful.

Build

You pick a specific solution (or piece of the solution) to deliver. This is an output. Impact mapping (Chapter 14) can help you pick the right output. Your goal in delivering this output is not necessarily the be-all and end-all; it is to understand the impact this output has on satisfying the need (reaching the desired outcome).

Product

The output of the project

Measure

You’ve delivered this output in isolation so you can see its impact on the outcome free from any other influences (as much as possible at least).

Data

Observe the impact on the metric you identified.

Learn

Examine the data and decide whether the change you delivered made the impact you wanted. If it did, great! You may be done. If not, you have to try something else. And you start the whole cycle all over again by looking at your remaining options and picking the next one.

In some IT projects you know what needs to be accomplished, and there is a clearly defined set of things to be done. This is often the case when the project was created to implement part of an organizational strategy. In those cases, the Build-Measure-Learn loop gets bigger, and there may be other ideas that are more helpful in the short run—specifically whether everything originally included in the scope of the project is necessary.