What’s the difference between an MVP and a PoC?

Consider this scenario: A transportation business has an idea for a product that will revolutionize travel as we know it. To be successful, though, it relies on a futuristic implementation of self-driving technology that may or may not be possible. The CEO is worried that a competitor may beat her company to market, so she wants to expedite the development process. The question is, should her company start with an MVP or a PoC?

If you’re not sure about the answer, you’re not alone. Sometimes, even the experts can conflate PoC (Proof of Concept) and MVP (Minimum Viable Product). But understanding the difference can save you time and money, and it can prevent failure to ultimately set you up for long-term success. For the purposes of this article, we are considering the MVP an extension of the prototype concepts we’ve been discussing throughout this ebook. By now you should know that prototyping is critical to overall product success and identifying the right MVP.

After reading this article, you’ll understand the differences between an MVP and a PoC and how to choose the right one for your needs.

What is a Proof of Concept, or PoC?

Entrepreneur defines a PoC as “a small exercise to test a design idea or assumption.” And while that’s definitely a valid definition, in a software product context, a PoC is more often technical in nature. It may be a small piece of code or engineering snippet, or it might be a bigger project. No matter the size, it’s all about determining feasibility and gaining internal validation with teams and stakeholders, as opposed to external validation with customers.

A PoC is an ideal way to test your assumptions about what you think is possible before sinking a lot of time and money into a project. Angel Almada, Director of Solutions Engineering at 3Pillar Global, describes a PoC as “A quick and inexpensive way to validate assumptions without causing customer friction. A PoC won’t produce direct value to customers but will help validate internal assumptions such as technology selection.”

When Should You Use a PoC?

If you’ve got questions such as “Can this be built?”, “Will this work?” or even “Will this give us the return that justifies the cost?”, a PoC can help you get the answers you need. Take that hypothetical transportation company we mentioned earlier. Because the product idea hinges on an untested piece of technology, a PoC is the clear choice. Why? If the underlying tech isn’t feasible, the product idea won’t work. Better to figure this out sooner rather than later. Early dedication gives the opportunity to tweak the idea and adapt to conform with what’s feasible before sinking a lot of time and money into it.

However, PoCs can be leveraged in much smaller contexts with large impact. Scott Varho, SVP of Product Development at 3Pillar Global gave the following example: “Our team was looking at options to move away from sessions based on browser cookies to some kind of session server and service to support our SaaS platform business goals. We had multiple options and settled on 2 options that seemed like they could work. Rather than just picking one and starting the long process of migration, we decided to do PoCs of each not to take longer than 2 sprints for both and then re-evaluate the best option based on that limited experience. The result was a choice we felt much stronger about and made the long journey of migration less subject to doubts about that choice. This kind of confidence is vital when doing any kind of infrastructure changes that always take longer than planned and present unforeseen challenges.”

While the term PoC is most associated with startups, companies of all sizes—even enterprises—use PoCs to test technical feasibility. Case in point: Walmart’s 2016 Hyperledger Fabric PoC tests. Walmart’s Big Idea was to use blockchain technology to create a food traceability system that could help prevent widespread outbreaks of foodborne illnesses. The question was if the technology would work as intended. To test the feasibility of such a system, Walmart, with their tech partner IBM, ran two small-scale, internal PoC projects using the Hyperledger Fabric blockchain-based tech. One project traced mangoes sold in US Walmart stores; the other, pork sold in Walmarts in China.

The PoC tests were a success and allowed Walmart to scale the system up. By 2019, they could trace over 25 products from five different suppliers and required all leafy greens suppliers to trace their products using the same system. Without the smaller PoC projects, Walmart wouldn’t have known whether it was possible or advisable to implement such a large-scale food tracing system.

What are the major differences between PoC and MVP?

Because both a PoC and an MVP can be used to test assumptions, it’s understandable that they get confused. Recall that an MVP is all about gathering the maximum amount of knowledge through the minimum feature set to prove (or disprove) your most important assumptions about your product’s viability and desirability. That means an MVP should be ready to use by real customers. On the other hand, a PoC is testing assumptions about feasibility, and as such, it’s strictly for internal use and not something that could (or should) be launched publicly.

When it comes to an MVP, usability is crucial. With a PoC, not so much. Francisco Ponce, Operations Director at 3Pillar, explains that “An MVP should have a high level of quality and polish, so no issues or malfunctioning are expected. A PoC may have low performance or a poor user interface, derived from the rush to make it.”

Another big difference between an MVP and a PoC is the order in which these methods should be applied. By its nature—as a way to test feasibility of various components of an idea—a PoC generally comes before an MVP. While an MVP is a product with the bare minimum of features, some—or all—of those features or functionalities may need the type of validation that only a PoC can provide. It makes sense, then, that a product may have many proofs of concept but only one MVP. That said, as you iterate on your MVP and add new features based on what you learn in the market, you may find you need to run another PoC before implementing something new.

Henry Martinez, Director of Solutions Engineering at 3Pillar, offers this whimsical way to think about the differences between these two methods: “A PoC is where feasibility fears go to die. An MVP is a ‘coming out party’ for innovative products.”

When You Should Use an MVP vs. a PoC

Determining when it’s appropriate to use one over the other really comes down to understanding the purpose of each method and weighing this against your needs. As we’ve outlined, if you aren’t sure if a particular functionality is even possible in relation to your product idea, you need to run a PoC. A PoC is also appropriate if you’re worried that implementing certain functionalities will be too expensive, as it can help uncover parts of a project that are simply too cost- or labor-intensive before committing time and money to an actual build.

And as we’ve seen, if you just need to test a smaller part of the whole, you probably need a PoC. Scott Varho, SVP of Product Development at 3Pillar, explains, “In engineering circles, PoCs are used to test out a piece of architecture or technique to see how it will perform and whether or not it solves a problem in a way that is valuable to the product(s) it is being considered for.”

Sometimes, doubts surrounding a particular portion of your idea may be a roadblock to progress. That’s why you might need internal validation from your team or stakeholder buy-in. It’s easy to imagine that Walmart stakeholders had serious doubts about the feasibility of blockchain technology to serve as an effective way to trace food supply chains, for example. A PoC can demonstrate whether or not your idea can be brought to fruition. In other words, the PoC demonstrates that it can be built, not necessarily if it should be built.

An MVP, on the other hand, is the right choice only after these types of doubts around feasibility have been put to rest. An MVP should be used after you’ve done your market research, created user personas, and reached consensus on the minimum feature set that you believe will deliver maximum value to users.

Conclusion

As you can probably infer by now, knowing whether you need to go with an MVP (or prototypes) or a PoC really depends on what kind of viability you need to test. Angel Almada says, “If I have a robust idea of what my customers might want—through user research and market validation—a prototype/MVP is the right approach to create a product that solves their needs and matures over time. If I want to have a quick ideation process for technology selection or to understand my customers better, a PoC is a better approach.”

At the end of the day, ask yourself which questions need to be answered. Are you unsure about technical feasibility? Then you need a PoC. Are you ready to test desirability and commercial viability in the real world? Then you’re probably ready to embark on prototypes ending in an MVP.

At 3Pillar Global, we strive to minimize time to value, solve for a real need, and excel at change. Learn more about 3Pillar’s services and how we can help you test the feasibility, desirability, and viability of your product by contacting an expert today.