Proof-of-concept, prototype and MVP are three terms that are thrown around a lot in mobile product development, especially in the startup space. However, figuring out how to fit these methodologies into your product development plan can be challenging.

It can take a while to understand the differences between these three concepts, especially when you’re looking to understand how choosing the one or the other might affect your budget or your future chances of success. We’ll walk you through the differences between a prototype, a proof-of-concept and an MVP for your mobile development project.

This article was first published on Tapptitude’s blog. 

Our team at Tapptitude has been building digital products for the past 6+ years. We’ve had numerous conversations on what our clients need to start with when planning a new mobile product for the market. With our background in mobile-first and cross-platform products and having worked in industries such as financial, health tech, consumer apps, marketplaces and automotive, we’ve seen quite a few things happening. These are just some of our insights in how to approach a decision in making a choice between a proof of concept, a prototype or an MVP. 

By going through each concept and its pros and cons, we’ll help you pick the best approach for your next mobile app. However, if you don’t want to go through all of that and want us to recommend the best option for you, feel free to reach out and talk to us about your project.

 POC, Prototype, or MVP – Which should you choose?

We’re going to walk you through the specifics of each of these three approaches and list the advantages of each concept, so you can get a better picture of what they have to offer.

Proof-of-concept in app development

A proof-of-concept (POC) tests whether a particular concept is feasible from a technical point of view. The POC application method needs to have a straightforward end goal and it has to demonstrate whether that goal can be achieved or not. Following the implementation of this process, all parties involved should be able to answer this pretty straightforward question: can this be built?

When do you need to pursue a proof of concept?

Before even considering a proof of concept as an option for your product, you should make sure you’ve run through the process of defining your product. You should be able to list and categorize all your product’s features by the technical difficulty of developing them and the competitive edge they would give your product. 

A key aspect of the proof of concept is taking the most high risk feature of your product – one that doesn’t exist yet on the market, that cannot be replicated by your competitors and that’s the key in delivering value to your users – and making sure that you can make it work. For a more complex product, you can go through proofing high complexity features as long as you need.

Only then does it make sense to build the full product and commit to the business behind it. 

If at any moment a proof of concept fails, you’ve created a window of opportunity to pivot the product and redirect your efforts towards a new type of business where you can generate value in a different way. 

 

The prototype approach to app development

If you’re looking for a way to start your product creation that pays more attention to the users’ needs, then what you need is a prototype.

Prototyping is a tried-and-tested method of creating code-free product preview and testing it with your audience before going full-in on development. Platforms like InVision or Marvel help us bring together screen designs to create a ‘smoke and mirrors’ version of your product. A prototype responds to taps and imitates the way a user inputs data, to give an almost real-life experience of your product. 

You will still need to go through a product definition process in order to know what to include in the main flow of the prototype, as well as to clarify your solution, the business model behind it and your validation strategy. 

A prototype is a great tool to run user interviews with your core audience and identify any issues that may affect your product before going into development. It’s also a way to showcase your product’s value and commitment in any early fundraising efforts you may be pursuing. 

The Minimum Viable Product (MVP) approach

An MVP, or minimum viable product, is a concept popularised by Eric Ries, author of The Lean Startup. Ries defined the MVP as ‘that version of a product which allows a team to collect the maximum amount of validated learning about customers with the least effort.’ This method allows you to start the learning process immediately, and make adjustments along the way, by building a product and seeing if and how customers engage with it.

Three steps to creating a successful MVP

There are three levels to what makes a product successful. It’s a combination of how useful, how usable, and how delightful a product is. A great MVP will check boxes from all three levels: it’s going to be useful, usable, and delightful at a minimum level at least.

 

How to plan your MVP?

To answer this question, we must go back to the basics. An MVP is a basic, core-value-focused type of your product, which you put in front of some users. Then, you watch and learn from the insights it generates about your target audience, as well as your business goals.

Here are a few ways to plan your MVP.

  • First, look at what are the core assumptions about your product and how it delivers value; your MVP should look to validate them.
  • Look at your competitors for insights and try to have a competitive edge over them. What they are doing sets the baseline of what is minimal in the market. 
  • Look at what’s viable on the market, so you can make it stand on its own well enough to warrant further investment.

Do you always need to build an MVP?

Simply said, no, if your business model risks are low or are not product-dependent. If your product is very similar to existing mobile products, then grab all the knowledge you can from what others have already invested time and money into finding out.

However, your product concept does require an MVP, if:

  • Your product demands a different behaviour from the user on a given matter;
  • The core value of the product is nothing new, but the UI is significantly different;
  • You want to build the product iteratively and properly lean.

Conclusion: POC, Prototype, or MVP for your next app?

Are you still having a hard time understanding these three concepts and figuring out how they apply to your product? The most important thing you can do is keep moving forward, instead of being stuck in decision paralysis. Choosing how to start is something everyone has had to do at some point.

If you’d like to read more about the differences between the proof of concept, the prototype and the MVP, get your insights here.