Your codebase is the best prototype

For those learning the Product Management discipline, Inspired is one of the best books you can start with. However, don’t take the book literally, Marty Cagan offers some extremely hazardous guidance in advocating for high-fidelity prototypes as the only means of shipping software:

In my mind, there’s only one form of spec that can deliver on these requirements, and that is the high-fidelity prototype.

The term “high-fidelity” refers to the fact that this should be a realistic representation of the proposed user experience. Except for the most trivial of user interfaces, I am not a fan of so-called paper prototypes. With the tools available today, it is now so quick, easy, and inexpensive to create a high-fidelity prototype for most products that there is no reason not to do so. This is still a prototype, so it’s fine to fake (simulate) the backend processing and data, so long as the user experience is plausible.

Over the past few years, my own thinking has evolved here from just prototyping a few critical components of the user experience, to now I advocate prototyping virtually everything—all pages/screens, and all the major use cases. There will still be some error conditions and corner cases that don’t pay to prototype, but the benefits of having a high-fidelity representation of the product that the full product team can interact with to understand the product to be built are so great that they dwarf the incremental costs.

Cagan, Marty. Inspired: How To Create Products Customers Love (Kindle Locations 1564-1573). SVPG Press. Kindle Edition.

On high-fidelity prototypes

As you increase the cost of change the greater the need for some variation of high-fidelity prototypes, so I agree with this. It’s more important to have high-fidelity prototypes when building an app for example than when building a website.

However there is one core tenant why high-fidelity prototypes are an antipattern.

The only high-fidelity prototype lives in your codebase

The problem is that as an idea exits the theoretical realm and moves toward embodiment it changes. It’s not foreseeable what those changes are but it is foreseeable that there will be changes.

A project will run long and scope will be reduced. An idea is much more difficult to execute in production code than it is in prototype software. Treating prototypes as if they are the working code allows you to skirt this reality.

The short: Any prototype that sufficiently reflects reality is no longer a prototype, it is your codebase.

Embrace it: Your codebase is your best prototyping software

Reality is demanding. Reality has user ready performance requirements, it has difficult to reproduce bugs, it has dependencies on less than bulletproof services, heterogeneous devices, and mixed contexts of use. Its important to remember this tenant: customers don’t use our specs, our redlines, or our prototypes, they experience our services delivered through code.

And reality firmly rejects a lot of good ideas.

Since we don’t design products assuming spherical cows, we need to use the tools of reality. The good news is you have such a tool: it’s your codebase.

To effectively cross this chasm we need to adapt our tools (codebase) and our processes to make it as easy as possible to go from concept to code.

A common criticism of this approach is highlighted by Cagan:

Second, there are typically too many critical things for the engineering team to do to use them for the product discovery process. By taking their time for this prototyping work they are not able to do what they should be doing—building production software.

Cagan, Marty. Inspired: How To Create Products Customers Love (Kindle Locations 2052-2054). SVPG Press. Kindle Edition.

This line of reasons highlights a philosophical blindspot of many product leaders. The goal of an engineering team is to deliver customer and business value.

A business isn’t built around lines of code or ‘critical things’, the measurement is simple: customer and business value. Every ounce of the process is valuable insofar as it aids us in maximizing customer and business value—to this extent engineering is not accountable for building production software but is instead is the delivery mechanism for delivering value.

By moving as fast as possible to working code, you reduce the delta in understanding between the ideator and the executor, reducing the time to market by confronting reality’s unknown unknowns as soon as possible.

Fret not, when I suggest that “your codebase is your best prototype”, the call to action is to make technology investments to lean-in to your codebase as your prototyping platform. Less move fast and break things, and more move fast with stable infrastructure.