Since Agile has become a method applied by many companies, from start-ups to corporates, the term MVP has become a house-hold name in as many offices. But what is a MVP exactly? What are the challenges? Are there alternatives?
Lets start with answering the first question:
What is a MVP?
A MVP is a Minimal Viable Product. Its soul purpose is to test the assumptions you made while conceptualizing a brilliant idea to conquer the world with (for example) your app. Working with a MVP you should be able to accelerate learning, reduce hours development and get user feedback. Sound logical right? Think again... There are exactly three difficulties with the terminology here. These difficulties all have in common, the difference between theory and practice.
1 What is "minimal"?
Minimal means that your app, or website, or whatever, contains only the features necessary to test your assumptions. In theory this sounds clear. However, in practice it is very difficult to determine what minimal exactly is. Especially when you have a group of capable and creative people, minimal might not so minimal in the end. It is not fun and often not well received in a team of creative people when features are dismissed in order to keep the MVP truly minimal.
2 What is "viable" ?
Viable is when the thing that you have developed can live; it has a complete user experience and, in theory, can generate enough cashflow to survive. The challenge is the cashflow issue. You have to build a business instead of building an app. Building a business is a totally different challenge. So, maybe your idea is viable, you might not have resources or time to prove this.
3 What is a product?
A product is something that you can buy that fulfills a need in your life. This means that the thing that you have made, is coherent enough for people to understand it. To make a product, means that your app is doing everything it should do. So, you have to build things (like dashboards, integrations, etc) that have nothing to do with testing your most important assumptions; the initial goal of the MVP.
Are there alternatives?
In the past decade I became to love the concept of the MVP. However, I have always emphasized the M. Minimal. I agree with Tom Chi (co-founder of Google X);
“Maximising the rate of learning by minimising the time to try things.”
When an MVP is minimal but not perfectly viable and not a product, it is not an MVP anymore. But, what you developed, enables you to test your most important / riskiest assumptions (the initial goal of your MVP).
Before you develop an MVP, you can develop something even simpler; the RAT (Riskiest Assumption Tests). With the RAT you remove the temptation of prematurely creating a rudimentary product. You just test, learn, explore and discover.
This seems easy. It is not. The factor that makes it difficult; people. Your team needs to be relentless in the pursuit of minimizing effort. In a phase of creativity and believing in an idea, this can be very challenging.
Some related challenges
The past decade I have seen a lot of challenges, which where the result of a different mindset when it comes to getting a product to the market. I will name a few.
Agile? People say they understand what it is to work Agile, but they tend to seek too much comfort in the project. They want to design the database model before it is clear what the app should do. In my opinion, building the MVP is about getting a first release to the market. It does not need to be perfect. You need to build enough flexibility in your software to cope with iterations or you must build the MVP and accept that you have to rebuild a large part in order to make it scalable.
Prioritize? Working on large projects, the challenge is prioritize. Make sure that everybody understands the goal of the MVP and make sure everybody understands that adding new features will push the deadline. This might sound trivial to you and me. But believe me, it is not trivial for everybody. People who constantly "think of new thinks" are useful when defining the product. You have to get them out of the way while working on a sprint. Developing solid software is about structure, organization and focus. The last thing you need is someone constantly trying f*cking up your workflow; "Yes I understand your concern but we really need this". Don't give in. Put new features on a wishlist. Usually, what is "really necessary" today, is not so important anymore tomorrow.
Enough resources? In large organizations with more then enough resources, there is no pressure to test assumptions quickly. The change money and time is being spend on idea's that will never be viable is very realistic. More important; the time this organizations spends on these ideas, competitors are discovering products people actually needs.