Proof of concept vs Prototype vs MVP in app development
The proof of concept, the prototype and the MVP are three terms that are thrown around a lot in mobile product development. It’s no wonder it can be hard to figure out how to fit these methodologies into your product development plan.
It can take a while to understand the differences between them, especially if you’re a new startup or a brand exploring mobile-first products to expand your offering. So if you’re feeling confused, let me tell you it’s ok.
If you’re feeling confused, let me tell you it’s ok.
You’re deciding how to start building your product. At the same time, you’re looking at your budget and thinking about how to minimise costs. No one wants to make the wrong choice and realise they’ve thrown money out the window.
The TL;DR for what to make of a proof of concept, a prototype and an MVP
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 had to do at some point.
No, really.
Every founder or intrapreneur that ever built a product started somehow. Even the ones that make the news headlines.
The short version for deciding between the three is this:
- The proof of concept (POC) method revolves around testing if an idea is doable from the technical side — in other words: can we make it work as we want it to, with the current technology and coding options available?
- A prototype of a product is a visualisation of it, meant to showcase the core user flows and help you identify usability flaws. It can be kept low-cost, or taken to full interaction levels, depending on what you’re looking to test
- A Minimum Viable Product (MVP) is the first live version of a product. It’s the core value proposition version wrapped in the essential features. It’s made to be launched as soon as possible to generate valuable user feedback and revenue.
The first thing to realise is that it’s not about choosing either the one or the other.
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.
This article was first published on Tapptitude on November 27, 2019. Read it here.
Let’s get to the bottom of a POC, a prototype, and an MVP
Next up, I’m going to walk you through the specifics of each of this method. Then, we’ll take a look at the pros and cons of each. If you’re in a hurry, scroll straight to the bottom.
If you’re in for the long read, here’s an outline so that you can scroll around.
The proof of concept (POC)
- When do you need to pursue a proof of concept
- Proof of concept helps you frame the development process
The prototype
- How many types of prototypes are there
- Prototypes are made to be shared and tested
- How is a prototype built
The MVP
- A useful, usable and delightful MVP
- How mini should your MVP be
- The business value of launching an MVP
- Do you always need to build an MVP
Let’s get started.
The proof of concept (POC) methodology
The proof of concept method is all about testing if a particular concept is feasible from a technical point of view. The process implies a project with a straightforward end goal. As a result, everyone 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 when to pursue a proof of concept. The specifics of your product dictate them, and each helps you frame the concept you’re proofing. Here they are:
- Do you have a prototype created?
- Has your type of product been built before?
- Do you have competitors that offer specific, high complexity features? Is your product based on new technologies, like AR or AI?
Let’s take them one at a time and see why these matter.
Your prototype is ready for development
It’s rare for a product to be one feature and nothing much besides it. That’s why one part of the product definition process is to document and illustrate through a prototype all the features your product entails. When you have this done (we’ll enter into details on this in the next section), it’s worth taking the time to plan your development.
High-risk features that need more time coding and don’t have proven functionality should be tackled first, through a proof of concept process.
High-risk features that need more time coding and don’t have proven functionality should be tackled first, through a proof of concept process.
If your make-or-break feature isn’t doable, there’s little point in investing in the development of all the other functionalities of your product.
Instead, you’re saving yourself those costs. You also create for yourself 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 someone done this before you?
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 interest to ensure that your plans have practical potential in the real world, with 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 proof first.
If someone has done these features before, 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 doing this?
Knowing what’s out there comes hand in hand with understanding what your competition is doing.
Say you’re building a product in a market that already has several competitors (let’s be real, your product probably is in this category).
Your product will have similar functionalities with your competitors’, but you decide to take one 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 built on new technologies?
New technologies — like augmented reality, artificial intelligence, or 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 proofing.
Whether it’s an AR-powered mental health product or an automated transcription service, you want the core feature to meet the user’s expectations of what they’ll get.
Proof of concept helps you frame the development process
In all these cases, the proof of concept method enables you to frame how you look at the development process:
- it allows you to identify the high-risk features of your product and prioritise them
- it breaks down product development in simple yes/no pilot projects to test the technical viability of your product.
If the results for 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 as we imagined it? We have to be honest, that happens. Our imagination has always had faster legs than tech and software innovation.
Despite your expectations, a failed proof of concept isn’t a death toll. But it is a signal to pivot your product.
You may discover that the feature you’re testing isn’t as good as you wanted, but still decent enough.
Or you may find you need to scrap your approach entirely. Either way, you’ll be moving forward with your product. And making better-informed decisions than you had at the start of your journey counts as progress.
The prototype
If you’re looking for a way to start your product creation that pays more attention to the users’ needs, you need a prototype.
Prototyping is a tried and tested method of creating a new product and testing the waters with it before going full-in on development.
The concept is borrowed from manufacturing, back when you wanted to test the first version of a product — say a radio, or a chair, or a car — and get everyone’s buy-in to set up the production line.
In product development, a 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 how a user inputs data, to give an almost real-life experience of your product.
Mind you, the process isn’t as simple as going from a blank page to a fancy prototype. Whether you’ve got a clear image of your product or just a fuzzy concept, it’s always easier to start prototyping with low-fidelity, low-resource iterations.
How many types of prototypes are there?
There are three types of prototypes you need to know about before you start designing one. Which kind you use depends 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:
- explore features
- replicate your competitors’ features to understand their building blocks
- align your team before starting the more in-depth work.
Low-fi, 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:
- Do people understand the different actions they can take on each screen?
- Do people use the product as you intended?
- Is the copy clear and consistent everywhere?
- Do users find value in what the product offers?
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 a high fidelity, interactive prototype. In this case, a UI designer takes the flows, features and structure visible in the wireframe prototype and brings them to life.
The designer decides on a colour palette and the building blocks of various elements. They add photography and consistent icons and designs 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, and many more, are all the domain of the interaction designer.
Prototypes are made to be shared and tested
Once you get this kind of prototype put together in Invision or Marvel, you have the equivalent of a cardboard Ferrari ready to take for a ride.
And by all means, do that.
Prototypes are most valuable when out in the world, getting poked and prodded by potential investors and future users.
The first 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 second will be able to give you 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.
How is a prototype built?
If you’re one of our clients, the process goes like this:
We start with a Product Definition Workshop, where we:
- outline your business and product goals
- help you position your product
- identify its audience
- map the product flows
- decide on the features we need to include.
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.
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.
The Minimum Viable Product (MVP)
Over and over again, we see in our work that there’s a general misconception about:
- What an MVP is
- When to consider building an MVP
This misconception goes somewhere along the lines of this idea:
In truth, an MVP should be more like this:
A useful, usable and delightful MVP
There are three levels to what makes a product successful. It’s a combination of how useful, usable, and 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 for the purpose for which it was designed. So whether I have a three-legged stool, a dining table chair, or a full-fledged office chair, I can use them all to sit down and write this article.
Usable refers to the ability of the product to be used in a simple and pleasurable way.
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 muscles in my back twinging. On the other hand, I can sit a couple of hours in a dining table chair caught up in the flow of writing. That makes it both useful and usable.
But if you want to keep me as a returning ‘user’, you’ll let me have the fancy office chair and feel delighted by it.
A great MVP will check boxes from all three levels: it’s going to be useful, usable, and delightful at a minimum level.
How mini should your MVP be?
When in doubt, go back to the basics. Trust the guy who defined the MVP in the first place, Eric Ries:
“The minimum viable product is that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.”
An MVP is a basic, core-value-oriented form of your product, which you release into the market. Then, you watch and learn from the insights it generates about your target audience, as well as your business goals.
But what’s core-value-oriented when there’s an app for everything, and any respectable product has a mobile version?
Look at your competitors for insights
The answer to that 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 you’re building 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 building a finance app, you should have something to stand out against the likes of Revolut or the Apple Card. Or, you know, move to a different market where you’re not competing directly against them.
What your competitors are doing is what sets the baseline.
Also look at what’s viable in 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.
And 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 in 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
- can you make money with it 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?
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:
- 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
- The development budget does not allow for more
Questions like:
- How many features should you include?
- How it should look like
- How long should it take to develop?
can be answered based on your context.
It’s exactly why we arrange a Product Discovery Workshop with all of our clients who come to us with a product idea.
When we do our due diligence to define and document your product from the start, we set the foundations for making better decisions in the future.
Proof of concept, prototype, MVP. Differences and takeaways
As you can tell, 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.
At the end of the day, what matters is that you choose the path that helps you and your team make better-informed decisions.
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 for as a successful product maker.
Tapptitude is a product studio specialised in helping funded startups and innovative brands to define, design, develop and grow mobile-first and interactive products that people love 🧡 to use.
If you’ve found this article helpful, make sure to check out Tapptitude’s blog here.
If you need help with starting your own product journey, we’re always happy to sit down with you for a talk. Contact us here.
