back to thedrum.com
MVP is one of those terms that means radically different things to different people. Here’s what it really means and how to avoid misunderstandings.
“An MVP is a process that you repeat over and over again: Identify your riskiest assumption, find the smallest possible experiment to test that assumption, and use the results of the experiment to course correct.” - Jim Brikman, Y-Combinator
Y-Combinator is Silicon Valley’s most prestigious start-up incubation programme. They have an interesting view on creating a minimum viable product (MVP).
They define it, not as a product at all, but as a process of testing your riskiest assumptions.
This is crucial for cash-strapped and overstretched start-ups because they can’t afford to take the same risks as established businesses. One misstep can have a huge impact on their viability.
The MVP approach allows them to run a series of micro experiments that expose risks, confirm hunches and correct their course as they go.
It means they’re able to place safe bets at every step of the product development process. Something larger organisations can learn from.
There’s often misunderstanding about what the term ‘minimum viable product’ means because an MVP can take many forms.
Ultimately, it’s not what you create or the format you choose that defines whether something is an MVP or not, it’s about what you’re trying to prove, test or understand.
There are many reasons you might choose to do an MVP, but here are some of the main drivers:
An MVP is the ideal way to test a new product idea with a specific audience group and understand whether there is traction within the market before investing further.
A second key reason to go down this route is to test the viability of your design or development or specific new functional or technical key features.
Lastly, you might want to build a proof of concept you can put in front of end-users, to test a hypothesis or idea and understand whether it’s something you can push forward with.
This is the approach we used to test different ideas in our work with UK Power Networks.
As part of our digital transformation work with UK Power Networks, we wanted to explore whether offering a Just Eat or Deliveroo voucher to people who’d had a power cut would help improve customer satisfaction.
But when we ran user-testing with a prototype being offered the voucher actually irritated customers.
Had we not tested this, we would have invested time and money to achieve a worse outcome.
This is a typical example of how you use an MVP, or series of MVPs, as part of a process, to test assumptions.
However, in our experience, this is rarely what people think of when they elect to go down this route.
Often, when organisations ask agencies to put together a proposal for an MVP, what we’ve tended to notice is that they really want a scaled down ‘Version One’ of a new site or product.
What’s driving the ‘minimum viable’ part of the brief is that there are constraints that mean creating a full-scale product isn’t possible.
If that’s the case, then it’s vital to have honest conversations about what is driving the decision. Is it there a deadline that you're trying to meet? Is it that you've got a budget constraint? Or is there another reason why you’re calling your project an MVP?
If you're not completely clear what your constraints are and what you’re expecting, it can be a dangerous term to use, both from the client and agency perspective.
As we all know, there are some areas where you can cut corners and others where you just can’t.
To avoid costly mistakes, you have to be ruthless about what you prioritise when you’re scoping your MVP’s requirements.
The hardest thing – and we see it all the time – is to stop adding in new things to your ‘must-have’ requirements list. This is because every new element adds complexity and potentially more time and cost to the project.
If you’re under a tight timeline or working to a fixed budget that you know can't be moved, you must exercise self-restraint and fight against scope creep.
Be aware that if you are being ruthless and still end up having 70% of your requirements in that must column, then you're not going to end up with an MVP. While that’s not necessarily a problem, it’s important to manage expectations around it.
There's absolutely nothing wrong with going live with the first version of a product that’s 85% complete and that you’ll keep building on. But bear in mind, that it’s not what an MVP is or what it’s for.
Both you and your agency must be clear what you mean by the term so there can be no misunderstanding around what will be delivered.
The last thing anyone wants is to end up with a mediocre product that you need to completely redesign a few months down the road because you each had a different definition of an MVP.
This is also why kicking-off with a good brief and being honest about your assumptions, budget and goals upfront is so crucial for project success.
