Why Build, Measure, Learn Isn’t Just Throwing Things Against the Wall

As a kaizen consultant, I often hear pushback when introducing Build, Measure, Learn (BML) to leadership teams: “Isn’t that just guessing and hoping something sticks?”

It’s a fair concern — and one worth addressing directly, because the confusion usually stems from how BML is drawn, not how it actually works.

The Problem with the Diagram

At first glance, a BML diagram can just look like cycle of activity without a clear objective. Build something. Measure it. Learn. Repeat. If you stop there, it does sound like organized randomness,  a polished way of saying try stuff.

But that reading misses the entire point.

Where BML Came From and Why It Matters

To understand BML, it helps to know what it replaced.

For most of the 20th century, organizations operated using a waterfall model: define requirements, design the product, build it, test it, ship it. Customer feedback arrived at the end, after months or years of investment. 

Sometimes this meant learning the hard way that organizations had invested in products customers didn’t really want. Not because the engineering was poor, but because the assumptions baked in at the start were never tested. Version one was built in a vacuum. Version two started before version one shipped. By version three, the organization finally had enough customer data to build the right thing. It’s an expensive way to learn, and one most organizations can’t afford today.

Agile development improved the process by building iteratively and involving customers earlier. But even a perfectly executed agile process can’t satisfy everything. Agile only answers how to build, not what to build or why.

BML was designed to answer much deeper questions

Why BML?

Contrary to popular belief, the goal of Build, Measure, Learn is not to ship products faster. It’s not even to build better prototypes. The goal is to maximize learning — and to do so efficiently — before committing major resources to a direction that isn’t validated by data.

This tracks closely to what I practice as a kaizen consultant. Kaizen isn’t about change for change’s sake. It’s about identifying a problem, forming a hypothesis around what’s causing it, testing targeted solutions, measuring results–and then cycling back.

In BML, the “build” step refers to a minimum viable product,  not a stripped-down version of a final product, but the simplest thing that generates the most useful learning at that moment. Early in the process, that might be a sketch, a question sequence, a simulation, or a small-scale pilot. It’s whatever creates enough signal to validate or invalidate an assumption.

Each MVP is built to test a specific idea.

The Real Starting Point: Hypotheses, Not Ideas

Here’s where most teams get it wrong. They treat BML as beginning with an idea. In practice, it begins with hypotheses, which are fundamentally different. 

An idea says: here’s what we should build. A hypothesis says: here’s what we believe to be true, and here’s how we test it. 

This distinction matters enormously. An idea generates a plan. A hypothesis generates an experiment. And experiments, unlike plans, are designed to be proven wrong, which is what makes them useful.

In my work with organizations across Canada and the US, I see the same pattern: leadership teams arrive with ideas dressed up as certainties. The Kaizen approach reframes those certainties as assumptions, then designs structured tests to challenge them before the organization commits significant time, budget, or team capacity.

Additionally, I bring a distinction that most even most consultants don’t understand–the process of BML should be built around Objectives and Key Results (OKRs). When OKRs drive the BML process, results tend to be even bigger, faster, and more impactful.

Experiments tend to answer important questions like–who is the customer really? What does value actually look like from their end? Does the pricing model hold up under scrutiny? What distribution path causes the least friction>

None of these can be answered by simply building a product. They’re answered by designing experiments.

Hypotheses (fed by OKRs) → Experiments → Tests → Insights

A more accurate version of the BML loop looks like this: Hypotheses — Experiments — Tests — Insights.

This framing clarifies that the loop isn’t about iteration for its own sake. It’s about moving from assumption to evidence systematically, and with each cycle building on the last.

The goal Is Insight, not data.

Any organization can collect data. What’s difficult, and what distinguishes teams that improve from teams that stay stuck, is extracting insight from data and using it to productively pivot directions.

This is where leadership discipline matters most. There is always temptation to run the loop and then rationalize the results rather than learning from them. Confirmation bias doesn’t disappear just because a process is structured. It has to be actively managed.

As a Kaizen consultant, the question I bring into every engagement isn’t “what did you measure?” It’s “what did you learn, and what did you change as a result?”

Using BML for Productive Improvement

Whether you’re a startup searching for product-market fit or a division inside a larger organization trying to innovate without wasting resources, BML done properly is a rigorous, hypothesis-driven process,  not a shortcut.

It is, in fact, exactly what Kaizen practitioners have always advocated: go and see, test your assumptions against reality, learn from the data, and build a culture where that cycle runs continuously at every level of the organization.

That’s not throwing things against the wall. It’s a proven model for improvement that actually sticks.

Are you ready to build management systems that drive continuous, measurable improvement? To discuss how this applies to your organization, reach out at leslie@leanexpansion.ca or 416.528.7990.