Skip to main content

MVP, the misunderstood and misused


The term MVP became as ambiguous as agile or startup. Everyone seems to be building MVPs even though in many cases (most?) it's not an MVP they are building, but the first version of their product, missing the biggest value a good MVP could deliver.

The concept of a minimum-viable product gained prominence with the rise of startups. Originally, MVP was considered a product discovery technique. The main reason was simple: not all ideas could be tested with prototypes, sometimes you do need to build something real to validate the solution.

The main purpose of the MVP is to learn and understand better the solution space. After the learning was done the MVP was retired and the proper product was built instead. Why was this important? Because of the word "minimal". A proper MVP that was built for learning never included vital security, scaling, accessibility or privacy considerations. That was fine if the MVP was retired after serving its purpose.

However, not everyone understood this vital limitation of the MVP. Startups usually have money and time just for that one MVP. If it's "successful" - startups will keep adding to it in a desperate attempt to stay afloat. If that works - they will keep building "MVPs" until they grow and realise they now need a huge refactoring, or more often, total rebuilding of their products.

But that's startups, for them, it really is the thinnest line between survival and failure. Unfortunately, not only startups now misuse the MVP concept. For many established companies, MVP became synonymous with the first version of a product. Business leaders, frustrated by long software development cycles, took the MVP as an opportunity to demand faster delivery from their teams.

The result? Products that have technical and design debt from day zero. Products that lack compliance, are full of security holes, don't scale and don't perform. And the teams that build them are often being blamed, even though it is not a fault of theirs.

The solution? Quite simply - honesty. Be honest about what you are building and why. If that's an MVP - you must throw away the code afterwards and start anew with all the learnings MVP provided. If you plan to use "MVP" code further, then just call it version one and don't mislead your team. That way you'll avoid many frustrations and time waste going forward.

Popular posts from this blog

Product management and operations tools - Jira Product Discovery review

  JPD is a new player in the market of product management software. Jira (and the whole Atlassian suite) has been one of the most popular tool stacks for teams to deliver software products. Now they're adding a missing piece - product discovery.

Product Vision: an elevator pitch for your product

On this blog, I write a lot about making data-driven decisions . But what if you just starting to think about your product? You have a vague idea and nothing more. No point to go for prototyping or even talking to customers as you don't know yet who to talk to and what to talk about. In such situation - start from creating a product vision.

2 simple but powerful filters for your problem and product ideas

Nowadays lots of people and companies want to innovate. They want to generate new ideas and turn them into profitable products. But how would you separate good ideas from not so good ones? How would you make sure you invest only in good ideas?