Bits and Atoms

More than two million drug-eluting stents were sold worldwide in 2011, of which 87% were manufactured from just five product designs [source]. The success or failure of product development is ultimately measured by financial outcomes. Each of us hopes our large investments in product development will be returned many times over by the sale of millions of profitable manufactured units.

A great product design is thus the set of instructions that enables scalable, salable, profitable production.

Of course, nothing conveys the value of a product design more concretely than a prototype unit or a unit off the production line. We use these prototypes and sample units for demos all the time, and are justifiably proud of the innovation they represent. Yet, these physical manifestations of a product design are not the design itself. A product design is an abstraction – a blueprint for the factories to make and maintain the product. The design itself is an organized mountain of information, comprising product requirements, specs, drawings, meeting minutes, inspection instructions, manufacturing procedures, risk analyses, and verification/validation results. A product design is the genetic code, the script, and the architectural drawings, and not the cell, the broadway performance or the skyscraper.

Great product designs are bits, not atoms. Yet most product development engineers grumble about “documentation.” I don’t get it. The documentation is what manufacturing needs to make the product. The documentation is the design.

Great product developers spend a ton of time defining and redefining customer and product requirements. The very best developers argue the most passionately about customer requirements. Witness the controversy about the customer value of skeuomorphic design playing out in the Apple executive suite. The best medical device developers don’t wait for marketing or management to hand them the product requirements. They clamor to spend more time with customers in the OR (or wherever the product is intended to be used). They study competitive/predicate devices.  They define the requirements themselves.

Great product developers write assembly instructions and component specifications for their earliest prototypes, for how else can they know that device performance indicates design quality rather than a component or assembly issue.

Great product developers lose sleep over the creation of verification tests that accurately predict real world product performance. They build tests early, to assess design iterations with confidence. They know their statistics cold, to separate real results from random chance. They envy software developers who get to develop products that operate in a well-defined operating system instead of the ill-defined, highly variable human anatomy. Yet they don’t shrink from the challenge of defining that anatomy.

Great product developers care deeply about product reliability. The very best developers take it personally when products fail. The best medical device developers have strongly held opinions on the best way to do risk analysis, from years of incorporating risk management into every design decision.

Great medical device developers know that the job of making physical devices ultimately belongs to the factory, and the the end product of product development is the code that makes the factory run.  Product development is the investment.  Profitable manufacturing is the return.  Product development creates bits. Manufacturing makes atoms.