How To Plan and Execute an App MVP

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.

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!

Not everything can be made simple

Now, of course, depending on what industry you’re trying to service, or what problem you hope to solve, not every idea lends itself so easily to a simple MVP. Some industries are heavily regulated — like, for example, insurance or finance. So, depending on your app idea, it may be hard to quickly launch a basic MVP if it deals with customer data or money. So if you need to pass the scrutiny of a regulatory body, quickly building a product will not be a reality.

If a product uses biotech or sends people to the moon or requires building a very complex app, what should founders do? In these cases, making a website or a simple app prototype or even a Kickstarter campaign that explains what you want to do and what that would look like, can be enough.

You still need somewhere potential users can go and give you feedback and engage with your idea. Far from being the case that a complex app needs more time to launch, ideas that require regulatory scrutiny can be done more quickly, by not building anything at all. Focusing on something that works by letting users know what the problem is and how it will be solved can be enough to demonstrate viability.

What an app MVP launch should look like

A lot of founders have misconceptions about what a launch is. They hear the word ‘launch’ and they think about a big party where ribbons are cut and everyone drinks champagne and tells you how great your app is. This, my friends, is not really what we mean by a quick launch.

The way to think about an MVP launch is not when you are briefing your PR team about all the great things your app can do. The type of launch I’m talking about is when you get some users. That’s the most important thing. Get some people interested in what problem you are solving and get them using your app. It’s that simple. The glitz of opening night can wait.

If you want to learn from your customers, the best way is to let them spend a little time using your product. Talking to them is one thing, but where the rubber meets the road is the moment they have your app in their hands. Give them the app. Let them use it. If it doesn’t solve their problem, you know that you need to get back to the drawing board and iterate.

How to build your app MVP quickly?

So you understand that you need to get your app in front of people quickly. Great. So, now you are asking, how can I do that? Here a few tips that will help you get it into their hands promptly.

Time-box your spec

Your spec should be the list of things your app needs to have before you can launch. So, let’s say you give yourself eight weeks of development. That is your target. Sit down with your development team and make a list of only the features you can realistically develop within that time and just concentrate on those. Use the time constraints to narrow down what is on your spec list. Because there is no time for extraneous features, your MVP won’t have them. Perfect!

Write your spec down

This is such a simple step, but it’s one that too many app founders fail to get past. Write down your MVP product specification and stick to it. Because if you don’t, the opinions of others or even a lapse of memory can throw you entirely off course and have you scrambling to include features or functionality that you didn’t initially plan on including, turning your eight week MVP into a six to twelve-month affair.

Cut your spec

You’ve made a plan. You’ve outlined that you need eight weeks to get your spec into the hands of customers, but now you realise you are behind schedule. Instead of beating yourself up, realise this is part and parcel of the development cycle and instead of changing the deadline, make cuts to your spec.

Start cutting what isn’t wholly necessary so that you can reach your target. If by some miracle your spec has no possible fat to cut away, then start cutting essential things. The main goal here is to get something in front of your users. Once you’ve achieved this, you are moving in the right direction. You can use the momentum — and user feedback — to keep moving forward. So don’t delay. Get it out into the wild.

Don’t fall in love with your MVP

As much as you love your product, don’t make the mistake of falling in love with your MVP. It’s just the beginning of the product, just a starting point. It is not the destination. So don’t get sentimental about your MVP. Be ready to make the changes and cuts necessary to make others fall in love with it. That is your goal. Try not to lose sight of it.

[“source=dreamwalk”]