In the first article, we discussed three key paths for bringing new medical devices to market:  designing for commercialization, designing for human trials, and designing for human trials with a focus on understanding the core technology. Ultimately, I argued that the latter approach allows us to work more efficiently and to minimize time and money spent going down the wrong development path.

While I still believe in this approach when developing truly novel technology, it’s important to recognize that it may not be right for every product. There is a spectrum of what counts as “novel.” The more novel the technology, the better it is to focus on understanding it thoroughly before developing the complete product. Often the technology and user interaction with the product are tightly coupled. Neither the development of the core technology nor the product that delivers it can jump too far ahead of the other. The development of each has to move incrementally together.

Assumptions = Risk

The key to pacing development of the technology and the surrounding product is minimizing assumptions. Assumptions equal risk. While we should try to keep the number and level of assumptions low, it’s more important to balance the assumptions between those about the novel technology, and those about how we expect the user to interact with the product. When assumptions about either the technology or the user interaction dominate, the effort in the other space may be wasted or misdirected. 

Iterate, Iterate, Iterate

As we prepare the technology for initial evaluation, we need to have built, in parallel, a good (not best) product around the novel technology in order to correctly demonstrate the product. While this clearly won’t be the final version of the product, it’s important that all of the individual pieces that make up the product (e.g. user interface, wireless capability, input devices, etc.) aren’t pulled together in a haphazard fashion. If we present a completely unusable product wrapped around an awesome technology, users won’t be able to understand how it works or the value of the technology. The real meaning of the technology—how it could positively affect their lives—is lost without enough of the product designed to communicate how to correctly and safely use it. On the other hand, if we go too far in developing the product before fully appreciating the nuances of the technology, we risk wasting time and development costs when new findings about the technology send us down a significantly different path. This development and user trial process will cycle through multiple times. With every iteration, we’re learning more about the technology and about the product that delivers it. If at all possible, this decision process about the number of design iterations and the number of trials needs to be dynamic and continue throughout the program, rather than a static plan laid out at the beginning of development.

Example in action

Let’s take another look at the example in the previous article: a hypothetical novel technology that uses ultrasound to non-invasively measure blood sugar levels for people with diabetes. The sensor is the novel technology and the raw information from the sensor can be presented in a variety of ways. We need to determine the right way to display this information to the user. Do we present the raw blood glucose reading and let the user decide what actions should or shouldn’t be taken in response? Or do we use this information as a “behind the scenes” input that firmware translates into warnings and guidance that the user simply needs to follow?

At every stage, we’re making assumptions about the answers to these and myriad more questions about user behavior and the core technology itself. Should the locus of control reside with the user or with the device itself? Should the device include its own interface, or should it leverage, for example, smart phone technology. In product development, we are constantly making assumptions about what the right answers are as we home in on the correct product solution. These assumptions are the key drivers in the answers to many development questions including, “How many iterations do we need in a given project?” and “How often should we do trials?” Every assumption is intrinsically wedded to the corresponding risk that we’ve assumed incorrectly. A key factor in this decision process is weighing the tolerance to risk verses the urgency to get the product to market.

Balancing the assumption scale

While the last article put the focus on understanding the core technology first, in truth, this isn’t a traditional chicken or egg question. When developing the core technology and the surrounding product, the problem is less a matter of which comes first, and more about continually balancing the assumptions we make about each. At the start of a project, there will likely be the greatest imbalance of either not understanding the novel technology or the user behavior. With time this disparity should lessen.

I believe this balancing act actually makes the development process on a grand scale easier to understand, but it requires continued rigorous analysis in order to make the best decision at every point in time. It should be noted that there can be inefficiency in switching back and forth between the two camps of understanding. This inefficiency must be weighed against trying to balance the assumption scale. We won’t make any progress if every time we have an assumption we can’t proceed. Analysis paralysis can kill the forward progress of a project and sometimes we just have to proceed with understood risk.

Ultimately, we need to pace product design with novel technology development in such a way that the usability is always “good enough” that the users can see the value of the core technology and can help we evaluate the technology and the product. When we strike the right balance, we’re able to learn as much as possible from each trial, and we can drive to a final, commercialized product in the most cost effective and timely way possible.