What is the Minimum Level of Quality (MLQ) expected for your Minimum Viable Product (MVP)

This question got me thinking about quality and the expectations of quality for your Minimum Viable Product (MVP).

This may seem like a basic question but I wanted to understand the expectations of quality (e.g. UI design, functionality, bug weight, etc) that an MVP needs in order to have at least a good shot at impressing customers and investors.

I would also include in quality scalability and ease of use.

I think it's partly about expectations.. 10 years ago you could throw any old clunky website up and people would accept it if the product/service was ok. Nowadays it's pretty uncommon to meet a design free website, especially for something you might buy, so the bar has been raised.

To my mind, you have to treat MVP as a full commercial release, including:

• professional looking website and sales process, appropriate for your target market
• professional looking support and pre-sales processes
• bug count - "reasonable" - ok, you can't go for bug free, but I don't think you should be throwing junk at the market either - that can kill you. You shortcut this at your peril.
• reasonable level of help and FAQs that should have come out of early beta/trialling

In other words it's a way to get moving and building volume, not a way to do 50% of the required effort. On the strength of that, it should be a product not a demo or proof of concept.

All of these items and processes will be needed in some form as further releases are made, so you need the full set to start to test whether your assumptions on market, website, support volumes etc are correct.

I think that there is a direct relationship between "viable" and the nature of your product and expectations of your market.

A MVP in the market of manufacturing of a biomedical device is much different that a social media widget for Facebook. In regulated industries the definition of "viable" has clear and definite requirements.

But in all markets there are basic expectations of quality that are expected by the targeted audience. By understanding the target market, an understanding of the minimum viability emerges.

Too often I have seen MVP emerge to mean -- well I got it to work -- from an inside out perspective -- as oppose to "viable" having anything to do with the relationship with the prospective customer. "Work" has to always mean work for the customer -- not work for the programming, design or development team.

As long as viable in viewed in this context -- then the MLQ and the MVP will be parallel qualities of the launch product/service.

This is one thing you need to keep in mind simply when building a minimum-viable-product,

Remove any feature, process,or effort that does not contribute
directly to the learning you seek.