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 if you’re part of a startup or a brand exploring mobile-first products to expand your offering. Your goal is to create amazing and useful products, but you also want to be mindful of your budget and find ways to minimise risks. No one wants to make the wrong choice and realise they’ve just thrown money out the window and have to start again.
So, if you’re feeling confused about where to start, don’t worry, as you’re not alone. We’re going to help you understand the differences between a prototype, a proof-of-concept and an MVP for your mobile development project.
During these last 6 + years of building digital products, we’ve had numerous conversations on what our partners need to start with when planning a new mobile product for the market. So, we’ve seen quite a few things happening and wanted to share this inside view on how to think of your go-to-market strategy with a product. We’re coming from a mobile product background, but the details below clearly fit for any digital product that needs to validate some core assumptions in a new market or with a new business model.
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.
Table of Contents
Need help defining your roadmap?
POC, Prototype, or MVP – Which should you choose?
We’re now going to walk you through the specifics of each of these three approaches. Then we’ll take a look at the pros and cons for each concept, so you can get a better picture of what they have to offer.
1. Proof-of-concept in app development
A proof-of-concept (POC) tests whether a particular concept is feasible from a technical point of view. Basically, the POC application method needs to have a straightforward end goal in sight, 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 the question: can this be built?
When do you need to pursue a proof of concept?
Different aspects can influence the decision to pursue a proof-of-concept in app development. Your product specifications will influence this decision and help you frame the concept you’re proofing. Let’s go through the most crucial aspects:
Do you have a prototype created?
It’s rare for a product to just have one feature and nothing much besides it. That’s why one part of the product definition process is to document and illustrate all the features your product entails through a prototype. When you have this done (we’ll go into details on this in the next section), then it’s worth taking the time to plan your development.
High-risk features that need more coding time and don’t have proven functionality should be tackled first, through a proof-of-concept. If your make-or-break feature isn’t doable, there’s little point in investing in developing all the other functionalities of your product. Instead, you’re saving yourself those costs and creating a window of opportunity to pivot your product. Redirect your efforts towards a different take that generates value for your business and re-uses the proof of concept code in other ways.
Has your type of product been built before?
If there’s nothing similar to your product on the market, then applying the proof-of-concept method is a must. It’s in your best interest to ensure that your plans have practical potential in the real world, for real users.
We recommend proofing all innovative feature requests from our clients before planning out the whole project. You can even ask us to do a technical risk assessment of your product specifications, to make it easier to decide which features to tackle first.
If someone has created these features before, that means there are comparable products on the market. In this case, there’s no point in testing features that have already proven their value. Which brings us to the next question.
Are your competitors already doing this?
Knowing what’s out there comes hand in hand with understanding what your competition is doing.
Say you’re building a product targeting a market that already has several competitors. It’s highly likely that your product lands in this category, as coming up with something original that no one has tried before is very rare.
Your product will have similar functionalities with those of your competitors, but you can decide to isolate a single feature and give it a distinctive edge. That is the kind of feature we recommend running through a proof-of-concept pilot. After all, we want your competitive advantage functionalities to work as expected.
Is your product based on new technologies, like AR or AI?
New technologies like augmented reality (AR), artificial intelligence (AI), or the Internet of Things (IoT) have reframed what people can achieve in their everyday lives. If your product has core features that are based on one of these new technologies, those are the features that need to be built, demoed and validated before deciding to base an entire product on their capabilities.
Whether it’s an AR-powered mental health product or an automated transcription service, you want the core features to work first.
The proof-of-concept helps you frame the development process
The proof-of-concept method enables you to frame how you look at the app development process, by allowing you to identify the high-risk features of your product and prioritise them. It also helps you break down product development in simple yes/no pilot projects to test the technical viability of your product.
If the results of your proof-of-concept pilot are positive, you have even more motivation to pursue building your product and taking it to market. But what happens if the results are negative?
What if we can’t build your core feature to perform the way we imagined it? We have to be honest, that does happen.
Despite your expectations, a failed proof-of-concept isn’t a death knell, but a signal to pivot your product. You may find you need to scrap your approach entirely, as the technology you chose doesn’t deliver the right results. And that is a great opportunity to pivot, in a moment when you spent a very small amount of money, to know something for sure. If you haven’t done that, the revealing moment that the technology doesn’t really work would have been closer to launch and after way more time & money spent.
Like our analysis? Sign up for our newsletter to receive more straight in your inbox.
Subscribe to our Newsletter
2. 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 a small new product and testing it with your audience before going full-in on development. The prototype is not yet the shiny end product, with all the things sorted out, but a core product that proposes some value for the users and gets them to test that value proposition. A prototype is a start of an iterative process, where, based on the user input, you create a better next iteration, on an on. The prototype concept is borrowed from the manufacturing industry. Manufacturers would create a unique first-version of a product – say a radio, a chair, or a car – then test it and get everyone on board to set up the production line, then they’d do it again, until they reach the expected results.
In product development, we can have design-only prototypes or coded products that work as prototypes (very close to POCs, but for different purposes).
A design prototype is an interactive mockup of your product, built without a line of code. 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.
Mind you, the process would not be going from an idea-in-your-head to a built prototype in one jump. You still need to go through a solid process of product definition, where you clarify the problem-solution fit, the overall business model and validation strategy, before jumping into any implementation. Because, clearly, a prototype sits on the border between product definition and product implementation.
How many types of prototypes are there?
There are three types of app development prototypes you need to know about before you start designing your own. The one you select will depend on how much information you’re working with and what your end goal is.
Pen and paper prototype
A pen and paper prototype is precisely what the name suggests. Instead of reaching for digital tools, you stick to pen and paper to sketch out the first iterations of your product. If you’re working with a team, you’ll likely end up replacing the paper with a whiteboard.
Paper prototypes are a great way to:
Low-fidelity interactive prototype
A low-fidelity, interactive prototype – or a wireframe prototype – takes your product brief, or any paper prototypes you have on hand, and showcases your product’s features and flows.
It’s built without focus on colours, images, or illustrations, and with a minimal emphasis on typography and icons. Instead, it focuses on functionalities and in-app copy to showcase how the product would work in a real-life situation.
Wireframe prototypes are great to visualise and review the functionalities of your product. If you put it together in a prototyping tool, you can use it to gather early user feedback. You can check for things like:
If you’re getting contradicting or negative feedback on any of these points, you’re still early enough in the process to make changes with low costs.
High-fidelity interactive prototype
If you’re looking for the closest thing to reality, your goal is to create a high-fidelity, interactive prototype, which basically means doing the full product UI and link it up in a testable interface. In this case, a UI designer takes the business logic, the UX of the product and produces the UI designs and brings them to life in the shape of a prototype.
The designer decides on a colour palette and the building blocks of various elements. They add photography and consistent icons and design each screen anew in technicolour. They also decide on the micro-interactions and animations a person sees as feedback as they use the product. Buttons changing colours, cards whooshing open or close, screen swipes left or right, are all the domain of the interaction designer.
Prototypes are made to be tested
Once you get this kind of prototype put together in Invision or Marvel, you basically have the equivalent of a cardboard Ferrari ready to take for a ride. And by all means, do take it for a ride.
Prototypes are most valuable when out in the world, getting poked and prodded by potential investors and future users. The former will give you credit for your work and have a clearer image of what you want to build. In turn, this gives investors more incentive to finance you. The latter will be able to give valuable feedback on how the product would help them – or not.
Knowing how people interact with your product is very valuable in this stage. There’s still room to make changes, and they won’t cost you nearly as much as they would later on, once you develop the product.
Remember, a prototype is an intermediary product towards the final launchable digital product, whose main purpose is to surface user feedback as a tool for product validation.
How is a prototype built?
If you’re one of our clients, the process goes something like this. We start with a Product Definition Workshop, where we:
Usually, we stick to pen and paper to visualise these flows and screens.
Then, we clean up the user flows and product map in digital diagrams, to have a clear picture of your product’s architecture. A UX/UI designer takes this documentation and turns it into a wireframe prototype.
Once the wireframe prototype goes through a round (or several) of feedback, it gets updated to a full-fledged high-fidelity prototype. Usually, this process takes between 4 to 8 weeks, depending on the product’s complexity. If you’re adding to it research time – for example, taking the wireframe prototype out for some testing – the timeline can extend.
You can choose to do your user testing with the wireframe or the high-fidelity prototype. Either way, it’s essential you acknowledge early that you will change your prototype based on user feedback.
A prototype is not meant to be pixel perfect. Instead, it should be capable of pointing out any errors regarding design or development early on. Prototyping is another way in which you can save costs as well as generate new ideas regarding implementation. This is how we get to the third methodology of validating a product concept, the MVP.
3. The Minimum Viable Product (MVP) approach
An MVP, or minimum viable product, is a concept popularized 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. Let’s clarify those terms a bit, as they have a specific meaning in product design.
Useful means that I can use the product to solve one of my needs. The solution I build should be useful in the context of a need, struggle etc. So, when I want to sit down to write an article like this, whether I have a three-legged stool, a dining table chair, or a full-fledged office chair, I can use any of them to sit down and write this article.
Usable refers to the ability of the product to be used in a way that improves the experience of it being useful (confusing a bit, I know). As there might be quite a few solutions to solve a need, a usable solution is, on top of being useful, also fit for its purpose.
Sticking to the chair example, it would go like this: writing from the three-legged stool is doable, but about an hour later, I’d be feeling the muscles in my back twinging.
Delightful. Not all chairs are made equal, as your back already knows. Therefore, choosing one over the other can be done even from this fancy angle: it needs to bring something more than its usefulness and suitability for a specific situation. That ‘more’ can be how it makes you feel due to its ergonomics, the material it uses, the story behind it, its smell, texture etc. The delightful side of things can be quite diverse and appeal to many different expectations.
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 minimal is too minimal?
To answer this question, you must go back to the basics. Once again, you’re going to trust the guy who defined the MVP in the first place, Eric Ries.
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
As said before, an MVP is as good as its validation strategy. And in order to have a validation strategy, you need to start with the core guesses (or assumptions, if you want to sound fancy), then devise a plan to test whether the users would actually behave as imagined. This is a way to reduce one of the main risks when launching a new product and a MVP is a tremendous tool to use.
Look at your competitors for insights
The answer to your question lies in what your competitors are doing.
If you’re building an on-demand delivery app, you should have something extra compared to DoorDash, FoodPanda, or Glovo. If it’s a productivity app, you’ve got to find yourself the niche that makes you stand apart from the likes of Fabulous or Evernote. If you’re working on a finance app, you should have something to stand out against the likes of Revolut or the Apple Card. What your competitors are doing is what sets the baseline.
Look at what’s viable on the market
There are different ways to keep your MVP at minimum effort, but you can’t let it cut into what makes it viable in the market. If your product can’t stand on its own well enough to warrant further investment, you need to pivot or approach the problem differently.
Here’s the neat part of these methodologies: if you’ve done your proof of concept on the trickier features, or gotten your prototype out to users early on, your experience with a live MVP will have better results than jumping straight into the water.
The business value of launching an MVP
If you’ve applied a proof of concept beforehand or prototyped your product, an MVP can help you focus on what really matters: are people actually using your product? And is it profitable enough to turn it into a business? If your audience is resonating with your product, focus on understanding how that is happening and how you can make it better.
If you’re not getting baseline results in how users are acquired and their actual usage patterns, ask yourself why. It might mean you’re not targeting the right people, or it might mean your product isn’t offering enough value to their users. Each case requires different actions to improve.
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.
As Eric Ries puts it, “we have to manage to learn something from our first product iteration.” If you can learn the lesson through other people’s experiences, there is no need to reinvent the wheel, is there?
However, the product concept does require an MVP, if:
At this point, you might still have questions about your MVP, including:
These questions can be answered only when put into context. This is exactly why we do a Product Discovery Workshop with all of our clients who come to us with a product idea.
Not sure what to include in your MVP?
Key differences between a prototype, a POC and an MVP
As we’ve learned by now, it’s your product concept and your context that dictates what you need when it comes to choosing between a proof-of-concept, a prototype, or an MVP.
There might even be cases when we’ll recommend doing at least two of the three before launching your product. Here’s an overview of the differences and takeaways of each, so you can make a better-informed decision.
What is the difference between a prototype and a proof of concept?
A proof-of-concept proves the technical feasibility of a product and whether it can actually be built, while a prototype is basically a sample, testable version of your product, typically design based.
What is the difference between a POC and an MVP?
The POC method tests the feasibility of your idea and whether it can be turned into a functional, viable product, while an MVP is an early stage version of your product, proposing some core values and which will be tested with real users.
What is the difference between a prototype and an MVP?
A prototype is a unique, trial version of your product that’s put to the test before launch, while an MVP is tested by real users and tweaked according to their feedback and input.
Proof of concept
Supports growth
Makes getting investment easier
Business value
Budget
While it’s important you don’t mistake any of these methods as replacements for what your product should be, remember that each can help you gain insights about your audience, the tech stack you need, and your business model. That, in turn, will help you save costs and set yourself up as a successful product maker.
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.
The short version for deciding between the three is this:
What you need to keep in mind is that it’s not about choosing just one approach. All three of these methodologies are used by product development teams to make informed decisions based on tested hypotheses. Using them saves money and brings to market a product that has the best chances of success.
Still hard to decide?
Like our analysis? Sign up for our newsletter to receive more straight in your inbox.
Subscribe to our Newsletter
This content was originally published here.