Do We Build, Measure, and Learn?
Proposed by Eric Ries, the Build-Measure-Learn (BML) cycle describes a process by which we can go about building products that resonate with users. It was introduced as an alternative to the Waterfall approach to development that involves working away for weeks, months, or even years before shipping and then finding that users don’t find the product valuable.
This Lean Startup technique, however, does have its critics – people who think it’s an excuse for shipping unfinished products. Perhaps, what’s worse is claiming to work according to this cycle when, in fact, we don’t.
What is Build-Measure-Learn?
The Build-Measure-Learn approach is pretty clear-cut. It is a cycle or loop that features three major steps: build, measure, and learn. It refers to a process of creating a product, measuring relevant metrics, and learning from what we measure to improve the product.
This technique is intended to help us quickly realize when we are going in the wrong direction. It enables us to retrace our steps in a timely fashion before it is too late to do so. The cycle offers us a way of collecting and dissecting user feedback for useful insights.
Ries helped to popularize the Lean Startup, which he described in his 2011 book of the same name. Build-Measure-Learn is one of the focal principles or components of this methodology on how to build Lean startups. It is a framework of continuous improvement, bringing more value to the customer over time.
A Travesty in Practice
Sometimes, what we see isn’t what we get. This is also the case with the Build-Measure-Learn cycle at times. The foregoing describes what this feedback look should ideally look like, but what obtains in some instances is a charade or a farce.
With the aid of two diagrams, ace product designer C Todd Lombardo succinctly describes this state of affairs in a Medium post. The first image shows what the cycle ought to be like, based on Ries’ idea. The second portrays what some teams do in practice while claiming to build, measure, and learn.
Teams sometimes don’t really learn from what has been done. No measuring takes place, so no real learning. As Lombardo notes, what may happen here is to continue shipping more features working only with historical data.
Teams simply build, build, and build.
Apart from those who apply the Build-Measure-Learn idea the wrong way, there are also people who think it should be discarded. They view it as nothing more than a trial-and-error technique. To them, it is simply shipping crackpot products and waiting to see if we’d get lucky.
Such views can’t be further from the truth. It is not simply about shipping minimal features. The aim is to build with some level of confidence and certainty and not just based on unproven assumptions.
How the Build-Measure-Learn Cycle Should Run
We may have a problem with this framework if we merely took it as-is. What appears to be the first step is building the product, followed by measuring and learning. No, it is not something we take and run with that way. We need to understand that the three-step diagram is just an estimation of what the Build-Measure-Learn cycle should be. There is a need for us to make slight modifications before starting the process.
The following are helpful steps to follow when looking to apply this Lean Startup technique:
Define idea and plan – Before going ahead to build, we need to, first of all, establish the ideas that we wish to test. What do we want to learn by building? What hypothesis are we looking to test to see whether it’s valid or otherwise? We should plan how we intend to approach our hypothesis testing and how to collect the necessary data.
Build – This is the assumed first step in the Build-Measure-Learn feedback loop. No, the idea is not to build the final product or maybe even a prototype but rather something that can help us to test our hypothesis. It means building a minimum viable product (MVP). This is a product that offers just enough features to attract early adopters. It needs to be adequate for testing (or measuring) the idea that we have defined.
Measure – After releasing our MVP, we proceed to use the technique(s) that we had settled on earlier to collect the data we need. We then go ahead to analyze the data we have to find out what they are telling us.
Learn – This is the point where we draw our conclusions based on the data available. Does it support or contradict our hypothesis? Do the results show that the idea we have is sustainable in the long run? Learning has to do with drawing valuable insights from the data at hand. It is about finding out if we should continue (by iterating), pivot, or start something new.
We should take into account how this cycle and our learning relate to the product roadmap as well. The process can help us to plan a well-updated strategic document.
