Our employee experts share their best tips and examples for each phase of the commercialization process in a four-part series on Medical Device Commercialization. This blog covers Phase One Medical Device Product Development tips for engineering, design and development. For Phase Zero tips, check out our blog on Product Definition.

Medical device commercialization is typically broken into Four Phases: Phase Zero Product Definition, Phase One Engineering Design and Development, Phase Two Transfer, and Phase Three Manufacturing.

What’s the Point of Phase One?

Be clear about what you’re trying to achieve in Phase One (Product Development) of medical device development. The goal might be commercial success, a clinical device, or the next round of funding. It should be crisply defined because Phase One usually involves a large expansion of effort. Costs are much higher than Phase Zero (Product Definition). Make sure that there is alignment on the objective to create a plan that is very specific and does not try to accomplish too much or has multiple objectives that could be in potential conflict.

My favorite question prior to prototyping is: “what C are we trying to P?”. What Concept are we trying to Prove, with a proof-of-concept prototype. These efforts should be focused on expending the minimum effort and budget to resolve the most uncertainty. Developing a highly integrated, multidisciplinary prototype system can be costly and time consuming – is there a way to answer the same questions by doing less? Maybe we don’t get as complete an answer but sometimes that’s good enough to make a key program decision.

It’s critical to understand the intended use and indications for use of a medical device. This helps consolidate what the product is trying to be. Getting alignment nailed down in phase zero is especially important when going to pre sub talks with the FDA.

Respect requirements management, but don’t be crippled by it. There can be a tendency to just design a “thing” without clear purpose. Instead check point against what the prototype device is supposed to do and what the requirements are.

Always plan for multiple iterations of the design because it would be very improbable for things to be right the first time – this is especially true for Phase One. But know when to stop refining an early prototype and start building it for quicker iterations and learnings.

The key milestone in Phase One is not so much that you make a prototype, but that you can do something with that prototype. It’s easy for a technical team to forget that you’re going to use the prototype to get some data, some confirmation from your target customers, or you’re going to get some usability information, and maybe an indication of what the costing is going to be.

Manage Risk

You must be willing to carry some risk forward, particularly early in Phase One. You can burn budget and paralyze development by trying to retire all risk. Align with the team on an acceptable level of risk, work to mitigate those risks and move forward at risk. Don’t be afraid of failure while trying not to fail.

Be open to failures experienced during prototype testing. Often these failures tell you more about the limitations and working constraints of your device than a prototype that works flawlessly on the first go.

Believing a task or a suggested implementation is risky doesn’t mean we shouldn’t do it. It only means that there is a probability that it will take longer, cost more, or not work as well as anticipated. Often someone suggests that we choose the less risky option. Often these options are not at all equivalent from the perspective of the problems they are intended to solve, and this is not always obvious.

Only with an apples-to-apples comparison can the risk be evaluated fairly. In many cases with this perspective, it turns out that there is only one option, and that is to take some risk. Then we need to plan for what happens if that risk resolves into an issue. There is always a probability that the coin will come up tails. It is important to recognize that this does not represent a failure of the team – only of the concept we were hoping to prove.

Minimum Viable Product?

If the market is well defined, the development process can be split into product development (Alpha) where the functional aspects of the device are developed and confirmed, and process development (Beta), where the manufacturing processes are proven.

Depending on the maturity of the device in the market, a MVP (minimum viable product) type of product might be warranted to verify the market opportunities. It’s important during MVP development that end manufacturing and assembly processes be thought through and planned, otherwise additional development time may be required to fix production issues during transfer and manufacturing phases.

To prove the market opportunities, the device development and process development can be shortened with some risk. Getting to market quickly might help prove the market, but it’s important to carefully consider service and reliability. There is a risk that field issues arising from short cutting the development process may turn off early adopters.

While there is risk in launching a “Productionized Alpha” design, important benefits could be gained:

• Understand and validate the market need of the intended end-product.
• Determine market size and competitive landscape of the product.
• Identify risks and potential challenges involved in the subsequent iteration device product development.

What’s the Point of Phase One?

Be clear about what you’re trying to achieve in Phase One (Product Development) of medical device development. The goal might be commercial success, a clinical device, or the next round of funding. It should be crisply defined because Phase One usually involves a large expansion of effort. Costs are much higher than Phase Zero (Product Definition). Make sure that there is alignment on the objective to create a plan that is very specific and does not try to accomplish too much or has multiple objectives that could be in potential conflict.

My favorite question prior to prototyping is: “what C are we trying to P?”. What Concept are we trying to Prove, with a proof-of-concept prototype. These efforts should be focused on expending the minimum effort and budget to resolve the most uncertainty. Developing a highly integrated, multidisciplinary prototype system can be costly and time consuming – is there a way to answer the same questions by doing less? Maybe we don’t get as complete an answer but sometimes that’s good enough to make a key program decision.

It’s critical to understand the intended use and indications for use of a medical device. This helps consolidate what the product is trying to be. Getting alignment nailed down in phase zero is especially important when going to pre sub talks with the FDA.

Respect requirements management, but don’t be crippled by it. There can be a tendency to just design a “thing” without clear purpose. Instead check point against what the prototype device is supposed to do and what the requirements are.

Always plan for multiple iterations of the design because it would be very improbable for things to be right the first time – this is especially true for Phase One. But know when to stop refining an early prototype and start building it for quicker iterations and learnings.

The key milestone in Phase One is not so much that you make a prototype, but that you can do something with that prototype. It’s easy for a technical team to forget that you’re going to use the prototype to get some data, some confirmation from your target customers, or you’re going to get some usability information, and maybe an indication of what the costing is going to be.

Manage Risk

You must be willing to carry some risk forward, particularly early in Phase One. You can burn budget and paralyze development by trying to retire all risk. Align with the team on an acceptable level of risk, work to mitigate those risks and move forward at risk. Don’t be afraid of failure while trying not to fail.

Be open to failures experienced during prototype testing. Often these failures tell you more about the limitations and working constraints of your device than a prototype that works flawlessly on the first go.

Believing a task or a suggested implementation is risky doesn’t mean we shouldn’t do it. It only means that there is a probability that it will take longer, cost more, or not work as well as anticipated. Often someone suggests that we choose the less risky option. Often these options are not at all equivalent from the perspective of the problems they are intended to solve, and this is not always obvious.

Only with an apples-to-apples comparison can the risk be evaluated fairly. In many cases with this perspective, it turns out that there is only one option, and that is to take some risk. Then we need to plan for what happens if that risk resolves into an issue. There is always a probability that the coin will come up tails. It is important to recognize that this does not represent a failure of the team – only of the concept we were hoping to prove.

Minimum Viable Product?

If the market is well defined, the development process can be split into product development (Alpha) where the functional aspects of the device are developed and confirmed, and process development (Beta), where the manufacturing processes are proven.

Depending on the maturity of the device in the market, a MVP (minimum viable product) type of product might be warranted to verify the market opportunities. It’s important during MVP development that end manufacturing and assembly processes be thought through and planned, otherwise additional development time may be required to fix production issues during transfer and manufacturing phases.

To prove the market opportunities, the device development and process development can be shortened with some risk. Getting to market quickly might help prove the market, but it’s important to carefully consider service and reliability. There is a risk that field issues arising from short cutting the development process may turn off early adopters.

While there is risk in launching a “Productionized Alpha” design, important benefits could be gained:

• Understand and validate the market need of the intended end-product.
• Determine market size and competitive landscape of the product.
• Identify risks and potential challenges involved in the subsequent iteration device product development.

Think About the Future

Start thinking about Phase Three in Phase One. Lay the groundwork for manufacturability. Understand how the device being built in Phase One would enable easy manufacturability or constrain it. You don’t have to solve those problems in Phase One, but you need to be thinking about them. Then in later stages, you aren’t hampering profitability due to challenging manufacturing processes.

But do not over design proof-of-concept prototypes. Be flexible. It’s easy to chop off product potential gratuitously just trying to be done. Be strategic about preserving ambiguity in the right amount. And don’t try to design prototypes to be finished products. Design them to show KOLs and investors or prove functionality in the clinic at whatever level is appropriate for that stage. There’s plenty of time to optimize for manufacturing later.

Alpha prototypes are typically only a small number of units built by engineers, in their lab – that’s Phase 1. Making a few more hundreds, or thousands, of it in the same setup won’t be realistic. To meet target tag price, it has to be built by someone else, somewhere else. To figure that out, more activities must be done thus moving to Phase Two – Design Transfer. More to come in our Transfer blog…

Subsystems, Silos and Roadmaps

Sometimes when deeply focused on trying to solve a problem one can forget about the interfaces with other parts of the system. Often this will end up as a big mess that has to be retroactively bandaged together. Instead design any subsystems to be part of the system with the end requirements in mind.

Avoid designing in silos with a lot of individual teams. For example, software is often siloed off doing their own development. When it comes time to integrate, the subsystems are not aligned and not congruent with expectations. Suddenly everyone is scrambling to make the integration happen.

If you’re working on a subsystem, make sure you understand how it interacts with the rest of the system. If anyone makes a change, consult, or involve the team SE (systems engineer) so they can bring in everyone who will be affected.

If you haven’t asked yourself, “how is my design going to impact other subsystems?”, you should think “Red flag”. If you are just getting your head down saying, “I’m going to build the best thingamajig ever and you’re not asking what other systems the thingamajig interacts with, you should hear alarm bells.

Your architecture and the relationship between subsystems need to get mapped out in Phase One. You can’t create architecture as a byproduct of your design. It should be a very intentional exercise.

Don’t Forget

Listen to your clients and other stakeholders. Value their inputs.

Speed up product development with proper program planning i.e. identify critical and non-critical tasks for optimum resource allocations (time, budget, human resource).

Avoid short cuts as much as possible. In most cases, they produce more harm than good in Phase Zero and One. Follow good engineering practices.

Employ experienced and capable people for your development team. This very crucial in concept design and resolving engineering challenges.

Use all available resources (i.e., software, apps, OTS parts and components, instruments, talents, knowledge base data sets, journals, research papers, and AI tools) to support design and prototyping efforts.

You can do a lot in silico. Not just at the very low level, but at a higher level like device impact testing against walls and floors, CFD, and even solid interaction at the low level and detailed level that can de-risk design questions that would take weeks, if not months, of physical testing and materials costs otherwise. Lots of parametric and comparative studies can be done simultaneously to save development time and budget.

Celebrate every milestone attained by the team to foster camaraderie and to be able to harness teamwork. A cohesive team can find better solutions to technical challenges.

We hope you enjoyed our tips and examples for Medical Device Phase One Product Development. We enjoy hearing tips and feedback from readers and look forward to your comments. Our next blog in this four-part series covers Medical Device Phase Two Transfer to Manufacturing pro tips.