Protoduction - Engineering Design for Prototyping and Low Volume Products

This one’s a bit dry but it lays out some ideas I think are really important for successfully launching a niche engineering product. The kinds of products I’m thinking of become a tool for someone else so they should adapt to the goals of the user rather than requiring the user to think differently about their goals. They should be blend in with the world they’re used in but they should be open to inspection and modification without undue effort.

There is a class of product which exists to serve as a tool or utility for operation by people who have, as their goal, to produce some other unrelated output. These people, the target audience of the product, use the product as a tool or utility. They do not know, and do not want to know, about the inner workings of the product. In order to use the product they will learn some operational procedures. In order to provide the maximum benefit to the target audience these operational procedures should be minimal, easy to acquire, and widely understood or documented by many other people.

Prototyping is a phase in the lifecycle of a product. During the prototyping phase the product is not yet ready for use by the target audience. At this time it is only used by the developers. The developers create a first prototype. Then the developers evaluate the performance of that prototype against the expected needs of the target audience. They use the results of this evaluation to inform updates to the design and produce a second prototype. This cycle can be repeated many times: creating sequential prototypes where each prototype includes incremental changes based on previous iterations.

The creation and evaluation of these prototypes is often called an iterative development cycle. The cycle is described as having stages which are clear and well-delineated however in actual practise the stages become blurred with incomplete evaluations before a new prototype is built, or a prototype being changed during construction based on guesses about future evaluations.

The prototype becomes more complex with each sequential iteration. There are multiple design and engineering disciplines involved in the creation of a product. Early prototypes can have very simple input from each of the disciplines but as successive prototypes more closely resemble the final product the specific tweaks from each engineering discipline push more and more specific demands on each other.

Prototype hardware should be flexible by its nature. Since the hardware is incomplete, the internals are easier to access than they will be in the final version. This applies to software running on the prototype as well, in a metaphorical sense. This flexibility comes with the cost of requiring an operator who possesses specific expertise and domain knowledge. This expertise lets the operator recognize required steps or conditions which have not yet been documented for the final product. The knowledgeable operator can execute test cases or perform tasks with the prototype which are expected to be possible with the final product even though there is not a complete user interface or special tools or software may be required. If the final product is successful then this special knowledge should not be necessary for operators of the final product - the users in the target audience.

This description is exceedingly general but it’s likely that developers can imagine prototypes that fit the description so far. The flexibility of the prototype is valuable and appreciated by developers working on the project, at least it’s appreciated by developers who already understand the ins and outs of operating the prototype. Indeed, if the final product is “buttoned up” then there’s a sense of a loss of functionality as the production software and hardware is created without the tools and affordances used during iterative development cycles of the prototypes.

Early prototypes are created from domain knowledge that exists within the environment of the developer. This can be imagined as any peer group: coworkers on their current team, fellow researchers or students in a school, or an online forum where they participate. However as the iterative design cycle is repeated, the knowledge gained from previous iterations becomes part of the domain knowledge feeding the creation of the next prototype. As this happens it becomes harder and harder for someone outside of the immediate group of developers to operate or understand the prototype and ultimately the final product. Even if that potential operator is a member of the same original peer group they will first need to ramp up. New developers become familiar with the path followed by the first developers to arrive at the design of the current prototype before they can truly understand how to operate it.

And so this demonstrates the crux of the problem of “protoduction”. The final product, if it ships, will have a set of operational instructions which are dependent on the path of development for the prototypes. If the product is aimed at a very large consumer audience then it’s likely at this point to involve other experts to prepare the product for the target audience: product managers, human interface specialists, graphic designers, and technical writers for example. These teams of experts can bridge the gap to the target audience for a successful product. This involves teams of significant size working together and committing the time needed to match the final product to the needs of the target audience.

For low volume technical products there is a perpetual shortage of these adjacent expert teams. There are a variety of reasons for this shortage. One common explanation might be that the product is being built in a for-profit company and the expected product has some predicted sales volume that doesn’t support engaging UI, product, and design teams. Alternatively the organization may just not employee these teams. Or the development of the product could be funded by a grant which doesn’t include these needs.

Recall that the focus here is on cases where there will be a low volume of a product designed to integrate into some other technical speciality. A conceptually easy way to break out of the protoduction trap presents itself. Recall that the earliest prototypes only rely on knowledge available to some peer group. The simple rule I will propose is to rely only on the knowledge that is available to the initial peer group when the project began. This means that a new developer can join the team after many prototype evaluations and understand how the prototype is built. Any missing knowledge or expertise can be filled in by consulting with the peer group. This should deepen engagement with the peer group, not simply be a one-way delivery of free training.

While easy to imagine it can be difficult to adhere to this rule over many iterative design cycles. It means resisting NIH syndrome over and over, researching before writing code, and adopting existing outside components which solve non-core problems. Even when those components may require some compromise to product requirements. There is no value in maintaining strict product requirements for a product that never ships.

Every time an existing outside component is adopted to solve a non-core problem that’s one more component which doesn’t need supporting product design and documentation. This keeps engineers engaged with the problems that are actually relevant to the product at hand. It also means that there are resources outside the development team to find or hire experts, reference material, or courses. When bugs are found in these outside components then it’s possible someone outside the development team can address the bug.

Any member of the peer group of the developer can explain these non-core components. This allows the product developer to continue developing the product while someone else explains the component. It means that development can be parallelized during later prototyping cycles without requiring ramp-up time for new members to the team. The target audience requires less documentation is that the outside components which have been used in the product also have pre-existing outside documentation.

The open source model is very compatible with bringing in these outside components. It’s completely reasonable for other models to use this rule as well. Focusing on the core function of the product makes a better result for the target audience. Reducing the time and effort put into reinventing components keeps engineers happier and more productive. The resulting product will make more sense and better fulfil its purpose with minimal wasted effort from everyone involved.