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.
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
Interesting I can also see how this approach aligns to our Ways of Being in terms of Doing what matters most and being agile and minimum. Succeeding together in terms of using real people for real feedback. The experimental nature of this approach feels like we’re being ourselves and in terms of maximising our efforts that’s surely a good example of showing we care about member resources by investing wisely.