How To Plan and Execute an App MVP

What is an app MVP?

We’ve all heard the term Minimum Viable Product (MVP) and we know launching an MVP is best practice for app startups. But what actually is an app MVP and how do you go about planning and developing one?

First, here’s the Wikipedia definition:

A minimum viable product (MVP) is a version of a product with just enough features to be usable by early customers who can then provide feedback for future product development.

You can read the full definition here but the above statement sums it up quite nicely.

For a founder, what it all really boils down to is spending less of your budget on building the wrong solution and more on building the right one. This is done by building a basic functional first version of your app for the lowest cost possible, then adding to it (or changing it) based on real user feedback and data.

When you’re thinking about an MVP, you should be thinking about extreme simplicity. Give your very first set of users the most basic, stripped back version of your product as possible. From there, you can gauge whether you are providing them with something of value or not before investing more money into it. It’s really that simple.

This guide was inspired by the teachings of YCombinator Partner and Twitch Co-Founder Michael Seibel. We strongly recommend listening to Michael’s MVP talk when you have a spare 25 minutes.

Thinking about the problem

All good startups begin with a problem. Clearly understanding the problem you are trying to solve before building your MVP, is a very wise move. To do this you need to get out there and speak to your potential users. Find out exactly who they are and what specific challenges they have. You don’t have to do years of meticulous, in-depth research or work in an industry for a decade. Just try and understand their pain points and figure out what it is about currently available solutions that don’t work for them.

Although it’s not strictly necessary, it can help if your app solves a problem you have personally experienced. If you already understand the problem, you’ll be in a better place to solve it. Designing a solution to a problem you have experienced personally also makes finding your first user easy – it’s you. 

However you choose to go about it, when it comes to your first users, you need to find out who they are and where they congregate, so you can speak to them about their pain points.  

Next, let’s take a look at the MVP app development process from a high level.

Step 1: Aim for a quick launch

One of the more abused concepts floating around Silicon Valley is “fail fast, fail often”. When misused, it can foster a culture of short term thinking that is destructive and chaotic. When used correctly, it can lead to an iterative process that uses each “failure” as a springboard or catalyst to evolve your product to better solve the issues your users face.

The best piece of advice anyone can give you about launching a new app is to launch quickly. Just get it out into the wild and in front of your users. It doesn’t have to be perfect, and it doesn’t have to be packed full of features; it just has to be capable of demonstrating some value to your prospective user base. From here you can find out what does and doesn’t work and gain those crucial insights that enable your app to evolve.

Step 2: Get some initial users

A surprising hurdle that many startups never get past is acquiring initial customers. This is somewhat related to Step 1. You need to get a version of your app into the hands of somebody, anybody, in order to get feedback. Before investing time and energy into figuring out how your app will work for everyone, concentrate on getting it into the hands of a few people who are most affected by the problem you are trying to solve.

This step really should be quite easy. If you understand your problem well enough, you should also understand who has the problem. Just reach out to some of them and ask them to try your app. If you don’t personally know anyone with the problem you are trying to solve and can’t find anyone with the problem, perhaps it’s the wrong problem for you to be solving.

Step 3: Get feedback from your users

To have a genuinely iterative approach, feedback is crucial. To get this feedback, you need to speak to your early users and be open to their criticism. It’s important not to take this criticism personally. It’s also important not to wed yourself to any particular feature or idea of what your app should be. 

Often founders will have a grand initial vision of what their app should be once it is ‘finished’ and they are inflexible to feedback that doesn’t fit into their plan. They somehow see feedback on early versions of the app as somehow invalid because it’s not feedback on the final, finished product. This type of thinking leads to the failure of many new apps.

If an app is not working well at its core, all the extra bells and whistles aren’t going to make a difference. So speaking to users, finding out exactly what is and isn’t working well, is the best way to know what you’ve got and what you need to do to improve it.

While having a vision is excellent, it needs to be flexible enough to incorporate functionality and use cases that you didn’t initially realise were important. Many successful apps are very different from their original conception. The reason they worked was that they could be improved or reworked to provide more value or a better solution to a problem.Step 4: Iterate on your app MVP

This is the final, but arguably most critical step. Once you build and launch an app it can be very easy to become attached to it. This attachment isn’t good for your product. If your initial users don’t find any value in your MVP, it can be tempting to try and crowbar it into another niche or find another problem for it to solve. Very rarely is this the right approach.

Remember – there is a legitimate problem your app was meant to solve. If, when it was put in front of people with that problem, it didn’t help to solve it for them, then the solution isn’t right yet. This issue can’t be addressed by casting around for new users.

“You don’t want a solution in search of a problem.”

Instead of changing the problem — or the user — you need to change the solution by iterating. If people don’t love it, you have more work to do. Find out why it doesn’t appeal to your users and improve on it. It’s that simple.

Handling user feedback

It’s important to note that this iteration process doesn’t mean just adding every feature users suggest to you. In fact, it’s usually best not to even get into new feature discussions with your users. Coming up with features is your job as the founder. What you really need from your users is to better understand their problems. Then you can design features to better address the most common problems first.

Now that you understand the basic premise and benefits of launching an MVP, let’s look at the process in more detail.

Start simple

Start by building lean. And when I say lean, I mean as lean as possible and as quickly as possible. Apps are time-consuming to build but startups should aim to release their initial app MVP in under 3 months. If it takes much longer than that, there are likely too many features for a true MVP.

Consider whether you even need to build an app as your MVP. Many MVP’s start as just a landing page and a spreadsheet. Whatever can be done quickly and at the lowest expense is best. Of course, nothing beats putting a real product in your customer’s hands, but if you can demonstrate your solution and gain feedback without building anything, this would be a good starting point.

Choose whatever form of your product that you can make quickly, that communicates your idea to potential users. Do it quickly and get it into the wild and in front of your users.

Limited functionality

This is crucial. Your MVP needs to start small. It needs to be a small but sturdy foundation that you can iterate from. To achieve this, the functionality needs to be minimal. Instead of thinking about your potential future users, it’s best to consider your initial users and the simplest solution to the larger problem. That’s all – nothing more. You might have some great ideas for little innovative add-ons, but now is not the time for them. Now is the time for making the core idea work. And to do that, you need to get a streamlined version in front of your users.

It doesn’t have to be special; nor does it need to be excellent; it just has to be a version that people can use and give you feedback on. So again, it doesn’t need to be the version you dream about with all the bits of functionality that would make it ‘complete’. All your MVP needs to be is a version that your users can use. That’s it.

Airbnb as an MVP

Airbnb was a perfect example of an MVP. When Airbnb first started, they didn’t have an app at all and the website couldn’t take payments. Yes, that’s correct. The revenue stream, the thing that would make it financially viable, was added after the fact. Initially, users who wanted to rent a property, had to meet up in person with the owners and exchange cash. However, even without payment processing, Airbnb demonstrated precisely what it was about their service that was valuable to prospective customers.

So the take away from this is that an MVP doesn’t need to do anything but address the core issue in the way that is simplest to build. Without worrying about payment processing, Airbnb could get the core functionality in front of their users to test and see if they found it useful. And they did. Later, they were then able to add the extra processes that make it viable — like a revenue stream!

Leave a Comment

Your email address will not be published. Required fields are marked *

Scroll to Top