Written by Eric Sugalski

Prototyping is an essential part of medical device development. But, the vast majority of companies get it all wrong. I've been in medical device design and development (with a heavy dose of prototyping) for the last 20+ years. In this brief article, I'll share my perspectives on prototyping best practices and some common missteps. Additionally, I'll provide an actionable framework to help you get the right prototyping strategy in-place for your MedTech project.

Prototyping gone wrong..

Prototyping has two use cases: 1) To learn, and 2) To validate. Let me first share how I define these terms in the world of protos:

• Learning - Discovering the things you don't know
• Validating - Proving the things you think you know

Most companies push the validation part right out of the gate. And here's what that looks like:

The cycle starts with a "proof of concept" -- demonstrating that the idea is plausible. It may result in the top prize at an academic competition, an early check in the form of a pre-seed investment, or accolades from senior management during an corporate project review. Teams set out to demonstrate that the idea has merit, and they've received some validation in the form of an early win. Kudos!

>> What happens next?

It leads to more of the same -- a push to continue validating the vision. Teams continue to design, build, and prove to investors and managers that things are on the right track. This is the way, says Mando. Build it, ship it, go MVP.

This focus on validation during the prototyping process leads teams up the tall Mountain of Overconfidence. But, eventually they reach the peak, and there they see the challenges lurking ahead -- reliability, manufacturability, regulatory compliance, unit economics, user ergonomics, workflow integration, and more.. The top of this mountain doesn't look as nice as it did from base camp. 

This then leads to a rapid decent into the Valley of Knowledge. Here is where MedTech teams go to learn, often reluctantly. But when they settle into this valley, MedTech teams gain user perspectives, clinical insights, market intel. In this valley, they discover things that weren't even on the radar before. When developing a novel device, this Valley of Knowledge is essential. There's no jumping over it.. 

(Slight tangent..) Sometimes, academic groups have a different problem. Their approach is often based solely around research -- experimenting, learning, iterating, experimenting more.. they enter the Abyss of Knowledge. When the MedTech prototype finally surfaces toward market application there's a slight Bump of Confidence. But usually teams will realize that the concept has been in a vacuum for too long and needs a full makeover -- hence, the Decent into Redirection. 

So, What's a MedTech Team Gotta Do?

Early validation is needed to get a new MedTech project off the ground. Without some of this confidence and validation mindset, nothing will get moving. That's the reality. But, after the nice pats on the back, teams need to acknowledge that there are holes in the plan and risks to be realized. So, the best thing to do is to dive into Learning mode and quickly, using Prototypes as the valuable tools to gather the critical insights.

Turning the Mountain of Overconfidence into the Hill of Overconfidence looks like this. 

It brings the Valley of Knowledge forward, which is what you ultimately want. Get those insights as early as possible, so you are able to redirect toward the right solution.

Teams that spend excessive time climbing the Mountain of Overconfidence are just deferring the essential learning process that needs to take place. It'll be there, waiting for you, when you're finally ready and accepting of it.. The penalty for this extended overconfidence? An elongated timeline and a bloated budget. 

The prototyping punchline:

> In Prototyping, Learn Early and Validate Later

Ok, I said there was going to be a framework for thinking this through. 'Nuff said on these theoretical plots. Let's get to it..

The 5 Steps..

Prototyping effectively in MedTech requires some big shifts in thinking. When you start the process, you're confident, you're optimistic. You're going to change the world of healthcare. That's the attitude that gets things moving. Nothing bad about it.

But once you have some runway, you need to face the reality that there are holes and uncertainties around your product, business, and execution plan. It's at this moment that you need to shift your mindset. Here's when you morph from an optimist to skeptic. 

That's where this process starts. Being the skeptic.

STEP 1: Isolate the risk factors

In skeptic mode, you put aside all of the reasons that your tech will dominate. Instead, you need to think of all the reasons that your business may fail. These failure modes are the risk factors. They're the ugly issues that can destroy your venture down the road. Below are some of them.

And there are others -- probably things that aren't even on the radar right now. Your job is to get clarity on these risk factors and the unknown unknowns that will surface through the learning process.

But, here's the key -- ISOLATE. Keep these risk factors (including their related prototypes and tests) separated for the time being. 

Why?? 

A few reasons: 

• It will be much faster to collect data on isolated risk factors 
• You'll get greater clarity around each isolated risk factor
• It'll force you to inspect each one in earnest (bundling = hiding) 

More on isolating risk factors down below..

STEP 2: Define the data and the tests

The second big shift needed is realizing that MedTech is not about the product or the prototype -- it's about data. What is the data that you need to compel payors to pay, clinicians to use, investors to invest? 

• Do you need animal data to assess clinical viability?
• Do you need cost data to determine economic viability?
• Do you need FDA data to confirm your pathway and verification plans?
• Do you need usability data to demonstrate clinical acceptance?
• Do you need performance data to illustrate reliability?

Once you have a sense of the data that you are seeking, then you should define the tests that will help you reach this data.

• Preclinical data -> Simulator, cadaveric, animal tests
• Economic viability data -> Budgetary estimates from manufacturers
• Regulatory data -> Feedback from FDA via Q-Sub process
• Usability tests -> Early user feedback via formative studies
• Reliability data -> Lifecycle testing on critical subsystems

STEP 3: Create the test materials (prototypes)

Now that you've pinned down the risks, the data, and the tests you need to run, you'll be able to specify with precision the test materials needed. 

That's what early prototypes are -- tools to run your tests. Tools to learn from. 

Now back to the theme of keeping things isolated:

Functional test materials - Rather than building the fully integrated Alpha, Beta with all the bells and whistles, zoom in on a specific subsystem. Use off-the-shelf parts. Cannibalize other products to get critical feature sets that would be too costly to develop from scratch. Laser-cut, 3D print. Focus on formats that allows you to build, learn and iterate quickly. Remember, this stage is about the LEARNING (through data), not proving or validating. 

Usability materials - Do you need fully functional prototypes to simulate use cases? Absolutely not. In fact, the slick prototypes and new functionality can take focus away from the user interfaces that are your primary interest with this usability risk factor. Often, usability materials are mockups (not prototypes). They have zero functionality. Instead they are created to act-out scenarios with users to understand their confusions, concerns, and overall perspectives. 

Don't build something that can be tested with a sketch - Often, a well drawn sketch does a better job at telling the story than a janky prototype. Whether the test comes down to regulatory, investment, and sometimes clinical perspectives, a sketch may do the job just fine.

4. Collect data - quant and qual

You've got the tests mapped out, you have the materials (including prototypes), now it's time to collect the data. First part of this is to get a basic protocol in-place. It doesn't need to be a full-blown protocol like what you run in V&V, but put on paper the test plan, the equipment used, the key topics discussed, etc. Treat it like you are collecting data, because that's exactly what you'll be doing.

Some of the data will be quantitative. Performance tests are obvious. But what about usability tests? What about clinician perspective tests? Those can be quantitative too. Build into your protocols means of tracking accuracy, timing, etc. Simple sensors can really help you understand how well users and operators are doing with your prototypes. 

But don't forget of the qualitative insights either. They're just as valuable as the quant. It's less about what users tell you though; more about what you observe through their actions. Holding the device backwards, mixing up steps, forgetting about a key component in the packaging -- these are insights you'll only capture through qualitative insights. Use video and photography heavily through this process to record these sessions so you and your team can refer to them later. 

5. Integrate and validate later 

It's tempting to want to develop the sexy final prototype. The one that has the production materials, the high resolution LCD screen, the machined knobs. You'll get there eventually, but you're best off deferring this final form until you've gotten through the messy parts of learning. Afterward, you'll have the key information needed to assemble the integrated design, and you'll have a much higher level of confidence that it be the right solution with users, providers, and other key stakeholders.

Prototyping is a mindset. 

At the early stages of a project, this mindset should be focused on risks and learning. Only after those risks have been sufficiently reduced should teams turn prototyping into a validation process. 

What path are you taking with your prototyping strategy?

Maybe you need some help mapping out the right process, reducing risk, and closing the gap between product and market fit?

Archimedic may be just the firm to help you move forward with speed, precision, and focus. Contact Us if you'd like to explore collaborations.

Thanks for reading!

Eric