Context is everything when doing front-end, qualitative research for product development. It’s one thing to ask open-ended, probing questions about the task under consideration, but it’s another to ask those questions in a setting that allows an interviewee to interact with his or her environment as he or she answers. In someone’s “natural” environment, you will get much deeper recall, demonstration and insight than you typically will in a focus group facility. But, when you are interested in doing this type of work with health care clinicians, being able to do a deep extended interview in a clinical environment can be the stuff of dreams – due to the hectic and sometimes chaotic nature of clinical healthcare settings. Imagine trying to interview an emergency room nurse about a particular device that she regularly uses – in the middle of the emergency room. 

Ask any fan of F1 racing—or, if you can find one, someone who has ever driven a Ferrari to its performance limits—what makes these cars go so fast, and you are likely to get the same answer: the brakes. To the uninitiated, this might seem counter intuitive at first, but it readily makes sense. Nobody would push these 700 horsepower monsters towards corners at blurring speed without the confidence in their ability to slow down rapidly at the last moment. As product developers, we can draw valuable lessons from this simple fact as we seek ever faster means to take concepts from the lab to the commercial market successfully.

One of the advantages held by larger corporations with large R&D teams is that there is a depth of knowledge and experience held by their employees that can be applied to new programs from their inception. This helps to bring the programs farther, faster and transfers expertise into those programs.

The paradox is that because of the sheer scale of these teams, individuals who might possess this knowledge are not always exposed to the very opportunities where they could apply it. Perhaps they acquired that experience at a previous job, or maybe their own career growth within the company has moved them into another position. As program managers, it is frustrating to spend six weeks solving a particular problem only to learn that several individuals within the company had dealt with a similar problem years ago but were not sought out to facilitate the solution.

My latest "aha moment" related to product development came during a recent training class on Customer Requirements. The familiar model for medical device development dictates that we start with customer (user) requirements, translate them into design inputs, design the product, develop design outputs, and then build the device. In the end, we try to get them all to line up so that we can perform verification and validation per FDA requirements. Often, there is some other requirement that isn't really a customer requirement—be it an internal business requirement or desired product feature—that we must try to fit it into this model. In my experience, it often feels awkward labeling these requirements that don't necessarily come from the customer, but still must be included in the device design. My "aha" came when the instructor put a name to these nebulous requirements: "design constraints." Of course they are! I knew what design constraints were, but had never used that terminology in conjunction with the FDA model. For example, a surgical instrument may require a size restriction to fit in the instrument case. This size restriction is not necessarily a user need, but really a design constraint that will limit the final design of the instrument to that size or smaller. Or perhaps the device maker wants to use a particular technology for product. Alternative technologies may solve the problem; however the solution is limited to the technology of choice—i.e. it is simply a design constraint.