What is 'Minimal Viable Product?'

What does MVP really mean?

In this article, designer? Laura Smith ?summarises reflections from our Head of Product,? Martyn Evans ?and Delivery Manager? Marie Ferreira . At Unboxed, we find that clients can interpret MVP in different ways, and that can impact the value of this experimental approach.

At Unboxed, we want to design better services. We spend a lot of time understanding what our clients need to deliver a service in a way that works for both service users and for the people who manage it day to day.

MVP, or minimum viable product, is one of the approaches we use to get our clients from insights (learning about what users want and need) to implementation (building or buying a solution). But we’ve found that people understand ‘MVP’ in different ways, particularly in the public sector. This can lead to tension and misalignment about what and how we’re delivering.

So what does it mean? And can MVP ever work in the public sector?

The origins of MVP

The definition of MVP has been somewhat stretched and distorted since its beginnings in the world of software development.

In simple terms, MVP, or minimum viable product, is about building the minimum features that allow us to deliver some value to users. In other words, users can use the product to do something that is useful to them. We need to deliver enough value to get feedback and better understand what users want and need. Then we can reflect and build the next feature or improve the features we’ve got.

We end up with a leaner product, it costs less and it’s available sooner.

MVP was one of the core concepts within the lean startup approach. Though even Eric Ries, a pioneer of lean startup, struggled to get MVP right.

“One of the most important?Lean Startup?techniques is called the?minimum viable product. Its power is matched only by the amount of confusion that it causes, because it’s actually quite hard to do. It certainly took me many years to make sense of it.” Eric Ries, author of The Lean Startup

Lean startup uses the terminology ‘product market fit’ (PMF). PMF is a period of experimentation to find the right product for the right market. You can do a lot of exploring early on without building anything — for example, through research or prototyping. Once you’ve validated your thinking, you can give a basic version of your product to people to see if they will pay for it and use it. Then you can learn some more until you understand which version of your product ‘fits’ with the market need.

An example

With?online sexual health service, SH:24, we took their insights from discovery and did some validation with users through very lo-fi prototypes — web pages drawn out on paper, STI test kits made from cardboard, SMS messages sent manually to one person at a time.

Once we had some initial feedback we built a working product very quickly. We were writing code without tests. We pulled a designer through the service. We hacked together a throwaway solution and learnt a lot along the way. It was one hell of an experiment but it meant SH:24 knew what their product was and how it met the needs of their market. They were able to build the full service in a way that allowed them to scale it afterwards with less risk and more confidence.

An MVP like this is one way to do PMF. So far, so many acronyms.

The point is that MVP is an experiment. It’s meant to be for learning. When you’ve got some ideas about your solution, you can gradually do more and more work to prove your assumptions.

MVP is not the thing you are building. It’s a way of getting there. The name — minimum viable?product?— doesn’t help much. But the danger lies in building something without doing all the experimentation and work to get to that point.

MVP in the public sector

MVP worked at SH:24 because the board had an appetite for risk, in part because they had the security of external funding.

We work with many public sector organisations, from central Government to local authorities and NHS Trusts, where the appetite for risk is, understandably, much lower. From the start, we need to ask some questions to understand the culture:

what is the client’s appetite for building products from scratch versus buying products off the shelf?

• what is their understanding of MVP?
• are they prepared for our experiments to fail?

We often end up with two big challenges to MVP:

1. A lack of capacity or appetite amongst staff (internal users) to engage with the MVP

2. A focus on product over approach

Doesn’t MVP mean more work?

Say we’re building a new tool for planning officers to process planning applications. These are busy people with a lot of admin who need software that, as a minimum, allows them to do their job. Ideally, it would make their job easier and more efficient.

It’s a complex project. We’re trying to engage many different councils at once and manage lots of political stakeholders. But we can only build a little piece of the puzzle for them. For planning officers, they need this little piece to do everything the current system does.

There are two things that might happen during MVP:

• we ask them to use a tool that, at the moment, does part of their job but not all of it. So they need to find another way of doing those other things, perhaps on bits of paper or spreadsheets or some other workaround
• we ask them to use the new tool for some parts of their job. But they still need to do all the other parts of their job in the old system, so they end up doing things twice in two different systems that work in different ways.

Either way, it’s more work for them. They may not understand the principles of MVP. They’re probably not even interested. They just want the finished product so they can get on with their job.

When people are already working to capacity, it’s hard to give them the time and space to engage with an experimental approach in a positive way. It’s no wonder that a council IT Director recently told us that,

“When people [working in councils] hear MVP, they think ‘crap solution’. They don’t want MVP.”

It’s different in the entrepreneurial world where it’s the investor who is taking all the risk. In the public sector, you’re expecting your employees to invest in the MVP when they’re too busy doing their day jobs. They get the same salary regardless. Unlike an investor, there’s no chance of a big pay off further down the line.

We often hear the term MVP used as a noun — ‘let’s build the MVP’, ‘let’s deliver the MVP’ which isn’t helpful to people who need to understand it as a process that they are part of, not as an end result which they can look forward to.

It can be difficult for us to challenge that way of talking about things.

We need to understand the reality for people who are actually using the tool. We need to understand their working culture and what the MVP process will mean for their day to day. Then we need to help them understand the value that they can get from it, for themselves and for the services they deliver.

A fixation on products

In the public sector, many, many employees are already using software which doesn’t do the job perfectly. The company that makes that software has built something that mostly works for lots of customers, it makes money and they can adapt it and sell it to others.

But it shouldn’t be about the product. A council should be able to focus on the?service?they want to deliver to users. What do they need that service to do? What impacts does it need to create for users?

MVP allows the council to prototype solutions, see what works, then go to the suppliers and tell them — these are the outcomes we want, can you build something that will deliver these outcomes? Starting with the product is the wrong way around.

In service design, we talk about products as something you buy, services as something you deliver. Too often, ‘MVP’ is couched in a mindset of delivering a product. What we should be saying is, “How can we use the MVP approach to improve or test innovations in our service?” A product may be part of that, but it exists to help us deliver a better service to residents or customers or whoever our users are.

Culture as a barrier to MVP

Culture is so important. Lots of people want to come up with ideas for new products and services. Maybe they even want to invest in them. But far fewer people are prepared to fail.

A key principle of lean start up is ‘fail fast and learn’. Entrepreneurs recognise that they’re investing money now, even though it’s high risk, as the rewards will be greater down the line. Testing and learning helps you reduce risk through a series of iterations, rather than building everything and hoping it will work.

Entrepreneurs generally have quite high appetites for risk. They move quickly, learn quickly, validate their thinking and move on. They might make 3 or 4 investments of ￡100,000, knowing that some of them will fail, but one of them will make them ￡20 million.

But the people we work with often just want to do their jobs and get paid well for them. In the public sector, there is very limited appetite for risk and even less from the politicians at the top. So they want to innovate without risk. MVP seems like a perfect option — they can produce a product quickly, simply and people can start using it. There’s no failure.

Either that or everything slows down and becomes too big to fail. Councils can’t be seen to be gambling with public money, so they need to keep building on top of the thing they’ve already got. It’s very difficult to cut their losses and start again.

How do we create an MVP mindset?

Google ‘MVP’ and you’ll find a diagram that shows two different approaches to building a car. The first starts with wheels, then a chassis, then ends up with a car. The user can’t use the product until it’s finished. The second starts with a skateboard then moves through a scooter, a pedal bike and a motorbike before getting to the car. The user is happy as they can use the product from its first inception as a skateboard. This diagram shows two things:

1. MVP is about building something that people can use right from the start. You can learn from how people use it, then iterate and improve.
2. MVP should be based on the outcome for the user, not the solution. The first option assumes the user needs a car. The second option is addressing the user’s need to move around. Through trial and error, they end up with a car.

You can try something small, learn what works, invest a bit more, learn some more, build some more and so on. In the alternative model, you’re building a whole car which no one can use until the whole thing is complete. People might say they’ll use it but you don’t know until you can actually let them try. Then you don’t know if they will keep using it. MVP helps you reduce risk and cost through a cycle of build, test, learn.

But this doesn’t always work, particularly in the public sector. It’s hard to say to people that you’re going to give them a skateboard when they’ve already got a car. The car might be a bit rubbish and creaky but it’s better than a skateboard. It’s hard for people to get on board with the concept.

An example from the public sector

MVP can work in the public sector, but the appetite and the funding have to be right.

Here’s an example of where MVP did work in an NHS Trust.

Through a service-wide discovery process, we had identified an opportunity for a better referral service within an NHS hospital.

Problem:

When patients arrive for an appointment the referral information can be incomplete. That makes the first appointment with a consultant like an expensive triage. The consultant needs to work out whether the patient even needs to be there.

Our hypothesis:

If we could get better information from patients before they attended, we could reduce the amount of wasted appointments by triaging patients to the right care, faster.

This might mean building an online form, integrating with the booking system — lots of work. We weren’t yet convinced that it was the right thing to do. We needed to know:

• would patients be able to give us the information we needed?
• would that information be useful for a clinician?

Experiment 1:

We went to the waiting room and asked patients to fill in a survey on a paper form. After that, the patient had their face to face appointment with the clinician as planned.

A different clinician then looked at our survey results from 100 patients. He compared the decisions made in their face to face appointments to the decision he would have made based on the information in the paper form. He was happy that these decisions lined up and that the information that patients had given would be useful in advance of the appointment. The clinicians could use that information to triage patients to the right care, reducing the amount of patients that needed to see a consultant and reducing wasted time for both patients and clinicians.

Experiment 2:

We’d tested the form with bored patients sitting in a waiting room. We needed to know whether they would complete it online in advance of their appointment.

We created an online survey with a free tool. We sent it to patients a couple of weeks before their appointment and they filled it in, giving us broadly the same information as they had in the paper survey.

What we learnt

1. people will fill it in an online form
2. we know that the data is useful for clinicians

The Trust was then more confident to invest money in a product that would do the same thing in a more efficient way.

Outcome

The Trust used some existing tools and an existing supplier to build the tool, and it worked. Unboxed didn’t even build the product at the end of it.

We delivered value by helping the Trust to test an idea and understand what they needed to build before they commissioned a supplier. This was the MVP.

Setting the environment for MVP

We meet many public sector clients who get MVP and who want to do it well. How can we support them to get the most value from an experimental approach?

Start the conversation early

Use your project kick off meeting to understand what the client’s perceptions are of MVP. Set out the value of the approach. Listen to what they think it means for their role and their involvement in the project. If people are unsure, or confused, or hostile, address that up front.

Service design works best when we build relationships?that allow people to question and challenge the approach from the start. This way you can address concerns and bring people on the journey with you, rather than having to deal with push-back mid way through a project.

Get the product owner on board

We’ve worked with POs who use the term MVP repeatedly — ‘let’s build the MVP’, ‘we’re building an MVP.’ This becomes the basis for the project — this is the thing we’re building — so that’s what their team understand by it.

We need to do more to challenge that thinking early on. We need to help POs to explain to their team that MVP is not what they are delivering but how.

Be honest

MVP can be scrappy, it can mean duplicating work while features are being tested. We might be asking people to try out a prototype that does some of the things they need but not all of them, while still using their old system. If people don’t understand how this is going to help them in the long run, it just becomes a frustration.

We need to have a discussion early on about 1) how the approach will affect their day to day and 2) how their involvement will help create a better service. The MVP is not the end goal, it’s a way of getting there.

Build in time for training

We run an agile training course for clients. It includes a whole section on MVP. It’s something we do early on in a project to help everyone understand the value of an agile approach. It also gives people a safe space to ask questions and check their understanding of MVP.

We look at how MVP supports agile principles of delivering value quickly and iterating on it. Then we set it in the wider context of agile ways of working, ceremonies, planning, backlog, scrum and so on. We help people to create their own language around all this and find the bits that they can take into their work.

Challenge the brief

We met with one Head of Digital from a local authority. They wanted to design a better way for residents to report potholes. Our first question was — how do you know that’s what residents really want? Maybe they just want fewer potholes?

Unless you are absolutely certain that your idea is the best way to meet the needs of your users, then your idea is just an assumption. MVP is a great way to test that assumption. The brief shouldn’t be ‘build an MVP’ but rather ‘help us work out what to build’.

When does MVP stop being MVP?

When you’ve built a product that has most of the functionality that users have asked for. In the example above, our simple survey gave the clinicians the information they needed to triage patients. It didn’t integrate with their systems or automate messaging or do any of the other things that might be useful, but it allowed the team to understand the value of that product to improve their service to patients.

It’s useful to think about the GDS approach of discovery, alpha, beta, live. Beta is a process of developing the full service. It’s live when you switch off the old service.

You could say you’ve reached MVP when the people stop using the old service to do the things that the new service does. Your product or service is now viable.

In the commercial world, your product is viable when you can be confident that people will use it and pay for it and you’ll make a return on your investment. You can still take an MVP approach to adding new features and improving your product. Facebook, for example, apparently used to release?fake door tests?every day. These might be buttons offering new features, even if the feature didn’t exist yet. They just wanted to see if people would click it.

MVP is a journey

MVP represents the journey from insights and ideas to a product that you know is going to work, that you know is going to provide better services to your customer and which allows your team to deliver that service efficiently and effectively. MVP is a way of innovating and understanding how technology can help to fill that gap.

At Unboxed, we try to fill that gap. We take the insights and design solutions, we prototype and test them, we learn more about what it is you and your users need. Then you can build the right product, or buy it if it already exists. MVP is a means of getting you to that point — to making the right decision with less risk and more confidence.