Proof-of-Concept. Prototype. MVP. Pilot.
When building software products and platforms, it is of critical importance to define the desired output. To start with the end in mind.
Standard best-practice is to test our hypothesis with stakeholders, users and customers as early as possible. What we wish to test, and with whom, defines what artifact we should build as we meander towards product-market fit.
Artifacts & Outputs
The artifact that we produce should reflect what we're trying to achieve. It should map to what we're trying to test. The form of our artifact will determine the decisions we make about what gets included, and what does not.
In essence, in the early stages of product development, we want to determine:
Will it work. Technically, functionally and commercially.
What will it be like.
Mostly we're trying to gather information on each of these aspects to determine (i) whether or not to proceed or (ii) how to refine and optimise.
The following definitions will help to frame the design conversations and decisions on our path to launching a product.
Proof-of-Concept
A Proof-of-Concept (PoC) is an implementation of a method or technology to demonstrate (or assess) its feasibility and practical potential. Here, the objective is to prove or disprove the technical feasibility of implementing the technology. Typically, PoCs are less focused on the experience of the user, and usually aren’t an end-to-end solution. Rather, the PoC focuses on a particular subset of the technology, often in another technical stack that production.
A PoC typically has a short life-cycle. The objective is to decide whether or not further investment is to be made. A PoC is not exposed to users and is evaluated by domain experts.
A PoC is far from ‘production ready’. Its functionality is limited to the aspects to be proved, is not designed for optimisation, for scalability, security or aesthetics unless those are the technical criteria under investigation.
In short, best-case scenario, you'll be refactoring a PoC.
Prototype
A prototype is an incomplete version of a product designed to test a complex idea in a realistic form with realistic users to capture feedback. The elements that are often tested are (i) the end-to-end solution, (ii) some new form of interaction or (iii) use of the product in a new, realistic setting.
Prototypes, like PoCs are deployed early in the product development lifecycle - usually for a brief period of time and often through multiple iterations. The prototype is designed to elicit feedback and then discarded. Where a PoC aims to test the riskiest technical assumptions, the prototype aims to test the most important aspects of the experience. A prototype is throw-away.
Where the project scope is particularly constrained - wireframes, Wizard of Oz prototypes and low-fi, physical prototypes may make an appearance.
Minimum Viable Product (MVP)
The Minimum Viable Product (MVP) is the first iteration of a product that is delivered to real users. Like a prototype it focuses on the most important features fo the product. The key difference is that an MVP puts these features into the hands of these users, not just to test, but to be used independently and on an on-going basis.
Like a prototype, the MVP is designed to capture feedback from users - in this case under real, continuous usage, independent of direct observation.
By generating insights early and at a low cost compared to a ‘complete product’, the MVP offers the opportunity to test the assumptions of the product in the wild. Typically, a product team will iterate and build upon the MVP but just as often, the product may be discontinued or pivot to a different solution.
While the MVP is a light-weight, scaled back solution, this can include the polish of a final release. However, including an aesthetic finish of reasonable standard is often required to make realistic judgements of the hypothesis. This is especially true when the product is in the consumer, mass-market sector or where alternative solutions are mature.
Pilot, Proof-of-Commerce
A pilot is the initial roll-out of a system or solution into production - typically, targeting a limited scope of the final product. Scope may be limited by the number or location of users who can access the system, the business processes affected, the business partners involved, or the technical integrations enabled.
The purpose of a pilot project is to test market assumptions and configuration options. Typically this is done in a production environment with an implementation that will form the basis of future iterations. Sometimes, (due to speed considerations or technical debt) the implementation will be kept independent from existing products.
A pilot is used for planning decisions centred on the launch of a product to a large-scale audience. The lifecycle is relatively short but typically longer than PoC, prototypes and MVPs. The feedback captured by the pilot is used to quantify the performance of the new product; performance usually meaning commercial uptake. While the feedback results may not be at the expected final level, the pilot should provide proof-of-commerce.
Translation Errors & Organisations
Pedantry is rarely greeted with smiling faces. But it sometimes pay to be pedantic. Language is important.
Nevertheless, people are people and groups of people are organisations. It is frighteningly common that these terms are used inter-changeably or misused altogether. This comes with risks.
PoCs, prototypes, MVPs and pilots have evolved from 50 years of software and hardware design and their adjacent industries. Hard lessons have been learned along the way. Hard lessons that have been encoded in these artifacts. Using them appropriately doesn’t guarantee success, but it drastically reduces likelihood of failure.
Calling something a PoC and expecting it to launch in market is a recipe in planned disappointment. Expecting a low-fidelity prototype to wow an executive team is a risky reputational undertaking.
Take the time to clarify the language upfront, and save weeks of hard graft and stakeholder miscommunication down the line.
Modern product development has imbued us with incredible power to build valuable, worthwhile products that maximise the chances of being successful on launch. Knowing in advance where there are unknowns and what our plan is to gather that information and feedback is an incalculable advantage over designing in the dark.
Know your terms; be pedantic.
— — —