Warning! Your MVP may cause discomfort (but it’s worth it)

We recently posted about how Co-op Digital and the Co-op Legal Service (CLS) combined their digital and legal expertise to build a service that makes it simpler to get a Co-op will. Together, we built something that’s both legally robust and easy to understand. In other words, it meets the needs of our customers.

But bringing together 2 contrasting ways of working so we could deliver this was tricky. The challenge was wider than combining the 2 disciplines. It involved building trust in the agile way of working with the wider Co-op business.

We start small

The digital team works in an agile way. Part of being agile is about getting value to your user as soon as you can through a minimum viable product (MVP). This means building the smallest usable thing that might be useful to them. Then, you watch how real users interact with it, listen to what they say about it and iterate and improve quickly based on what we learn from research.

Being perfect’s not the point

Releasing an MVP helps us build something useful at each stage of delivery and it’ll help us build the right thing. The point of working in this way is to avoid building and overspending on something that doesn’t meet user needs. So, releasing an MVP actually makes sound business sense.

But it takes time to learn about the needs of your users which means it takes time to build the best solution. This is a daunting process for anyone who isn’t used to working in this way, because an MVP is very rarely pretty.

In fact as Reid Hoffman, Founder of LinkedIn says:

“If you’re not embarrassed by the first version of your product, you’ve launched too late.”

A reputation to uphold

When we released our MVP, real Co-op customers were going to be using it to give details about their situation and to book in a call with one of our will writers. It’s understandable that anyone who’s unfamiliar with this way of working would be nervous about releasing a product with known problems. We’re operating in a competitive environment and what if potential customers were put off by a poor user experience? What if they went to a competitor instead? Would releasing an MVP put the Co-op’s wills services’ reputation on the line?

Reaching a compromise

The biggest sticking point was that the digital team wanted to release a very stripped back version that didn’t cater for a whole customer segment. CLS had an assumption that launching such a minimal service without the option to make a ‘mirror will’ (something often used by spouses) would put potential customers off.

As David Bland says in his post Spruce, the corporate minimum viable product:

“The challenge with a minimum viable product is that you decide what’s minimum, but the customer determines if it’s viable.”

The digital team had to trust CLS’s judgement on their customers and release something more developed than we might usually expect an MVP to be. We were happy to do this because we knew we could learn lots from doing things this way.  

Understanding each other better

The more the 2 teams worked together, the more the trust grew. CLS came round to the idea of releasing an MVP (or something close to one) after we explained:

  • it’s possible to iterate to fix any customer concerns in a matter of days
  • we could ‘turn off’ the beta instantly and we could also control the traffic to the online version and only allow access to a small percentage
  • the phone call part of the journey could act as a backup and we could help customers over the phone if they had any problems online part of the service

Data-driven decision making

Once we’d launched there was a mindset shift in the team and the wider business. Together we looked at data and tied that to user research instead of relying on assumptions.

Tracking user behaviour with analytics tools really helped confirm that releasing as early as possible was the right thing to do. It was like having a window to view a customer’s behaviour and we used the data to help make decisions about the product development.

We could see at which points customers were stopping their journey and this helped us prioritise work. For example, we knew that an automatic postcode lookup feature would be useful here. It was coming up in user research regularly as something that would help smooth the user experience. However, when we looked at the data in our analytics we found that the vast majority of people were filling in the address fields manually just fine. So we decided to de-prioritise building postcode lookup. There were other areas that needed attention before this.

Taking a leap of faith was worth it

The metrics tools helped us show stakeholders and the Co-op Legal Service the connection between our product improvements and the bookings and sales. We could also show that the online business is generating a new set of customers that’s not cannibalising the original service. We knew we could potentially scale this up which is really positive from a business point of view.

In the next few weeks the digital part of the team will start transitioning over to Co-op Legal Services who will continue to iterate the product.

Find out more about Co-op wills.

Ben Aldred
Product engineer

What we mean when we talk about a ‘minimum viable product’

Co-op Digital is helping the wider Co-op transform its business by building digital products and services. We know some of our readers have an interest in how technology and digital skills can help businesses but if they’re not part of that digital and design community they’re unlikely to be familiar with some of the terms we use in our blog posts. Soon, we’ll be publishing a post from the wills team on their ‘minimum viable product’ so it’s worth explaining this particular term now.

‘Minimum viable product’ or ‘MVP’ means slightly different things to different people and organisations but here’s what we mean when we talk about MVPs.

Defining ‘MVP’

At Co-op Digital we work in an ‘agile’ way to deliver software because we believe it’s important to give the user value, quickly. Part of working in an agile way is releasing an MVP to help us learn what’s working and what isn’t so that we can improve products quickly, cost-effectively and without needless risk or waste.

An MVP isn’t the first release of a big concept made up of smaller features. It doesn’t come with a plan to add more features in the next iteration whilst also trying to fix features that don’t work. It’s not the final product either.

To us at Co-op Digital, an MVP is the first attempt to solve our users’ problems. It’s an experiment. It’s the smallest ‘thing’ we think could be valuable to our members, our customers or other users. We then grow that thing based on the feedback we get from real use, by real people.

What’s the ‘minimum’ bit?

We want the most meaningful feedback and to do that, the product that users see must be real. But if we release loads of features at the same time it becomes difficult to work out which part of what we built was useful and which bits weren’t.

Des Traynor uses this graphic (adapted from a Peter Merholz presentation) to explain MVPs on the Intercom blog. It’s a good analogy to help explain.

image split into two parts. part 1 shows a cake base, cake filling and icing. part 2 shows a cupcake, a cake and a wedding cake

If our end goal was making a new kind of wedding cake, we might first test with a simple cupcake. We’d include just enough features to maximise our learning. We could get it into people’s hands so they could taste it and we could check the flavours and uncover any problems in our factory. With the feedback we’d get, we could then iterate quickly, safe in the knowledge we have the right ingredients and that our oven works, and so on. At each iteration we are providing value to the customer (cake to eat) and value to the business (cake to sell). We’d do that rather than try to build the wedding cake straight away.

In other words, building an MVP is about doing the least to learn the most.

Quick feedback, efficient improvement

Starting small means we can get a tangible product in front of users quickly, and start to observe, analyse and measure quantitatively and qualitatively. Getting started as soon as possible helps us quickly create a feedback loop that can prove or disprove our ideas for how to improve the product.

Starting with an MVP is a proven way to make the best use of an organisation’s effort and maximises the value for members, customers and other users. Best of all we’ll know the thing we’ve done works, before we invest in building it.

Ben Aldred, product software engineer