The Purpose of Prototypes
Note: This is part of the product creator series of articles, based on the overview article, The Era of the Product Creator. This series is intended for anyone that wants to create a successful product, whether or not the person has had professional training or experience in product management, product design, or engineering.
Overview
We have been using prototypes since forever, and the book INSPIRED described the four main types of prototypes in use by product teams. Until very recently, the relative costs and benefits of the various types of prototypes have been largely consistent for literally decades.
If you’ve been wondering why it is that Figma has been so successful, they have been the primary tool for the most popular type of prototypes (“user prototypes”) for several years.
However, one of the other forms of prototype (“live-data prototypes”) has historically been more expensive to create, and required time from developers, so while it was powerful and essential in certain situations, the cost meant that we only paid this price when absolutely necessary.
The reason for this article is that this calculus has changed with the new generation of gen ai-based prototyping tools.
I’m referring here primarily to tools like Lovable, Bolt, and Figma Make.
These tools have brought the cost of prototyping in general, and live-data prototypes in particular, way down to the point where it can be faster and cheaper than a user prototype, and this is truly game changing for serious product creators.
But it’s clear to me that many people do not understand the real purpose of these tools.
Most importantly, these tools are generally not for building actual products – and they don’t need to be.
The highest order use of a prototype is to help you discover a successful product.
So what does it actually mean to discover a successful product?
It means that you have identified a problem worth solving (the easy part), and then you have managed to discover a solution worth building (the hard part).
Moreover, it means that the solution you have discovered is substantially better than the alternatives that currently exist. Better enough that people will switch to your solution.
Understanding “a solution worth building” is right at the foundation of being a successful product creator, which brings us to the four key product risks.
The Product Risks
Specifically, the solution you have discovered is valuable (the customer will buy the product and/or choose to use); the solution is usable (the user can figure out how to do what they need); the solution is feasible (you have the technology and the skills needed to build and deliver a product-quality solution); and the solution is viable (it can work for your business – you can cost effectively build, distribute, market and sell your solution, the solution is legal, secure and compliant with relevant regulations and laws).
Once you have discovered a successful solution, then actually building that solution has never been easier or faster, although that will almost always be done with different tools and different skills.
Just know that the vast majority of products fail not because they can’t be built, but because their creators couldn’t discover a solution worth building.
In other words, the solution failed to address the risks.
The Purpose of Prototyping
The primary purpose of prototyping is to help discover a successful solution.
Going from an idea that could potentially solve a problem, to a prototype of an effective solution is the craft of product. And this involves fleshing out the idea, exploring the consequences and implications, and rapidly iterating on the solution.
There are many other techniques that are helpful in both problem and solution discovery, and eventually it’s worth learning more of them, but far and away, the most important discovery technique is prototyping, and then using the prototypes you create to test the risks – before you proceed to building the actual product.
The Act of Prototyping
The very act of prototyping helps to flesh out a product idea, far beyond what we can do in our minds, or in a paper specification, or in a spreadsheet, or a PowerPoint presentation.
This is especially true when your product provides a user experience (either for your external customers or for your internal employees), but it’s also true when providing a developer experience (e.g. an API for a platform product).
How Realistic Does The Prototype Need To Be?
Most people know that prototypes are essentially quick and cheap approximations or simulations of an eventual product.
But this begs the question, how realistic does the prototype need to be?
There are three primary dimensions to what we mean by “realistic” (aka “fidelity”):
- Visual fidelity refers to how realistic the prototype looks and feels.
- Behavioral fidelity refers to how realistic the interactions are.
- Data fidelity refers to whether the data shown in the prototype is actual data (referred to as “live data”), or just realistic data (maybe from an earlier point in time, or maybe just made up data).
Perhaps the most common advice on prototyping is the notion of “just enough fidelity” – the idea is that we only need the prototype to be realistic enough to accomplish our purposes, and no more.
While this advice isn’t necessarily wrong, for most people, this advice is overly simplistic, and is at the root of so many misguided conclusions.
The key to understand is that “just enough fidelity” depends on the particular risk we are addressing.
“Just enough fidelity” for feasibility is very different for usability, which is different for value, and when testing viability, the fidelity needed may be different depending on which stakeholder you’re testing with.
For example, a CISO (security officer) often needs low visual and behavioral fidelity in order to assess security and potential vulnerabilities. Yet a marketing executive or CEO that is responsible for the company’s brand may need to see very high visual fidelity, yet not need high behavioral fidelity. And a lawyer often needs very high fidelity across all three dimensions, depending on the legal consequences.
For a feasibility prototype, often we don’t care at all about either visual or behavioral fidelity, and in fact an effective feasibility prototype may not even need a user interface.
Productizing the Prototype
Once we have discovered a solution worth building, then we can proceed to build and deliver a production-quality solution (one that is reliable, scalable, maintainable, performant, and secure).
Many people refer to the difference as “building to learn,” versus “building to earn.”
Product discovery is all about building to learn, and product delivery is all about building to earn.
The Prototype as Spec
Once we have the necessary evidence that we have discovered a solution worth building, we now need to communicate to the engineers the many details of the necessary product.
A secondary but still valuable benefit of the prototype is that it can help serve as a tool for communicating the intended experience.
Tom Kelly, of the legendary design firm IDEO, argued that “if a picture is worth a thousand words, then a prototype is worth a thousand meetings.”
In an upcoming article, we’ll talk about other ways of describing the intended experience, but for now, it’s important to understand that the prototype is your go-to tool.
The danger is that many people mistakenly confuse this with the primary purpose of the prototype. They want to create an effective artifact for communication, and they use a prototyping tool to do this. But without testing the prototype, they end up spending the time and money to build a product that ends up failing in the market.
Thinking Through Prototyping
If you’ve been wondering why top product model companies are now evaluating a job candidate’s use of these tools during interviews for product creators, it is because this is how great products are created.
Building your skills in creating these prototypes, and then testing these prototypes, is at the very core of product creation.1 The good news is that the barriers to learning and using these tools have never been lower.
- Please note that this entire article applies to those building both conventional (deterministic) products, as well as AI (probabilistic) products, although with AI products, there are additional layers to what it means to “test” a prototype, which will be described in future articles. ↩︎
