What is a prototype?

The definition, and the map that ends the confusion

The definition is straightforward. The confusion starts when the word is used interchangeably with proof of concept, MVP, beta or pilot, and the nuances between them are exactly where innovation initiatives get mis-scoped and stakeholder expectations go wrong. To keep the terms apart, Innovation Mode introduces two dimensions. Functional completeness is how much of the envisioned product the artefact contains: the share of the full feature set that is in scope. Production readiness is how ready it is to be released: its compliance with the go-live prerequisites of a real product, from security and privacy to reliability, scalability and support.

Every artefact in product development sits somewhere on those two axes, and the picture explains more than any glossary:

Read the map from the bottom left. A functional prototype has little of either dimension on purpose: a limited set of features, the ones that carry the essence of the concept and test its hypotheses, with no claim to being releasable. The MVP, in the upper centre, is a different animal: real customers use it, so its production readiness is high even while its functionality stays deliberately limited. The confusion between those two is the costliest one in practice, and What is a minimum viable product? covers the right-hand side of the map in depth.

The artefacts, from sketch to market

The book's definitions of the artefacts on the map, in rising order of investment:

Static prototype

A non-interactive visual representation of the product's interface, from wireframes that show structure and information architecture to polished mockups with full visual design. Used throughout product design, in workshops, brainstorming sessions and discovery, to capture early feedback before anything is built.

Functional prototype

An intentionally incomplete, working instance of the product: fast and inexpensive, realistic to use, limited in functionality and full of conventions behind the scenes. Built to serve a specific purpose, usually a business experiment, and retired as soon as that purpose is served. Physical products prototype too, and 3D printing has made that cheap.

Proof of concept

A partial implementation of an idea that tests its feasibility: whether a given technology works as intended in the real world. Internal only, reviewed by experts against predefined criteria, unconcerned with scalability, security or reusability, and often thrown away once the question is answered.

Pilot

A small-scale rollout of a developed product to production, in a controlled way: specific geographies, markets or user groups. It assumes the product is ready, and it exists to test assumptions and configuration before the general launch.

Minimum viable product

The first instance of the product itself, released to real customers, so safety, security, availability and performance must all hold. Where a prototype approximates the product, the MVP instantiates it. The MVP guide covers its definition and the method for defining one.

Preview, beta and components

The map's remaining corners: a preview or beta product, nearly complete but released with caveats to an early audience, and the stand-alone component, production-ready engineering that implements only a slice of the product's functionality.

The same words also name the form factors of a business experiment: a landing page, a clickable prototype, a functional prototype, a physical prototype or a proof of concept, chosen by what the experiment needs to learn. For the practical software questions, which kind to build when, what to leave out, the tools and the cost, see the software prototyping article; for side-by-side differences, Prototype, MVP or proof of concept?

Why prototype at all?

Because some concepts cannot be argued into existence. The book's examples make the point: a virtual reality experience that lets analysts explore multidimensional data, a mobile experience that adapts to the user's gaze, a digital assistant giving medical advice by voice. No document conveys what those feel like, and no meeting can settle whether users are ready for them. A prototype answers both, and Innovation Mode counts five distinct ways it earns its cost:

1. It aligns stakeholders. People who interact with a realistic instance of a complex concept understand its form, its experience and its business potential in a way no description produces, and the discussion steers accordingly.
2. It powers business experiments. When a concept carries real uncertainty, a prototype exposed to users turns opinion into data: technical feasibility on one side, actual engagement on the other.
3. It enables user research. In interviews, usability tests and focus groups, a prototype is the thing to react to; in large organisations, internal groups plus a micro-questionnaire make this cheap.
4. It showcases innovation. Catalogues of functional prototypes, and expos where physical ones can be handled, make the company's willingness to experiment, and to accept failure, visible.
5. It accelerates product development. The insights from prototype-powered experiments feed product decisions and spread the experimental mindset itself.

One warning belongs beside the list. A prototype is a measuring instrument, and a bad instrument gives bad readings:

Shortcuts are allowed. A poor experience is not

Prototyping is a different mode of software development, and treating it like production work kills its speed. Hard-coded values, static or artificial data, mocked services and technical shortcuts are all legitimate, because the code has a short life and a single purpose. Developers who dismiss prototype work as throw-away have it half right: the code may be thrown away, while the learning it buys is the point.

That bias resolves every trade-off the work raises: cut the architecture, not the experience. Accept any convention that makes the prototype faster to build, and none that makes it worse to use, and never one that creates a security or privacy risk. Rapid prototyping practices turns this into a working method for an engineering team: build, reuse or mock, decided feature by feature.

What AI changes: prototyping in hours

Rapid prototyping has always rested on the same enablers: expertise, reusable assets and implementation frameworks. The book's inventory is concrete, a catalogue of safe, anonymised datasets so data never blocks a build, a catalogue of APIs, libraries of reusable components and UI elements, ready AI and ML models, streamlined hosting and monitoring, third-party services searched before anything is built, and the makerspace for physical work. AI now multiplies all of it:

The practical consequence is a change of unit: a concept described in natural language becomes a working, testable experience in hours rather than weeks. In a design sprint, that moves the prototype day from clickable mockups to functional software that yields real interaction data. It also moves the bottleneck: when building is nearly free, the scarce skills are choosing what to prototype, designing the experiment around it, and reading the results honestly. The artefact map does not change; how fast you move across it does. On Ainna, the agentic innovation platform, concepts carry their prototypes with them through validation.

Where prototypes sit in the lifecycle

Prototypes belong to validation, the stage between a promising concept and the decision to build. A framed problem and a product concept come first; the prototype then powers the business experiments that test what the concept assumes, with real users in realistic conditions. What survives moves right on the map: the validated concept goes to the opportunity realisation team, the backlog is framed, and the first production artefact is the MVP, where the MVP guide and How to write a PRD pick up the thread.