Innovation // How to become a more data-driven organisation

In our white paper “How to become a more data-driven organisation”, we wrote about the five steps that an organisation would need to take, which are:

1. Outcomes: Defining goals and metrics to ensure clear and measurable outcomes
2. Analytics: Implementing and sharing the analytics to improve data-driven decision making
3. Innovation: Testing assumptions through hypothesis testing and learning
4. Data Platform: Gaining new insights and enabling more intelligent features through improved data integration
5. Culture, Skills and Capabilities: People who believe in and understand the new ways of working are as important as the technology

This deep-dive will focus on Innovation and how we can create meaningful hypotheses and create experiments to provide us with the data we need to make better decisions. 

What is an MVP?

MVP stands for Minimum Viable Product. The basic concept is pretty simple: what’s the smallest thing that we can build to confirm if our core assumption is correct.

We do this by listing out our assumptions, selecting one, then creating a hypothesis to test. More on this below.  Over time, this basic concept has evolved to mean different things to different people.

Quite often, we hear clients and colleagues refer to a limited number of features as an MVP, where Epic user stories have been broken down into smaller stories and only a preordained few features make it through to release with a view of adding more at a later stage. We tend to think of it as a Phase 1 rather than an MVP.

Often these features are decided upon based on commercial or business rationale in a meeting room rather than testing an assumption for viability for resolving a genuine user, customer or other types of problems.

They aren’t testing any assumptions or looking to test and learn. Instead, they have decided that this is the feature set, and we will break the product down into smaller pieces and deliver it iteratively.

What are assumptions? Why are assumptions important?

Assumptions are a set of statements that we currently believe are true, although we acknowledge that there is a risk that we may be wrong

At the heart of every product, there should be a desire to solve a problem. Often, these problems are based on our personal experiences, but how do we validate that others may also have these problems? How do we validate that whatever solutions we dream up will help solve these problems?

In short, we list out all our assumptions and then decide the most important one to test to validate our thinking.

The Uber Example

Here is a selection of some of Uber’s initial assumptions before creating their MVP.

• People want fast access to cheap rides
• Drivers will be open to flexible work schedules
• Drivers will use their own cars
• Passengers will switch from using licensed cabs
• Passengers will trust drivers
• Drivers can easily know when and where to pick up a passenger
• We can manage a marketplace through fare elasticity
• We can build a customer base cheaply
• Management of rides can scale through automation
• Customers are Urban car owners who don’t feel like driving
• Customers are Urban non-car owners
• What you see here are some of the core assumptions that the founders of Uber had when it comes to finding a way to disrupt the licensed taxi industry.

The next step is to create a hypothesis to test.

What is a Hypothesis? How do you create one?

Here is a framework or template for creating a hypothesis which breaks it down into four different sections. Here they are and I will explain and give an example from Uber on each one separately:

1. We believe that [describe a category or segment of customers] will [behave in a certain way]
2. If we create [this experience]
3. We will know our assumption is validated when we see [this evidence]
4. We will see that outcome within [this timeframe]

Given the Uber example above, here is the hypothesis that the founders of Uber tested:

1. We believe that busy urban professionals will use a mobile app to hail an unlicensed taxi
2. If we run a pilot with a free web promotion and 20 cars in New York City
3. We will know our assumption is valid when we see 10 passengers per driver per day
4. We will see that outcome within 1 month

So this is what they did. They tested their most fundamental assumption – that busy city workers would use a mobile app to hail an unlicensed taxi.

They didn’t have to have the full proposition developed and launched in order to test this most basic of assumptions. Once they validated this core assumption, they were able to continue testing their assumptions and build out their platform.

Build, measure, learn – the feedback loop

The format of the hypothesis as outlined above gives you all you need to follow the build, measure, learn feedback loop. It clearly allows you to state what it is that you are testing.

• Learn: Hypothesis is that busy urban professionals will hail an unlicensed taxi via a mobile app
• Build: A mobile app that will allow users to hail one of the 20 cars available in NYC
• Measure: How many passengers each driver has per day – with a minimum target of 10 passengers per day – with a 1 month period

The results of the test will hopefully give you the information you need to validate your hypothesis. You can then move onto the next assumption or change your test.

A light touch approach

It is so easy to over-complicate a product or service. You feel so passionately about it that you speak to friends, colleagues, networks about it and you have enough confidence to build the final product.

Be sure to test the fundamentals of your offerings before you invest a lot of time, effort and money into something.

The data you gather from these tests will help validate demand for your product and help to shape your proposition.