I’ve been wanting to write a post for some time comparing and constrasting the definitions for terms like proof of concept (POC), prototype, and minimum viable product (MVP). A recent LinkedIn post from Blocksmith on blockchain technology included a very cool 4-quadrant graphic that inspired me to (finally) start typing. I’ve adapted this representation a bit to fit my mental model of what differentiates these outputs. I’ll then share a quick definition of each type of deliverable or "output" depicted.
Vertical Axis
First, let me describe the axes. Vertically, we differentiate outputs based on whether they are made available to the market. At the low end of the axis, the output is never intended to be released to the market, including customers. At the top, we find assets that are available to the market through “standard” (not special) channels, like as a download from the site, for example.
Horizontal Axis
On the horizontal axis, we differentiate outputs that are expected to reliably deliver customer value (their value proposition) in “production” a.k.a. “the real world”, with those that are not expected to deliver practical value.
You’ll notice that the upper left and lower right quadrants are “grayed out”, meaning the axes are mutually exclusive in these areas (and thus make no sense).
Proofs of Concept
At the bottom left of the chart, we have POCs. As the name denotes, these are built simply to prove something, primarily to the team developing it. In tech, most POCs are technical. The goal is to make sure that some implementation we’d like to leverage in our product is feasible. For example, we might test a machine learning algorithm on a limited set of data to convince ourselves we're headed in the right direction. Normally, the product development team has no intention of showing these to external stakeholders broadly. POCs are not designed to solve problems in the real world in the form they are implemented.
Prototypes
Moving upward and to the right, we have prototypes. Prototypes are designed to validate execution in real-world environments (a type of feasibility or, more often, validate the user experience {desirability}). Prototypes often simulate (fake) backend processing and are not intended to be installed and used by customers. One of the simplest forms of a prototype is a wireframe or clickthrough. Prototypes using "dummy" data are common.
Betas
For our next output, we cross some important thresholds: a beta is an early version of a product that is intended for a limited part of the market and may have some important restrictions. Betas tend to be a bit buggy and may have fractured user experiences. However, they’re an important vehicle for the product development team to get feedback in a production-like environment. It’s very risky to “go to production” with a beta. I use Adobe’s Premiere Pro to edit videos. I’ll install a beta to see upcoming features but would never rely on one for an important project.
MVPs
The minimum viable product has many definitions. From my perspective, an MVP is the smallest increment that can be shipped with reasonable confidence that you’ll meet the business objectives you set for it, e.g., validated learning, adoption, revenue. MVPs are products! They’re expected to solve real-world problems and should be available through traditional distribution channels. I wrote a separate post about MVPs if you'd like more insight on this critical concept.
Conclusion
The outputs described in this post are important tools for product managers and their teams. The terminology you choose may differ but you should have a clear definition of each of them and set appropriate expectations with stakeholders. I believe the axes I chose in the diagram represent common perceptions of these teams in technology.