Prototype vs Implementation

The Austin CTO Club recently met to discuss Managing C-Suite Expectations. One specific point received little attention that evening, and in my opinion deserves additional thought: prototype versus implementation.

When presented with a prototype, executives frequently think of it as an early implementation. Many of the concerns that separate prototype from implementation are invisible to executives, and reasonably so: security, scalability, deployment, integrations, and so on.

Without knowing about how easy or difficult these concerns are to address, it’s no wonder that time to production deployment is their focus. From where they sit it seems that product development stalls after the creation of the prototype. And in the meantime they have other concerns, including evaluation of additional prototypes. This dynamic leads to tension during implementation between the need for careful attention to security etc. and the need to move quickly to market.

Vibe coding is on the rise. It shortens the time to prototype creation as well as opening the door to prototype creation to those with less technical knowledge. An increasing number of product managers can use AI to produce prototypes. We will see the number of prototypes produced increase. My guess is that it will rise by a couple orders of magnitude. And then what happens?

Mind the Gap #

How does everyone react to this superabundance of prototypes? And what does this mean about the gap between prototype and implementation? How do we help executives operate in this prototype-rich environment? I’ve heard at least four different ideas for addressing this.

Ignore It #

Ignore the problem, and hope it goes away. Doing nothing is usually an option, and often an underrated one. In this case, ignoring it seems likely to exacerbate the problem unless and until the AI tools that speed up prototyping become good enough to address the additional concerns of implemention. In other words, if the tools become sufficiently capable, the gap between prototype and implementation closes, eliminating the problem.

If you bet on the gap disappearing and it does not, where does that leave you? And what can you do in the interim when the gap does exist? What if the gap closes, but then your production implementation exhibits some bug? Who fixes that if those who implemented it lack deep technical know-how? This approach seems very high risk, though perhaps it helps a smaller company get to market more quickly.

Dumb Down #

Some people advocate for creating prototypes that look more like wireframes than polished applications, giving a visual clue as to the incompleteness of the implementation. This would highlight that something is a prototype and not an implementation.

The entire reason for polishing an application is to make it more attractive. Sticking to cruder presentations foregoes that benefit. Can the less attractive option win over the more polished alternative? That seems doubtful, especially if you believe better UX and design add value for the user.

Flood the Zone #

What if you create enough prototypes to overwhelm those who evaluate them? The superabundance of something reduces the value of each one, so each one is thereby easier to dismiss. The low cost of producing any one prototype does lower the opportunity cost of your selection of which one to implement.

Does the superabundance of prototypes lead to greater ambition, and attempts to select more options to implement? This sounds like a new expression of the original problem. Expectations scale much more readily and quickly than capacity does. If prototype capacity doubles, how much executive ambition for implementations scale?

Experimentation #

Treating prototypes as experiments that explore implementation options, and the choice of implementation as outcome of those experiments, draws a business-related distinction between prototype and implementation. This is easier to convey to non-implementors than direct implementation concerns. It also leverages the role of non-implementors in increasingly important decision making.

This approach does require tempering the scaling executive ambitions, just as with flooding the zone. In this case is the scaling on the prototype side gives wider choice among different implementations, letting non-implementors improve the quality of outcomes through their choices, even if implementation capacity does not rise.

Other Approaches? #

There are doubtless many more ways to address the question with some combination of constraint, education, and planning. What approach would you take?