What You Should and Shouldn't Include in Your MVP

If you read my previous blog on Agile Project Management and Scope Creep, you’ll note that I touched upon another project management technique known as Minimum Viable Product (MVP). Although there are many definitions of the term MVP, for the purposes of this discussion I’m referring to a product that has been built with enough features to solve the absolute basics of the problem it is trying to solve. It can be seen as an unmatured solution that will solve the problem, but will still need to be built upon. This type of ‘concept’ MVP is commonly used by start-ups to prove or refine an idea more rapidly and at a lower cost compared to building a releasable product.

Now in this post, I’ll try to answer the question of what features you should consider putting into your initial concept MVP and what should be left out.

But before answering this question, let's cover a few other important ones.

Question #1 – Why should we build a concept MVP and not the full product?

The answer to this question lies in the realm of uncertainty and resources, but one of the following answers will likely be right in your case:

1. I want to test some of the ideas before I build the full product
2. I want to build a POC (Proof of Concept) to see if the product even works
3. I don’t have all of the resources needed to build the final product
4. I want to be quick to the market

Question #2 – Who will see/use the MVP?

In most cases your audience for the MVP will be the ones who you believe will use it and have likely already given some input into your requirements list. This could include Internal Clients, Business Clients, or specifically identified Potential Clients. Most of these audiences should fall into the following categories:

New Product:

1. Early Adopters
2. Friends and Family
3. Potential Partners
4. Potential Investors

Business Product/Internal Product:

1. Product Manager
2. Friendly Users
3. Testers

Out of all the potential audiences listed above, the two that really matter are Early Adopters and Friendly Users, as their answer to the questions “what do you think?”, “will you use it?”, and “what will make you use it more?” matter greatly.

CBInsights research shows that 42% of startups fail because there was “No Market Need” for what they were selling. This is the case for many internal applications as well, from the outset there has to be demand and need for your product in order for it to be successful.

Question #3 – What are the goals of the MVP?

Since we need to be ready to hear the following answer in early previews: “I tried it and it’s pretty cool, but …” We need to:

1. Showcase the product and its main functionality (“I tried it”)
   1. If you can’t show it, don’t build it (simulate it or mock it)
2. Collect and use the feedback (“It’s great, but …”)
   1. Make sure to record feedback on functionality and use it to make a difference in the next iteration
   2. Make sure the MVP is still modifiable enough to allow you to deal with the “but …”part of the feedback. If elements are hard to modify, they should not be part of the MVP.

The process of validating the product is represented in the above diagram. The add-ons (arrows pointing up) are based on the client’s feedback of what they want in the product, the arrows pointing down are the throwaway mini ideas/experiments you presented to your audience.

Question #4 –  What should we actually put in the MVP?

Finally, we’ve made it to the big question - what should be in the MVP? To answer this we must first understand that the concept MVP is not a formal product per se. Instead it is something that should help you clearly demonstrate your idea for the product to the audience.

The MVP should be created with the intention of learning from the audience what needs to be developed, through manual (survey or questionnaire) or automated (behavior and usage tracking) means.

In reality, a good idea with an excellent presentation is not enough when showing off your MVP, some sort of a working demo has to be present to receive meaningful research. When building out your MVP, focus on:

1. Main value proposition
2. Main differentiators of your product from similar products
3. Learning Tools – Automated tools for data collection or manual product reviews collection.
4. Something that will help your audience evaluate your solution against others and provide constative feedback.

Question #5 – What should not be included?

When presenting your MVP to a limited and known audience, it is important to remember that it is not at the maturity level of a paid product at this point, instead it is at a level that will provide you with functional feedback. Because of this, we should not be spending our resources on the branding or sales and marketing related features of the product.

Here is a list of features that should not be included in a concept MVP:

1. Scale support (i.e. the MVP does not need to be built to support the full end product user base)
2. Marketing and sales features
3. Features other than the differentiators and main value proposition
4. Features for experienced users, not early adopters (they will probably will not see your product in the next few years)
5. Monetization capabilities

To summarize, a product’s concept MVP should allow you to demonstrate your value proposition to your very first users (early adopters, friendly users), this will allow you so you to learn from them and have the flexibility to be modified per their needs.

Online utilizes the concept MVP methodology in many areas of what we do, including Digital Experience. If you would like to learn more about MVP please leave a comment below.