Product Management, User Experience

What Qualifies As a Minimum Viable Product?

Minimum Viable Product

Minimum Viable Product

Product management professionals are always looking for a way to get to market faster.  One common-sense way to do this is to build less prior to market launch.  So what’s the least you can possibly build?

Minimum Viable Product.

Except, it’s not that simple.

In the lean startup world, minimum viable product is the smallest possible product built to test a hypothesis and to achieve “validated learning.”  If the experiment is to test conversion rate on a landing page, the landing page would qualify as an MVP.   But no-one is paying you for a landing page.  As a commercial product, a landing page is not viable.  Marty Cagan writes:

I refer to that that as an “MVP Test” so that people don’t confuse an experiment with a product.

A more “viable” interpretation of MVP is a very narrow product that solves a specific problem really really well.  An example I think of in this category is Dropbox.  Dropbox solves the problem of sharing files across machines really well, and is viable commercially as a product consumers will purchase, but requires additional features to fit into the enterprise.  Dropbox launched Dropbox for Business to address these needs.

What about Minimum Marketable Featureset?

How well will your product solve the problems you’ve identified?  This is a solution space question, not as relevant for the problem space.

An interpretation of MVP I’ve seen frequently is the smallest collection of features to satisfy the happy path.  This often is enough to demonstrate the product to prospects and to install it, but may lack some of the administrative capabilities and exception handling that a client might expect in a robust product.

This is a challenge entering an established space within enterprise software.  Enterprise buyers frequently purchase from a feature checklist known as a Request For Proposal (RFP).  RFPs are written to ensure the enterprise addresses all the needs of all the stakeholders in the purchase.  How will your offering stack up if you respond to an RFP with the limited set of features in your narrow MVP?

It’s difficult to identify and isolate market problems that people will pay to have solved, but that’s not all there is to product management.  Thinking of the solution space, they’ll only pay you if the product you offer solves enough of their problem(s), and solves them well enough.

People don’t want to buy a product that doesn’t solve their problem.  So should you talk about where your product is going, or what it does now?

Another way of asking is: how much of the problem do you need to solve, and how well, for that solution to qualify as “enough” to your buyer?  Perhaps the answer to this question is what defines “viable.”

How much is Minimum in the Enterprise?

As Eric Ries states, “probably much more minimum than you think!”  Jesus Rodriguez put this differently: “The Enterprise Minimum Viable Product: Focus on Viable Instead of Minimum.”

If at all possible, create your own product category.   If you’re going into a crowded space with existing competition, there are RFPs and expectations.  If you’re creating the first widget of its kind, while there are always substitutes, there aren’t as many expectations about what your widget will do.  You can define what that entire kind of product does.

Most companies can’t or won’t do this.

If you’re going to market in an established space, you may be able to sell a differentiated product to early adopters, without adding many of the frills.  But to gain market share among the early majority, you’ll need enough features that the early adopters will provide enthusiastic recommendations of your product, and you’ll need enough functionality to meet expectations about the “table stakes” features–things a product in that category couldn’t possibly not have.

Minimally Robust Product

I perceive a continuum.  On one hand, the mere ability to conduct an experiment is the least possible “product” one could build, but is so minimal that it’s not sold or bought.  On the opposite extreme, is the product with every possible feature and is fully “done” (impossible, of course).

RELATED:  What is product management? Who's asking?

How Much Minimum Is Viable

In a mature product space, to appeal to early and late majority buyers and to achieve satisfaction, I propose that you must reach past “minimum marketable” and “minimum viable” and reach what I call “minimally robust.”  Criteria for this might include:

  • It has to solve key problems, well.
  • It must meet the basic needs that buyers won’t voice, because they’d never assume a product wouldn’t solve them.
  • It must be stable, implementable and administerable.

Identifying the features that meet those criteria is the fun part!  It’s different in every product category.  You’ll need to talk to people.

Where to Go from Here?

Once you have a product in market, how do you prioritize what to build next?  Here are a few questions to ponder:

  1. What features will impact the highest percentage of your product’s client base?
  2. What features will help your implementations and support teams from an operational standpoint?
  3. What features might help you solidify a narrower path through your product, that can address a more granluar problem that people will pay to solve?
  4. Are the features your clients are asking for all over the map or targeted in certain area(s)?
  5. Are the features your clients are asking for validating your vision for the product or suggesting a different direction?

There are plenty of questions to think about, but the first one to solve is how deep and wide you need to go before putting a product in a paying client’s hands.


  1. Hi John. Interesting post. The real key around MVP is validated learning. Some great reads:

    Ramli John

    Joel Gascoigne:


  2. Nice Article John. I would like to give another definition for MVP that is Minimal & Valuable Product 😛 I think whatever we build or test, if it is going to add value, then it can be categorized into an MVP.

    – Rajaraman R

  3. Great writeup. In your opinion, do you think it is useful to create MVPs for products that already have an established market? Can one not look at the fact that people are already paying for competitors’ products as a sign of validation?

    This becomes especially thorny, I think, when the product that one is envisioning on building is “better” or “easier to use”. The only way this can really be proved is by building the actual product and literally showing HOW it is better or easier to use, which can run counter to the minimalist principles of the MVP. How do you reconcile this?

    • I think the maturity of the market determines how far along the continuum one must go. To go into a mature market covering the breadth of the established solutions without the depth is tough, if selling apples vs. apples to the same prospects.

      Maybe it’s a portfolio play. Maybe the product is aimed at a different market segment that isn’t as demanding.

      Alternately, you might differentiate on decreased scope. Perhaps you could solve some of the market problem, with a subset of the standard feature set found in established products. Even then, for the subset you choose to go after, it seems to me you need to be “minimally robust” once you get beyond sales to friendlies.

  4. Minimum is in the eye if the beholder. The product person is placing a bet. Their job is to place the smallest bet possible to yield the maximum possible economic return. The answer to this question is hard because there is no absolute. You are playing odds, gambling hoping to win.

  5. Usually, with this sort of topic, it’s helpful to consider what we’re trying to accomplish. Test specific hypotheses and assumptions? Then run an experiment. Explore and document the preliminary business model for a new product? Think in terms of minimum viable product, and document accordingly.

    It’s the difference between testing your assumptions vs. knowing what assumptions you have and need to test.

    Whatever the terminology, there is a place for both approaches.

  6. ttorres

    I like the distinction between experiment and MVP a lot. I think it really addresses a lot of people’s concern with the MVP concept.

    But I’m not a big fan of defining MVP in terms of feature sets. I think it’s more about understanding where you offer the most value and tackling that piece first. It’s more about benefits and value than features in my mind.

    This may just be semantic, but I think that when we talk about MVPs in the context of features, it’s a slippery slope to half-assed products that feel unfinished. Whereas, when we look at them in terms of what’s the core value / benefit that someone is gong to get out of this product and how we build an MVP to validate that value, your MVP is much more solid than a half-baked, feature-based product.

Leave a Reply

Theme by Anders Norén


Get the B2B Product Newsletter to Master Your Craft

Join over 300 product managers sharpening the saw.

%d bloggers like this:
Read previous post:
Business Model Canvas
Another Day, Another Product Canvas

We product people seem to really like the canvas! In my world, there are three canvases which have gained some...