Prototypes vs Products

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.

In a previous article in this series, I discussed the new generation of gen ai based prototyping tools, and how they help in product discovery.  If you haven’t yet read that article, I’d encourage you to do so before you continue with this one.

Many people responded with how these new tools have enabled and empowered them to move from helping the product designer or engineer to shape a product from the side, to actually participating in shaping the product directly.  

Some teams are still finding their way on this (as the product creator roles have more fluid boundaries now), but overall I consider this an extremely good thing for product in general, and for product discovery in particular.

But there has been at least one surprising consequence of this trend, and that is we’re learning that not everyone understands the difference between a prototype, and the eventual product.

Now, to be clear, there has always been some confusion by customers and stakeholders that when they see a prototype, they don’t necessarily realize that it’s just a prototype, and what they are seeing is not a final product, but this type of confusion has existed for several decades, and any capable product manager or product designer today knows how to address this.

What I’m talking about here is confusion on the part of the product creators; the product manager in particular.

Most product people today do seem to understand the concept that in product discovery we’re “building to learn” and in product delivery we’re “building to earn.”  

And those product people that come from an engineering background usually understand that there are very different demands and considerations for each of these activities.

But for those that don’t have that engineering background, it’s understandable that they may look at a very high-fidelity, live-data prototype and think that it can’t be all that hard to make the leap to something we can actually sell and service and that our customers can run their business on.

But I’ve now witnessed more than a few product managers embarrass themselves in front of their engineers.  So this article is intended for these people.

Partly what fuels this confusion is that so often when we are learning to prototype effectively, we start with very simple products or experiences, often with just a few important use cases and business rules.

But for most actual products, especially ones that we hope to build a real business on, the scope of the product is much larger, often reflecting dozens or even hundreds of use cases and complex business logic.

And for enterprise-class solutions, those which deliver tens or hundreds of thousands of dollars of value per year, these are usually extremely complex, often reflecting thousands of use cases and very complex business constraints and policies.

In addition to business complexity, commercial products must deal with run-time complexity.  

The product must be consistently reliable (“reliability is our most important feature”), instrumented with telemetry and observability (both to detect issues and also to report outcomes), maintain performance as its use scales, handle the necessary range of languages and currencies, support necessary integrations, and deal with operational challenges such as zero-downtime maintenance, fault-tolerance, data security, compliance, and disaster recovery.

It’s worth pointing out that some product teams are working on internal tools and customer-enabling products, which while they are considered products, the operational demands are usually, although not always, much less, and in these cases, there is a shorter path to what we would consider product quality.  

But especially when we are talking about customer-facing products, because of the excitement and enthusiasm around the new tools for prototyping, some of the tool providers are making claims that they are nowhere near able to deliver on.  In some cases this is just typical marketing exaggeration, but in other cases I’m pretty sure some of these people genuinely have no clue.  This is unfortunately a reality, and as always, it’s buyer beware.

But if you look closely at the range of gen ai-based code-generation tools, you’ll see pretty clearly that one major class is focused on helping product creators with prototyping (e.g. Lovable, Bolt, Figma Make), and the other major class is focused on helping professional product builders to build commercial-quality products (e.g. Claude Code, Cursor).

And if you watch skilled users of each, you’ll see that they utilize their respective tools very differently to get the most out of their tools.

This makes complete sense to me because they are each using their respective tools to solve very different problems – building to learn is very different from building to earn.

Is it possible that someday (e.g. in the next 3-5 years) the code-generation tools will truly be able to go from prototype to product for complex, enterprise-class solutions?

In my mind, this is an open question.  But a few considerations:

First, it’s important to acknowledge that it’s risky to argue that something can’t happen.  

Second, I’m aware of some research efforts that are exploring this very topic, but I haven’t seen anything yet that gives me any confidence that this will be addressed in this timeframe, and the issues stem from the limitations of spoken language as a specification language.

Third, while I would be the first to say it would be truly amazing and valuable if someone could solve this, it’s also not something that needs to be solved.  So long as we have very good solutions for each of product discovery and product delivery, we can meet the needs of our customers and our business.

But at least for now, it’s critical for product creators to understand the difference between these two activities, and the tools used for each. 

Special thanks to Chris Jones and Thomas Fredell for their feedback on earlier drafts.