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 Medical Product Development before it really works
There are lots of pressures: investors and management want to get to market as quickly as possible for 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, and 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. Read ‘Technology Readiness Assessments and Mitigations‘ to learn more.
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 medical conditions. 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 the 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 them. 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.
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. Download the whitepaper ‘Managing Requirements‘ to learn more.
7. Underestimating the 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 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 are put off.
Recommendation:
Avoid the pain points of getting MedTech to market. Be realistic about schedule and budget. Include iterations for refinements and unknowns. Listen to the Podcast ‘Avoiding the Pain Points of Getting MedTech to Market‘ to learn more.
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 to their advantage. 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, it’s 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 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 diagnostic devices. 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. Learning 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 them explicit and realign the development team.