Image source: dizain/Shutterstock
What’s your biggest fear? Spiders? Small spaces? Heights? How about missed feature opportunities in your medical device? The latter probably doesn’t pop up in most people’s minds, but for medical device product managers and people trying to build a multimillion dollar company, it’s a big one. Like other fears, you shouldn’t let this anxiety complicate your requirements documentation. This article is all about the biggest worry I see over and over again in our clients’ eyes, and what we can do to alleviate those fears both as designers and as managers.
A Component-Level Example
Here’s how the nightmare goes: a medical device design engineer is working away on a product feature—let’s say an internal battery. The requirements document states that the battery life must be at least 4000 mAh and weigh no more than 300 grams, so they search around with a few vendors and cobble together two options:
- Option #1 is a 4500 mAh battery that costs $10 and weighs 250 grams.
- Option #2 is an 8000 mAh battery that costs $11 and weighs 305 grams.
The latter could provide double the working life, which would be great for the product, but is over the maximum weight requirement. Here’s where the nightmare gets real: the engineer chooses Option #1 (the smaller battery) and doesn’t tell anyone about the larger option. The product later loses ground to a competitor that has longer battery life and the product manager is to blame for writing out the requirements.
This example is a little hyperbolic, but is meant to show a situation that, theoretically, could happen: the engineer is just following the written requirements. What’s even more interesting about this story is that it would never, ever happen for one fundamental reason—engineers are human and are driven by their very nature to pursue efficiency (at least, all the engineers I’ve ever met in my life are). This means that in this case, electrical engineering designers would go out of their way to advocate for the bigger battery even though it’s slightly overweight because it’s a much more efficient option. At the very least, they would present both options to their product managers just for information’s sake.
Fear of Missed Features
The reaction to the fear of missing out on component-level improvements is often to define the device requirements at the feature-level documentation. This is often manifested in an effort to exhaustively write down both the required and desired features individually to be 100% sure the design engineers are aware of them. These desired requirements (or desirements, if you prefer) usually end up in the requirements document, which in turn get can get passed on to the risk specification, verification, and validation documents. It is true that design teams appreciate well-written design input documentation, but the added burden of including these desirements in multiple DHF documents is significant and adds cost and time to device development.
Hitting all the Markets
Similar to missing out on a key performance feature, the fear of missing a key market can have an even bigger impact on the development path. In this particular nightmare, the designers don’t just miss out on a better battery option; they miss out on the whole idea of a portable unit to begin with, which results in a product unsuitable for certain users, cutting the market down significantly. Once again, the reaction to this is often to "simply" add a number of desirements to the requirements document so that the device could do everything possible.
In a black and white world, the designers would know which desirements are reasonable, include those, and then not achieve the remainder. This costs a bit more, but results in the best achievable product possible. In reality things are a lot muddier. Those engineers who are always trying to be as efficient as possible are unlikely to quickly accept failure and move on. Instead, design teams will start to make small concessions and the product will probably get hit with scope creep:
- “If we just make it out of metal, in can be sterilized.”
- “If we just make it slightly longer, it will be able to treat hands and feet.”
- “If we just add a solar panel, it can run forever.”
It’s obviously a good idea to try to attract the largest market possible with the least amount of effort, but to designers who are used to going the extra mile and delivering an A+ product, not meeting requirements (even if non-essential) can feel like a failure they will try hard to avoid.
Counteracting FOMO for Components
Instead of detailing out every possible scenario, time and cost can be saved by investing up front to ensure everyone has a working understanding of the device’s intended use case and environment. This can (and should) be documented separately to keep the requirements as concise as possible, while still capturing that knowledge in a different place for easy reference. From there, the engineering team’s ingrained desire to make the best possible product can take over without feeling challenged to meet all the desired requirements. It seems like a small difference, but the verbal approach to convey a vision for a future that may or may not happened is very different from a written challenge no one wants to fail to meet.
Fighting FOMO by Reducing Documentation for Desired Features
A simple method to avoid writing every desired feature down in the requirements document is to create a separate, lower-level document that details out the “important but not essential” design features of the device. This is typically the system architecture document, and it is written in plain language. It isn’t used for safety or efficacy verification, or user validation, so the resultant burden of adding low-level desirements is much less in the long run. Writing it will also ensure the design team knows why certain features are or aren’t included.
Choosing the Best Markets to Avoid Scope Creep
Often, a holistic view of the product is required to understand which markets are the most achievable. That can only be accomplished by a team of people who are each responsible for business, design, and clinical applications. If the design team has been verbally updated on other possible user scenarios, they will certainly point out opportunities to meet other market needs without having to be challenged to do it. After that, business and clinical applications specialists can decide which markets are worth pursuing. Using a design team with experience across the medical industry and a strong clinical/human factors presence will further support the team pointing out other applications and avoid missing out on easy to reach markets.
Finding a Solution that Works for Everyone
The problem with these strategies is that they require a relationship with a certain amount of trust—the product manager must trust that the design team is internally driven to see how more-efficient options can fit into the big picture and is creating a product that is suitable for as many markets as reasonable. This trust is counterbalanced by the pressure medical device manufacturers are under to make excellent products. It can easily take 1 or 2 years for a Class II device to get to market, so not only do products have to be excellent, they need to be excellent in the long term. This pressure inflates the desire to document everything, including desired features, to be as sure as possible that nothing gets missed. The result is that that 1 to 2 years turns into 2 to 3, and the pressure for success only inflames the need to be cover all bases.
It’s All About the Team
Finding, or creating, a culture of people who take the time to ask not just ‘what,’ but also ‘why,’ is the key to creating this trust. These types of medical device designers have the exact same fear of missing opportunities as product managers. Their motivation is slightly different—it’s the desire to create the most-efficient medical device possible—but it results in the same behaviour. Invest early in sharing the big picture goals with everyone; you’ll find it’s much easier to trust people you’ve trained yourself. Don’t be afraid to document everything, but consider where you are writing things down and what impact your requirements will have on your team’s level of effort. Holistic understanding and efficient documentation will mean you and your design team can trust each other to work quickly without fear of missing out.