Getting Maximum Impact From a Minimum Valuable Product

Startups and more established companies alike are always looking for ways to minimize their risk when entering a new market while also getting a product to market as quickly as possible. After all, a product in development isn’t producing revenue but is certainly taking up resources.

There are a number of approaches to getting products to market faster, whether those are physical or digital products. One that’s been around since the early 2000s is the concept of a minimum viable product, popularized as part of the Lean Startup methodology.

But while the MVP methodology has been hailed by many as the “best” way to get a product to market quickly, there’s also been plenty of pushback. Which is where the concept of a minimum valuable product comes in.

What Is an MVP?

At its most basic, an MVP is a barebones version of a product that can be released much faster than a more fully-featured version. Ideally, an MVP should have a broad enough feature set to satisfy early adopters.

The idea behind creating MVPs is to get products to market more quickly so that companies can 1) start earning revenue and 2) get feedback to improve the product. While this has obvious advantages (such as not wasting months or years developing a fully-featured product that no one actually wants), it also has some serious disadvantages.

One such disadvantage is the tendency for product teams to create an MVP that is too barebones. They end up with the basic functionality of the app or other product they’re creating but, to users, the end result feels generic. If many products are stripped down to their most basic functionality, they lose any competitive advantage and all start to look and work the same.

Take to-do list apps: A basic to-do list app will have the ability to record new tasks, mark them as done, and usually a method to prioritize them. Other expected features include things like setting due dates, tagging or categorizing, and assigning them to others. Even including those features won’t set a new app apart from its competitors. And yet, when designing an MVP of a to-do list app, that’s what a lot of teams would end up paring down to.

Shortfalls of MVP

MVPs have other potential shortfalls. Cutting corners is one. When the goal is to create a barebones product, paring things down to a minimum is inevitable. But there are some corners that shouldn’t be cut.

This is particularly true when it comes to sacrificing user experience. A product’s UX is vital—sacrificing the experience a person has while using the product will negatively affect its success. In this case, the MVP may indicate that the entire product isn’t viable when it’s really just the experience that needs work.

One of the biggest shortfalls of MVPs has nothing to do with the MVP itself. Reid Hoffman, founder of LinkedIn, is famously reported to have said, “Launch early enough that you’re embarrassed by your v1.0 release.” That kind of thinking is damaging to companies and to their users.

The way many design teams approach creating MVPs is a problem in itself. MVPs are supposed to be a process in order to create a valuable end product that meets user needs. Instead, designers often treat each MVP as a distinct thing, without looking at each as a stepping stone toward the final product version. More importantly, they often release MVPs that should be viewed more as internal prototypes on the way to a product ready for release.

What Is a Minimum Valuable Product?

Minimum valuable products (which will be referred to as MVaPs for short) are an extension of the MVP concept. But rather than looking to create the minimum viable iteration of a product, designers create the minimum iteration of a product that provides real value.

But what does value mean? What does it include?

There is value to the end user to consider first. MVaPs need to put user needs and expectations first. This means looking at best practices for the type of product being designed, conducting user research and usability studies, and crafting user personas and use cases to determine the best potential ways to meet user needs.

There may be more than one idea about how to meet user needs, which is where testing prototypes comes in. Presenting functional prototypes to actual users in order to see which iteration might meet their needs best is an important step in creating an MVaP.

Next is value to the project itself. MVaPs need to be designed in such a way as to advance the project at hand. That means they need enough functionality to be able to glean useful insights into the way the product is perceived by the market.

And lastly, MVaPs need to provide value to the business as a whole. One risk with releasing MVPs into the world is that they can reflect poorly on the brand releasing them. MVaPs should add value to the brand they’re representing, even when they’re not the final iteration of a product.

Another thing that sets MVaPs apart is that they focus on competitive differentiation. Designers take an objective look at what sets their competitors apart from one another, and then what will set their product apart from those. This needs to be incorporated into the MVaP, whereas it’s not necessarily included in an MVP.

MVaP, as described here, isn’t the only version of a souped-up MVP out there. There’s also the minimal marketable product (MMP) presented by Roman Pichler. His idea is that the earliest market-ready product should contain just enough functionality to be launched, marketed, and sold effectively.

SLC is another similar concept that WP Engine uses. Since customers hate MVPs, they theorize, why do startups constantly subject their users to them? Instead, users should get products that are simple, complete, and, arguably most importantly, lovable. Why should any company present their users with a product that’s impossible for them to love?

The bottom line with creating an MVaP is that even the first iteration of a product should be useful and desirable to customers or users. Without delighting users, or at least satisfying their most pressing needs, a product is bound to fail.

What Goes into a Minimum Valuable Product?

Creating a minimum valuable product will likely take more resources than creating an MVP, but the payoff will be substantially higher, making the extra effort well worth it. Here are a few things to keep in mind when building an MVaP.

One of the first things to consider is the feature set for the MVaP. The smallest useful feature set should be included in any MVaP. Included in those useful features, as mentioned previously, are the features that set this particular product apart from competing products. Identifying which features competitors include is a valuable part of this step. That doesn’t mean that an MVaP needs to include every feature a competitor features.

Take the first iPhone, for example. Smartphones at the time included a number of features that Apple intentionally left out of the first iPhone. Things like copy and paste, a software development kit (SDK), and even things like being able to send text messages to multiple recipients and 3G connectivity.

Later iterations of the iPhone obviously incorporated those things, but the first version purposely left them out and focused instead on things that set the product apart: their software (iOS was revolutionary at the time) and multi-touch interaction capabilities. The original iPhone was a runaway success, selling more than 6 million units before being discontinued in favor of the iPhone 3G.

The MVaP process doesn’t have to be entirely removed from the idea of MVPs. In fact, starting with an internal MVP is useful. But the MVP should be expanded upon until it becomes a valuable product before being released to the public, or even to early adopters outside the company. Internal testing and small focus groups can advance an MVP into the realm of a valuable product without risking damage to a company’s reputation or brand and without alienating customers.

Designers should ensure that the first MVaP released to the public incorporates features that support the main goal of the product—whatever that happens to be. The end goal for an MVaP should always be to create a product that will delight users, even if the final iteration of the product will include more features or improvements. It’s better to release a product with a minimal version of important features, even if the vision the product team has for how those features will eventually work is more complex (or even entirely different).

In fact, rather than thinking solely in terms of feature sets, product teams should take a step back and think about user needs. Are there better ways to meet user needs than how the competition is doing it? Are there experimental features that could be more easily incorporated into a product that the competition hasn’t yet embraced but that would make users’ lives easier? Just because the competition offers 15 different ways to complete a task doesn’t mean that it’s necessary for every product in the industry to do the same.

Conclusion

Regardless of whether a minimum viable product or minimum valuable product is the starting point, the end goal should be a maximum value product. Either system is a means to an end, that end being the creation of a product that stands out from the competition, delights users while meeting their needs as completely and efficiently as possible, and creates value for everyone involved, including the brand.

While minimum viable products sometimes have their place, a minimum valuable product will get teams closer to the end goal in a shorter period of time because value is built in from the beginning. Providing people with value in the products being offered should be the goal of any business or brand. Value builds trust, which builds goodwill, repeat business, and positive word-of-mouth.