The Hypotheses, Design Experiments, Test, and Insights Process

Contents

Introduction

Business Creation and Improvement Methods

The Build, Measure, and Learn Process

The Enhanced Build, Measure, and Learn Process

The Hypotheses, Design Experiments, Test, and Insights Process

Introduction

It is instructive to delve a little into the history of Business Model Development Processes before discussing the Hypotheses, Design Experiments, Test, and Insights Process.

If you want to skip straight to The Process, then click here.

As with many endeavours, when contemplating creating a startup, you need to develop a strategy that is appropriate to the scale and context from which you are starting at. With this in mind, a startup is not a smaller version of a large company. In a large company, much is known about the market segment and its customers as well as the Solutions that satisfy those customer’s needs. Furthermore, large companies have different agendas, budgets, and have relationships with customers and distributors, suppliers, and government bodies. Therefore, a startup’s starting position is likely to be quite different to that of any large company.

Lastly, a startup’s purpose is to learn – a startup is a temporary organisation searching for a scalable, repeatable, and profitable Business Model. Paraphrased from The Startup Owner’s Manual Strategy Guide, Steve Blank.

Business Creation and Improvement Methods

There are many iterative methods for creating and improving businesses, and they all share a theme of maximising benefits while reducing risks of failure and waste. One such method is the Plan, Do, Check, Act (PDCA) process.

During the genesis of the Lean Startup Movement, a process similar to PDCA was developed for startups, called the Build, Measure, and Learn Process.

For a mercifully brief history and the basis for this paper, please refer to Why Build, Measure, Learn – isn’t just throwing things against the wall to see if they work – the Minimal Viable Product, Steve Blank.

The Build, Measure, and Learn Process

The purpose of the Build, Measure, and Learn process is to learn as much as possible about customers’ needs as well as the proposed value proposition to satisfy those needs. The principle employed is incremental and iterative – repeatedly investing the least amount to test hypotheses, while learning as much as possible from experiments, as quickly as possible.

A hypothesis (plural Hypotheses) is a fancy name for a guess. For our purposes, a hypothesis is a provisional idea, a prediction, whose merit requires testing. To be useful to us, a hypothesis must be expressed in a form that we can test it.

The process is repeated, increasing the fidelity (detail and exactness) with each cycle of the process to learn more, for as long as there is more to learn:

• Build – a Minimum Viable Solution (MVS) to test hypotheses based on identified Jobs To Be Done (JTBD), that is needs, and test the MVS with real customers in their natural habitat.
• Measure – the results of customer testing, for example, the MVS performance, price, and customer reactions and feedback.
• Learn – from the analysis of the results and synthesise lessons. From the lessons, there are four possible outcomes – repeat another cycle of the process while increasing fidelity, pivot to another idea and start a new process cycle, abandon all further exploration, or launch a business and scale for growth and sustainability.

The original method only had the Build, Measure, and Learn functions, with later modifications adding Ideas, Minimum Viable Solution, and Data to make intermediate or implicit steps explicit:

• Ideas – precede building the MVS in the Build stage.
• Minimum Viable Solution – is the output of the Build stage and measurements (results) of the MVS in test are recorded.
• Data – is the output of the measurement stage, which becomes information via analysis, from which lessons will be synthesised.

The Enhanced Build, Measure, and Learn Process

Further modifications by the author added the Pivot, Abandon, and Launch and Scale stages to make the options at the Learn stage explicit:

1. Pivot – and start a new process.
2. Abandon – the project as futile.
3. Launch and Scale – a business for growth and sustainability.

The Method Explained

Job To Be Done

The beginning of every navigation of the process starts with identifying a Job To Be Done (JTBD), that is, a hypothesis about a customer need. To reduce the risk of waste, an entrepreneur does not spontaneously start with a Solution to an imagined need.

Ideas

Having identified a JTBD hypothesis, the entrepreneur develops ideas for how the JTBD hypothesis as well as how the hypotheses to fulfil the JTBD can be tested.

Build

The entrepreneur builds a Minimum Viable Solution (MVS) such that the hypotheses can be tested. Being an incremental and iterative method to test hypotheses, no attempt is made to build the complete Solution.

The testing of hypotheses and the ability to gather meaningful test data must be carefully considered during the design of the MVS. The aim should be to achieve repeatable and verifiable test results from both qualitative assessments and quantitative measures.

The entrepreneur then takes that MVS out of the office into the real world and tests it with or on real customers in their natural habitat.

Minimum Viable Solution

At this stage, the MVS is a minimum bundle of benefits worth paying for that tests specific hypotheses of the JTBD and what the value proposition is, at this point, envisaged to be. Although the MVS is a subset of the final Distinctive Value Proposition (DVP), it is still a bundle of benefits and value worth paying for.

Within the functional scope of the benefits that the current MVS provides, it (and therefore the hypotheses) is tested in the wild.

Measure

While the MVS is being tested, the entrepreneur carefully measures every aspect of MVS use, performance, and customer response, paying particular interest in validating or invalidating each hypothesis.

Data

From the tests, meaningful data that will lead to insights is collected.

This data will be used to either validate or invalidate the hypotheses and to synthesise insights.

Learn

The data is analysed, the status of hypotheses established, and insights are synthesised.

From the insights, a choice needs to be made about the next steps to take:

Repeat

One or more hypotheses were more or less validated, and it is deemed worthwhile to invest more to learn more, by say testing more hypotheses, with another circuit of the process.

One or more hypotheses may have been invalidated, but information has led to improved and or new hypotheses.

With each circuit of the process, the fidelity is increased to learn more.

Pivot

The project has invalidated the hypotheses (also see Abandon below), but another opportunity with new hypotheses has been uncovered from the insights synthesised.

Based on the new hypotheses, a new circuit of the process is begun, and the process repeated.

Abandon

The project has disproven the hypotheses and will be abandoned. Possibilities include:

• There is no JTBD, or it is not so important that anyone cares and wants a Solution for it.
• The projected costs of DVP development are too high and or rewards too small and or too uncertain to risk continuing exploration by starting another circuit of the process.
• The resources and or enthusiasm to continue exploration have been exhausted.

Launch and Scale

The project has proven to be successful, meaning that the final hypotheses were validated, and the last MVS was either the final DVP or close enough to being the final DVP that there is little more to learn, that warrants another circuit of the process.

All that remains is launching the DVP and scaling the business.

Summary

A concern with both the plain and the enhanced Build, Measure, and Learn Processes, especially with the diagrams of the processes, is that it is implied that you are building something, in order to test hypotheses via experiments. Since implications take too much to explain and can lead to wrong assumptions and to oversights, it is better to be more explicit with our models – with less to explain, there is less to get wrong. This leads us to The Hypotheses, Design Experiments, Test, and Insights Process in the following section.

The Hypotheses, Design Experiments, Test, and Insights Process

The limitations of the previous processes have been to an extent addressed by the following model.

In the diagram above, you can see that the process has within it a loop, or repetitive cycle, starting with Hypotheses, moving to Design Experiments, and working its way back to Hypotheses again.

The Method Explained

Job To Be Done

The beginning of every navigation of the loop starts with identifying a Job To Be Done (JTBD), that is, a customer need. To reduce the risk of waste, an entrepreneur does not spontaneously start with a Solution to an imagined need.

Hypotheses

The process cycle begins by acknowledging that the ideas spawned by what you imagine is a JTBD are simply untested hypotheses. Whatever we design and build will need to match the hypotheses we want to test.

Having identified a candidate JTBD, the entrepreneur develops a set of hypotheses about:

• The JTBD.
• Who the customers and users are likely to be.
• What the Minimum Viable Solution (MVS) or Minimum Viable Distinctive Value Proposition (MVDVP) will be for the current circuit of the loop.
• What the Distinctive Value Proposition (DVP) will ultimately be.
• Pricing.
• Distribution.
• Demand creation.
• And many more …

As more insights are gathered with each circuit of the loop, hypotheses will likely be discarded, modified, and new ones developed.

Design Experiments

Experiments are specifically designed to validate or invalidate the hypotheses. There will likely be different experiments, and therefore MVS to test specific hypotheses, such as finding the right customer versus confirming the category benefits.

The experiments will initially be in the form of an MVS, building with each successive circuit of the loop to a MVDVP, and finally onto the DVP. There is a subtle distinction between MVS and MVDVP compared to prototypes. MVSs and MVDVPs are designed specifically to learn as much as possible on the path to validating or invalidating the hypotheses, they are not successive iterations of prototypes.

Being an incremental and iterative method, no attempt is made to build the complete Solution or DVP at the outset.

The entrepreneur then takes that MVS out of the office into the real world and tests it with or on real customers in their natural habitat.

Test

At this stage, the MVS or MVDVP is a subset of what the final Solution and value proposition is, at this point, hypothesised to be. Although the MVS and MVDVP are a subset of the final DVP, they are still a bundle of benefits and value worth paying for.

Within the functional scope of what the MVS or MVDVP currently is, it is tested in the wild.

Insights

The goal of the experiments is not to collect data as such, but to analyse meaningful data to synthesise insights that will inform the next steps in the process and therefore startup journey:

Repeat

There are many reasons to repeat the process:

• One or more hypotheses were more or less validated, and it is deemed worthwhile to continue investing to learn more with another circuit of the loop, with as the case may be, new and or improved hypotheses.
• One or more hypotheses may have been invalidated, but insights have suggested new and or improved hypotheses.

With each circuit of the loop, the fidelity is increased to learn more.

Pivot

The project has invalidated the hypotheses (also see Abandon below), and or another opportunity with new hypotheses has been uncovered from the synthesised insights.

Based on the new hypotheses, a new circuit of the loop is begun, and the process repeated.

Abandon

The project has invalidated the hypotheses and will be abandoned:

• There is no JTBD, or it is not so important that anyone wants a Solution for it.
• The projected costs of development are too high and or rewards too small and or too uncertain to risk continuing exploration by starting another circuit of the loop.
• The resources and or enthusiasm to continue the project have been exhausted.

Launch and Scale

The project has proven to be successful, meaning that the final hypotheses were validated, and the last MVDVP was either the final DVP or close enough to being the final DVP that there is little more to learn that warrants another circuit of the loop.

All that remains is launching the DVP, and scaling the business.