The Build-Measure-Learn Cycle

The build-measure-learn cycle is a core concept of product management and the broader practice of product development. Coined by Eric Ries and refined in his book The Lean Startup, the cycle emphasizes rapid experimentation and iteration as a way to validate ideas and improve the likelihood of success for the product.

The philosophy behind the build-measure-learn cycle is continuously testing and validating hypotheses about what customers want and, by extension, what will positively impact our desired outcomes. It's done by building a minimum viable product (MVP), a stripped-down version of the product that just enough features to test key assumptions and gather feedback. After the MVP is built, we collect data on how customers interact with it. The team then pulls insights from that feedback, learning from that data to inform the next iteration of the product.

This ideally helps show us user needs early in the process, along with potential feature candidates. It also helps inform work priorities by exposing the highest potential opportunities. It empowers a team to quickly and efficiently make changes to the product based on real-world data, instead of relying on assumptions and guesses.

What about non-iterative development?

The build-measure-learn cycle is usually associated with iterative development, but it can also be applied to non-iterative development in some contexts. While the build-measure-learn cycle is most commonly associated with iterative development, the concepts behind it—testing assumptions, gathering feedback, and using data to inform decision-making —can be applied in other development contexts as well.

What are we building?

In the build phase we'll be building something, but that doesn't necessarily mean new features that are headed into production. That might be the case, depending on the maturity and state of our product, but we might also be working to validate our assumption about how to achieve our objectives or test customer reactions to something.

In the case of the latter, we might create a minimum viable product (MVP), designed to minimize development time and resources while being functional enough to test the key hypotheses. The MVP should be the smallest thing you can build that provides feedback on your key assumptions while delivering value to users.

The concept of the MVP has become increasingly abused, with the term often being treated as a euphemism for a quickly produced "good enough" deliverable that is never revisited. An MVP isn't the final product—but it should provide a clear understanding of the customer needs and the core features that the final product might have. Based on the feedback and data collected from the MVP, the team can decide on the direction for the next iteration and continue to build accordingly.

What are we measuring?

In the measure phase of the build-measure-learn cycle, we collect data on how customers interact with our changes to the product and use that data to inform the next product iteration. Key metrics that may indicate the performance of a product iteration include:

• Engagement metrics show us how customers interact with the product. For example, how many people visit the website, how long they spend on a page, or how many pages they visit.

• Conversion metrics tell us whether our changes are achieving our goals. These include things like the number of people creating an account or making a purchase.

• Retention metrics measure how well the product is keeping customers. For example, how many people return to use the product after their first visit, and how long they're using the product before losing interest.

• Qualitative metrics are based on customer feedback. Surveys and interviews can give a deeper understanding of the customer's perspective, and why they choose to use the product or not.

The MVP should be designed to test key assumptions the product team hold about the product. It's important to note that, to make informed decisions, we need to have a clear idea of what to measure, how to measure it, and what a good or bad result would look like. These should be part of the ideation process and defined well before building begins.

It's also worth noting that collecting data is only half of the equation. In the measure phase it must be analyzed to figure out what it means and what should come next.

What are we learning?

In the learn phase of the build-measure-learn cycle, we use the data collected during the measure phase to inform the next iteration of the product. We learn from the feedback and data what's working and what isn't, what the user needs are, and where any pain points are.

We should consider:

• Are customers using the product in the way we expected?

• Are they achieving the goals we set for them?

• Are there pain points or issues that prevent them from using the product?

• Are there any unexpected needs or behaviors that we weren't, but should be, aware of?
  
  The product team should focus on the most impactful changes for user experience, engagement, or conversion.

In the "learn" phase we should also confirm or invalidate the assumptions and hypotheses that we had at the beginning of the cycle. We can understand the actual needs of our users and, importantly, what our real value proposition of the product is.

This is an ongoing process. The team should continuously use feedback and data to inform development and adjust the product strategy as necessary. The learn phase is not the end of the build-measure-learn cycle—it's the beginning of the next iteration.

Quiz