10 Medical Product Development Gotchas

and How to Avoid Them
image description

written by Adam Jacobs, CTO 

Sunrise Labs delivers 'best in class" medical device design and engineering expertise for all
stages of product development.


One of the benefits of working at a medical product development company is seeing many products developed with a wide range of organizations. Supporting over 30 client projects a year gives us a broad perspective and provides the opportunity to share key takeaways listed below:

 
1. Moving to formal Product Development before it really works

There are lots of pressures: investors and management want to get to market as quickly as possible on the least amount of money, clinical testing will be available on a certain date, etc. However, remember that cost increases exponentially at later stages of development. Doing fundamental feasibility and risk reduction allows R&D teams to work on getting the details right before moving into more expensive and formal product development phases.

There are often results that are promising: papers written, initial data sets taken with small sample sizes. Extrapolating this to being ready to make a product is a leap of faith. The data could be from one machine at one site, ignoring inter-unit variability. Small sample sizes likely do not reflect the population at large, especially its rare cases. Environmental conditions can vary significantly. Handmade test units in laboratories can be difficult to replicate with less expensive or mass-produced parts.


Recommendation: Perform a Medical Technology Readiness Assessment and establish the criteria for switching from feasibility and risk reduction to formal product development. Then don’t jump the gun.





2. Not getting adequate feedback from stakeholders

We think we know the market and users. We’ve spoken to experts at conferences, have clinicians on the board of advisors, and have experience with a medical condition. However, these experiences are with a select group that may not represent all the stakeholders needed for product acceptance. This can include less experienced physicians, nurses, health aides, hospital administrators, payers, and others. Different regions and countries have different needs and ways of working. Missing the mark on any of them can lead to failure.

Recommendation: Research far, deep, and wide into your users and stakeholders. Look for failure points and weaknesses in your strategy then adapt to the real needs.



3. Trying to get it all: not starting with a Minimum Viable Product

Thinking big is how the project got started and funded, but it may not be the way to build the first version. Getting the core functionality needed for market acceptance allows a platform from which to build. Important lessons will be learned from the MVP that will inform subsequent versions and allow the market to be tested.

Allocating resources to non-essentials reduces the runway available on the core technology. This also increases the chance of not completing the project on schedule and budget and all the implications related to missing those promises.

Recommendation: Specify a Minimum Viable Product. Be ruthless in reducing scope and defending against additions to it.



4. Ignoring high risk or difficult issues until the end

The team is ready to be productive, so we do what can be done. The risky, leading edge and difficult steps can take a long time and it's easy to become inured to it. Unfortunately, the hard stuff doesn’t go away. That means that effort is being spent before feasibility is established and significant changes may be needed later to accommodate solutions. Doing tasks now seems like it’s going to reduce the schedule but may actually extend it. This is because changing something is harder than starting from scratch. For example, expensive data is taken, but later changes made may require a lot of effort to be relevant to an updated system.

Recommendation: Resolve all key risks and difficult items before investing a lot in detailed design.



5. Not working with experienced experts

Experts in the field know things that not everyone does. They can save many iterations because there are subtleties that are not obvious. Think of these as secondary and tertiary effects that make the difference between working and not. When a beginner designs something, they are trying to learn and focus on first-generation solutions. If subtler effects are not known or being dealt with, iterations are required as learning evolves.

The alternative is to work with people who have the experience to jump right to sophisticated solutions. Note that for non-experts, it's hard to know that things aren’t as simple as they seem.

Recommendation: Bring in experienced, capable people to guide and work on R&D.



6. Writing vague requirements and architecture documents

These documents are used to guide product development, inform team players, and keep the process aligned and efficient. If they don’t provide adequate clarity, time will be wasted, and integration will be inefficient. Take the time to fully define what is needed for the MVP. A well thought out architecture provides key design decisions that provide a solid foundation for detailed design choices.

Managing Requirements Whitepaper
Recommendation
: Write complete, unambiguous, and testable requirements. Write a detailed architecture document that outlines the system and discusses key technical approaches. Get broad feedback and iterate multiple times until it’s mature.



7. Underestimating time and cost to bring a medical product to market

The process to get medical devices to market requires following quality processes and a thoroughness not required in other fields. Additionally, users expect high quality looks, results, and reliability. These are accomplished through careful engineering analysis, design, testing and iteration. In product development it’s unusual to get everything right on the first or second time. This is not because the design team isn’t good, it’s because there are things to learn, designs to refine and unexpected system interactions. A good project manager anticipates and plans for these. Naturally, funders may want to reduce budgets and get to market sooner. However, this often costs more in the end when shortcuts are taken, mistakes are made and needed refinements put off.


Recommendation:
Avoid the pain points of getting MedTech to market. Be realistic about schedule and budget. Include iterations for refinements and unknowns.





8. Using bleeding edge technology

There are advantages to the latest technology. They can be faster, smaller, and cheaper. What they are not is well tested, mature, and reliable. It can take a lot of time to debug issues with chips, software, new operating systems, and new methods. Using reliable, multiply sourced, mature technology can remove a lot of headaches and reduce time to market.

That is not to say that innovation should be excluded. If there are compelling reasons such as creating a new market or disruptive technology with the new approach, the investment and risk may be worth it. Be forewarned: the road to disruptive technologies is littered with many that didn’t disrupt much.

Recommendation: Use proven technology unless necessary and worth the risk.



9. Connecting to phones and the cloud for the wrong reasons

Cell phones and connectivity are at the center of modern society. It’s natural to want to leverage them for their advantages. However, there are hurdles and costs to going this route. If this is a new product, it’s unlikely that connectivity is part of the MVP. Does it add functionality that is an essential performance of the medical device? If not, design the architecture to add future connectivity.

It’s important to know who connectivity benefits. It’s a considerable investment from the user to connect Bluetooth, set up Wi-Fi, go onto apps, etc. Patient compliance can be improved or hurt by expecting people to be tech savvy and willing to spend their precious time on it. If the benefit is to the company rather than the User, its likely users won’t adopt it for long.

Also, connectivity is a different business model than typical medical devices. The FDA requires programs to keep security up to date and maintain HIPPA compliance. Cell phones, tablets and PCs change rapidly, requiring near constant maintenance to accommodate and test new operating systems and hardware. These pressures will change the company’s focus, core competencies and capital needs. Is the investment to do all this at the core value the company is bringing and worth it?

Recommendation: Only use connectivity when users will benefit and it is key to the product benefits.



10. Quality, Cost, Schedule: Pick any two. Not three.

All three project priorities are important, but which two are MORE important. Tradeoffs must be made and without knowing what the priorities are, time and budget will be used inefficiently.

Quality is built into the development process for medical devices, but what specific level of quality is needed? Reliability needs are different for life support devices than for a diagnostic device. Accelerated development costs more. If funding is scarce, consider slowing down development that is more cost-effective and gives more time to work out risk and refinements. If there is a competitor about to corner the market, invest the extra money to speed things up.

It is common for priorities to change. Funding can run out or become available. Learnings can lead to needing time to work out difficult issues. However, changing these priorities causes a lot of disruption: many optimizations previously performed may be lost.

Recommendation: Quality, Cost, Schedule: Pick any two. Then stick to it. If priorities are changed, make it explicit and realign the development team.


The team at Sunrise Labs hopes these hard-learned lessons help guide medical device developers to more effectively create products that help patients lead more healthful lives.