“The Minimum Viable Product (MVP) is that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.”

— Eric Ries

The MVP is a concept that is often abused and misunderstood: it takes a strong product manager to push back against demands from certain stakeholders to add new features and functionality that are beyond the agreed scope. 

However, the reality is that when there are commercial drivers and many different owners, MVP purity will quickly be discarded. All too often the MVP isn’t minimal, it’s instead just treated as a box in which as much scope as possible is stuffed. In this situation we’re faced with what we could call a “pseudo-MVP” — where something is called an MVP but is, in fact, anything but. 

In this post I’m going to explore how pseudo-MVPs arise and what can be done to minimize them. Anyone who’s experienced a pseudo-MVP will be aware of the damage they can cause, so acknowledging them and taking steps to mitigate are extremely important.

To begin, let’s start with the specific goals or principles of an MVP:

• Learning through feedback. An MVP should help teams learn from the customer and market. It should enable short feedback loops so new product or technology decisions can be made.

• Minimal dependencies. An MVP empowers businesses to get started, by keeping dependencies and idle time to a minimum.

Consequences

If those are the two principles of an MVP, what happens when its scope is increased? 

Let’s assume the original roadmap looked like this:

If the scope changes, the first milestone will likely be pushed further into the future. While it might be called an MVP, with a larger scope it is probably more accurate to call it a pseudo-MVP. It might look something like this:

This has significant consequences for our feedback loops — one of the core principles behind an MVP: 

As you can see, when we’re dealing with a pseudo-MVP the feedback loops are much larger. That means we’re failing to properly test those all-important aspects of the product, like user-satisfaction. This creates an increased risk that more changes will be required in the future and makes it harder to catch any defects and issues. Ultimately this has an impact on the bottom line: it requires more work and will therefore cost more.

This is bad from both your perspective and the customer’s: 

The causes of pseudo-MVPs

But how can we tackle pseudo-MVPs and keep them from undermining our product delivery cycles? The first step is to properly understand what causes them.

Requirement ignorance

While business stakeholders are often viewed as the people most likely to be responsible for scope creep, sometimes they are correct: the product at a particular milestone simply isn’t the right one. Such a problem is a symptom of a lack of knowledge or awareness about product requirements.

Process ignorance

When business stakeholders push to extend the scope of a product, sometimes it is because they have little awareness or experience working in a more agile manner — to them, the idea that more is better is obvious.

Pressure

Everyone is accountable to someone: while it may sound counter-intuitive that expanding the scope of a product will speed up delivery, from the perspective of a business stakeholder who is under pressure, cramming certain features or functionality into a particular milestone could be symptomatic of certain demands from elsewhere in the organization. As a product team, it’s easy to overlook this.

Availability

Feedback loops are clearly important for MVPs — but it’s important to remember that even with the right processes in place, if the stakeholders you expect to provide feedback aren’t available or they don’t have bandwidth to offer useful insights that you can take forward, the MVP will be practically useless.

Some useful techniques and approaches

There are multiple methods of moving away from Pseudo-MVP to an actual MVP. Below there are a few ideas that can help you minimize and hopefully avoid them completely. as follows:

Joint workshops

Joint workshops can foster a sense of unity with the business stakeholder. Business stakeholders and the product team should always have a common goal — delivering a quality product promptly and within budget. From the start of the initiative, build unity by working together to design and plan the product and the timeline of its development and delivery.

Asking what-if questions

While gathering requirements, it’s essential to ask questions about what happens if each requirement, function, or feature does not exist. Think of this information as the raw data for planning the MVP.

Pre-workshop explaining the process

Before presenting the roadmap proposal, organize a session where the MVP and its benefits are outlined. Get stakeholders onboard, and highlight that short feedback loops are critical — that they are the lens through which the MVP should ultimately be viewed.

The conversation must be center on this core issue: what makes sense to deliver as soon as possible for the purposes of testing and feedback? It certainly shouldn’t wander into can you add this to the scope of MVP?

Learn to say no

When a demand to increase the scope harms the business by compromising deliveries due to pseudo-MVP milestones, it is important to say no.

Of course, this must be supported by evidence. You also need to be comfortable escalating.

Analyze feedback

Although it is important to have confidence in the roadmap proposal, it is also important to acknowledge that it is a draft that is subject to feedback. When the business stakeholder wants to increase the scope for the product to be viable, don’t just assume that they are trying to unnecessarily expand: analyze the feedback and consider how you can incorporate it.

Summary

Pseudo-MVPs are dangerous for organizations as they push milestones and shorten feedback loops. In the long run that can cost quality and money. It’s critical that everyone understands the importance of short and rapid feedback loops — ultimately they are beneficial to all stakeholders. As we’ve already noted, this can be supported through:

• Fostering joint workshops

• Asking what-if questions

• Pre-workshops explaining the process

• Learning to say no

• Analyzing feedback

   

Have a great time delivering outcomes that meet the target spot-on!