What makes for a good MVP? (2024)

Releasing a minimum viable product (MVP) is like dipping your toes into the pool that is your target marketplace, before taking the plunge completely. Some people swear by them as good business practice, citing the value of looking before you leap.

But others are less enamoured with the concept of an MVP. After all, who — as a customer — wants an unfinished product that does the absolute minimum to solve their problems? Could releasing an MVP hurt your chances of market success later down the line?

So, what makes for a good (or bad) minimum viable product?

What is an MVP?

Your MVP is the foundation of your product. It’s the cake part of your iced cupcake, the bread and butter of your software sandwich. It holds only the features necessary to solve the specific problem you’re targeting.

MVPs are a great way to get a feel for the market that you’re hoping to enter. You can see whether there’s a demand for your product before sinking cost into something no one wants. Nine out of ten start-ups fail, and 42% of these did so because there wasn’t a need for their product. An MVP, then, highlights a lack of market need before you use up further resources. It’s a way to question your assumptions and see if you need to provide answers for them.

Minimum viable products also make developing a product more manageable. They can help your team avoid feature creep. Because all features must be relevant to the core goal, extraneous and unnecessary features that weigh your product down are avoided.

Against the MVP

The argument goes that releasing an MVP hurts your standing in the market by disappointing customers. Because the product is simple, and only does the bare minimum to attempt to fix a customer pain point, it won’t be well received, and it won’t retain customers.

It makes sense, except this isn’t what a good minimum viable product stands for. It’s not a half-built product that only really acts as a proof of concept — you have a prototype for that. A minimum viable product is a process to test your assumptions, and a starting point for your product.

But there is truth behind the concerns about MVPs. When done badly, minimum viable products can misrepresent the end goal you see for your product. This means that any insight into market it provides can be incorrect, and you can risk targeting incompatible customers for your project as a result.

Deconstructing the good MVP

The difference between a good MVP and a sloppy one can be seen in the interpretation of the words ‘minimum’ and ‘viable’.

In a good MVP, ‘minimum’ doesn’t mean ‘lazy’ or ‘settled for’. It means the simplest that your product will be. The ‘minimum’ part of the minimum viable product forces your team to boil the product down to the core functions it needs to have to solve a problem simply, elegantly and effectively. It’s the bar to reach for before a product can be called a product.

The problem is, a product that’s ‘minimum’ can sometimes fail to be ‘viable’, and viability is just as important to a good MVP. ‘Viable’ means that the product is usable. It ensures that the product does actually solve a problem or work as it’s intended to. A product that doesn’t work or can’t fit with the market need is not viable.

And therein lies the crux of what makes for a good minimum viable product: a release that consists only as the core of what it will become, but a core that’s still fit for customer use.

A good MVP

A good MVP is a working, usable product. It’s solid — not vapourware or a demonstrative dummy product. Many brands have failed on the MVP front because of reductive thinking; they build the bare minimum functionality they can ‘get away with’, or an incomplete product ‘just to get the feedback’.

This line of thought cuts corners, while a true MVP doesn’t compromise on competence. When you release an MVP that ably fixes the problem you want it to address, its simplicity won’t turn interested customers away. After all, they just want their problem solved.

Just because it’s an MVP, it doesn’t mean it can be created or treated apathetically. You need to conduct market research, and know who to target with your product. You need to write user stories and consider the customer pain point you want to mend. And you need to carefully select which features are core to achieving that.

Bells and whistles

Done badly, an MVP doesn’t help you analyse the market, attract compatible customers, or give you a working model to build your product on. But, done well, an MVP can save you time, resources, and help you start to build a customer base.

A good MVP is your product at a stage where it only solves one, specific problem. It’s a starting point for you to grow from. You build on your minimum viable product later to improve the way it solves that same problem.

But for now, you’re releasing a good, simple product. You’re demonstrating the core value your product will always hold and finding out if it solves a pain point that consumers face. It just doesn’t have all the bells and whistles yet.