Is this a Prototype or an MVP? Well, actually, it’s a Proof of Concept.

Are you using technology terms properly? This is a practical guide to help you define a ‘prototype’, versus a ‘proof of concept’ and a ‘minimum viable product’. Read on to avoid costly misunderstandings.

When building software products or solutions, it is of critical importance to define early enough the target output — in terms of both functionality and ‘production readiness’.

Using the right terminology for your software project is critical since it sets the expectations with your stakeholders — all those with direct or indirect interest in your project, including customers, sponsors, decision-makers, vendors, or partners.

The following provides quick definitions and practical guidelines — it will help you select the right term for your project — or reconsider its scope :)

Proof of concept — PoC

A Proof of concept (PoC) refers to an implementation of a certain method or idea using specific technologies — in order to assess and demonstrate its feasibility and confirm its practical potential. The objective is to prove the idea and/or technology by exposing a realistic, functional implementation of a subset of functionality. It is usually small, focusing on a particular aspect of the product, and is typically not complete.

A PoC typically has a short life cycle. The objective is to decide if further investment is to be made or not. A PoC is typically not delivered to end-users (might be exposed for feedback, though). In most cases, a PoC is reviewed by domain experts and evaluated against predefined criteria — to make decisions regarding possible next iterations and further investment. After a successful proof of concept, a prototype may be developed which is then used to seek funding or to demonstrate to prospective customers.

A PoC is by no means ‘production ready’. Its functionality is limited/ focusing on the aspects to be proved — it is way less than the full product. Its architecture and implementation follow rapid application development practices — introducing assumptions, static data, hard-coded elements, mocked APIs, etc.).

Usually, the PoC is not concerned with scalability (it could work great but might not be ready to scale). It may not include full security models and layers (makes sense to invest in security after a decision to move beyond PoC). And finally, it may not be reusable (refactoring and re-engineering might be needed if there is a decision to move on).

Wireframes

Also referred to as static prototypes, wireframes are visual guides representing the structure/layout of a website or an application. They arrange graphical elements and layout/ structures, serving a particular purpose — as defined by a product concept or other creative idea.

The objective is to provide early visualizations of potential user interfaces, thus setting the basis for quick iterations and product decisions. Wireframes can be used to hide complexity by focusing on user interaction scenarios and aspects of user experience. They are great to help explain the concept and capture feedback from users and stakeholders.

Wireframes are used for decisions in both early and mature stages of the product development process. They are typically reviewed by product team members, stakeholders, and representative users. Feedback is used to make decisions about the features, information architecture, user flows, and other aspects of the product.

In some cases, wireframes are static approximations of a potential user interface and experience. High-fidelity wireframes provide a great level of detail that is closer to a product — in terms of look and feel. In other cases, wireframes might also support basic interaction, flow, and navigation on top of graphical elements (clickable wireframes) powered by mocked data. There are tools enabling interactive wireframes using front-end web technologies such as HTML, CSS, and JavaScript.

Functional prototype

Software prototyping refers to incomplete versions of the software product. The purpose of a functional prototype is:

• To present a potentially complex idea in a realistic form to its target users and stakeholders
• To allow them to interact through characteristic scenarios and good approximations of the real (to-be-developed) product, and
• To capture feedback empowering better and faster product decisions.

Functional prototypes are used early in the product development process, for a short period of time — for demonstrations, discussions, and user testing. As soon as decisions are made to move on to product development, the functional prototype is expected to become obsolete shortly.

The functional prototype is typically a quick implementation (under assumptions and other constraints) of the most representative/ important functionality. This is by no means a stand-alone or production-ready deliverable. Access to the Functional prototype is not expected to be given to clients directly (typically only as part of workshops and demonstrations). The functional prototype should not be that expensive to build — but this depends on the case. To build the real product though, a disproportionate effort may be required.

Minimum Viable Product — MVP

In product development, the minimum viable product (MVP) is an implementation — the first instance of a product — with just enough features to create value for real users and drive engagement. It provides ways to gather usage patterns and direct feedback from real users, thus enabling informed decisions regarding further product development. A proper MVP generates insights early enough and at a lower cost compared to a ‘complete product’. This allows for better decisions when at the early stages of the development process.

The term MVP is frequently misused — in many cases wrongly interchanged with PoC or Prototype or ‘an obvious use-case to start with’. In contrast to both POC and Prototypes, the MVP has increased production readiness (exposed to real users/customers), while offering only the right minimum subset of features to keep the users happy and engaged.

Defining the MVP is not a straightforward process: one way is to define the big-picture/the best possible product, as the superset of features/epic user stories. Then, by using value and cost estimates, cluster the features and prioritize wisely to identify this minimum subset that serves your primary purpose: to create value for your users while establishing continuous feedback and learning channels.

Physical prototype

Rapid prototyping refers to techniques used to quickly fabricate a scale model of a physical part or assembly using three-dimensional computer-aided design (CAD) data. Construction of the part or assembly is usually done using 3D printing or “additive layer manufacturing” technology. The purpose of a physical prototype is to review a realistic physical instance of a product concept.

It has a short lifecycle as part of the product design phase. Feedback is captured by exposing the prototype to members of the product team and potentially to other stakeholders.

The physical prototype is a draft instantiation of the key aspects of the product concept. This typically does not meet safety, security, or other requirements.

Pilot Project

A pilot project refers to an initial roll-out of a system into production, targeting a limited scope of the intended final solution. The scope may be limited by the number of users who can access the system, the business processes affected, the business partners involved, or other restrictions as appropriate to the domain.

The purpose of a pilot project is to test certain assumptions and configuration options — often in a production environment. This assumes that you do have the technology, the components, and the products involved. The pilot is a small-scale test and feedback-capturing process, in a real /production environment.

This is used for planning decisions related to the launch of a product to a large-scale production environment. The lifecycle depends on the case, but it should be relatively short. Feedback is captured (implicitly and/or explicitly) which is then used to quantify the performance of the new product — for the given production configuration.

A Pilot makes sense when the tech, components, and products are at a mature state/ ready to be released in a production environment.

Defining the outcomes of your software project is critical — especially in B2B situations with multiple stakeholders of various levels of technology and business understanding. Articulating and communicating the right project outcome — MVP, Prototype, Proof of Concept — early enough can help set and manage expectations.

Images: unsplash.com