While working away on my laptop at a hotel breakfast, I couldn't help but overhear the four gentlemen poring over an iPad two tables way. Their intense discussion revolved around rolling out their high-tech prototypes in a medical care complex. Since I've written about prototypes and prototyping, I couldn't help but eavesdrop.
Forgive me.
The foursome represented a mix of medical care complex personnel and what was clearly an entrepreneurial innovator with a potentially high-impact idea. I'll skip the technical details, but this was clearly a sophisticated group who were both smart and ambitious. The prototypes were their gateways to success. Their debates included whether it made more sense to field one or two more "finished" prototypes or whether they could get more information more quickly by fielding "roughs." Were "staggered roll-outs" more cost-effective than "staggered builds"? They talked about the need to be able to "patch" quickly and whether their prototypes should optimize particular subsystems or overall system performance. They argued timelines and sequencing for test.
These questions are classic and it's always fascinating to hear how — and what — decides them. Getting great value and insight from prototypes and pilots is more an art and craft than a science. Successful tech prototyping in health care contexts is particularly demanding.
That's why the more passionately they spoke, the more nervous I got. Something was missing. Whenever innovators gather, I always listen for what's not discussed. In almost 50 minutes of detailed discussion (yes, I am that kind of eavesdropper), I heard not a single mention, reference or allusion to the challenge of training the people onsite on how best to use or learn from the prototype. Details of prototype design and roll out were discussed as if the medical care personnel were irrelevant to the process. It reeked of "over the wall" technology transfer. OMG.
When something isn't explicitly discussed, that doesn't mean it's not important or being ignored. Usually, it indicates a topic that's either taken for granted — i.e., we know that already so there's no point in discussing it now — or that it's someone else's job so it's really their problem to discuss. While this behavior is typical, it practically defines innovation dysfunction.
Any innovator deploying any prototypes in the field can't possibly assess the economics and costs of staggered roll-outs, staggered builds and optimization trade-offs independent of the people who will actually be using those prototypes. Their level of training, their abilities to observe and report, their mistakes and misunderstandings, the natural variability they individually introduce are costs and risk factors that invariably influence design decisions around the prototype. What's more, as new and improved iterations of the prototypes emerge, so do new demands for training, observation, interaction and error management. If your conversations don't reflect and respect that reality, you're not doing planning or design, you're simply indulging in speculation.
In other words, you can't meaningfully budget, schedule and iteratively improve prototypes without literally and figuratively accounting for their users. You certainly can't do this in the high tech, capital intensive, information-rich and litigatory-crazy health care environment. If anything, medical systems prototype development and testing has to be even more user sensitive and aware.
This design/prototyping conversation wasn't. They talked about virtually every system-level element except their people in the field.
After they fixed on their sequencing and schedules, they stood up to shake hands. They had agreed to a prototyping protocol that would be obsolete moments after real humans had real interactions with their real prototypes. The great German General von Moltke once observed that, "All plans evaporate on contact with the enemy." For serious innovators, that aphorism becomes, "All prototypes evolve on contact with the user."
Are you talking too much about your prototypes and not enough about their users? Or do you (honestly) think that because your prototypes have incorporated your users' requirements, you don't need to talk about them anymore? Pay close attention to what you don't talk about.