How To Build An MVP

In the world of tech startups and new digital product launches, failure happens fast. Many factors can spell disaster for new tech launches, but a lack of user need is one of the most damaging. In the UK alone, 42% of 101 startups fail due to a lack of market need for their services or products.

How can you limit the chances of your venture failing? How can you win users early, then build a product they will always come back to? It’s all about the MVP, or minimum viable product.

For founders and digital startups as well as CTOs at tech firms launching a new product, MVPs are absolutely critical to your success. MVP’s work to concentrate your development efforts and give you a clear goal - whilst also preventing distraction and feature-bloat from entering the process.

Creating an MVP is part of the ‘move fast’ mentality of start-up culture - but it benefits any tech launch. MVPs allow you to:

• Start building up your userbase early.

• Begin gathering live, analysis-based feedback.

• Identify new features based on genuine need.

• Create early brand loyalty.

• Secure initial investment for start-ups.

MVPs also rapidly increase time and cost efficiency by preventing scope creep and keeping development teams focused on ‘what needs to be done’ as opposed to ‘what can be done’. The MVP’s most significant impact, however, is that launching one allows you to start gathering genuine user feedback in a live environment. Without one, you’ve only got assumptions.

So, we know that having an MVP is critical - but how can you plan and build one for your own project? As stakeholder or investor expectations creep in, teams gain enthusiasm for certain features or ideas, and market changes shift timelines or perceived needs; how can you ensure you build a successful MVP?

Let’s take a look...

How to build a minimum viable product

Step 1: User research

Before you start writing any code, you need to understand your users. An MVP (and your product in general) should exist to solve a problem - so you should already know who your target users are. Once you know who they are, you should perform user research to establish how they behave, what they need and what they enjoy.

This process helps you create a better map of how your product can meet user needs. The most important features are those that are critical to the problem-solving the app provides. Extraneous features don’t need to be in the MVP - but you won’t know what is extraneous until you know what users need.

Step 2: Plan for speed

You must plan your MVP for a quick launch. This can be a matter of weeks, not months, which means you must plan for a development process that can deliver a working MVP in this timeframe. Some businesses don’t have the resources to accomplish that - so they outsource to software agencies, just like our own product studio.

We titled this step ‘planning for speed’ as opposed to ‘work quickly’ because it’s important to account for what rapid development actually means. For your MVP launch, you don’t need to develop for ALL of your users - you need to focus on a sub-set, with your team focused on building the core features around them.

Your investors, designers, developers and project managers must all understand that getting the MVP launched quickly is more important than launching it in a ‘perfect’ state. If they are, therefore, new to the world of MVP, you’ll need to brief them and help them understand the planning decisions.

There’s no such thing as perfect: how not to build an MVP

Some of the world’s most famous startups launched MVPs that lacked many of the features which define them today. Airbnb, for example, had no payment gateway, so day-one users had to exchange cash with their hosts (not ideal). It also lacked the ‘map view’ that showed you where properties were in a city. Yet despite this, it’s now a billion-dollar company known across the world.

At the risk of sounding mean, your ‘launch’ is not as special as you think it is. Nobody remembers the day Facebook, Twitter, Linkedin or Instagram ‘launched’. The important thing is getting the launch done so you can begin iterating.

Step 3: Build your spec

The ‘spec’ is the MVP’s scope- a document that outlines what it will include at launch. This spec should ideally be created with some pre-completed user research to hand. We would also strongly recommend putting timeframes against the spec by working with development and design to understand when you can launch it with the features you’ve specced in. You’ll also need to include testing time in the spec (more on that soon.)

Now, take that nice spec you’ve got…

Cut it.

Seriously, chop out any non-essential features/functionality. If you’ve got no ‘non-essential’ features, consider if you can afford to chop any of the ones you think are essential. Doing this will expose features that aren’t entirely needed and will also ensure you can hit the deadline you’ve outlined in the spec.

Step 4: Develop it in a proven format

You’ve gathered user information. You’ve briefed your team/agency on what the goals are. You’ve outlined a spec, then cut it down to bare essentials. You know what an MVP is, why you need it and when you’re going to launch it.

How do you actually get it built?

We’d advise the MoSCoW method, an Agile development practice that focuses on prioritising sprints around a system of ‘Must haves’, ‘should haves’, ‘could haves’ and ‘won’t haves’. Of course, your spec might have already done some of this categorisation - but MoSCoW isn’t just a planning exercise, it’s a way for a development team to work.

Work in a sprint-based system where each week targets X key feature/function—review in every scrum. Keep MVP development focused on the launch deadline - any new suggestions for features should be placed into a backlog rather than shoved into the MVP. Once the build outlined in your spec has been agreed upon, your development team should focus solely on achieving that.

Step 5: Incorporate strict testing

While there will inevitably be bugs in an MVP, remember that it is your main way to secure new customers and feedback. That means it needs to create a good impression, which it can only do if it actually works.

While we mentioned avoiding a ‘perfection’ mindset earlier, your MVP sprints should still incorporate testing - both from developers and if possible, from QA teams or users themselves.

What’s important to note here is that your testing should be planned from the beginning to avoid your whole project getting bogged down by QA. You must test each core component of the MVP to ensure they function and that, ultimately, the app/software can actually solve the problem.

Step 6: Launch without looking back

When it’s time to launch, do it. Don’t delay the MVP because of new feature requests. Stick to the spec and get the product live. Once it is, you can immediately reach out to the users you’ve already contacted and get them to trial the new MVP. Then, you can begin marketing it to a wider audience, gathering new customers and generating the all-important data and feedback which will drive your product from MVP to full launch.

Going from MVP to finished product

Once you’ve launched your MVP, it’s all about working in iterations. With a tangible product out in the market, users can begin interacting with it to give you an idea of what features need to be improved or added. Each new cycle of development can be based on learnings created by the MVP.

There’s also a chance your MVP fails to attract much interaction. If that happens, try not to be disheartened - it’s better to watch an MVP fail than see a full product with far more time and investment go up in smoke. The MVP gives you the ability to take stock and either pivot or improve.

If you’d like to learn how to go beyond the MVP, read our follow-up article ‘How to take your digital product from MVP to finished product’. Remember that ‘finished’ isn’t really a thing in software. By the very nature of digital technology, your product must continue to transform and adapt or be left behind.