Many companies struggle to choose the aptest technique to validate their concept and choose between POC, Prototypes, and MVP. In our previous context, we discussed the definitions, applications, advantages, and use cases of these elements. You can find the link to the article here and peruse the write-up for a comprehensive understanding.

It is essential to know that it depends on the business idea or the end product and your target audience (B2B, or B2C, B2B2C); and you may need to use PoC, Prototype, MVP or a combination accordingly.

Idea validation using these concepts will ensure that your final product will enable you to achieve its ultimate goal.

A PoC can usually provide a direct response to whether the concept will be viable or not for the target audience. Idea feasibility will be measured here, and with the comeback, you can decide whether to proceed with the existing plan or not. Furthermore, a PoC can help convince your initial pre-seed investors that your concept can be implemented and is technically viable.

On the other hand, MVP enables companies to grasp information about the target user's experience and respond to the core business purpose of the application. The insights received from actual users helps to validate the overall objectives, identify the user pain points, and address the issues over time.

If you want to present how exactly your final product will look like, or manifest the main design elements, prototyping is the best way to give the big picture to the end user. It further helps to run multiple test areas while saving your resources. If you are looking for investors to work on your project, a tested prototype is the best way to demonstrate and pitch your product.

Should PoC, Prototype, and MVP be Throwaway Builds (Minimum Initial Investment)

It is always better to look at PoC and MVP as throwaway codes. If your business idea takes momentum and finds traction, it is vital to build everything from scratch with architecture and design to cope with it for the next 3 to 5 years. 

For PoC, think of the least expensive way to implement. Typically, when developing a PoC, factors like  product scale, architecture, UI elements are not considered. Instead, the requirement is to check on technical feasibility and customer feedback on your new product idea or a particular feature.

With all things considered, your PoC will be a hardly scalable piece to turn out for something decent. Hence, it is better to consider it as a throwaway build.

In relation to prototyping, it can be either a throwaway or a part of your final user interface, depending on the model type you select. For example, you can use rapid throwaway prototypes to receive user feedback and discard it later. These models are used to validate the system functionalities and requirements. Hence, it needs to be removed as it does not add any advantage to the final UX/UI elements.

For MVP, you may have to build in a way that could cope up with the demand for the next 12 to 18 months (Not a rule of thumb, but empirically proven ). It is common to see startups control the growth without hurting long term plans to build the post MVP version. However, for the long run, it is essential to opt for a complete rewrite ensuring your final product can have flexibility, extensibility and adaptation with upcoming technology and supplementary changes.

A Guide to Choose from Poc, Prototype, and MVP

Exhibiting a decision matrix using a table. - includes questions and scores for users to choose the correct method for their products.

Check out the reference tables at the end of this article.

Decision Matrix

Parameters	POC	Prototype	MVP
Use Case	For Technology/Market/Behavior disruption (completely new idea, so need to prove a concept is viable to build)	To verify user journeys and messaging in a solution are understood by the intended users. Save time and money. Could used to attract seed funding	Get actual users to use your solution to solve the identified problem. Evaluating your solution solves the problem in an acceptable manner. Gather feedback from users to improve upcoming versions of the solution. Aim to the initial target audience response
Purpose	To verify technical/market/behavioral assumptions before getting down to development. / To clarify which way to go with the development. Convince internal stakeholders	Make the application usable for its intended users. To assure that the end users could navigate and get the job done using the solution. It is the working model of several aspects of your product. Prototypes help make decisions about product development and reduce the no. of mistakes and waste.	To prove, your solution is effectively solving a problem and it is effective enough for the customer to pay for solution.To get the minimum version of the product to the market
Form of implementation	Most rudimentary implementation to prove the relevant disruption is viable to implement	High or Low fidelity Wireframes/UI, users could navigate through different screens but nothing has been implemented	Usable solution by its real user, just to solve the identified problem (nothing more, nothing less)
Target audience	Internal users (Decision makers about the project GO/NO GO)	Specifically selected sample of target audience (real users). Should be able to access more than once to verify the prototypes (should be able to involve with iterative process of prototype building)	Sample of target audience. Easily accessible, Give genuine feedback. Test the product with a pre-selected potential customer group
Cost	Less budget and is ideal to collect internal funding. Might have to invest on new tools and accessories.	Much less cost to build the prototype compared to PoC or MVP. More time/resources spent here saves time/resource at the expensive development phase	No compromise on quality as the end product would be used by real users. Cut the cost by reducing features, not the quality. Well-defined budgets and looks for investment
Human Resources	Requires technical experts to develop the basic concept. Could involve tech related R&D	Less technical resources as no coding / development is involved. Need to recruit testers, Iterative design processes	Here you are developing the actual product (at a smaller scale with less features) So needs full technical expertise
Risk Evaluation	PoC involves the highest risk or all. But lessen the risk in upcoming phases.	Reduce the risk in terms of user satisfaction in product navigation	Reduce the risk of losing time and resources of the full scale development
User Interaction	N/A since is its used internally	Gives an overview to the end user how the end product will look like with basic elements and navigation. Highly interactive with users but without real functionality.	Full user interaction. UI/UX, Key Functions and even feedback from users also a part of interaction
Apparent time to create	If you have several options or if you uncertain about the feasibility of the concept	When you are confident about your idea and needs to start and test the design process	When you are positive about the idea and the design, and ready to launch it to the market
When to Show the investors	Pre-seed / Seed	Pre-seed / Seed	Pre-seed, Seed, rarely for Round A
Cashflow	Negative (expenses only)	Could leads to Positive cash flows from Investors (Seed level)	Should lead to Positive cash flows from service revenues & Investors
Extended use	Can be used to develop MVP	Output can be used to develop the solution. No waste. If the prototype consist of UI design, it could be used for the development	Can be expanded and used for the full version of the product. You may have to throw away the code (Do not hesitate to do so)
What you should not do?	Invest time/resources to make the PoC usable to others.Implement things that have been already proven	Use placeholder content or graphics. Train/Assist testers. Test how UI/UX work on real environment	Compromise on quality Implement extra/supplementary  features
Outsource or in-house work	At this stage, you are working on an idea to check out its possibilities of turning it into reality. Hence, it is ideal to do in-house to ensure that your concept would not be revealed to third parties /competitors.	Prototypes can be fully outsourced as they will be exposed to the public for test-run purposes.	MVP can be done internally or with the contribution of a third party. A mixed team is preferred here to build up the product. Here, the expertise (outsource party) can help with the best techniques while the in-house team is conscious of the progress/development plan.

Final Take Away

Building a solid foundation is essential to deliver a successful software product. Your PoC, prototypes, and MVP will be your foundation for the process, with actual feedback. They will help you to iterate the product process and enhance the features to meet the user requirements or the ‘real-needs’.

However, software product development is not limited to paying attention only to the initial process but is involved with many crucial steps that need to be considered throughout the proceeding. With that note, the next phase of the development process will be discussed in future articles.