Main content

By Opinov8, December 17 , 2019



A minimum viable product is a straightforward concept: Develop the simplest version of the product that’s still attractive enough for some real buyers, namely early adopters. You get feedback from users with a more critical mindset than in a beta testing program where they might forgive glitches and fail to mention possible improvements. In turn, you still have scope to add new features and improve the product before taking on the expense of pitching it to a wider market.
It can be tricky figuring out which features to include or leave out when developing an MVP. These are three that you can safely exclude.


Maybe features

By definition, an MVP only needs genuine “must-have” features. In theory, it’s a simple process. Take every suggested or potential feature on your project and define it as Must Have, Should Have, Could Have, or Would Like To Have (MoSCoW for short.) The problem is that if you ask the people who conceived or developed the features, they’ll almost always define them as “Must Have”.
You need to ruthlessly pare down the list and get developers to fully justify “must-have” status. Develop a one-line description of what the product does and its unique selling point. If a feature doesn’t directly address that description, it has no place in an MVP.


Untested features

The freedom and flexibility an MVP brings can be a trap, especially if you misunderstand its place in the development process. Use an MVP to test a concept like “track your widget stock on a blockchain” or “AI analysis of your Instagram feed to produce restaurant recommendations.” Finding out if people are prepared to pay for these solutions and whether they use them once the initial novelty passes is a great use of an MVP.
However, this isn’t the place to test whether the underlying technology fundamentally works: You need to take care of that before releasing the MVP.


Makeshift features

Always remember that though an MVP is a stage in a process for you, it’s an end destination for early adopters who buy it. That means you shouldn’t include a feature that plugs a gap to make the MVP “ready” when you know you’ll remove or replace that feature in the final product.
A good way to think of this is a common analogy. If your final product is a car, an MVP of simply four wheels and a chassis is useless: It’s a logical developmental stage, but it’s not a functional product.
Some uses of this analogy suggest a bicycle would be a suitable MVP because it’s a more primitive form of transport. However, a bike not only misses fundamental features of a car (goes long distances without stopping; carries an entire family), but it has features that won’t be in the finished car (works without fuel; works on cycling paths.)
The software equivalent is straightforward: Don’t include anything in an MVP that fundamentally changes what your intended product is or what it does. Doing so completely undermines the benefits of getting feedback from early adopters.