Is It Time to Break Up With Minimum Viable Products (MVPs)?

When the concept of building an MVP prototype reached the mainstream, startups and product teams across the world fell in love. 

The right principles had finally come along that made their approach to product development feel validated.  

But years of being a committed partner to building MVPs has left some teams feeling cracks in the relationship.  

As sad as it sounds, prototyping an MVP since it came to the mainstream may not be enough anymore. But that doesn’t mean you can’t get that spark back.  

In fact, there’s a few tweaks you can make that will bring the romance back with MVPs, bringing with it a greater emphasis on your end users and increasing the chances of customers loving you back. 

Read on for some relationship advice for you and your MVP framework to get your product delivery process back on track. 

Relationship Profile: What is a Minimum Viable Product (MVP)? 

If you’re asking “what is a Minimum Viable Product?”, an MVP is defined as a version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort. 

If you’re in a committed relationship with MVPs for product delivery, you’ve got a lot of things going for you: 

• You can lower the risk of failure on full launch by starting small then scaling into the ideal product by iteration. 
• Lower overall costs because you’re making just the essentials for iteration. 
• You can roadmap out improvements post-launch because of hypothesis testing and iteration giving opportunities for fixes quickly. 

But I hear what you’re saying about the above. “Well why would our relationship be on the rocks if I could lose all that?”. Well, it’s not all that it seems… 

The Cons of Staying with the MVP Framework (as it is): 

Now although the MVP framework isn’t cheating on you, there are still some serious red flags around using MVPs.  

1. MVPs are misunderstood 

The original Lean Startup principles emphasised the benefits of an agile approach to building new products and features. Issue is, as it’s grown to be used beyond Silicon Valley, it’s been morphed into something it’s not. 

The term ‘MVP’ has become a business catch all; used for explaining everything from buggy to poorly designed products. 

As a result, the main idea of an MVP has become ‘the minimum featured product that customers will actually buy‘.

This misinterpretation has meant business leaders and non-agile teams have turned to building MVPs under the illusion that shipping “something” as fast and as cheaply as possible will produce the desired results, when they’re solving a company need over a user one.  

As a result, the idea of MVP has now become something everyone thinks they know, but only a fraction of people use as it was intended.  

Extra reading: Slalom has a great section on why MVP is not meant for public launch at all. 

2. ‘Viability’ is too open to interpretation 

‘Viability’ is purposefully a vague concept that’s not always a bad thing. Product Managers can tie this to a number of different criteria and define the scope based on what’s worthwhile pursuing. 

But just because something might make sense on paper due to its market size or the fact the product is possible, it doesn’t always translate to something people fall in love with and want to use again and again. 

Once again, ‘viability’ leaves MVPs open to a shrinking scope in order to be what’s the cheapest or quickest to develop. 

It’s a race to the bottom, which often means compromising on usability and research considerations that greatly influence success later in the process. 

It essentially starts off on the wrong foot by looking for the least effort and fewest components rather than being about creating value and solving user needs. 

4. It’s not competitive enough 

3,500 – 4,000 new apps are launched every day in the Google app store.  

That’s just the app market for one store, but knowing that digital products are going to market every day, standing out from the crowd is tough and the competition aren’t slacking. 

As a result, producing the minimum viable product that is not about experimenting and just about the features themselves means risking falling below user expectations and landing in the category of products that exist but aren’t used (25% of apps are used once after being downloaded then not used again according to Statista). 

No one has ever been truly happy with a ‘minimum viable relationship’, so your customers aren’t guaranteed to live with your product happily ever after if you’re only about putting in the ‘minimum viable’ effort. 

Making MVPs loveable again 

1. Always start with a hypothesis (and user research) 

The Lean Startup focused on creating new products by ‘learning’ first, not building straight off the bat which is what some teams are guilty of.  

An informed hypothesis for your MVP is critical. It’s your north star and the reason for creating an MVP for testing in the first place. 

But teams don’t create informed hypotheses without the research to back it up. Harnessing existing user research and data can help guide the hypothesis in the right direction and offer assurance that what you’re building is in the right direction from the off.  

The result? Less pivoting later on, less building on a whim and more building with the users in mind. 

2. Do user testing earlier 

Conducting user testing at earlier stages like interactive prototyping can foster the experimental mindset needed to build products that user love. 

By building prototypes of your MVP through tools like Figma and Adobe XD, you can answer your hypotheses and produce feedback way cheaper than trying to launch on the app store first. 

Now this goes against the meaning of MVP, as a design to test would be considered waste amongst the most arden lean followers.  

However, having iterative design become a staple of your deliver process comes from a good place. 

Iterative design offers agility and provides room to facilitate rapid changes at a lower cost and with less waste going forward (it’s cheaper to change designs and wireframes than lines of completed code), staying true to MVP’s principles. 

3. Don’t assume you can’t afford UX 

We’ve already mentioned how it may be tempting from a resources point of view to cut straight down to what’s functional, but by embedding a focus on user research and usability, teams can stop MVP’s being the antithesis to UX, but something that works together in collaboration.  

At the stage where the MVP is being tested, even exciting and useful ideas can fall flat if they don’t look impressive and delight users having built in user insights about what they actually want. 

Rather than focus your experimentation on what the feature does alone, teams should also consider thinking about the interface and the journey users would take to solve their problem: 

• How would it be presented on screen? 
• How would users discover it? 
• What is the best way for users to interact with it? 
• Does it fundamentally solve their problems? 

It doesn’t need to be everything they always wanted as that goes beyond MVPs, but it does benefit from experienced considerations for the purposes of testing and preventing a disjointed mishmash of interface elements when the build finally comes round. 

Conclusion: MVP needs your help to make this work 

If there’s any takeaways this Valentine’s Day, dumping the MVP is probably too hasty a decision. We’re certainly not suggesting that here. MVPs have simply been misunderstood so often that people don’t know what it really means anymore. 

To build better products users find value from, you don’t need to adopt an entirely new framework at all, you just need to make sure you’re putting in the effort to make MVPs the best they can be by being steadfast by the principles of user testing, user research and iteration.