The idea of a minimum viable product (MVP) is simple. Build a thing that barely passes as a usable product. Involve real users to produce a feedback loop that provides direction for future decisions. Why MVP? You learn from real user experiences and build on facts. You waste less time on assumptions and instead base the development on real insight.
The definition of MVP is simple to grasp, and with simplicity comes misunderstanding and misuse. And in the case of MVP as an idea, I can recall a period of overuse.
Overuse and inflation
As with any idea, overuse and misuse cause the idea to lose effectiveness. In the 2010s, close to everyone was building an MVP first. This approach often ended up meaning loads of different things.
There was the version 1 milestone called “MVP”, after which the development continued normally without a release or any feedback.
There was the “MVP” that had boatloads of features, user levels, integrations, optimisations, and just stuff that someone somewhere deemed necessary.
There was the true MVP release, after which no one knew what to do next.
You get the idea. The problem is not intentional misuse, but I suspect one is the organisational complexity and competing resources. People, teams, and structures impose their needs and constraints on projects. Building an MVP, even if deemed a good idea at the beginning, rarely is such a guiding force that repels all other business requirements and needs.
The idea becomes forgotten, and people building the supposed MVP become frustrated and apathetic. The idea faces inflation.
MVP reinvigorated
The idea behind doing the minimum possible work to validate the sensibility of what you’re doing before committing is actually pretty normal. We use trials before buying. We rent before buying. We date. We try to learn before committing.
We want to avoid unnecessary work, but we cannot keep planning, imagining, or building in secrecy. We need exposure and feedback to learn. The main point is not to get as many users as possible, but to gather knowledge and validate hypothesises.
In a sense, building an MVP is learning in public. It requires courage and composure. It introduces unforeseeable parameters and a harder-to-control design and development flow after the initial launch.
We do this because the results are often worth it. Even a buried MVP can be celebrated as a successful foray into gathering knowledge or as an avoidance of a huge failed product development cycle with its matching marketing costs.
A successful MVP is a start on a much surer footing and with significantly increased confidence.
Reducing waste is not only better for the business but also for everyone around it; the people and the environment. Read more about sustainability in software development.
When to consider if an MVP might not be what you need
Sometimes you need very high-quality products. Perhaps your reputation depends on it. A haphazardly built MVP can ruin it.
Other times, your competition already has a product that you don’t. You might be behind, in which case, anything can prevent your users from switching. Or a low-quality MVP launch can drive your customers away. These are the case-by-case it-depends situations, that require lots of strategic thinking and work on markets, users, and competition.
You might think an MVP exposes you to imitation by (usually bigger) rivals. This is possible but often overemphasized.
Sometimes a whole Minimum Viable Product is too much. Interest and sentiment analysis via mockups or smaller experiments can be much more efficient before building anything.
When to build an MVP:
- When you have the possibility to quickly build and launch.
- When you can manoeuvre, pivot, and make decisions without delay.
- When you can transparently share feedback and information with your team, and the team itself self-organises and makes some of the decisions.
- When you can stay true to the idea of an MVP and efficiently learn in public.
- When, after a few months, you don’t sacrifice the ideology to corporate politics, frustration, or to think you know it all yourself.
MVP above everything is a learning process and can bring an enormous amount of insight and competitive edge in a short period of time. It’s also saving a lot of resources when focusing on learning and prioritising development work in what truly matters for the end-users.
