Agile Software Development

Restoring the Broken MVP

Arguments are growing around the idea that the minimum viable product (MVP) has lost its way, or more specifically—everyone has forgotten what an MVP should actually be. It is time to reset ourselves on the purpose of the MVP. In an article at TechBeacon, Allan Kelly discusses what the MVP really is and how its purpose became perverted.

Not So Viable

Kelly believes the MVP should exist as one of three basic types: a product that has only the features necessary to test the market, a product with its must-have features, or a product proof of concept. The MVP has its closest roots in the first and last definitions, but Kelly concedes that there are circumstances where the other definition can apply. For instance, if it is possible to build a product with all of its “must-have” features in just a few months, then he thinks it is alright to treat such a thing as an MVP. Anything longer than that opens up an MVP to too much tampering by vacillating stakeholders.

But that is only one of many ways an MVP can be abused:

Today everyone wants to build an MVP, to build less with the hope of saving time and money. Managers may say it’s for testing the market, but I’ve seen many startups and enterprises build an “MVP” just so they can meet a deadline or try to make their developers work faster with more focus (or with less attention to quality). …

However, I’ve also seen developers use the MVP designation to justify a buggy or underperforming product. Both sides should hold each other accountable for meeting the MVP’s initial goals—nothing more and nothing less.

MVPs can still be a great help if you use them in the right contexts at the right times. But if you try to use MVPs as a way to cut corners, do not be surprised if little value comes from it.

For further elaboration on correctly using MVPs, you can view the original article here:

Show More