The real value of MVPs and how to use them effectively
By: Jules Lipman
Tags: Product Design, Minimum Viable Product, Product Development, Agile Methodology, Lean Startup

Demystifying the minimum viable product

What is an MVP

Minimum Viable Product or MVP is one of the most chronically misused terms in the technology sector today. In any organisation, teams will use terms like experiment, pilot, beta, alpha, MVP and v1 interchangeably, often within the same sentence. Every team has delivery pressures as Product Managers have committed to delivery dates and Engineering Managers are working to meet those dates. Often an MVP is deployed with bugs and incomplete flows through the perceived balance of ‘minimum’, ‘viable’ and the expected delivery date.

Customers using your oh so ‘minimum’ MVP

A bit of history

MVP rose to popularity in 2010 with Ash Maurya’s Running Lean and in 2011 with the release of Eric Ries’s The Lean Startup. Both authors stressed that companies fail when they build the wrong product after too much time and cost have been invested. Instead they suggested that an iterative vetting of ideas would lead to faster feedback for course correction towards the ‘correct’ product, with the least amount of sunk costs.

The Agile Manifesto written in 2001 and Lean became the perfect pairing. Agile specifically speaks to ‘delivering working software frequently’ and ‘welcoming changing requirements, even late in development’. While Lean suggests that each of those frequent releases should be an iteration on the previous, with learnings from the first release (MVP) directly impacting the next release.

However there is a difference between understanding the general principle and knowing how to execute it.

The build-measure-learn loop popularised by Eric Ries’s The Lean Startup

What’s the problem today

With minimum viable product the controversy exists around the term ‘viable’. How ‘minimal’ does it have to be in order to be ‘viable’? This debate has sprung forth many blog posts shouting ‘Death to the MVP’ and keenly suggesting alternatives like MAP ‘Minimum Awesome Product’ and MLP ‘Minimum Lovable Product’.

So what should the approach be?

Let’s get back to the foundational focus: How to de-risk your idea.

In technology, there’s no roadmap to success. Every investment in a new feature or approach has attached to it the actual costs of time and team salaries, plus the opportunity costs of where that time and money could have otherwise been spent. To pursue any opportunity you are investing your salary, plus the salaries of your team along with the opportunity costs, speculating that revenue increases driven by those changes will be greater than the costs invested. If not, the business will eventually fail.

With this perspective, it’s clear that the higher your initial costs the greater the return must be. Equally, smaller investments greatly decrease the pressure on ROI.

Which brings us back to the MVP. All debate aside, let’s accept the primary context of the MVP as a coded piece of product. Considering a 2 week sprint of 8 team members, say a Product Manager, Product Designer, Engineering Manager, plus five Software Engineers, that’s already an investment in the realm of $45k. That’s not including the time and cost of the research and preparatory work required to have high-fidelity designs in tickets ready and allocated for the sprint, nor any additional sprints needed to complete the work.

This already represents a substantial risk. By spending that amount you are committing yourself to receiving at least that amount in increased revenue. So treating your MVP like an option you can easily drop or pivot from, just doesn’t work out in practice. Even if it’s not performing, teams often try to rationalise the investment due to the sunk cost fallacy.

Where money goes on unvalidated MVPs

Let’s take a second to think about where that revenue comes from.

Revenue comes from your customers. Revenue is the direct result of customers placing a tangible, monetary value on the ability of your product to solve a critical problem for them.

If you’re going to spend at least $45k per sprint you best be sure that what you’re building is solving a critical problem for the customer. No one is spending money with you because of the ‘potential’ for your feature to solve a problem for them in the future. They’re spending money because your product is solving a problem for them right now. Following releases will build on this critical path to provide more options and engage a greater subset of customers whose solution requirements are more specific.

So before you even get to your MVP you need to be confident that it will in fact solve a critical problem for a reasonable portion of your customer base. If scope is being cut to the point it undermines this critical path for the purpose of ‘de-risking’ then it’s a strong indicator that you shouldn’t be discussing an MVP at all.

Where does the confidence for an MVP come from? By making small time and cost investments in customer research and experiments.

To know what is important to your customers, you need to talk to them. Look over your existing sources of information like NPS and page tracking. Short or long form surveys, 1:1 conversations with current customers, potential customers and customers who have recently churned from your product. When you have a basis from these sources you can start creating low- and mid-fidelity design prototypes to test (again, shorter time and cost investment than a high-fidelity design prototype). Additionally you can validate by minor coding activities like a new CTAs linked to an informational article (rather than the completed feature) to test interest in the feature. Throughout the research and experimentation process, Engineering is always involved in the learnings, able to guide on what should be included in the design prototypes to ensure what’s shared is achievable and feasible.

Jumping to an MVP from a ‘gut feel’ is a fallacy. It’s not the best way to de-risk your investment. The massive array of research and experimentation options before you ever get to code are the best way to de-risk.

“Think of the Build/Measure/Learn loop as a fast idea validator. If you put a reasonably good idea in AND manage to attract early adopters, it is possible to iterate and refine your MVP… But if you start with a bad idea, all you learn is that your idea sucks. And then you’re stuck.”

— Ash Maurya Don’t Start with an MVP

MVPs in Beta

MVPs can be approached in different ways. Beta testing is when an MVP is released to a select group of customers for a restricted time period. A beta is most relevant when testing a new product direction, to better understand the current customer appetite for this kind of change. Customers in a beta are recognising that what they’re using is the critical path, often with little to no additions and that this feature may or may not continue into the future.

When a beta is successful the customer subset may be expanded to all customers, then the beta tag may be removed when the MVP is iterated to the point it meets the standard of options and additions available across the rest of the product.

It’s important to also define what a beta test is not. Beta is not an excuse for a sub-par, buggy and incomplete solution. By the time you have made the decision to invest in your beta you are committing to the effort required to create an end-to-end critical path solution for the customer. Customers use your product to solve their problems, even in beta. If bugs are getting in the way of that, they won’t use it even if the zero-bug solution would be a solution for them. This can lead to tainted feedback on your beta, which may inform the wrong decision, losing that investment because the time wasn’t spent to make the critical path work end-to-end.

Prototypes develop in complexity as your confidence does. Source

So where does it all go wrong in practice?

Every team has delivery pressures. Product Managers have committed to delivery dates and Engineering Managers are working to meet those dates. In the effort to release on time and move on to the next roadmap item, scope can be cut to the point that the ‘viability’ of the well-researched and validated MVP, is lost. Teams should consider an MVP as their first, rather than only pass at solving that specific customer problem. To maximise the investment teams must leave adequate space in their roadmap for iterating and extending this foundation to create a robust solution loved by the largest possible subset of their customer base, and in turn maximizing the potential revenue from this investment.

At the end of the day, in isolation an MVP is not the best way to de-risk your project. MVPs require the insights provided through customer research and small experiments to ensure the coded MVP directly addresses a critical path for the customer. MVPs can go wrong when delivery dates take precedence over the scope required to deliver a viable, end-to-end, critical path solution for a paying customer. MVPs can also go wrong when considered as the only step, rather than the first of many, to create a robust solution for a specific customer problem. Ultimately, successful teams measure and learn from research, build measure and learn from design prototypes and experiments, before ever committing to build measure and learn from their first MVP.