Minimum Viable Product (MVP) in a nutshell: why, how and when? – interview with a Product Specialist Jakub Kochański

Minimum Viable Product (MVP) is the minimum set of features that is required in order to engage users (possibly early adopters) and start the learning-feedback loop. This product development strategy has proven countless times to be the most beneficial one as it minimizes the risk of running out of money and enables one to find the perfect product-market fit.

However, building an MVP can seem intimidating and startups around the world still shy away from following this process. That is why I asked Jakub Kochański – Product Specialist from Fream, where he continuously improves Evryplace – the virtual tour software boasting thousands of users – to shed some light on Minimum Viable Product.

During the interview we will discuss the following: benefits of MVP, how it is done, what challenges await a product developer and what mistakes are there to avoid. Then, we will move on to finding the balance between minimum and viable, and actions that should follow each MVP.

1. To your mind, what are the benefits of the MVP?

First of all, thanks to MVP your business idea can be validated by the market without investing too much effort. Lots of products get actually cancelled during the stage of building MVP, when the stakeholders verify that their idea will simply not work, thus saving a lot of resources. In this scenario, without the MVP these resources would be put into developing something useless – which the startup founder liked but the users did not need. But let’s say that was not the case, and the creators followed through. The MVP was developed, and the early users of the Minimum Viable Product caught onto it. In this scenario, we have some users, who are extremely helpful as they give us insights on what works for them in the product, and what does not.

A stakeholder has a very different perspective from the user, and despite the oftentimes astounding amount of empathy they have, they will never be able to walk in the users’ shoes. Basically, thanks to MVP we are able to develop further features more accurately and avoid dead ends.More precisely – there will be love points which you will want to build up on and hate points which you will want to eliminate in further versions of your software. This information makes a world of a difference in product development.

Generally MVP gives you the information: should you scale this idea (or just parts of it)? Pivot it? or maybe abandon it and move on to something else? Each of these answers is valuable as it tells you how to efficiently invest your resources.

2. How to construct a successful MVP?

Once again: a successful MVP is the one that gives you useful information. After a successful MVP you know that there is a customers’ need which you can accurately address. A successful MVP does not always mean your early adopters love your product from the release. Sometimes they will, sure, but it is very rare. An MVP becomes a successful one when your users engage with the solution and find the core of your solution useful and give you feedback on how to further develop and improve it.

I would say it is less about what you construct  and more about how you do it. To construct a successful MVP you should develop it in a reasonably short amount of time (depending on a product it can vary between couple weeks to couple months) and with an easily adaptable framework. Building a complex architecture with multiple dependencies will create a situation in which you might later have to sustain the parts of your MVP which will not be further used.  Keep it simple: only the core of your potential product, no visual or functional fireworks. A successful MVP is the one that was created fast and with as little resources sunk as possible – one could use the well known phrase “less is more”, which is much easier said than done.

3. What is the biggest mistake one can make while building a Minimum Viable Product?

I think it would be when it is built too robustly, and built over a longer period of time than needed, for example three months instead of a couple of weeks for a simple product. Of course we want our early adopters to see our full vision and be able to use a ton of features, which are factually important. But let’s remember that the MVP of AirBNB did not even support payments – it was just a listing of available accommodations. I’m not claiming that if it did support payments it wouldn’t have achieved such a success. My point is rather that in a world where 9 out of 10 startups fail and roughly about a third of them due to lack of product market fit – there are bound to be startups which invest too much in their vision without validating it early enough with the customers.

The other mistake is falling in love with your MVP – which might lead to an odd situation when you believe the product is amazing – it’s just the users who do not get how brilliant it is. You have to see eye to eye with reality – building an MVP is about humbleness  and the ability to admit that you could have built your product differently than you initially thought. Obviously, marketing during the release of a new software product can play an important role – new needs are created daily by the marketing departments around the world. In my opinion, however, it is way easier to market something rooted in the real needs of the customers, thus rendering the odds of success higher. That is why you should not fall in love with your MVP. Instead, treat it as something that can, and most probably will, evolve multiple times, often to the point where it doesn’t even resemble what you built at first.

4. How to find the balance between minimum and viable?

Generally MVP should be lean. The amount of functionalities and features should be stripped to the bare bare minimum with a potential to get user engagement and bring unique value. The point of it is to get feedback as early as possible and with as little resources invested as possible – which is the main benefit of the MVP. Of course the developers of a new digital product or service will think that everything about their idea is important.

The point of MVP is to strip it down from the unnecessary features, which might be hard. There is no simple

formula for that. Sometimes there are no unnecessary features and that’s when it comes to tough decisions and cutting down on the necessary ones. For example when we developed a feature of image enhancement  in our web app for virtual tours we dropped the idea of developing highlights and shadow control of highlights and shadows. We wanted to see if the users need this feature at all and we developed it with solely the basic control of the brightness, contrast and saturation. This gave us insights on how to satisfy the need to make the imagery which users’ upload to our web app look better.

Prioritizing is and always will be difficult but it is inevitable. You have to ideate which of the features are more important to the user. Your development team will help you with that. The goal is to develop a version of your product which responds to the higher needs – which are more common among the users or more important to satisfy. We have to remember that we often think something completely different than the users do.

5. We’ve built an MVP, what next? What if it goes wrong or how to grow your potential on a successful MVP?

You iterate.

Listen to what your customers said about your MVP and with this insight you try to ideate the solution. If your users found your web app useful but they lack the ability to communicate to other users – add it. If they find it too slow – find a way to shorten the user journey.

These are simple examples. It is hard to say specifically how to resolve your problems or build up on good features, as there is no one solution to these. There are always multiple possibilities. Being creative and open minded about refining software goes a long way towards your goals. Trying different solutions with the users will definitely affect whether you  succeed or fail. Budget always is the bottleneck – everyone wants to develop right from the start instead of spending money twice building and refining. It leads to a trade-off between costs and usability of the product – in my opinion it is important to at least be aware of that and manage this trade-off consciously.

Generally, develop a solution based on what your users say. When you implement it, release the next version of your product and then validate it with your early users again. It is simple and keeps the user in the center of your development, and with short production cycles allows you to make steps and at the same time check if those steps have been set in the right direction. If you reached this stage, this means your MVP was successful, and your product went past the MVP stage and started its process of becoming a full-pledged market-ready solution.

__________________________________________________________________________

To sum up, the MVP allows you to build your startup or product faster, cheaper and on a better foundation – based on evidence, keeping users in the development loop and being more honest with the terms reality offers.