This is a post in our series about building minimum viable products to test the viability of your idea with real customers. This could be a good read for you if you're looking to build an MVP for your startup or enterprise.

Let's take a look into how and why you should try to go minimal when building a Minimum Viable product (MVP) application. Yes, I know, it's in the name. But let's dig a bit deeper!

"The Minimum viable product is that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort." — Eric Ries, Author of The Lean Startup

The purpose of an MVP is to test the market viability and learn about your customers. Your MVP should have just the Bare Minimum features needed to deliver that value and get your customer to part with their money.

Staying focused

When you're close to the idea it is easy to get carried away and start adding cool features. Try to avoid this at all cost. I've noticed that it is a good habit to write down the ideas for later to get them out of your head. This will help you let go and keep focused on the core value delivering features.

Keeping the scope small and manageable will maximize the chances of MVP project success. It is far easier to successfully execute a tight, well-defined MVP than a complex, monstrosity of an app. This will, as well, minimize your losses in case your MVP flops or turns out non-viable.

You should aim to get to an MVP which you can build and launch within a few weeks to a maximum of a couple of months. Generally, that should be enough time to build most MVPs. If it takes longer, you're likely building something that is too big i.e. a much riskier investment.

Exercise in minimalism

Let's assume you have a clear idea what is the problem you are solving. Next, you will want to drill down to find the core of your product that is just enough.

Unfortunately, there is no secret shortcut or strategy that will let you come out with the correct feature set every time. Ultimately, you'll have to interact with your future customers to find out where the sweet spot is.

We've used the following process successfully to establish which features should be included in an MVP:

• Create a list of product features that will solve your client's problem.
• Step into your customers' shoes and see what is the bare minimum feature set that will deliver the value.
• Get in touch with your future users and see if they agree. If you can, try pre-selling to validate the value proposition of the minimal feature set.
• Iterate points 2 and 3 until you have validated the minimum set of features.

Essentially, you will be repeating this process after you have your first MVP out. Take in user feedback (learning) and release new versions to address that and better serve your users.

Detecting non-essential features

Even with the best intentions of whittling down your product, you easily end up having too many features. Here are a couple of ways to spot features, which you should cut:

• For each feature you intend to put in your MVP, think: “can I still deliver the value if I do not have this?”. If you can, then cut the feature.
• The feature was added as a result of "It would be nice/cool/great to have X...". These are often nice-to-have features that are not critical to your MVP.
• The customer is saying "If your product had an integration with X, then I would pay...". The integration is probably not what you need. It might be a warning sign that the core value of your product is not high enough.

This should help you keep it minimal, when it comes to building your first MVP!

ps. If you're on the ride for the first time and looking to outsource your MVP development, our Flightplan: MVP outsourcing course might just be for you. :)