The term Minimum Viable Product (MVP) has been hijacked. It is often used by managers to refer to a product that contains the minimum acceptable feature set for first release to the customer.

“It’s no use until it has all these features” is the usual argument.

Eric Ries defines MVP in his book The Lean Startup as a version of a new product that allows a team to collect the maximum amount of validated learning about customers with the least effort.

The classic example is a creating a simple signup page, taking out some Google ads, and seeing how many people are interested in you idea based on the description you’ve written.

This is a far cry from a fully featured product with all the bells and whistles.

One of my team made an interesting comment recently about the word ‘viable’. He said the term ‘viable’ changes depending on what you are testing, and what you are trying to learn. In the example above, we only want to know if the broad idea is any good. There is no implementation to test.

The first feature will have some minimally viable state where it can be tested and validated, even though it might not be considered customer ready. The more complex an application gets, the more application context is needed for the next stage of tests, and viability.

We are layering new minimally viable work on previously validated work as we build the application.

The mismatch between manager’s use (and understanding) of the term, and a team’s, creates problems during the development of a product. The team is focussed on validating work, while the management is focussed on the feature set for version 1.0.

If there is not a clear understand of what a term means, fix that, or find something that is meaningful in your own context.