The critical things you need to know about building an MVP (part1)

I speak to a lot of potential clients about new app projects — both start ups and established businesses. During our first conversation I can pretty much guarantee that something like this will be said.

It sounds great doesn’t it? Build an MVP and get to market quickly.

But more I speak to clients, the more I realise how much misunderstanding there is out there on what actually constitutes an MVP.

This article lays out some of the crucial things clients need to know about building an MVP, and perhaps more importantly, the misconceptions.

Understand the basics

MVP stands for ‘Minimum Viable Product’. Essentially it’s the most basic product that you can reasonably build to test your business assumptions. It has just enough features to engage your target audience but simple enough that it’s quick to bring to market.

“ 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

A company will often build an MVP to target a particular subset of users or early adopters. These will often be more loyal and more forgiving of a partially finished product and more willing to provide feedback.

Don’t confuse minimum and viable

The crux of the MVP lies in the place where minimum and viable meet. The product must be sophisticated enough to test the assumptions, but simple enough that you can get to market quickly (the minimum bit).

Often clients misunderstand this. The hear the work minimum and think they need to ask this question:

Or even this question:

This is a mistake, and it’s a fundamental misunderstanding of the purpose of an MVP. In actual fact, the real question you need to ask is.

Work out your hypothesis and then work backwards to determine your feature set

Before you can work out exactly what you need to build, you’ll need to determine the hypothesis you are trying to test. You may be trying to work out if your users will transact in a particular way — for example make a payment or download a feature. On the other hand, you may be trying to establish whether they will engage with your content — in which case your metrics for success might be the amount of time they spend on your application.

Once you’ve decided on your hypothesis you can work backwards to determine the actual feature set you need to build. Just the minimum to reasonably do the job. Of course, there is no set formula for this. It will vary quite wildly depending on the type of product you are building.

When we started to build Q App, we wanted to build an app that allowed users to order in pubs without having to get up from their seats. We thought that the product would eventually allow users to do all sorts of fancy things like table delivery, order for specific timeslots etc. But first of all we needed to test our hypothesis — that people wanted to order drinks from their phone and avoid the queue at busy times.

Of course, because our minimum feature set involved taking a payment, we had to introduce a level of complexity into our first version. The user needed to be able to set up an account and add a credit card etc, none of which was super simple. But that was the type of product we were dealing with.

Had we been building a different kind of product we might have been able to go to market with a much simpler MVP.

Find the point where ‘minimum’ and ‘viable’ meet

Interestingly enough, when we first had the idea for Q App we tested the concept with a very basic ‘MVP’. Our first ever ‘product’ consisted of a mobile phone number which we placed on the tables in a bar. Users were invited to text an order to this number to order their drinks. They could then go up to the bar and pay in cash.

It worked very well, and was certainly ‘minimum’, but was it ‘viable’? Only partly. Sure we knew that users wanted to pre-order their drinks, but we didn’t know whether they’d be prepared to set up an account and go through the necessary hurdles inherent in a proper payment application.

It wasn’t until we built version 1.0 and tested it, that we knew they would be.

The following graph illustrates the concept. As the complexity of your hypothesis increases so does the required complexity of your MVP. Build too much and you’ve wasted time. Build too little and you won’t really give your product a proper chance.

Be strong — stick to your guns

The following point is really important. I’ve seen a LOT of projects get into problems over this.

Once you’ve settled on the feature set that you need for your MVP, build this and only this.

Don’t be tempted to add more features — even if it seems like it’s only ‘one more thing’. One more thing can turn very quickly into a bloated and over engineered version 1.0. Whatever it is, it won’t be an MVP.

What does this mean in practice? Well, quite often, during the project build cycle, something like this will happen:

When Joe in accounts asks if he can have the payroll calculator included in Version 1, politely explain that for now you’re just building the minimum required to test the market. Stick to your guns and be strong.

This is much harder that it looks, especially in big organisations. It requires the strength to say no, but it’s vital to getting your MVP to market.

Next Time

Well that’s it for now. In the next post I’ll cover some of the other mistakes that clients make, including leaving out the feedback cycle and not considering the whole product.

I’m a product strategist based in London. I help companies make compelling and engaging digital products, and opimise for growth. Get in touch at tim@nimblelondon.com