Why you need to stop obsessing about your MVP

Minimum Viable Product (MVP) was a great concept. It sheds light on our assumptions and helps us think about how best to approach our product development journey.

However, its greatness is perhaps only matched by the great confusion it causes. While intuitively ‘gettable’, its meaning is often confused, co-opted or lost altogether. So much so, that in some circumstances it gets contorted from something designed to help us reduce uncertainty and improve our chances of success to something that is used to create a ‘theatre of certainty’ and definitely won’t help our chances of success.

Where does it get misunderstood? And how should we think about MVP to make the most of it? We’ll get to that in a moment, but first, let’s briefly reflect on its origins.

Mitigating risks

Building successful new products and services is a complex undertaking. Success will be determined by many factors and variables. Some of which will be known and ‘certain’, some of which will be unknown, while others will be educated guesses and hypotheses which may prove to be true or false. This is where MVP comes in.

MVP was popularised by Steve Blank and Eric Reis (Lean Start Up Movement). For Reis, the definition was a ‘version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort’. While Blank and Reis get the kudos, it was actually Frank Robinson from SyncDev back in 2001 that coined the phrase (yes, almost two decades ago). For Frank Robinson, MVP was founded in the principle of “maximising return on risk”. The key word here is risk. There’s plenty of commentary about the nuanced definition, but for me the essence of MVP is unequivocal:

By identifying and validating critical assumptions and risks, as efficiently as possible, we will improve our chances of success.

Doing this alone won’t guarantee success. We still have our known-knowns to build and deliver on and there’s the unknown-unknowns – things that crop up during our product development journey that we need to address. But MVP was a brilliant way for us to think about mitigating the risks associated with our bets on what are the critical factors for success.

So how does MVP get misused?

Here are a few common examples.

• MVP as the ‘minimum thing’. A simpler, faster, lower-cost version of some ‘full thing’. There’s rarely an acknowledgement that it’s a test. Even rarer are the conversations that it might actually fail or lead to a pivot. This usually happens because of a fixed release date, budget or it’s a wheeze to convince someone to fund an initial version!
• MVP without the ‘viable thing’. Let’s say you’ve got an idea for a new eCommerce service targeting a niche audience. The viability of this new proposition is less likely to hinge on say the store user-experience. These are ‘known-knowns’ – existing patterns are there to be used – and just take time or investment to implement. Viability will be determined by a myriad of less-certain factors like the cost to attract your target audience, and the ability to convert these visitors and make enough margin. Prototyping and validating your business model is as critical as your other critical success assumptions.
• MVP1, MVP2, full launch. On other occasions you see roadmaps with MVP, then one or two subsequent releases swiftly followed by the label ‘full launch’. If MPV1 is testing a key risk/assumption and MVP2 another, then great. However, this is seldom the case. The incremental releases usually signify increasing depth and breadth of features, and this sort of labelling leaves stakeholders with the false impression that ‘we build two things and then it’s ready for showtime’. Great products and services are continuously iterated and matured, so it’s not very wise to present your road to success in this way.

How to think about MVP to improve your chances of success

MVP remains a useful concept and rightly part of our toolkit. There are a few ways you can apply it within your organisation which helps make it more valuable.

1. Describe your MVP in terms of what you are trying to learn

Using MVP to describe ‘the thing’ risks your stakeholders becoming attached to ‘the thing’. Instead focus your stakeholders on the outcomes, not the features. This allows your teams to define ‘the what’ and the sequencing, and focus them on the riskiest assumptions. This approach can flow through to your product development roadmaps too. Work this way and you’ll have a higher probability of success. As Steve Blank said, ‘an MVP is not a cheaper product, it’s about smarter learning’.

2. Have multiple MVPs

Thinking in plural helps stop the focus on a single end product. Multiple MVPs also help minimise the biases that occur when we anchor to one idea or even worse, when a single idea gets too big to kill.

It’s also important to remember an MPV needn’t be a product at all – it just needs to maximise your learning vs effort. A clickable prototype or faked landing page is a valid MVP, too.

3. MVP as a mindset

Reframing MVP as a mindset and approach helps change the conversation from ‘things and features’ to the critical hypotheses and tests to help us derisk. You can also apply this to other aspects of your overall service offering. What are critical service or cost assumptions you need to prove? Can you prototype something to validate these? This is also something you don’t do at the start of your journey – it should be a continuous activity as new assumptions/risks appear. As Tom Chi, co-founder of Google X, says: “Maximising the rate of learning by minimising the time to try things.”

Remember: new product success is elusive for even the smartest and most experienced teams.

MVP offers a smart way to identify and mitigate risks and improve our chances of success.

Used wisely, and the language carefully, It can be very effective.

Would you like to talk about this further? We’d love to hear from you.

• Read on: How the Beta Business model can help you build your business of tomorrow