5 Reasons to NOT Outsource Medical Device Development

Written by Eric Sugalski

I know what you're thinking - this is a sales pitch in disguise. Not the case. The intention of this article is to help you understand when to steer clear of outsourcing. And there are plenty of those cases in my POV.

On February 7, 2023 at MD&M West, I participated in a panel discussion with James Fox and Greg Lange to weigh-in on just this topic. It was a candid and spirited conversation, in part because our views differed on some key topics.

Below are my personal views on the 5 reasons. Some of these reasons weren't represented in our talk, but I think they're worth discussing anyway. I welcome James, Greg, and others to share additional perspectives in the Comments section below.

Reason 1 - Cost

Ok, my comments on this reason differ a bit from the discussion points on stage. At MD&M I spoke about the hourly rates of design and development firms being significantly higher than the comparable rates of salaried employees and why that's not really a fair comparison. Fairly obvious stuff, so I'll spare you the details. In truth, the cost points I put forth at MD&M were a bit clickbaity - since the topic of cost turned in favor of outsourcing, due to in-house inefficiencies, long-term fixed costs, etc.

But I think a more interesting and relevant topic (that was not discussed on stage) is this - Do you need butts in seats or focused expertise?

Butts in seats may sound derogatory, but it's not meant to be. There are many cases where you need people to turn the crank. Maybe that's executing on test plans, updating drawing templates, updating part numbers. A fair amount of product develop is administrative, testing, or supply chain work, and you don't necessarily need a firm to do this for you. An intern or junior engineer will often get the job done. If this is the bulk of the work that you need to do, take the insourced route - It will be much more cost effective and the output will not likely be too different.

Go outside when you need focused expertise. That may mean implementing a novel technology, optimizing use case and human factors, working around roadblocking patents, or the like. You'll be paying a premium to get this expertise, so make sure the project you are outsourcing really needs the specialization you'll be paying for.

Another topic to consider in the cost equation is process and oversight. Do you already have a well-honed process? Are you ISO 13485 certified? Do you have an established way to onboard new technical talent and efficiently train them to your process? And do you have project managers and technical managers to guide and integrate the activities of your various teammates?

If the answer to the above questions is yes, then you probably don't need to outsource. It's going to be more expensive than your internal development process, AND you won't be able to control the process as you would with your internal team.

Part of what outside firms bring to the table is their own unique and honed process that enables creative and objective thinking, unique methods to rapidly derisk, and swift execution based on internal best practices and SOPs. These processes of an outside firm won't perfectly align with your internal processes.

Getting an outside firm to ditch their processes and use yours is a bit like bringing your own recipe to a high-end restaurant and asking the chef to cook it. To a certain extent, you'll be negating the very thing you are hoping to receive when outsourcing - which is typically unique thinking, objectivity, and a side of diligent execution.

Here's the punchline to the cost reason - outsourcing will come at a premium. So, make sure that premium is worth it. Expertise, speed, novelty, objectivity - these are all good reasons to consider leveraging an outside firm. But outsourcing because your internal team is backlogged can be a tough cost to justify. Probably better for you to expand your internal team in this case.

Reason 2 - Your tech isn't up to snuff

The idea of concurrent technology development and product development sounds like a time saver, but it's almost always a time sink.

Let's say you are developing a unique hydrogel to be used as a surgical sealant. The exact volume of the hydrogel, the viscosity, the dispense rate - all need to be optimized. You may want to jump into product development of the applicator while this hydrogel is being refined. Seems like this could allow you to reach the market faster..

Here's the issue - product development needs constraints. And there are always multiple constraints that need to be balanced. In the example above, the product will need to be designed to actuate the dispensing, meter the hydrogel, allow precise user control, and achieve this function in a reliable, cost-effective, and manufacturable format.

If the hydrogel suddenly changes - say, the viscosity is altered - there's a cascade of modifications that take place on the product. A larger actuator needs to be implemented. This requires a larger power source. The PCBs need to be re-spun to accommodate. The housings need to expand to encase the new components. And a new human factors study is required to evaluate the ergonomics with the larger and heavier form factor.

Product development will always be chasing the technology. A small change to the tech usually means a big change to the product. And the further along that a product design gets, the heavier the changes become to implement.

A better approach is to let the tech mature independently. Apply resources to optimize the tech faster - through a clear DOE.

If there are other risks to evaluate in parallel with the tech, keep those separate and isolated. Don't try to integrate them too early. Questions about use case and ergonomics? Build and test mockups with users to understand accuracy, control, and comfort issues. Questions about unit costs? Build up a preliminary BOM with key components to estimate capital outlay and potential unit costs.

There can be work done in parallel, but it's best to save the detailed design integration until after the tech has matured.

Reason 3 - You're hell bent on MVP

WARNING, this one is a pet peeve of mine, and I've written a lot about it already. So, this may seem like a rant. These days it feels like I'm on a small island with this topic - probably the reason that the rant is getting louder and louder..

There are a lot of different interpretations of MVP out there. I'm going to use the definition of Minimum Viable Product that was authored by Frank Robinson in 2001 and later popularized by Steve Blank in 2005 and Eric Ries in 2011.

A minimum viable product (MVP) is a version of a product with just enough features to be usable by early customers who can then provide feedback for future product development.

A couple of key points about this definition of MVP:

• It implies a commercial product (not a prototype)
• It implies defeaturing products to a bare minimum set of features
• It implies iterating after a product has been released in the market

This works great in apps and other products that have very short iteration cycle times. But this concept falls flat on products where cycle times are long and expensive. Can you MVP a car? A skyscraper? A space shuttle? Of course not - it's a silly premise to think that years of effort and hundreds of millions of dollars will be invested into a market experiment.

The same is true of medical devices.

From clinical work, to quality documentation, tooling and manufacturing ramp, regulatory clearances / approvals - the iteration time and cost for medical devices is massive. It is completely impractical and irresponsible to defer market feedback until a medical device has reached the market. When companies take this approach, the well runs dry, and they rarely have the financial resources to iterate after market belly flop.

A much better route for medical devices is to identify the critical risks early and complete focused experiments to evaluate each of these risks in isolation. Technical risks and potential solutions can be iterated rapidly at a breadboard level. Usability risks can be evaluated at a mock-up level. Regulatory risks can be evaluated through early Q-Sub processes. Payor risks can be evaluated through clinical and economic outcome discussions with potential customers.

So, what does this have to do with reasons to NOT outsource?

Well, most development firms use research, analysis, and strategic thinking to inform the products that are subsequently developed. MVP dismisses this process. MVP says, "We're not going to understand whether customers will buy this product until it's on the market. So, let's not waste time overthinking it. Instead, let's build a quick and dirty version and see what happens when it's released."

Works for apps, not for medical devices.

Competent development firms know this. They don't want to fall into the MVP trap. They want you, your product, and your business to be successful. Your success becomes a case study in a development firm's portfolio, which adds to the credibility and marketability of the development firm. The MVP duds just fall into the archives of frustrated and forgotten projects.

MVP thinking in medtech sets you and the development firm up for failure.

Reason 4 - You're Seeking a Band-Aid rather than a Long-Term Solution

This reason evolved a bit through conversations with Greg and James. A couple of other titles in the running were:

• You want to execute, not plan
• You want surgery before the diagnosis

Ok, I'll admit, these titles all feel a bit preachy. But this is a very real thing that happens all the time with new clients.

Most development firms want to assess the problem and put together an appropriate roadmap to execute on a solution before diving into the weeds. But many clients just want the execution and don't value the roadmap.

This is like doing a construction project on your house and having all of the carpenters, electricians, plumbers, roofers, etc. show up the first day to figure it out.

The roadmap is the architecture. A good one defines the constraints, the vision, and the process to make it real. Putting together this roadmap is a critical exercise in strategy and planning that leverages the experience and insights of a development firm. When executed right, this roadmap is one of the most valuable outputs you can obtain.

If you jump straight into detail work without a solid plan in-place, you're playing Medtech Whack-a-Mole. Your team will be focused on building a functional model. You'll get there only to find a major human factors issue pop-up. You'll tackle that one, then a reliability issue will pop-up. You'll address reliability, and then see regulatory issues pop-up. On and on..

Doing rather than planning may feel efficient in the moment, but when you string together the consecutive mole whacking, it always adds up to a lot more time than a well-planned approach from the start.

Does a well informed plan make these unforeseen issues go away complete? No, definitely not. But, it puts 80% of the risks on the table from the get-go. This informs the right requirements, forces discussions around trade-offs, and ensures a common vision among all parties when starting the development process.

In order to do this right, the roadmapping process needs to be a phase or a project unto itself.

It requires research, exploration, requirements definition, risk analysis, and planning - completed by a qualified team of experts. Many companies expect this as part of the proposal process. And many development firms unfortunately walk straight into the trapping pit . But without a reasonable time period and budget carved out for the diagnosis and roadmapping phase, you'll be getting a short-sighted plan and a long-list of CYAs via crafty assumptions in a proposal.

Reason 5 - You're Trying to Outsource your Secret Sauce

Your company needs to have some competitive advantage when you get to market. Maybe it's a patent. Maybe it's a locked-up supply chain. Maybe it's an algorithm informed by machine learning. Maybe it's a commercial partner with an established customer base. Maybe it's exceptional user experience.

Whatever your secret sauce may be, you need to guard that and value it as part of your long-term value and business strategy. This transcends any product development project. It's a significant element of your business that deserves continued research and refinement.

Whatever your secret sauce may be, you need to guard that and value it as part of your long-term value and business strategy. This transcends any product development project.

Outsourcing your secret sauce just doesn't make sense. Figure out what yours is and build your internal team around it.

So there you have it. 5 Reasons to NOT outsource product development:

1. Cost
2. Your tech isn't up to snuff
3. You're hell bent on MVP
4. You're seeking a band-aid rather than a long-term solution
5. You're trying to outsource your secret sauce

Also, I'm going to posting these articles on LinkedIn. It's a better forum to stir up conversations. If you're interested in weighing in on this topic, please do! HERE's a link to the post. Thanks.

Despite all of these reasons to NOT outsource medical device development, maybe you're still interested. If so, here are a few ways that Archimedic may be able to support you:

1. Product Development Planning -- We'll work together to create the development strategy that integrates technical, clinical, regulatory, and commercial pathways. This is a short, cost-effective, and high-impact program that ensures your project is focused in the right direction.
2. Q-Sub Prep -- Have questions about pathway, predicates, pre-market testing requirements? We'll help you prepare for a Q-Sub meeting with FDA to get the right information and inform your product development strategy.
3. Focused Prototyping -- Program to help you prototype to reduce specific risks around technical and usability aspects of your medical device. By the end of this program, you will gain confidence in the product architecture, subsystem functionality, and use case.
4. QSIM -- Our Quality System Implementation & Management program makes our ISO 13485 certified QMS yours. We set you up with a secure and compliant document control system, train you on procedures, and supply fractional quality management support.
5. Full PD -- Need to advance your concept to design freeze and through V&V? We can support the entire process. Our Full Product Development programs are designed to achieve the critical milestones while generating all the documentation you need for your regulatory submission.

Want to discuss any of these programs? Just head over to the Contact page to get the conversation started.