When building software products or solutions, it is of critical importance to define early enough the target output — in terms of ‘functional completeness’ (how many features should it contain?) and ‘production readiness’ (should it be ready for a production environment?).

Using the right terminology for your software project is very important since it sets the expectations of your stakeholders — all those who have direct or indirect interest to 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 rethink its scope and objective.

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 the 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 (in some cases it 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 — including assumptions, static data, hard-coded elements, mocked APIs, etc.

Usually, the PoC is not concerned with scalability (it may work great but with no capacity to scale). Also, a PoC 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 - in a software context it may be considered through-away code).

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 and set the right focus on user interaction scenarios and aspects of user experience.

They are great to help explain a complex concept and capture feedback from users and stakeholders.

Wireframes are used for making better 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 choices 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 which is closer to a product — in terms of look and feel. In other cases, wireframes might also support basic interaction, flow, 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

A software prototype refers to an incomplete version of a software product. The purpose of a functional prototype is:

1. To present a potentially complex idea in a realistic form to its target users and stakeholders
2. To allow them to interact through characteristic scenarios and good approximations of the real (to-be-developed) product
3. 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; it is by no means a stand-alone or production-ready deliverable. Typically, a prototype is not exposed to clients or users directly (usually, only as part of workshops and demonstrations).

The functional prototype should be relatively inexpensive to build — but this depends on the case. In all cases though, to build the real product, a disproportionate effort may be required (in comparison to the cost of building the prototype).

Minimum Viable Product — MVP

In product development, the minimum viable product (MVP) is a first implementation — the first instance of a product — with just enough features to create value to real users and drive engagement.

It provides the means 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 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 always a straightforward process: one way, is to define the big-picture/ the best possible product, as the superset of features/epic user stories. Then, depending on the context, the product team uses value, cost and reach estimates to cluster the features and prioritize them wisely - in order to define this minimum subset which serves the primary purpose: to create value for your users while establishing continuous feedback and learning channels.

Physical Prototype

The physical prototype is a draft instantiation of the key aspects of a product concept.

Typically, a physical prototype is not concerned with safety, security, or other requirements - as its purpose is to review a realistic physical instance of the product concept and capture feedback by exposing it to members of the product team and potentially to other stakeholders. It has a short lifecycle as part of the product design phase.

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.

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. It can be thought of as a small-scale test and feedback capturing process, in a real production environment.

This assumes that the technology, the components, and the products involved are all available and ready for production.

The purpose of a pilot project is to test certain assumptions and configuration options — while in a production environment - in order to make planning decisions related to scaling up the product or launching it to other segments or markets.

The scope of a pilot project 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. Its lifecycle depends on the case, but it is typically short.