There are many opinions on what constitutes a minimum viable product (MVP), from thought-provoking philosophical discussions that examine the nature of ‘minimal’ and ‘viable’ to those that give you a step-by-step breakdown of specific requirements. However, these tend to be based on specific experiences. There is nothing inherently wrong with this approach, what works for one person is great, and it might work for someone else. That being said, every company’s situation is different, and therefore specific strategies might not work universally. A greater emphasis needs to be placed on general guiding principles that you can apply to a specific situation.

Therefore, this guide will look to provide a framework to use while developing your MVP. Rather than imitating someone else’s steps and actions, this framework will allow you to analyse your situation and deploy the most effective techniques and strategies for you.

Before we get started, we should lay out what we mean by MVP. There are many different types and many valid approaches. In order to get the most use out of this guide, an MVP should be thought of as a functional and, to some extent, scalable MVP. Pieter Levels, someone who has launched more MVPs and tested more ideas than most, in his book Make states that “a first prototype should function really well… Minimum needs to be minimum good.”

That being said, this framework will be constructed in 4 parts and be made up of 6 general principles:

1.    Find your value proposition – This will be a process of discovery and most likely take several iterations to get right, but you need a grounded value proposition in order to help shape every other step of the process.

2.    Do you need an MVP?  We’ll look at the factors that need to be present in order for an MVP to be a good idea, whether or not there are steps you can take beforehand, and the possibility of not even needing one.

3.    Building your MVP – what should be your focus, feature selection, business model considerations, when is it ‘ready’ for the public?

4.    How to determine success? What are the different models of feedback, and how can you implement them to get the best return in value from your MVP?

Find Your Value Proposition

Principle 1: A clear and targeted value proposition that your potential customers will immediately understand will help guide your later MVP decisions.

By the point you’re considering an MVP and taking steps to bring a product to customers, you should have an idea and a problem that you are solving. Nothing motivates customers more than the promise of alleviating a pain they have in their life. 

As time goes on, you might update or realign your value proposition as data and customer feedback comes in. But a value proposition is always your starting point. It is the key to guiding the rest of the decisions about your MVP.

Your value proposition needs to be:

1. Important enough to a specific type of customer that it solves a problem or addresses a real need.

2. Unique enough that it can stand independent of other companies and have a clear distinction or USP.

3. Short and easy enough to understand that it can be read or explained in seconds.

4. Something that your target customers just get.

Solving a problem that people can easily relate to is the easiest but not the only way to achieve these four things. If your target customers don’t get the value, then you can either change the offer or the customer. If there are shades of grey (which there will be) with regards to some understanding and some not, then look for patterns amongst the “yes’s” and the “no’s” to investigate the cause of the miscommunication. Is the product the problem, or are you targeting the wrong people?

One way to formalise this process can be seen in Crossing the Chasm by Geoff Moore. His template allows you to clearly articulate the important points of your proposition.

For   _______________________ (target customer)

Who    _______________________ (statement of the need or pain point)

Our (product / service) is        _______________________ (product category)

That (statement of benefit)    ______________________ .

A good way to identify value statements and help you determine yours is to take companies whose products you know well and try and fit them into the template outlined above. If you can figure out what the value proposition and target market of other companies are, then you will get better at doing it yourself.

One tip when practising this exercise, focus on specific products and brands. This is typically easier for earlier stage companies rather than mature, multi-product, multi-brand companies. The more diverse the product range, or list of offerings, the harder it is to nail a single value proposition. 

Do You Need An MVP?

Principle 2: An MVP is not always the first step, and other forms of testing and quicker steps can help prove the viability of a product.

With a value proposition in hand, we’re going to put the brakes on diving straight into building an MVP because, not every startup at this stage will need one, nor might it be the correct course of action to take. Why? Well, an MVP isn’t the only way to test an idea or test a product to determine its market viability.

For example, a proof of concept, prototype or ghost MVP might be more appropriate. An MVP, at its core, is a functional product that works well enough that you could release it to the public and has a level of scalability built-in. But even though it is watered down from a full-featured version, an MVP still might be overworked compared to the levels required for the next stage of your company.

Maybe your service is complicated, and you need to make sure that it works in varying use cases (proof of concept), then perhaps test that people understand how to use it (prototype) or prove that the value proposition is compelling enough that people will pay for it (ghost MVP), before finally releasing to the public and gather feedback from your target audience (MVP).

Naturally, the distinction between these stages can get blurred.

A proof of concept is an internal test where you make sure that you can execute on your idea. The technology is there; you have the people, network or understanding to bring it to life. It is normally ugly, clunky and has no bells or whistles. But underneath the rough exterior is a functioning system. With a proof of concept, you can solve the problem outlined in your value proposition.

A prototype would be the next step, or perhaps you don’t need a proof of concept, and this would be your starting point. A prototype presents a visual or tactile feel for what the product will do. It lets you and the testers see where you are going, and the leaps in imagination required to see it as a full product are reduced compared to a proof of concept. Your target customer should be able to understand the value in the prototype even though it is not the real thing.

A ghost MVP can take a few forms. However, the basic intention is to test whether your target customers will pay for your product/service before you’ve built a proper MVP. Perhaps this takes shape in a simple form and payment screen, and you manually complete the tasks required that an MVP would look to automate (in order to have scalability). Or they arrive at the checkout screen and put their payment details in (indicating they would have paid), and you don’t charge them. There are multiple services and ways that this can be achieved, some of which you can find in the companion article here.

These are smaller, easier to achieve steps. They provide solid indicators that you are on the right track and that you have made correct decisions about your product when you put them in front of people, even if it is not the wider public. They can help you reduce the number of iterations of your MVP you might need.

They also allow you to change direction with less sunk costs. If the techniques or strategies you had planned to use don’t pan out, then there is less at stake. You can pivot in a day or week with a ghost MVP, rather than the month or two it might take with a functional, scalable MVP. All these preemptive steps provide feedback gathering opportunities and help guide MVP decisions.

One thing to consider here is that you might be able to use the prototype and proof of concept products to market and sell your future final version. By using services like Kickstarter or Indiegogo, lots of smaller companies have taken pre-orders which have allowed them to realise their final products and skip the MVP. This is one example when making an MVP might not be required at all.

Building Your MVP

Principle 3: Build the solution to the problem that the customer has, not what you think they have or will have.

By this point, you should have a pretty clear idea of what shape your MVP is going to take. Your value proposition has given you the groundwork to find the minimal effort way to solve the problems your customers are facing. And any proof of concepts, prototypes or ghost MVPs, have taken you through the initial idea and refined it, leaving you with an executable vision.

There are three steps to building an MVP: feature selection, business model implementation, and feedback strategy (we’ll examine this in the final part of the framework – How to determine success).

Feature Selection

Choosing features is, in theory, easy. You have the problem so, implement the solution. What features are required to do that?

This diagram has many forms, and you’ve probably seen it many times. But that is because it illustrates one of the core principles of an MVP.

When you initially have the idea for your product, you are solving a problem you have identified in the market. But over time, as they do, that idea evolves, and other ideas start to transpire, changing its shape and eventually its function.

All ideas that start with “we could do…”, “wouldn’t that be cool”, “how useful would that be”, “it totally should be able to…” inevitably lead you a little further away from the initial solution.

You are solving a problem in the simplest way possible. Not the most effective, not the most comfortable nor necessarily the fastest – just the simplest. Just remember it has to solve it! If it doesn’t function, the user can’t get it to work or has problems understanding it, then you’re not solving it.  

A good way to help yourself narrow down this focus is to take whatever your estimated build time for the MVP is currently. Say it’s three months… and cut it by a third. If you had to launch to the public in a month, what would that product do and look like?

Business Model

Principle 4: Find where your MVP or product will have its point of sale and determine a way to test both it and any necessary supporting structures. 

If you have tested this with a ghost MVP, then you will be well on your way. If not, part of having a viable product is having one that generates revenue. Maybe your business model isn’t a direct business-to-consumer or business-to-business model, and therefore, you don’t have to charge the customer directly (making it harder to test and implement). But determining where the eventual point of sale is and testing how your product will generate income is as important as determining the solution and features of your MVP.

If you don’t test your business model, you may find out too late that the problem you are solving isn’t something people are willing to pay for. Or that you haven’t solved it in a way that would encourage a transaction to take place. If you’re going for a business-to-business-to-consumer strategy like showing ads on your product for example, then you need to determine the effectiveness of those ads so you can sell the viability to customers.

How To Determine Success

Principle 5: Determine what you are testing, how you are testing, and what success looks like.

Another consideration when building your MVP is the parameters that you are going to use to test it. This can mean multiple things, it can be the market you deploy to test in, the features you launch with, levels of access granted to different customer segments, and naturally the data you collect on user usage, experience and feedback.

An MVP is only as good as the system around it that determines how successful it is. If you cannot accurately determine what users like, how they use the product, places they get stuck and the types of interaction different market segments have with your product (think tech-savvy early adopters compared to older generations), then you will have a hard time drawing effective conclusions from your MVP.

Therefore, it is best to establish these parameters early on. With your value proposition, you know the target customer, and you know the problem, so look at how sub-sections or niches of that target audience react. What are potential patterns that will tell you how people are behaving and the variance among those behaviours?

One great way to do this is charting out your user’s journey through the product, how they will interact with it, where will they end up? Further, things like, what does a happy user look like, or a disgruntled user? What do they do in these emotional states? These are your specifically targeted customers; you should have a strong idea of how they would generally behave on different journeys. You can then use these journeys to inform where you place points of feedback and data collection. To find out more about what market research looks like for a startup, check out one of our other guides here. 

Feedback

Principle 6: A successful MVP is one that gives you clear data and feedback on how to improve your product.

Here are the main ways to get the data you need so that you have the greatest return from the time and effort of building this MVP.

Passive Feedback

This could be the total amount (of anything); total sales, the amount of time spent, registrations, logins or even actions undertaken. What was your market penetration (how many people you targeted versus how many became customers)? Average price per customer (how much was the average payment?). What was the virality factor? (how many people did users invite to use it on average). What was your user growth in week one versus week five?

You get the gist. You’re looking at the users/customers to determine how they’ve taken to the product; this would be a non-intrusive way of examining success. This data is passively collected by your product or the systems supporting your product, and it is up to you to do the analysis once they are in use.

One-way Feedback

Here you’re asking customers for feedback at a set point in their customer journey. This is perhaps after a week of use, or after they have used a free trial but not signed up for the full package. You can also have multiple stages of one-way feedback for those committed (or incentivised) early customers, where they fill out feedback questionnaires at different points in their journey.

Rather than passive data, here you are getting an active formulated opinion in a structured way. You can compare responses to determine patterns and spot potential issues far more easily. Possibly the most important people to get feedback from are those that leave your product after trying it for a little while. These people will have a specific reason for why it didn’t solve their problem or fulfil their need and their feedback, therefore, is invaluable as it will help you determine weak points in your product, targeting and strategy.

Two-way Feedback

This time you’re getting on the phone, meeting them in person, or having a video call to interview your customers. Whilst you might have a script to determine the line of questioning, you have the freedom to dig deeper and pursue more subtle reasons for different things. Don’t underestimate the value of a good conversation and its ability to reveal the inner workings of your customer and their experience.

A successful MVP doesn’t have to go viral. It doesn’t need millions of customers overnight. A successful MVP is one that solves multiple customer’s problems. The important difference there in case you missed it, is customers, not users. If you’re solving a problem that multiple people are willing to pay you for, then your MVP has been a success, and you’re on the right track. If they aren’t paying, or the business model doesn’t have a path to revenue, then dig through the data to determine where you’re going wrong.