It’s not your fault your minimum viable product sucks. Not entirely, anyway.

The pressure on software product managers seems to grow more intense every year to deliver something—anything—to the market as quickly as possible. After that, the thinking goes, your early adopters will let you know how to improve it.

Nor does this pressure come only from internal sources like impatient executives or jittery investors, although you probably feel it there as well. But with lower barriers to entry into the software game, the falling prices of development tools, and the widespread availability of coding talent, the market itself is putting ever more pressure on you to deliver, ASAP.

In practice, this often means scaling your product’s strategic vision down to the bare essentials, developing the scaled-down version as quickly as you can—and ultimately pushing out a minimum viable product.

How Agile Can Worsen the Minimum Viable Product Pitfalls

As if you weren’t already facing enough pressure from within your organization and from those right-on-your-heels competitors, the idea of pushing out stripped-down products as soon as they are “minimally viable” also has the support of today’s most popular software development methodology, agile.

The agile philosophy tells product teams to strip functionality from a product’s early development in favor of being able to release the product sooner.

The plan, according to agile, should be to build a product with the minimum functionality required for early users, release that product as soon as possible, gather feedback from users, iterate based on that feedback, and continually repeat this process to improve the product.

This can be a smart strategy. But for it to work, you must have an accurate and complete understanding of what constitutes a minimum viable product, or MVP.

What Should Your Minimum Viable Product Include?

If you misinterpret the MVP’s true meaning, you risk introducing users to a product that is just short (and sometimes way short) of their expectations. Worse, if you underwhelm or disappoint this early group of users, in many cases they won’t give your product another chance.

Often the misinterpretation comes down to neglecting to include one key ingredient that belongs in every version of your product—even your MVP. We’ll discuss that key ingredient below.

First, let’s define the term. According to Wikipedia, a minimum viable product is “a product with just enough features to satisfy early customers, and to provide feedback for future development.”

The way this often plays itself out is that the product team reviews the major epics and features on the product roadmap. If the team had originally prioritized seven epics as constituting a strategically cohesive and viable product, the product manager identifies, say, three of these epics to pursue for her minimum viable product.

But by simply selecting a portion of the functionality on the roadmap to include in what it calls its minimum viable product, this team risks going to market with a product that isn’t truly an MVP at all.

Here are the two fundamental requirements an MVP must meet:

1. The MVP needs to fully address a need or solve a problem for the user.

Even when you are stripping down your product’s planned development to MVP levels, you still need to keep in mind the total user experience, and you need to make sure that whatever functionality you include fully solves a problem for the user.

Tweet This:
“The minimum viable product needs to fully address a need or solve a problem for the user.”

This is why you cannot simply choose three of seven features on your product roadmap and decide that once you’ve built out those three features you will have a minimum viable product to ship.

You must always make sure that your MVP, in at least one area of its promised functionality, provides the user with a complete solution.

This obviously doesn’t mean your MVP needs to do everything you ultimately plan for your product. It means only that you need to be sure you are not simply giving your users three-quarters of the functionality to complete several tasks—but that you’re actually giving them the end-to-end functionality required to perform at least one task.

If your product doesn’t do that, you don’t have an MVP. And if you release it anyway, you run the real risk of disappointing your users and turning them away from your products forever.

2. The MVP needs to delight the user.

This is the key ingredient so many minimum viable products neglect to include. But in our opinion, if you don’t have something in your product that delights the user in some way, you do not have a true MVP.

As we have argued previously, customer delight is a must-have in your products. This is particularly true of software.

Why? For the same reasons we listed above explaining why you are facing so much pressure to release products sooner and with less functionality. With the barriers to entry for software providers continually falling, and the fact that you’re facing more competitors than ever, you can’t release an unimpressive, minimally useful product and expect to find a loyal user base eager for your next version.

For this reason, we think the Wikipedia definition above, which is widely accepted in the product world, misses a critical element of what constitutes a minimum viable product. Your MVP should not simply have just enough to satisfy early users; it must also delight them.

Customer Delight: The All-Important Ingredient Many Minimum Viable Products Miss

Product teams often neglect to focus on customer delight in their minimum viable products for logical (although misguided) reasons. They’re under a time crunch. The market seems to be pulling ahead. They are low on budget. The CEO demands it.

And adding some element to the MVP’s already-stretched development plan just because it will delight users can seem unnecessary and even risky.

But think of all the times you’ve tried a new software product—particularly one in beta or where you otherwise knew the company was in early days. If that product wasn’t impressive in any way, didn’t deliver something at least a little cool, were you likely to want to keep using it? Were you likely to be interested in future versions of the product?

How many chances do you think you’ll have to re-introduce your product to users, if it doesn’t wow them the first time?

Post Comments


  • Adhar Walia
    September 7, 2017 at 11:09 pm

    Great article! Minimum Viable Product is an overly used term in today’s agile environement. I think MVP should be used to validate your hypothesis. It provides quick feedback and allows product managers to iterate from there on. It should focus on one hypothesis and address that one problem. However, MVP is not Minimum Desirable Product (MDP) or Minimum Loveable Product (MLP), which is what delights a customer and creates loyalty among customers. It is usually not the first customers but the loyal customers that matter. I think of MVP as a way to test with small set of users and use the learning to launch a product with features that are desirable. The Minimum Lovable Product (MLP) or MDP is one that your core set of users love and it should meet three charasteristics.

    1) Usable: the minimum feature set should be usable by core set of target users
    2) Valuable: it should be valuable and should solve a real problem
    3) Feasible: the resources available to create the MLP should be feasible

    • Maddy Kirsch
      September 8, 2017 at 9:38 am

      Thanks for your comment, Adhar! I like the distinction you make between Minimum Viable Product and Minimum Lovable Product. Creating a loyal user base early on is so important, and your three characteristics of an MLP are a great way to get there.

  • John
    September 12, 2017 at 7:55 am

    The key to MVP is basing it on assumptions trying to be proved to move the market fit forward. Basing an MVP on choosing from a feature list is a recipe for disaster, as you’ve pointed out. Create personas, crate a lean canvas, develop assumptions, know the market and work with a control group first. As you prove assumptions your MVP will shape up on a natural path that understands and fits user expectations so it can grow the right way, lower risk and deliver.

  • Johannes Klose Andersen
    September 12, 2017 at 8:19 am

    I like to use Gay Kawasakis take on a MVP, an Minimum Vaible, Validated and Valuable Product. But then again, if it is valuable to the consumer, you have your validation there, and I haven’t seen a product thats valuable and validated, but not viable. So im back to MVP, but V as Valuable instead of Vaible.

    • Andre Theus
      September 12, 2017 at 9:10 am

      Thanks for chiming in Johannes! I very much like Guy Kawasaki’s books. And I agree with your comment, it’s crucial even for your early product to provide enough value.

  • Daniel Pardes
    September 12, 2017 at 8:27 am

    Agree on parsing the point where you get feedback and where you actually release more widely to get the love. The best articulation I’ve seen on MLP is here:

  • James Black
    September 12, 2017 at 8:46 am

    Great article Maddy. A lot of folks expect that at the end of a sprint (Scrum Framework) we expect our team(s) to ship their product increment to production. However; in reality at the end of each sprint we should have a potentially shippable increment. This means that we do not actually ship it until there is enough functionality to be of any value to our customers (by solving a problem at-hand).

  • Tony Moura
    September 12, 2017 at 9:46 am

    This article is great proponent of UX. Yet, a number of the comments don’t even seem to touch on it. As a 22 year Sr. UX Architect it drives me insane when product owners, product manager and/or executive leadership charge ahead without really knowing when their intended end users problem really is and what’s needed in the eyes of that end user to fix the problem. So many times “assumptions” are made by founders, executives and others on what “they” feel will solve the problem as they feel they know it. A product gets built and then tossed to users. When the feedback comes back in, that becomes the feature roadmap.

    Do your users, your brand, your budget a favor and simply find out as far up front as possible. What really needs to be solved to meet your intended end users requirements as simply as possible. That insight, becomes your MVP.

    • Devang
      September 28, 2017 at 5:58 pm

      In addition, in my experience depending upon the problem you are trying to solve, MVP success chance increases when all internal stakeholders (compliance, security, legal etc.) experts are engaged early and often from hypothesis validation to finalizing MVP and execution.

Leave a Comment

Your email address will not be published.