Build, Measure, Learn cycle
One of the key components of the Lean methodology: the Build, Measure, Learn cycle is a way to gather and analyse feedback. First seen in the Lean Startup Book by Eric Ries. The process is all about learning fast, so you can build fast. This is done by measuring early and using the outputs to enhance your learning.
The process is best described as a cycle approach. In the inner circle you have the stages: Ideas, Code and Data and on the outside you have the steps to move from stage to stage: Build, Measure and Learn.
The overall purpose of the cycle is to “Minimise the total time through the loop”. But how is this done? We will start with Ideas and work our way around the cycle:
IDEAS
This part of the process is concerned with ideation and planning. First part is to work out what the focus of the cycle should be. Is it based on a learning from a previous cycle or an idea from the internal team. Either way you should spend time doing ideation activities to expand the idea further.
The second part is planning and working out what experiment you need to conduct. What does that mean? Experiment is a term that is used a lot across Lean, Agile and Design Sprints. An experiment is essentially a test. It can be as simple as a change in wording, or as complex as a new feature. To get the most out of an experiment you need to identify the hypothesis you are trying to prove. The hypothesis should come from any assumptions you have made in the ideation or from the learnings of any previous experiments. Once you have the hypothesis you can plan how to prove or disprove the theory. This is the experiment. Examples of experiments could be A/B testing a website to see if changing the words on a button increases the amount of click throughs, or changing the opening hours of an online chat functionality decreases wait times.
The key to experiments is to make them small enough that they are quick to build and test. This will reduce costs and maintain the “Minimise the total time through the loop” ethos.
When planning the experiment you need to understand how it is going to be measured so that the necessary elements are included in the build.
BUILD
It’s now time to take your idea and turn it into code. Within the Lean Startup context this is where you would create your Minimum Viable Product — MVP. If you are in the growth stages this where you add the new features to expand your product.
While conducting the build it is important to make sure you follow best practices in terms of Unit tests, Continuous Integration and Incremental Deployment.
CODE
Now you have your code and it’s ready to deploy. Before you deploy it though it is worthwhile making sure that any required refactoring from previous cycles have been included. Otherwise you are left with a lot of unfinished features, and technical debt.
MEASURE
Depending on the maturity of your product, how you plan to measure your experiment can differ greatly. You may be measuring through capturing analytics, running UX testing on prototypes or even having shadow sessions with users.
DATA
How ever the measurements are captured you need to analyse the data. This can either be qualitative or quantitative (See our post on Qualitative vs Quantitative). To analyse the data it should be grouped, sorted and filtered. Insights and trends can then be identified.
The data then needs to be presented and shared across the internal team. At this stage it should be also compared against previous data.
LEARN
This is the critical part of the process: Make a decision on what to do next. The decision should be based on the insights and trends from the measure stage. Generally there are two possible paths Pivot or Persevere. Pivot means you change direction either partially or fully. Persevere means you carry on what is there and move on to the next cycle.
— -
The process described above is only a general overview of the process. More details on the process can be found in the Lean Startup book by Eric Ries.
How do we use the process at Siso
At Siso we are all about adapting. Instead of having a single cycle approach we use a double cycle approach.
The main reason for this is that we find focusing on one experiment at a time can often mean that a single feature is developed well, instead of developing a full product. By having multiple experiments running at different stages means we have continued learning and more rapid improvements. This takes the “Minimise the total time through the loop” ethos to the extreme.
Another thing we do is that we don’t use the pivot and persevere approach to learning. We instead use the Google Design Sprint outcomes of:
- An efficient failure
- A flawed success
- An epic win
Using these gives us more depth to next step discussions.
We don’t use the Build, Measure, Learn cycle in isolation. We use it along side Agile methodologies and the SUDA framework.
— — —
This artcile was originally published on http://www.siso.co.nz/2019/11/10/build-measure-learn/