This website or its third-party tools use cookies which are necessary to its functioning and required to improve your experience. By clicking the consent button, you agree to allow the site to use, collect and/or store cookies.
Please click the consent button to view this website.
I accept
Deny cookies Go Back
  • Skip to content
  • Skip to primary sidebar
  • Skip to footer

KBP Media

Just-in-time resources for product people

  • About
  • Blog
  • Contact
  • Newsletter
  • Login

Kent McDonald / January 12, 2020

Build Measure Learn

Tweet
Share
Share2
2 Shares

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.

Build measure learn loop

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.

Filed Under: Product Management

Become a more effective product person

Previous Post: « 7 Things product people need to know about agile
Next Post: A product person’s guide to working with SMEs »

Reader Interactions

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

Primary Sidebar

Search this Site

Become a more effective product person

Learn more about these topics

Business Analysis

Product Ownership

Product Management

Portfolio Management

Technique Briefs

Footer

Contact Us

3232 190th Street

Prole, IA 50229

515.344.3290

About Us

KBP.Media provides services and resources to help your organization reach its outcomes, make your product team more effective, and your career more rewarding.  
Learn More

Inside Product

Get a weekly rundown of hand picked resources for product owners, business analysts, and product managers. 
Get Inside Product

© 2021 KBP Media · Rainmaker Platform

Privacy Policy

  • Home
  • About
  • Contact
  • Privacy Policy