What is an MVP? A Global Perspective

by Luke Gallimore, Head of Product Management

On 9th February 2021 a hive-brain of designers, developers, product managers, and consultants from across our global offices gathered (virtually) to answer a question that had been the source of much debate:

“What is an MVP?”

This article is a summary of what we learned.

The workshop aimed to answer five basic questions around MVPs:

1. What is the objective of an MVP?
2. How do you decide if a feature is MVP or not?
3. What are the common misunderstandings of MVP?
4. What alternatives are there to MVP?
5. So, what is an MVP?

Let’s start with the basics; what the point of an MVP is in the first place.

What is the Objective of an MVP?

We identified three core objectives that any MVP should aim towards. The thread that runs throughout them all is balancing investment and risk.

1. Speed to Market

Any MVP must successfully find product-market fit as fast as possible. This means that it needs to create the required value for the business and the user with the smallest feature set possible. ‘Required value’ needs to be defined and understood as accurately as possible.

2. Lean Value Creation

Any MVP must adhere to the product strategy and deliver an important initiative on a company strategy with the minimum investment possible. Defining an MVP should mean avoiding building features that do not deliver value. MVPs cut the fat. And if you do fail, MVPs limit wastage of time and money, thereby reducing risk.

3. Build Confidence

Any MVP must effectively test a concept as a live, compliant product, in a real environment with minimal investment. It must demonstrate that an idea is technically feasible, commercially viable, usable and valuable in real context and environment. This does not require perfection. Once the foundation is solid, you can build on top of that with confidence.

How Do You Decide if a Feature is MVP or Not?

Just as we all are innocent until proven guilty, features are useless until proven valuable. We identified four categories of interrogation which any feature idea must stand up to in order to pass this ‘MVP test’.

1. Drive Towards Simplicity

• Can you explain the idea simply to users and the business?
• Can we validate this idea by some other means e.g. prototype or POC?
• Is the level of technical complexity proportionate to the value it will create?

2. Understand Stakeholder Factors

• Why is this functionality being asked for — where does the demand come from?
• Will someone get in trouble if we don’t build this?
• Will we lose support from our users or the business if we don’t build this?

3. Focus on the Product Strategy

• Can we achieve our competitive value proposition if we don’t build this? This is a very important question.
• Can we achieve our product vision and our product strategy if we don’t build this?
• Will we fail to hit our KPIs if we don’t build this?

4. Understand What Failure Means

• If we don’t build this, will the product break an important business or user process or flow?
• Are we bound by legal requirements to build this?
• Will our return on investment be below required if we don’t build this?

What are the Common Misunderstandings of MVP?

The MVP term can be misused easily. There are four very common fallacies to which we can all fall prey to.

1. ‘MVP’ as Quantity over Quality

An MVP is not a way to build everything you want at a lower quality than is ideal or required. There are ideas that might be valuable, but which are over-and-above ‘minimally viable’. Hedging your bets by packing an initial release with lots of ideas if often done. It’s usually because the work hasn’t been done in discovery to sort the wheat from the chaff.

2. ‘MVP’ as a Way to Lower Costs

An MVP is not a negotiation tool or an arbitrary label for a budget. Often MVP is used to define a ‘finished product’, but for cheaper than was originally expected or estimated. This misses the point of an MVP, which is not to reduce costs but to reduce risk. Saying a feature is required for MVP is not a cheaper way of getting what you want developed.

3. ‘MVP’ as a Wishlist

An MVP is not an un-prioritised list of features. Your competition will have lots of features which you naturally feel the need to gain parity with. However, the truth is, that most of your competitors will also have a significant amount of product debt too. Including the ‘should haves’ and ‘could haves’ is a bad practice for MVP. ‘Must-haves only’ is the rule.

4. ‘MVP’ as Something Too Simple

An MVP is not the bare bones or ‘core’ functionality, without any sizzle. In fact, it may be required by your product strategy to launch an MVP that includes lots of high-fidelity interaction design for example. Launching an MVP that is just a skeleton is incomplete. This is more on the lines of what a prototype or proof of concept is.

What Alternatives Are There to MVP?

Sometimes what we are looking for is not an MVP. Here are some common examples of achieving the desired outcome when MVP is not a suitable tool for discussion.

• Trap door and A/B tests can help you validate an idea in a live product.
• Pretotyping and prototyping can help you test ideas and prove value propositions without having to spend additional time on legal and compliance issues that a live product might have.
• Proofs of concept can help you determine if more investment is required (and help you secure that funding).

So, What is an MVP?

We arrived at a definition of MVP which retains the flexibility needed for the range of contexts in which MVPs are used, whilst being precise enough to have constructive debates. Meeting all four of these conditions is necessary for a product to be accurately described as an MVP:

1. An MVP is the output of a process of investigation, prioritisation and validation of ideas (product discovery); AND
2. An MVP is the minimum investment required to determine if a product can find market fit; AND
3. An MVP is a product that can successfully be taken to market and generate value there; AND
4. An MVP fulfils the basic legal requirements for the context it is live in (this is not required of a prototype or POC)

The fact that this was such a constructive and well-argued debate within our own organisation proves that the MVP term is one that must be used with caution and with precision. Even if the above does not align with your view, we’d encourage one key takeaway from our exercise:

Make sure everyone knows what you mean when you say ‘MVP’, and get your whole team on the same page, as early as you can.

Thanks to all who did the legwork on this article by lending their expertise and experience to answering this great question.

Linn Elster, Oliver Todd, Daniel Lee, Emil Bunk, Kamho Yung, Bo Mouridsen, Bjørn Jerveland, Anders Skjøt Kongsbak, Pavel Šrámek, Randi Hovmann, Niels Truong, Yaw Dako, Sven de Brouwer, Tobias Lund-Eskerod, Gemma Wood, Sigrid Rosell, Frederik H. Nielsen, Simon Ejsing Phillip Cohn-Cort