The medical device product definition process can make or break a novel medical device. Our experts discussed the topic and offered tips in a recent medical device product definition roundtable. Their tips range from general guidelines to regulatory, reimbursement, lean startups, architecture, and hazard management.

General Guidelines

Start out by thinking about what the product needs to do, not how it will do it. Think about it as a product, not a technology. Think about where it’s going to land and how it’s going to change the market, not just what it can accomplish technically.

Understand who the users are and what the use environments are, so you can properly target them and understand the risks that will go along with these users and use environments. The capabilities of users, and specific conditions within the environment might impose particular needs, whether it’s IP rating or size, shape, mobility or whatever based on where it’s used and what’s around it.

Identify your exit strategy. That will help organize product definition by features that are needed for the product to get bought and things that will make it attractive for people to buy you.

Regulatory

Understand technical risks and identify possible mitigations.

Understand your regulatory strategy, what path you’re choosing, what market you are choosing and how risk-based you are. Do you want to take a novel approach, or do you want to piggyback on predicates and go with something that the regulators already understand?

Avoid jumping to solutions instead of writing down the fundamental requirements and working from there. That can hinder the regulatory process and prematurely engineer the product instead of understanding what it has to do.

Regulatory compliance of software is a nightmare, and you have to really understand the cascading impact of things you think of as convenient to design.

Have sufficient regulatory knowledge to understand the implications of a design that mitigates a certain safety risk in software versus hardware.

Reimbursement

Make sure you’re going to get reimbursed as that’s going to determine whether users will be able to afford your product.

A successful product, or investor interest, is based around return on investment, which is really about reimbursement, understanding the size of the market. That’s going to define funding for development because making medical devices is not cheap.

Focus

It’s probably more effective to focus on one or possibly two target markets rather than trying to roll out a device for all markets. Multiple markets make the regulatory submission much more complex and can complicate the design process.

Focus on the key functionalities to get the product to the market versus including bells and whistles that may not be important to either device approval or getting to the market.

A part of product definition is really about the kind of the results that people are looking for as opposed to the actual product shapes the definition. The focus is on what problem are you solving.

Lean Startup Model

It’s not easy to design a value proposition that fits into the silos of budgets, gives a benefit to the buyer, helps the patient, and saves money. People will need to recognize that value, agree to buy it and change their training or whatever else is required must go along with the device.

That is essentially the lean startup model where you see your company as a series of experiments, you identify the most critical risks and try to address them as cheaply and efficiently as possible. Those activities line up with funding milestones.

A lot of the critical risks will get addressed during your product definition phase. Some of those are market risks, some of them are technical risks, and some are margin risks. Can you do it in a way that makes sense?

Others are defining the buyer landscape, who is going to pay how much for the product, how does it fit in the existing portfolio? It’s really the whole field of product management at the early stage. You can expect to have five or 10 kicks up the can in order to get the basic proposition right.

Get some real-world experience. Whether that’s an official clinical trial or getting the device into the hands of end users, whether it’s the prospective patient or technician, just get a sense of whether the device actually does what you think it will do for them.

That feedback is so important because otherwise you may think you’ve got the perfect solution and your target users are thinking, “Oh, this is causing worse problems for us.”

Talk to about 50 people and really understand what they need. Many times, a founder is a leader in their field, academically or clinically, but the market that they would want is not what everybody else wants. A lot of people get stuck down that alley.

Company founders need to have a clear vision of their product, but they must guard against confirmation bias. They can be certain what the product should be and still miss what the market niche is because they are not hearing what key opinion leaders or end users ask for or need.

Architecture

Architecture is the other half of product definition where we think through how the system needs to be implemented to address the requirements.

People tend to jump right to engineering solutions without exploring and then they blur the two. They state an architectural item as if it’s a requirement or vice versa. But the two are both required to do a great, detailed design of the right product.

Designing and thinking through the architecture allows you to identify risks associated with technological choices and interconnections and interfaces and so on that may need exploration before committing to it and designing a whole bunch of stuff.

Don’t close your mind to the potential of a truly distinguishing way of solving the problem that makes the product stand out.

There’s a fun, iterative nature to this process, where it’s only when you start thinking through how you might even implement it, that you realize that maybe some of your requirements weren’t thought through enough. We hadn’t asked “why” quite enough times to get to the very, very fundamental, underlying requirement.

Figure out what you want the software to control as early as possible in the design of the system. Otherwise, you’re going to end up with bad scope creep. “Oh, it’s easier to have this controlled by software” without knowing how easy or hard it is to implement that in what is already built.

Hazard Management

The final element of good product definition is hazard management. Once you have requirements and an architecture, you should see if it stays together through a risk management process to confirm you’ve created something safe and effective. If you haven’t, then you’re probably going to have to go back to the drawing board.

That also unpacks the relationship between software and high severity risks of harm that you need to think about as you are designing things. This should be done before detailed design, although oftentimes people tend to do it later, or they don’t do it formally to begin with.

Towards the end of phase zero, when you have pretty good requirements and an architecture that has a good chance of meeting them, conduct your first significant risk management iteration to see if they come together and make something safe and effective.

Having engineers and somebody with clinical experience present is key for risk management.

Conduct sufficient human factors analysis to understand use cases that you know about, so they get included in the risk management process.

What drives the product definition? End user predefined requirement or technology? Probably both. If you purely drive definition from the market, you’ll make a device that’s hard to invent. And if you drive it purely from the technology, you’ll make a definition that no one wants to use or no one can use, or it doesn’t do what you want.

It’s the iteration through requirements in architecture and risk management that helps you figure out the right balance between market and user and clinical input, engineering input, and make sure the device is safe and effective, or likely to be safe and effective.

Closing Thoughts

Be holistic and bring in people that really understand all the pieces of the puzzle.

Keep an open mind afterwards. Just because you wrote it down doesn’t mean it’s right or doesn’t mean that it stays right.

We hope you enjoyed our tips for better medical device product definition and would enjoy sharing reader tips.

Image: StarFish Medical

Astero StarFish is the attributed author of StarFish Medical team blogs. We value teamwork and collaborate on all of our medical device development projects.



[embedded content]