There are many startup owners who mention a minimum viable product concept when writing a project documentation. To me, a minimum viable product (or an MVP) sounds wonderful because it falls in with our development approach. So, when I see an MVP mentioned in project specs, I start believing that the project owner thinks the same way I do and is familiar with the rest of the Agile (or Lean Startup) methodology.
However, it is not always so. Sometimes people use these words - minimum viable product - not how it was supposed to be used in the beginning. So, let us go through some aspects of MVP development to make it clear what project is an MVP and what project is not an MVP.
There are a few people who have made a contribution to the MVP paradigm. The most famous one is Eric Ries, the author of the Lean Startup methodology. He defined MVP as "that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort".
It is a little bit different from what many startup owners think MVP is. They mix it up with what we call "a minimum loveable product" - a project that has all features they cannot sacrifice but still fits in their budget (or does not fit in it).
However, MVP is not about staying within the budget and not even about impressing users with a minimal effort. It is about learning.
What is an MVP
The first thing about MVP is purpose. A minimum viable product is designed to change the world. So, a traditional ecommerce software is not an MVP. Nothing that has been done many times before is an MVP. A new hot idea is what requires a minimum viable product development.
MVP is supposed to solve a real problem. Probably, a kind of a problem no one has solved before. If an MVP software solves a real problem, it can afford to be minimal because users will fill in the gaps in the feature set with some tools outside of the application.
MVP is built to learn customer feedback. Since it refers to a new idea, the startup owner should acknowledge and accept the fact that a possible user reaction is unknown. So, it is essential to get user feedback and see if the startup has a potential.
It is worth reminding that a minimum viable product is minimal. Ries highlights the point by saying: 'It is much more minimum than you think'. It means that the project owner should pursue a release as early as possible to get a feedback sooner rather than later.
What is not MVP
MVP is not about getting profit - neither at the first stage, nor at the second stage. Well, probably at the third one - who knows? It all depends on the user feedback.
MVP is not designed to impress potential users visually or by a rich feature set. What should impress them is the specific problem the product is supposed to solve.
A minimum viable product does not actually refer to building a small product. Rather, it is a strategy to launch a software that will later become a platform for other products for solving the same problem but more attractive and refined according to the user feedback.
MVP is not something carved in stone. A minimal viable product is supposed to change. It is a set of experiments every one of which makes the project more adjusted to the user feedback, more mature - and hence more viable.
How to build an MVP
You have first to decide whether you need to follow the MVP pattern or not. If you know your audience and your project is just a way to grow your business, you can simply follow the "release early, release often" approach of the Agile methodology. It is much easier than getting knowledge about the world in an iterative "build-measure-learn" manner.
Define what makes your product stand out in the market. What makes it unique? What real problem is it supposed to solve? How important is this problem? To whom?
Developing an agile minimum viable product requires experience. If you have decided that you need to involve this strategy, find a professional software development company who knows how to track user activities and gather feedback.
Once the project is started, be proactive. Your development camp can help you to define minimal work scope, but your job is to make it viable. Get your early adopters and motivate them to be the first who can get value out of your idea. Let them think that they are ahead of the future.
Be brave and decisive. Following the MVP approach requires not only a hope that "the idea will work out as expected", but also an ability to learn from the feedback, remove unnecessary stuff from the project and focus on the main problems your minimum viable product is supposed to solve.