What are some common pitfalls of medical device design? How can you avoid those and manage your medical device project while setting expectations? 

In this first interview, Julia will be talking with Dustin, one of the technical project leaders at Blur, about the tension between planning and execution in medical device design. 

Julia

Dustin, thank you for being with us today. Can you tell me a little bit about yourself? How’d you get started here at Blur? What is your background? 

Dustin

Happy to be here. Sure, so I went to school for mechanical engineering. I’ve been a product development engineer my whole career across a few different industries, but most specifically in mechatronics and electromechanical devices. I worked with Blur actually as a client first, had a really good experience, and when it was time for me to make the next step I called up the partners here and said, “Hey, I think it’d be a good fit.”

Julia

You saw our cornhole tournaments and you just couldn’t stay away. 

Dustin

That’s right. I just had to be a part of that. So yeah, I’m here as a kind of project leader taking some of the bigger, multidisciplinary projects and doing some project management, some design controls and kind of technical oversight on some of the bigger programs here. 

Julia

Awesome. And I have a question for our non-technical listeners on here like me. What’s mechatronics? 

Dustin

Yeah, I mean, it’s just a word that makes me sound smarter…

Julia

It’s just a word.

Dustin

Yeah, I mean, so I would say mechatronics in general… It refers to, kind of, putting together mechanical and electrical devices, usually with a motion aspect. So things like robotics, you know, anything that isn’t just a plastic widget that’s going to be disposed of. It’s a much more complex system. It’s a lot less siloed, and refers to that broad bucket in my experience. 

Julia

Fancy moving parts. 

Dustin

That’s right, everything that moves. I like things that move. If something I’ve designed is not moving, that probably means it’s broken. 

Julia

Can you talk a little bit about some common design pitfalls or things you’ve seen just from clients coming in the door and your experience in being a technical project lead? 

Dustin

So there are a lot of common pitfalls. One that we see a lot across industry is this balance between planning and execution. A lot of clients want to have an entire plan built up front so that they can budget for what they need and know what the resources are gonna be. We want to know what the end date is gonna be so that we can go call all our friends and say, “Yeah, August 2024 is when our product’s gonna be ready.” On the other hand, there’s the execution mode of let’s not think about planning, let’s start tomorrow, get in the lab, start cutting metal, put something together, and let’s see how it works. That has its own advantages. 

There’s really this tightrope walk that we need to have: a tension between planning (looking at what our risk factors are through the whole project and figuring out how to get in front of those) and execution (we don’t know what we don’t know, so we need to build things to find out the answers that we aren’t even thinking about right now). I’ll talk through both of those. 

You know, on the one side, it’s a very common pitfall to get really into the planning phase. In my experience, the pitfall to that is, once again, the unknown unknowns if you will, the things you don’t even know about your product because you haven’t experienced it yet are impossible to plan for in some sense. In that sense, you always have to take any schedule built up front with a big grain of salt because you’re gonna learn things as you go, things aren’t gonna go the way you plan. And that’s a good thing, right? 

Product development is really hard and it’s very nebulous. There are very few projects that I’ve been a part of that you can see the end point super clearly from the beginning. And that’s only compounded when you have really complex devices. Suppliers are going to fall through on you, materials aren’t going to work the way you expect them to, things are going to get stuck in customs and delay you two weeks. A lot of product development, you know, there’s real engineering, but a lot of it really is this kind of risk management and planning coupled with direct execution. 

It’s pretty common to really try to focus up front on scheduling out a program. And you have to do that, but to a certain extent, you have to be willing to go with the flow and say, okay, this is what we’re targeting. These are the resources we think we need, but we have to start moving and reevaluate as we go. Um, so it’s just very difficult to know in March what your day-to-day work in December is going to be when you’re designing a new device, and even worse for a medical device. That’s kind of my first pitfall is just putting too much stake into that initial planning stage. 

On the other side, the other pitfall that you can fall into is going straight into prototype mode right at the beginning. That can produce some good results initially, some proof of concept, and in some products it might be the right answer to say, “Let’s get this thing working and show that we even can make this happen.” You need to have a plan precisely to identify those big risk points. I can think of many times where I’ve called machinists begging them to get something to me, you know, a day early, and then it shows up and some other part wasn’t there and could have, could have saved everyone a lot of time and energy, and you really want to save those moments to when you really need them. 

One of the things I really like at Blur, along that spectrum I think we do prioritize getting to prototypes. And I think that has a lot of value for most projects. If I had to pick between the two options, I’m always going to be in favor of getting to a prototype, getting hands on something, and learning those unknown unknowns. There’s so many things when you’re designing something from scratch that you just don’t know yet, and as soon as you can get it into the eventual user’s hands, you’re going to be so much better off. 

So much of product development is risk management, right? It’s supply chain and risk management. It’s these kinds of boring things in a sense, but they make or break the project. You can de-risk so much of a program just showing that it’s on a table working, right? Everything seems like it’s gonna work when you’re designing it in CAD, but it takes putting it together to really see it. Then everyone has confidence in that schedule that you’ve put together based on that. 

I wish I could say that I had the right answer for every program, how to tightrope walk that, but to me, you’re always kind of going between them, trying to figure out the right fit for each project. 

Julia

When a client is thinking about how to explain to maybe one of their stakeholders, this tightrope walk and this balance between execution and planning, what are some questions that they could ask, or what’s a good way for them to explain to it to someone else so that they can really understand this balance that they’re trying to strike? 

Dustin

Yeah, so like I said, so much of product development is risk management and risk mitigation. The first [question] that comes to mind is how risky is this project? That can mean a lot of things. You know, mid 2020, your biggest risk might’ve been, “I can’t get half of the parts I need for this.” That makes it a very risky project. Nowadays it could be, “I’ve developed a completely new technology that I proved works in a lab and no one’s ever seen it before.” That can be a very risky project for a different reason. Or on the flip side, it could be, “I have this product, it’s already in the market, we’re selling a bunch of them, we want to make these five changes.” That might be a very low risk project. 

There’s things like schedule risk, technical risk, supply chain risk, all of these things are your fundamental questions on how to kind of balance. The further up the risk chain, the more I would be looking at the execution side of things. How can I lower that overall project risk through execution to get to a point where I feel confident about a timeline? 

Julia

That’s interesting because I think that might be the opposite of what people think. If I’m thinking about, oh, I want to start this project but it’s kind of risky, in my head I would think I need to plan even more and might get stuck in that analysis paralysis versus trying to experiment and figure out what those risks actually are in order to have a successful project. 

Dustin

Yeah, I mean, obviously everyone has different styles for this. But I think definitely where I land on it, and where I think Blur in general is really strong at, is if we’ve proven something kind of works and maybe it’s in a lab or not in the right environment, my first instinct is, “Well, how can I get it to a point where I can show that it’s viable in the clinical setting?” Then we can productize it. Getting that kernel of an idea into something that we can show is viable and has a business case and a path to clearance is really critical; you can plan all you want, but that’s really what’s going to determine that project plan. 

On the other hand, a minor change, a small revision, things like that, we can feel really good about that project plan most likely. If I can see all the way to the end of that program and I’m saying, “No, there’s not that much risk,” those are the ones where I invest even more planning time. So yeah, maybe it is a little counterintuitive, but so much of engineering is breaking things. And so breaking them early and often is usually a really good way to show what you do know, show what you don’t know and find those answers before you spend a lot of money and time planning for something that you could never have foreseen. 

Julia

Right. You talked about having clinical foresight when you’re developing a product and when you’re developing product requirements specifically. How do you go about that process? Can you talk us through that? 

Dustin

Yeah, it’s another big kind of pitfall that I have seen quite a bit, and specifically in med device for sure. Someone has a really good idea for a product and has even built a prototype, has something that makes good business sense, but hasn’t done that part that’s fundamental to any device that we’re going to the FDA with that ties any requirement or any aspect of that device ultimately to some sort of user or clinical requirement and need. 

If I’m developing a hospital bed, it’s a very common pitfall, you know, starting basically with how to build the device. Well, I need it to be eight feet long and I own an aluminum extrusion company, so I’m gonna make it out of aluminum extrusion and I think I can make it cost this much. We really need to take that step back for a hospital bed and say, well, what does this need to do? What does the user need it to do? I’m not gonna define that device as 30 inches wide because that’s what other hospital beds are. I’m gonna start from, well, what do I need the width of this thing to do? I need it to hold a person. Do I need it to be 5th to 95th percentile person? I have to make that choice, right, but it’s based in a user and clinical need. What width is the hospital door I have to go through? Does it have to go through every kind of hospital door? Can it go through only wide doors? What that means is, once again, the user, either the patient or the operator, those are their needs and those should be driving your ultimate product requirements. 

It’s very important that any product requirement could eventually be traced back to, “What do I need this device to do as a user?” It’s very common to build in requirements based on what we think is possible technically or what we can get easily, and as engineers we do it all the time. That can get you quite a bit of the way towards a prototype, and you may not know all of the needs when you start, but the importance of the user feedback is you… you have to make sure that you’re building a device that’s ultimately gonna solve the problem you’re trying to solve. 

It’s a very common pitfall to build a device that works perfectly that doesn’t help anyone. What that ties to is the ultimate business case. It’s totally normal to have product requirements for what you want to build to be viable for your business to sell. Those are obviously important too. You have to be able to make something that’s viable in the marketplace. The ultimate specifications of a product should always be able to trace back up to, “I should be able to do this as a user. I need this device to do this as a user.” 

It’s just a really common pitfall to not have a basis in the clinical need. It makes a better product, and more importantly, it makes the FDA confident in your product. I might build this whole device that has this amazing processing power, can do all these things, but if I designed it in a way that it has to lay against someone’s skin for two hours and it’s too hot, I’ve built an amazing product that doesn’t really solve a problem because no one can use it. It’s a random example, but making sure that every aspect of how this thing gets used, every requirement specification can ultimately be traced back to what I need it to do. I think that’s… That’s what should be our aim as product development engineers: trying to solve the end user’s problem, and then everything else should come out of that. 

We like to talk about requirements traceability, so everyone’s probably heard that. The standard way that I would look at it is you have your user needs, your product requirements, you might have specifications based on that, and then you might have ways to test those specifications. For the FDA, that’s what they want to see. They want to see, here’s my test plan to prove that my device is safe and effective, here’s the requirements that I’m testing to, and here’s how I got to those requirements, which is that ultimate user need. 

Julia

Yeah, that’s it. I love that you brought the FDA up because by focusing on the user needs and making sure that requirements are traceable back to that, one, you’re, like you said, you’re actually going to be solving the real problem. Everyone starts out with this great idea because they have a problem that they want to solve and a user need that they have seen, whether it’s in their own life, whether it’s someone they know, someone they love is going through. I’ve heard so many stories, especially working at a consulting company, about how these companies came to be. They’re always trying to solve a problem. But also you’re right, the FDA cares about, and really only cares about, user safety. And that’s the main thing. So being able to show that your device is safe and effective for the people who are going to use it is really important. 

Dustin

Yeah, it’s one of the most important things. And another related point to all this that ties into it is those base user needs, that you’re really trying to get to the core of the problem. If you find yourself designing the product in the user needs, you’re already in the wrong spot. If I’m writing user needs and I’m saying, “Well, it needs to be 24 by 36 inches in size,” I’m already too far down because it’s like, well, why? If ultimately the answer to the why question isn’t, “Because the user needs it to do this to be effective,” [that’s not the correct requirement]. Maybe it needs to be that size because I need to fit it through an ambulance door. Okay, well then that’s your base need. Don’t try to define how the product will embody that need at the user level because all that does is really stifle the engineering. 

If you tell me as an engineer, “Make it 24 by 36,” I’m going to make it 24 by 36. If you tell me it needs to fit through this space, you know, maybe there’s many ways to do that. Maybe it can fold up. Maybe I can go in the Z direction or make it three-dimensional. If you hand someone a spec sheet, that’s what you’re going to end up with. If you hand them a list of needs, you’re going to get something more innovative. 

Julia

Yeah, that’s so true. It’s focusing on the why of the product. I find if you just keep asking why until you can’t ask why anymore,  you just keep drilling down, you go, “All right, this is the why.” Oh, it needs to be 24 by 37 because of this. Well, can you go even further than that? 

Dustin

Yep, it’s very common and it’s hard. It is like a kind of challenge when you’re building these user needs, but they’re fundamental to your product success. Every program I’ve ever been on that’s been very successful start to finish starts with rock solid user and clinical requirements. 

Julia

So you’ve got this prototype, you’re getting excited because, oh, maybe you’ve proven that the device can do what you say it can do. You’ve got your user needs down. Now you’re ready to commercialize. 

Dustin

Yeah, so I’ve fallen into this plenty of times. Getting to a prototype is super critical to program success, but it is very easy to fall into a way of thinking that says, “Well, it’s working. A bunch of engineers made two of them work on a workbench, so my product is almost ready.” It’s especially compounded when it goes into the fab shop and we 3D print nice covers for it and we paint it. And it’s like, oh my gosh, this looks like it just came off an assembly line. 

Julia

It looks real. 

Dustin

Exactly. And that’s great. And it’s an important part of the process. But a common pitfall is seeing that device and going, “Oh my gosh, we’re 80% done.” In a lot of cases, that phase from blank sheet of paper to that device that feels good and works like we want it to and we can use it to do testing, that’s the easy part of the project. A lot of people tend to think that the hard part’s over. The hard part is really taking something that we now know works and getting it into a state that the FDA will accept. What that ultimately means is making something that’s safe and effective, proving that it’s always going to be safe and effective, and making sure that it’s a product that can be assembled, can be tested, can be serviced throughout its life. 

Another big part that adds into this along with, you know, 3D printing and kind of nice finishing techniques are using non-robust solutions to get to a proof of concept. What I mean by that is I might need to use a specific microcontroller to monitor a bunch of things on my device. I can go on Amazon and I can get an Arduino, an off-brand Arduino, we’ll make it even worse, for five bucks. And it can do all these things. I can write a program in an afternoon that’ll monitor temperature and run a pump and move a motor. And it’s like, “Oh my gosh, in an afternoon and $5, I’ve got this thing running,” but I can’t commercialize that. 

What’s going to happen when that off-brand Arduino changes six components on that board and doesn’t tell anyone or just goes off the market and gets replaced? Have I debugged that software to the point that It’s always going to work exactly the same way and I can’t get it into a state where it’s going to do something that I don’t expect? How do I know that temperature sensor is reading the correct value? Do I have a calibration? Do I have a way for a user to verify it? These are like the kind of questions between getting something running on a bench and having a real product.

The hard part of product development and product realization really is getting all those things solved. And they’re not as exciting and fun as scrambling and throwing an Arduino together on a workbench, but they’re just as critical, if not more critical, towards actually getting something sold. It’s just a very common pitfall to see the thing working and say, “Oh my gosh, we’ve made it, we’re done.” When in reality, that stuff is like where real engineering is being done as well. 

That off-brand microcontroller, maybe it’s the perfect only solution on the market and we’re gonna have to spend a lot of our engineering effort proving that that’s still going to be safe and effective and maybe building a bunch of bumpers around that, so to speak, some training, you know, keeping it in the bounds. But the goal from a de-risking and project risk perspective is always like, well, how many of these things can I just not think about? What’s the version of this that we can put together and know that this isn’t going to be a project risk so that we can focus on the ones that we’re not sure about? Usually that’s the important part of your product, right? Most people are building something, putting something out onto the market because they have a new idea. Those are the things that are untested, right? So why put a bunch of project risk on some of these other things that we just can’t prove. 

Where I always try to go is those two pieces right there: proving that it works is important, but you’re not even halfway yet a lot of the time. And then the other piece is focus on the parts of your device that are really novel and make those your project risks. Don’t spend a lot of time trying to get away with risky other sections of the project. How can we get it down where the core focus is the part that you’re bringing that’s new to the market. 

Julia

What would you say as an encouragement to someone who, as they’re listening, has realized they’ve been focusing a lot on their project plan and maybe I need to move more towards prototype development. Or, they realized they have some clinical use cases that they haven’t thought about as they’re developing this prototype. What’s some encouragement or thoughts that you have for them? 

Dustin

The main one is, you know, there’s very rarely ever a time in product development where you’re like, “Oh man, I have to go backwards.” Everything you’ve done is learning, right? Product development, I said it before, it’s hard and it’s nebulous. No one goes in knowing exactly how it’s going to turn out, so chalk it up to learning. 

What I always try to do, and I do this always through any program, is just make sure once a week or two weeks, you take a step back and you ask these questions: Are we balancing our plan against our execution? Are we getting too far in one or the other? How can we kind of react to that? Can we invest more heavily in building this thing up and making sure it works before we plan our whole schedule around it? Or maybe it’s the opposite and we say, “Okay, we’ve been in the weeds for two weeks trying to get this proof of concept to work, we need to actually think through all the pieces here.” 

Take a step back, try to weigh those things, always thinking about your project risk. That’s what should drive all decisions: risk. Risk defines schedule and risk defines where your priority should be. So if I take a step back and the riskiest part of my program is building a device around something I don’t know works, that’s a really good sign I should build that thing right now and see if it works. If my whole project risk is planning to use a component with a six month lead time, I might need to make a plan around that to make sure that in six months, I have as many as I need. That I’m covered past 6 months and I’m not going to, as has happened to me and has probably happened to anyone else who’s done product development, bought one less than I needed, for instance. It’s always looking at risk and asking where do I need to put my focus? 

I think the biggest piece of advice is just look for what you see as the riskiest item. That’ll help drive where you should put resources. You’ve never gone too far, so to speak. It’s all about just trying to balance all this against how much time you wanna spend doing it. 

Julia

Dustin, thanks so much for being on today and sharing your experiences and your advice about just product development and design in general. 

Dustin

Yeah, of course. Thanks for having me on. I’m just kind of talking about my experience and people can have different experiences, but hopefully this is helpful and hopefully I don’t listen to this in two weeks and go, oh my gosh, what the heck was I talking about? So we’ll see. 

Julia

Yeah, I hope that too. Then we’d have a bigger problem. 

Dustin

Yeah, exactly. 

Julia

Thanks so much for listening in today. This is In Focus, signing out.