Perils of Productization Before Prototyping

I noticed a trend in most junior engineers as they gain experience and maturity that they sometimes are less willing to move quickly and prototype, and instead want firm requirements spelled out before starting work. There are times when this desire comes from previous projects where prototypes were forced to live beyond their intended uses, or a prototype wasn’t identified as such but as a fast way to get code written, often at the expense of technical debt. But there are also times when junior engineers seem to want documentation for its own sake, or as a way to forestall every possible problem before that problem actually exists. They want to design a way around every edge case. And so the requirements grow until they become the spirit of the capability or project rather than just the mission statement.

The tragedy of this is most new engineers show up ready to kick ass and prototype to their heart’s content. Then as they grow, documentation is somehow perceived as a sign of maturity. (Incidentally, I see something similar in gate reviews from maturing program managers who will ask “but can we staff it?” to indicate … something.)

I certainly have a reputation for a disdain of requirements, but unfortunately that’s a part I have to play to move the Requirements Overton window towards action — I need to be a force for urgency, sometimes manufactured. Requirements of some form are of course a necessary part of any project, but they should be the compass heading and not the “turn by turn” directions to create the product. Every little edge case or function doesn’t need to be spelled out as a requirement.

Prototypes need requirements too, but they serve a different purpose since the prototype serves a different purpose. A prototype’s role is to explore feasibility, either for a capability or an approach. Can this function be performed in this way? Can this algorithm or messaging library keep with 1 Hz or 100 Hz input? Can we map this data to our taxonomy? Can we detect this target? After the prototype demonstrates feasibility, the concept can be proven out and then productized — productization is where robust requirements serve as insurance against scope creep and help separate services that perform distinct functions.

Prototypes should also be guided by the explicit understanding that they are often not meant to last, that engineers needn’t fear being forced to maintain prototyped code for years. This helps unleash the creative processes without concern for sustainability. Prototypes are optimized for learning rate: we want to know as fast as possible whether or how a given task can be accomplished. Simply put, it is better to spend 3 days prototyping to determine feasibility than 2 weeks trying to plan how that task might be accomplished if our assumptions hold.

Prototyping engineers need to be told they are expected to move fast and not be concerned with technical debt, CI/CD, interfaces, maintainability… the only metric that matters is learning rate. We need to know as quickly as possible whether a solution exists.

Further, if a few days spent prototyping results in a negative result, that is just as critical a finding as a positive one. That’s time saved not over-architecting some complex approach that is doomed to fail. Even if the prototype constrains the future solution space — i.e. it can only work under XYZ conditions with ZYX hardware configuration — those can be turned into requirements that flow to other systems (which are inevitable). We want to answer the exit criteria for the prototype gate:

• Kill: archive the knowledge, stop the project
• Extend: continue to explore because more knowledge remains to be gained
• Transition: feasibility and capability is shown, so we migrate to a sustainable solution

If a prototype is determined to be transitioned, only then do we begin to consider whether any existing code or intermediate product is retained versus thrown away to start fresh — perhaps with a full systems-level specification as the first step. The mistake, however, is to take this productization approach before we know whether the capability will succeed.