Kenneth MacCallum, P.Eng., Principal Engineering Physicist, StarFish Medical07.19.22
There are plenty of thoughts and words that discuss strategies for developing innovative medical devices. Two key conditions can have a huge impact on the chances of success: Creating sufficient space to achieve it and the act of admitting you need to innovate.
I’m limiting my definition of “innovation” within the context of developing a medical device design that successfully balances all the product’s high-level requirements in a way previously not possible or unknown. In other words, the problem-space is so constrained that no known solution exists.
Any project manager will attest to the challenges of leading a team to a successful innovation. Of the three levers—time, budget, and scope—the first two are seemingly impossible to predict and control. The instinct to grip these levers tightly turns out to be counterproductive. What works better is to actively let these levers go. I call this making space for innovation.
This metaphor represents leeway in a number of program dimensions. The more I think about it, the more dimensions I come up with.
The first dimension that must have additional slack is timeline. Somehow, every project seems to have a timeline written in stone: the dates of key milestones are believed impossible to move. In my experience, if this impasse isn’t solved up front it solves itself in the end. If the team isn’t finished by a particular milestone, that milestone slips. That feels like one of the laws of the universe.
There are two problems with letting the universe run its course: the program typically takes longer and everyone involved gets really grumpy. It’s ironic the desire to speed things up tends to drag them out. Almost always, if we act like our problem is less severe than it really is, we’re probably diverting time and attention to the wrong places. In the meantime, everyone is stressed out thinking they’re on a last-mile sprint, when in reality, they’re only midway through a marathon. As the big date gets closer, it gets bumped, bumped again, and so on. This means the PM is constantly facing difficult conversations, the team is constantly getting harried, and shareholders are increasingly filled with doubt.
To make space in the timeline, the first approach is to try to get the problem-solving off the critical path if possible. A second approach is to tackle the big, hairy problems sooner in the timeline and push out more predictable tasks. A third is simply to extend the timeline. This latter option is often the least palatable because no one is happy making this program compromise. Typically, all three approaches will be necessary to predicting and tracking to the program timeline.
A second dimension we need to make space in is the program budget. Time and budget are interrelated. If you need more time to solve a tricky problem, you will also need more budget. If the challenge has been successfully moved off the critical path, you might not need more timeline but will need more people to work on it. If you managed to negotiate a timeline extension, plan for the team to work for additional months.
This leads to difficult conversations. Often the realization the only path forward is by innovating is accompanied by the realization the projected program costs must rise. This may trigger a reassessment of the program’s cost-benefit. That's fine—if everyone chooses to continue, there must be budget reallocation to accommodate the new understanding. If the program gets canceled, it’s probably better it happened sooner. Whichever way it plays out, there will be strong opinions and emotions.
A third dimension needing space is in each team member’s mind. The more of the problem-space you can jam into a brain and let marinate, the better your chances. This makes sense: I am more likely to solve a problem if I hold most of it in my head day in and day out, working it from many angles. This means a program is more likely to succeed with a small team whose members spend most of their time on a project, compared to a large team whose members are spread thinly across many projects. Innovating is not typically successful if the team is heavily time-sliced. It takes time for the innovation process to bear fruit and to get everyone's mind into the most conducive state. We've all experienced this: Constant interruptions prevent exploring the depths of a problem space. Constant pressure from a bunch of projects prevents committing to any one of them. This also applies when the team is focusing on other project areas. Keeping the team focused on the project’s high-risk, tricky parts is important. Once those hard nuts are cracked, move on to the other stuff.
Yet another dimension improved with space is architecture. If you can encapsulate a particular need for innovation within a certain subsystem, then expand its interface, you’ve now decoupled it from other work that must happen and reduced constraints on the problem. Imagine there’s a critical algorithm needed to ensure device safety. Until it’s invented, you don’t know what computational capabilities will be required. One way forward is to assume it will be segregated in its own processor with a defined interface. You can then define electrical connectivity and allocate a reasonable volume based on worst-case expectations. This may allow the rest of the team to move ahead confidently. When you eventually solve the algorithm question and determine exactly what hardware it needs, drop it into that empty volume.
A final dimension needing space is everyone's expectations of the solution. Often a key element to an innovation is realizing some requirements were wrong in the first place. Similarly, a problem may appear trickier than it should be because it’s the wrong problem. Often the team or other stakeholder fixates too heavily on an expected outcome. It’s important to explore different solution-spaces, even if they’re quite different from what was originally anticipated. Sure, that original vision of a potential solution might have looked really compelling. It’s pretty common to let that go and embrace something quite different. Maintaining an open mind and peripheral vision is useful.
Tunnel vision makes you ignore or not appreciate alternative solutions that might be amazing.
Many other ingredients encourage successful innovation in medical device development. Often we don’t even realize that we need them, or we hesitate to admit it.
Why might we not spot we’re stuck in a big woolly problem? Unfortunately, there are a few assumptions that fool us into thinking otherwise. One is not knowing the real requirements. Another is thinking we have a solution that achieves all requirements when, in reality, we have multiple “solutions” only solving a few requirements at a time. Yet another is assuming because a solution is known to exist that your team can achieve it easily or predictably. Maybe the worst is assuming innovation isn’t needed solely because it would be inconvenient or uncomfortable otherwise.
These sorts of requirements are achieving a desired clinical outcome, meeting sufficiently low product cost estimates, keeping patients and users safe from harm, or meeting regulatory standards. These requirements seem contradictory; there’s no clear path to a solution that addresses all of them, all at once.
To make the challenge even trickier, requirements are often illusive. They may not reveal themselves until both the problem-space and the solution-space have been explored sufficiently. They can masquerade as different or simpler problems, leading us down blind alleys.
Similarly, it’s frequently impossible to predict exactly what a requirement’s target value should be unless we've spent time prototyping and testing. We might not know what’s possible or truly necessary. If we’re not careful, we could set arbitrary thresholds that just complicate things.
It’s natural to approach a list of requirements as individual items at first. Nevertheless, the product must meet them all, simultaneously. Achieving each requirement individually is often not much of a problem. Achieving them all together with a single solution can be a significant, woolly challenge that takes years to overcome.
For example, it might be straightforward to develop a diagnostic ultrasound system. Lots of companies have been doing this for years. Developing one that also achieves a particularly aggressive cost and size target is a different problem. It’s important to recognize when your problem space is constrained in additional or different ways than others with known and understood solutions. Regularly challenging your architecture against all requirements throughout the design process will help avoid this trap.
Another assumption getting us into trouble is mistaking the whole human race for our project team. There may be an example in the world today of a solution—some other company or team may have cracked a similar nut. That’s a great data point to have but unless we can access that solution, it’s not nearly as helpful as we might think. One way or another, our team must either harness or develop that same technology. Whichever of those two options is available, it may still take a ton of effort. Often onboarding some existing but “new-to-us” tech is as risky, unpredictable, and time-consuming as inventing it in house. The time and effort expended is often the same. Just because a technology already exists doesn’t mean our team doesn’t need to gain expertise.
Since we’re stuck with more uncertainty and unpredictability when we innovate, it can seem pretty attractive to imagine we can do without it. Wouldn’t that be great? Our timelines would run like clockwork; we would always nail our budgets. The reality is developing new medical devices is hard. Instead of shying from the challenge, we must freely admit we're trying to achieve something that has never been done before, then move forward deliberately.
Kenneth MacCallum is a professional engineer with a degree in engineering physics and 25 years of product development experience in medical, metrology, and ROV products. He is perfectly suited to multidisciplinary projects involving electronics, optics, lasers, complex mechanical design, and software as well as mathematically intense or ill-defined problems, having experience in all of these areas. His primary focus is in analog and digital hardware design as well as firmware and programmable logic.
I’m limiting my definition of “innovation” within the context of developing a medical device design that successfully balances all the product’s high-level requirements in a way previously not possible or unknown. In other words, the problem-space is so constrained that no known solution exists.
Any project manager will attest to the challenges of leading a team to a successful innovation. Of the three levers—time, budget, and scope—the first two are seemingly impossible to predict and control. The instinct to grip these levers tightly turns out to be counterproductive. What works better is to actively let these levers go. I call this making space for innovation.
This metaphor represents leeway in a number of program dimensions. The more I think about it, the more dimensions I come up with.
The first dimension that must have additional slack is timeline. Somehow, every project seems to have a timeline written in stone: the dates of key milestones are believed impossible to move. In my experience, if this impasse isn’t solved up front it solves itself in the end. If the team isn’t finished by a particular milestone, that milestone slips. That feels like one of the laws of the universe.
There are two problems with letting the universe run its course: the program typically takes longer and everyone involved gets really grumpy. It’s ironic the desire to speed things up tends to drag them out. Almost always, if we act like our problem is less severe than it really is, we’re probably diverting time and attention to the wrong places. In the meantime, everyone is stressed out thinking they’re on a last-mile sprint, when in reality, they’re only midway through a marathon. As the big date gets closer, it gets bumped, bumped again, and so on. This means the PM is constantly facing difficult conversations, the team is constantly getting harried, and shareholders are increasingly filled with doubt.
To make space in the timeline, the first approach is to try to get the problem-solving off the critical path if possible. A second approach is to tackle the big, hairy problems sooner in the timeline and push out more predictable tasks. A third is simply to extend the timeline. This latter option is often the least palatable because no one is happy making this program compromise. Typically, all three approaches will be necessary to predicting and tracking to the program timeline.
A second dimension we need to make space in is the program budget. Time and budget are interrelated. If you need more time to solve a tricky problem, you will also need more budget. If the challenge has been successfully moved off the critical path, you might not need more timeline but will need more people to work on it. If you managed to negotiate a timeline extension, plan for the team to work for additional months.
This leads to difficult conversations. Often the realization the only path forward is by innovating is accompanied by the realization the projected program costs must rise. This may trigger a reassessment of the program’s cost-benefit. That's fine—if everyone chooses to continue, there must be budget reallocation to accommodate the new understanding. If the program gets canceled, it’s probably better it happened sooner. Whichever way it plays out, there will be strong opinions and emotions.
A third dimension needing space is in each team member’s mind. The more of the problem-space you can jam into a brain and let marinate, the better your chances. This makes sense: I am more likely to solve a problem if I hold most of it in my head day in and day out, working it from many angles. This means a program is more likely to succeed with a small team whose members spend most of their time on a project, compared to a large team whose members are spread thinly across many projects. Innovating is not typically successful if the team is heavily time-sliced. It takes time for the innovation process to bear fruit and to get everyone's mind into the most conducive state. We've all experienced this: Constant interruptions prevent exploring the depths of a problem space. Constant pressure from a bunch of projects prevents committing to any one of them. This also applies when the team is focusing on other project areas. Keeping the team focused on the project’s high-risk, tricky parts is important. Once those hard nuts are cracked, move on to the other stuff.
Yet another dimension improved with space is architecture. If you can encapsulate a particular need for innovation within a certain subsystem, then expand its interface, you’ve now decoupled it from other work that must happen and reduced constraints on the problem. Imagine there’s a critical algorithm needed to ensure device safety. Until it’s invented, you don’t know what computational capabilities will be required. One way forward is to assume it will be segregated in its own processor with a defined interface. You can then define electrical connectivity and allocate a reasonable volume based on worst-case expectations. This may allow the rest of the team to move ahead confidently. When you eventually solve the algorithm question and determine exactly what hardware it needs, drop it into that empty volume.
A final dimension needing space is everyone's expectations of the solution. Often a key element to an innovation is realizing some requirements were wrong in the first place. Similarly, a problem may appear trickier than it should be because it’s the wrong problem. Often the team or other stakeholder fixates too heavily on an expected outcome. It’s important to explore different solution-spaces, even if they’re quite different from what was originally anticipated. Sure, that original vision of a potential solution might have looked really compelling. It’s pretty common to let that go and embrace something quite different. Maintaining an open mind and peripheral vision is useful.
Tunnel vision makes you ignore or not appreciate alternative solutions that might be amazing.
Many other ingredients encourage successful innovation in medical device development. Often we don’t even realize that we need them, or we hesitate to admit it.
Why might we not spot we’re stuck in a big woolly problem? Unfortunately, there are a few assumptions that fool us into thinking otherwise. One is not knowing the real requirements. Another is thinking we have a solution that achieves all requirements when, in reality, we have multiple “solutions” only solving a few requirements at a time. Yet another is assuming because a solution is known to exist that your team can achieve it easily or predictably. Maybe the worst is assuming innovation isn’t needed solely because it would be inconvenient or uncomfortable otherwise.
These sorts of requirements are achieving a desired clinical outcome, meeting sufficiently low product cost estimates, keeping patients and users safe from harm, or meeting regulatory standards. These requirements seem contradictory; there’s no clear path to a solution that addresses all of them, all at once.
To make the challenge even trickier, requirements are often illusive. They may not reveal themselves until both the problem-space and the solution-space have been explored sufficiently. They can masquerade as different or simpler problems, leading us down blind alleys.
Similarly, it’s frequently impossible to predict exactly what a requirement’s target value should be unless we've spent time prototyping and testing. We might not know what’s possible or truly necessary. If we’re not careful, we could set arbitrary thresholds that just complicate things.
It’s natural to approach a list of requirements as individual items at first. Nevertheless, the product must meet them all, simultaneously. Achieving each requirement individually is often not much of a problem. Achieving them all together with a single solution can be a significant, woolly challenge that takes years to overcome.
For example, it might be straightforward to develop a diagnostic ultrasound system. Lots of companies have been doing this for years. Developing one that also achieves a particularly aggressive cost and size target is a different problem. It’s important to recognize when your problem space is constrained in additional or different ways than others with known and understood solutions. Regularly challenging your architecture against all requirements throughout the design process will help avoid this trap.
Another assumption getting us into trouble is mistaking the whole human race for our project team. There may be an example in the world today of a solution—some other company or team may have cracked a similar nut. That’s a great data point to have but unless we can access that solution, it’s not nearly as helpful as we might think. One way or another, our team must either harness or develop that same technology. Whichever of those two options is available, it may still take a ton of effort. Often onboarding some existing but “new-to-us” tech is as risky, unpredictable, and time-consuming as inventing it in house. The time and effort expended is often the same. Just because a technology already exists doesn’t mean our team doesn’t need to gain expertise.
Since we’re stuck with more uncertainty and unpredictability when we innovate, it can seem pretty attractive to imagine we can do without it. Wouldn’t that be great? Our timelines would run like clockwork; we would always nail our budgets. The reality is developing new medical devices is hard. Instead of shying from the challenge, we must freely admit we're trying to achieve something that has never been done before, then move forward deliberately.
Kenneth MacCallum is a professional engineer with a degree in engineering physics and 25 years of product development experience in medical, metrology, and ROV products. He is perfectly suited to multidisciplinary projects involving electronics, optics, lasers, complex mechanical design, and software as well as mathematically intense or ill-defined problems, having experience in all of these areas. His primary focus is in analog and digital hardware design as well as firmware and programmable logic.
