servicing your medical device

In Focus Podcast - S1 003: Viewing Service as a Business

In Focus Podcast: S1 - 003

Viewing Service as a Business Rather than an Afterthought

Play Episode:

How do you generate cash flow from servicing your medical device rather than treating service as an afterthought?

The trick is to view service as another business opportunity and plan for it during development. 

In our new series, In Focus, our team will highlight different aspects of manufacturing. Our goal for this series is to help you prepare for manufacturing and provide tips to manage your customer expectations while building a successful business for your product.

In this interview, Julia Grenon will be speaking with our director of operations, Brett Creech. She’s been in the medical device field for 14 years. 12 of those in manufacturing and service.



Britt, before we dive into the business side of service, can you give us a definition? What exactly is service and why is it so important in the medical device industry?


Thanks for having me on! I’m very passionate about service. It’s something that means a lot to me. I think that a lot of people have service as an afterthought; they don’t consider it as a “transfer to manufacturing” piece and then they have to scramble when they get their units in the field to provide service to their customers.

It’s important that you educate your customers about service because it can be a positive to do so. People generally are prepared for their electromechanical devices to have service at some point, as long as you tell them that it’s going to happen. The last thing you want to do is tell your client this thing will never fail. It’s 100% guaranteed not to work forever. If they are given no insight into future service solutions, they will be very disappointed when something goes wrong. Naturally, if you can warn them that the device may need a repair–say, every two years–then they prepare for that. So, instead of being upset, they’re welcoming that service and avoid having to scramble to service their device because they didn’t think of the fact that their unit can fail once it gets in. 

Medical devices have electrical mechanical components and they have wear and tear. It’s just a natural aspect of what an electrical mechanical device is. Your customer needs to know that they need to be prepared that at some point their medical device will need service and repairs.

There is also the option for depot repairs, where a customer can return their device to a location and the repair happens on site and is shipped back to them. Or there’s field repairs where you send a person out in the field to go to that person’s location, repair their device at their site, real time.

There are pros and cons to both of these types of repairs. The pro for depot repair is you’re not invading someone’s space to do the repair, but it takes a little longer shipping back and forth. That takes a couple of days, whereas a field repair can happen much faster but you interrupt their practice. So, you need to think about the pros and cons of each of those.


In your experience, Britt, who typically performs service; is it the customer is that the contract manufacturer? What have you seen? 


I recommend that if you’re going to do deep repairs, you utilize your contract manufacturer. They already know the device. They manufacture it for you. They’re going to be the experts who can troubleshoot, get that unit repaired and back out in the field as soon as possible

If you’re going with field service or even a combination, I recommend that the customer utilizes their own internal resources because they need to be the person engaging with their customers and maintaining that relationship. As a contract manufacturer, we’re behind the scenes. You are the one handling your customers expectations, managing those relationships, and we’re backing you up, doing the service repair work for you, but you get all the credit.


So we’ve defined what services we’ve talked about and who should perform service in which situations. When during the development process do you think someone should begin considering service for their product?


You should really be thinking about service early on, but by the time you’re transferring to manufacturing, you really need to have it locked down as part of the process of transferring it to manufacturing. You want to go ahead and plan out what’s going to happen once you deploy medical devices out in the field. For instance, how are you upfront selling service agreements to your customers? Are you going ahead and talking to them about service?

It’s just like Geek Squad at Best Buy. They tell you right away at the point of sale of a computer that, hey, you should go ahead and purchase this Geek squad agreement because at some point your computer is going to fail and that’s how you manage expectations.

Be sure to communicate future repairs that may be needed upfront, and keep on hand the parts you may need for repairs. That way, you’re not scrambling with lead times on parts and can quickly have units shipped to your facility, get them repaired and send back right away to reduce downtime for the customer.

So service is really an opportunity to continue to build trust with your customer outside of just the sale of the device. 


You’re continuing to build the relationship.


Right! You want them to be confident that if something happens you can get it fixed quickly.

At my previous company, I both built and repaired machines. Once, I had a client whose machine went down at 8pm, and they had customers lined up the next day to use their medical device starting at noon. So, I got on a plane that night and got to their site by 8PM. I fixed their unit and then jumped right back on a plane and returned home. But I had a customer at that point for life because they were happy that I understood that they had scheduled customers lined up at noon. They understood that they were asking a lot of us and we were able to meet their needs. And from there on out, they were spreading the word about our medical device and how great we were.

So sometimes I think people think of service as a negative, but it actually can be a positive and it can actually build that relationship if you’re prepared for it. Our team was always prepared to fly in the split of a second because we knew that we were field service engineers, but we also had the ability to overnight units for depot repair, and made sure that we were on top of that to build those relationships.


So where did you fly to? 


Albuquerque, New Mexico. 




Yeah, I flew in that night, Got there at 8AM the next morning, fixed their unit, and was back at the airport at 10AM the next day.


That’s a fast trip!


Very fast trip. Not much sleep either. 


But I’m sure it really helped that customer feel confident and know that they were taken care of. 


Yeah, definitely. I was happy to do it


So what are your tips on helping people really change their perspective on service? Not seeing it in a negative light, but seeing it as just another business opportunity and another way to build trust with their customers? 


I’d say the first step is to do research. When I first got into service and units were failing, we found ourselves repairing parts constantly. I wanted to figure out a solution to this problem. 

So I went to Lowe’s. I already needed to buy a washer and dryer for my home, so I went and spoke to a Lowe’s representative, I asked them, “What’s the failure rate on these?” I didn’t think they would have the answer. But instead, he gave me a full report card that showed me every device there from dishwashers to washing machines and the failure rate.

And it was eye opening to me. It made me realize that failing products is normal. And he also went ahead and told me about service agreements and options to make me feel more comfortable with my purchase. 

It’s the same thing with medical devices. You need to prepare that, and ask yourself some questions: 

“What is going to be my failure rate?” 

“What is the mean time to failure?”

“What are the most likely components to fail?”

“And then what are people willing to pay for a service agreement to have peace of mind?” 

So you need to know your market. Start lining out those service agreements and figuring out what was going to make you profitable, because you need to understand what’s your highest cost item that could fail. This will help you incorporate that into the cost of the service agreement while also ensuring it’s a rate that people can afford. You also need to ensure the cost of repair is not more than the cost of the device, because then clearly they’re not going to buy the agreement. So you’ve got to be smart and tactful.

And I’d also say that you need to prepare your sales people in the field to go ahead and start selling these right away. I recommend you build a service team who can call customers once they’re at the one or two year mark and ask them if they want to renew their service agreements. And the agreement should also be part of the original point of sale. 


Yeah, just ready to go right off the bat. Right?


Yep! If I am a customer receiving a medical device and I get all the information upfront, I would be grateful, and see it as a point of assurance that if something goes wrong, I know who’s there to help me, I know who to call and what my options are. 


Like you were saying earlier about Geek Squad, you know they’re there if your computer breaks. So it’s just a point of comfort rather than a point of distress. 


Right. Yeah. It makes them feel prepared, it makes the process easier and that’s the goal.


Awesome. Well, that was some really good information, not just service, but also how to change your mindset and turn service into a positive rather than a negative.

Coming up, we will dive deeper into service and different aspects of manufacturing.

Thanks for talking with us, Britt! 


Thanks for having me! I can’t wait for the next chat to share more information and stories. And if anyone out there has any further questions, feel free to reach out to me. I’m happy to talk about any topics really to service.

transfer to manufacturing

In Focus Podcast - S1 002: Transfer to Manufacturing

In Focus Podcast: S1 - 002

Transfer to Manufacturing

Play Episode:

What do you need to know to transfer your product to manufacturing? How can we improve the transfer process and make it easier for everyone involved? 

In this episode Julia and Britt interview Blur’s Director of Electrical Engineering, David Moody. He has 30 years of experience in the pharmaceutical and medical industry, and for the past 20 years he’s been directly involved in the transfer to manufacturing process for small and large companies. It’s safe to say he’s seen the good, the bad, and the ugly when it comes to the transfer process, and he has lots of advice for us on how to make the process workable for everyone involved. 


David, in your own words, can you describe what transfer to manufacturing is? 


Transfer to manufacturing is when you start getting all of the documentation in place such that somebody besides the engineers who designed it can put something together. And put it together over and over and over again in a consistent and reliable manner. So you’re not constantly changing stuff. 

You wanna have all of your bill of materials in place so people know what to purchase. You need to have assembly instructions so people know how to put this device together. Any other instructions that go with it, programming instructions, calibration instructions, those all need to be prepared. [These are prepared] a lot of times with the collaboration of the manufacturer, and that is some place where Blur does excel is in helping our customers create these documents. 

The transfer to manufacturing is literally transferring all of the knowledge that the customer has about this product to another set of people. 


It’s the process of making a device or a product repeatable and consistent by someone else. 




So what would you say that most people miss in transferring to manufacturing?


Usually people are good during the design aspects,  thinking about how something is going to be built. They will maybe design it so you can get to all the fasteners or, you know, the cables are routed nicely so that you could put them in after things are built. Items that people don’t usually think about are the manufacturing specific, which would be any test fixtures. You might need something to hold parts together. You know, when it’s built by R&D engineers, they’re just going to put it on their desk and put it together. But when you have to build hundreds of these, you might need some fixtures to hold things in place. When there’s electronics with microprocessors on board, now you have to support the programming of the devices. So you may need a dedicated programming fixture that might power the circuit board and has a dedicated computer with all the programming software. 

The other thing people don’t realize is all of the incoming inspection that goes on with manufacturing. Whenever parts are ordered, they need to be inspected. They need to be input into a quality system, an inventory system. Those are the things that everybody forgets about. 

There’s a huge difference in building one in an R&D lab versus some large number per month for many months.


And there’s also just scaling that too. I mean, after you start manufacturing a product, you may go back and realize you need another fixture because of an end-of-line failure that you could have caught, you know, upstream. And so you and I have worked together on some things like that, where there was an LED indicator that was failing at the end and we were having to NCMR that to troubleshoot it. And you quickly came up with a fixture that allowed for us to test that real time to avoid that failure. 


Right, and we’ll come up with, “We think this is a list of all the test fixtures that we’re gonna need,” but really you don’t know until you’ve gone through the process once. Britt mentioned there’s always room for improvement in our process. So we try to make it as efficient as we can. If we can automate a process, it may sound like it’s expensive upfront, but if you’re eliminating a person doing a job repeatedly, your automation always pays for itself. 


How soon should you transfer to a manufacturer? Is there a too early and is there a too late? 


There is a too early. If you get manufacturing involved too early and you’re still making change after change after change, there’s a lot of wasted effort. People are looking at designs that may or may not be what you’re going to build. 

The too late would be when you have completed all of your project, you’ve done all of your verification tests, and now you just want to do a handover. A lot of times the manufacturing people are going to request some changes, either to make things easier to build, easier to assemble, easier to test. 

Usually once you get to a design freeze point where the customer has all of the key features, the key functionality of the device, that’s when you want to start engaging your manufacturing partner. At that point, they can go through, they can review the design, they can help you fill in gaps with documentation you may need like if your bill of materials isn’t correct. If you’re missing assembly instructions, they can help with assembly instructions. 

They can guide with suggestions on what kind of fixturing you might need. If you need test fixturing, you may need to change your design. That is especially true with circuit boards. If you have to measure voltages or signals or something on a circuit board as an in-process check, if those are not in place during the design of the board, then it’s very difficult to measure those after the fact. 

You really need to know the requirements of who you’re working with. Large manufacturers can have a lot more requirements than a small company does. You really need to get involved early to know who you’re working with so that in the end, it doesn’t delay your final product. 


Yeah, I agree. 

How would you say we’re unique at Blur and in our manufacturing transfer process? 


We’re all under one house, one roof. We have, I think, the luxury right now of being in two buildings right beside each other. If the manufacturing team has any questions, the engineering team just willingly jumps in and helps. 


You guys are pretty much on the line for our first builds every time. You’re very nearby. 


Yeah. There’s usually a key contact person engineer. It’s their responsibility to get to understand the project and get to understand how it’s built so when questions do arise, we have a resource available immediately. You know, usually within minutes of being contacted, someone is helping production with something. 

A lot of times we can address issues internally. By addressing things internally, it allows us to be much quicker, much more reactive to whenever a problem comes up. 

We all are really one big team, one family. The engineering and manufacturing, it’s not us versus them. The engineers work really well with the manufacturing team. 


I think that team mindset too is reflected even in the way that we talk about the two different buildings. The R&D space we call Upstairs, the manufacturing space we call Downstairs, which can be a little confusing to clients sometimes when we forget. “Oh, they’re downstairs, I mean manufacturing.”


Right. I think it’s the only place I’ve worked where there’s not a like, “Oh, you’re a totally different team,” mentality. We really are just one group here. 


Yeah, that’s what I’ve seen as well. It’s a great culture and we work well together and it makes things go smoother, I’d say, and makes an overall better product as well. 


Well, thank you, David, for being with us today on the podcast. You had some really awesome insight into the transfer to manufacturing process, specifically at Blur and what clients need to look out for in general when they’re going through that. 


It’s been my pleasure. 

Blur Product Development - medical device design

In Focus Podcast - S1 001: Medical Device Design

In Focus Podcast: S1 001

Medical Device Design

Play Episode:

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. 


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? 


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.”


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


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. 


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


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


It’s just a word.


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. 


Fancy moving parts. 


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. 


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? 


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. 


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? 


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? 


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. 


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. 


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? 


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. 


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. 


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. 


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? 


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. 


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. 


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. 


It looks real. 


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. 


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? 


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. 


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


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. 


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


Yeah, exactly. 


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

Prepare for Risks - Contract Manufacturing

When to Involve Manufacturing in the Design Process

When’s the right time to involve manufacturing in the design process? Britt Creech, Leader of Operations at Blur, weighs in on this topic and shares insights on how Blur approaches design and manufacturing phases.

Parallel Development and Manufacturing Phases

At Blur, we know from many years developing medical devices that most customers have aggressive timelines to meet their deadlines. Britt is no stranger to tight timelines in manufacturing, having been in the medical device field for 12 years. “It’s critical at Blur for us to have a parallel path in development and manufacturing phases to achieve these targets,” Britt says.

In a perfect world, the design would be frozen before transferring to manufacturing; however, most clients come in with almost finished products that require final modifications.

The good news is that we have a design team that can assist with these final tweaks and help prepare the documentation, freeze the design, and start ordering parts. They work in parallel by ordering parts with long lead times while ensuring that the design is ready for manufacturing.

Documentation Assistance

What happens when a customer has a finished device with no documentation, such as assembly instructions, bill of materials, and raw material specifications? Britt notes that they work with the client side-by-side, breaking down the device and documenting every step involved in building it. 

“Together, we build the device back while writing assembly instructions, creating drawings, creating material specifications, and coming up with what the requirements are for final testing, and then helping them understand what testing is needed and implementing the final testing,” Britt explains. 

They also help the client understand what testing is needed and implement the final testing to ensure they have a finished product that can be commercialized.

From Prototype to Manufacturing

By following this approach, the Blur team takes a prototype directly to a place where the device can be manufactured. The team at Blur can evaluate what’s left to be completed for your product and work alongside your team to make sure you have a finished product that meets your needs.

Get Started with Blur Contract Manufacturing

If you are looking for assistance with your product development and manufacturing process, reach out to us! Let us know where you are in your process, show us what you’ve done so far, and we can tell you what’s left to be completed. Our team looks forward to working with you and helping you achieve your goals.

medical device contract manufacturer

How Project Management Helps Tackle Complex Projects

Project Management at Blur Product Development

Project Management is key for successfully transforming an innovative idea into a functional medical device. At Blur, we work on complex projects that require specific expertise in electrical and mechanical engineering. The success of these projects depends deeply on communication, trust, and a solid project management schema. Read on to discover how we keep projects continually moving forwards.

Breaking Down Complex Projects

The cutting-edge projects we tackle often feature new or unique technology. As a result, it’s impossible for us to know everything from day one. We make our best estimates for how long a project will take, but we keep reevaluating and pivoting as needed. This approach allows us to stay flexible and adapt to changing circumstances and technologies.

Communication is Key

When it comes to complex products, communication and trust are critical to the success of your project. At Blur, we evaluate our assumptions as we go and make sure to adjust the scope of the project as needed. We are always communicating with our clients, keeping them up-to-date on our progress, and making sure they are comfortable with any changes we need to make. We believe that by doing this, we can create a project that is both successful and meets the client’s needs.

Two-Week Agile Sprints

We modified a two-week Agile sprint, typically used in software development, to work with our product development approach. Instead of tracking specific code releases, we’re tracking granular tasks that flow into larger buckets that then make up the scope of the project. We’ve found sprints provide higher alignment on priorities, commitment, and accountability with our team. During each two-week period, we create clear expectations for what deliverables are due from each team member. When we sit down, we have a prioritized list of everything that needs to get accomplished on the project, which drives alignment and accountability within the team.

At the end of the two-week sprint, each team member presents demonstrable deliverables, allowing us to align with our clients on expectations and track progress towards success. The sprints help us capture quick wins and learnings along the way while avoiding getting caught up in the big picture. Understanding exactly what tasks our team needs to accomplish within two weeks makes sure that our short-term goals lead to long term success.

Product development ideation on a whiteboard

Regulatory Guidance in Product Development

Blur is a full-service product development firm that offers a comprehensive range of product development services to help turn your ideas into reality. Product development isn’t just about bringing a product to market. It’s also important to ensure that your product complies with regulatory requirements. 

That’s where our regulatory services come in

Regulatory guidance is crucial to the development of any medical device. By providing essential design controls and testing from the outset of the design process, regulatory guidance can help ensure that a product meets regulatory requirements and achieves market clearance more quickly.

The first step in obtaining regulatory guidance is to determine the classification of the product and the appropriate regulatory strategy. This will help identify what types of testing are required, including verification testing, validation testing, and usability testing. In addition, it will identify any applicable standards and guidelines that must be followed to ensure compliance and streamline the product development process.

Ideally, regulatory guidance should be involved in the very beginning stages of product development. This ensures that the device is classified correctly and that the appropriate regulatory strategy is identified. It may also involve a pre-submission with the FDA to review and discuss questions that may arise during the development process.

Throughout the product development process, regulatory guidance ensures that testing protocols and test reports meet the required standards to produce high-quality submissions. Additionally, it ensures that appropriate product development documentation is maintained to address any questions that may arise from the FDA.

Regulatory Services: Navigating Regulatory Compliance with Ease

At Blur Product Development, we understand that regulatory compliance can be a daunting task for most in the medical device product development field. Fortunately, our regulatory services team can help you navigate this process with ease. We offer a comprehensive suite of regulatory services, including regulatory guidance, compliance assessments, and FDA submission support. Our team of experienced regulatory professionals can help streamline your product development process, saving you time and money.

With our regulatory services, you can rest assured that your product will meet all the necessary regulatory requirements, allowing you to focus on what you do best – developing innovative and high-quality products that improve people’s lives.

To get started, we arrange a call to discuss your needs and learn more about your product. We help determine the appropriate regulatory strategy and how we can assist you in achieving market clearance quickly and efficiently.

Ready to take the next step with your product development process? Contact us today to learn more about our product development and regulatory services.

Blur Product Development Quality and Operations

Why Quality and Operations Must Work Together

Building a strong team is the foundation of any successful business. At Blur, quality and operations working together is a foundational part of the team atmosphere. Our goal is to keep our teams engaged in the entire process by including them in the development as well as any changes in procedural requirements. This allows the process to work with the team rather than against them. As Noah Muse, the Director of Quality at Blur states, “We have the same goal and we’re working together to get there.” 

Quality and Operations

“At Blur, it’s believed that quality and operations need to work closely together,” says Noah, “Everyone has the responsibility of quality in the organization as well as the desire to meet customer goals and to work together to achieve them.” Although our quality system may have a lot of standard operating procedures (SOPs) in place, we ensure that there are flexible pieces within them. This gives each of our teams room to maneuver while maintaining the high standards they have set for themselves.

Noah holds an ongoing meeting called Cooperations where quality and operations come together to develop processes and SOPs. The unique part about this meeting is that they don’t design these procedures in a vacuum: “As we’re developing or making changes to some of the procedural requirements, we’ll engage the team that works in that area and that allows the process to kind of work with the team rather than against them,” Noah says. 

The regulatory bodies like the FDA and the ISO standards provide general QMS standards, but there are a lot of ways to incorporate the requirements and handle customer needs.

Why such high standards?

In the medical device industry, companies must adhere to strict QMS standards set by regulatory bodies such as the FDA (Food and Drug Administration) and ISO (International Organization for Standardization).

The FDA and ISO have established QMS standards to ensure medical devices are safe and effective for use. These standards outline the requirements for developing, manufacturing, and distributing medical devices. In the US, the FDA’s QMS standards are outlined in the Code of Federal Regulations (CFR) Title 21. This includes requirements for design control, production and process control, and corrective and preventive actions.

Standards for Medical Device Manufacturers

Similarly, the ISO has developed a set of international standards called ISO 13485 for medical device manufacturers. This standard outlines the requirements for implementing a QMS and ensuring that medical devices consistently meet customer and regulatory requirements.

Adhering to QMS standards is crucial for medical device manufacturers to ensure the safety and efficacy of their products. Noncompliance can result in legal consequences, recalls, and reputational damage. Therefore, medical device manufacturers must implement robust QMS systems and regularly monitor and improve them to maintain compliance with the standards set by regulatory bodies.

If you’re looking to improve your quality and operations, reach out to Blur and let us know where you are in your process. With our team-oriented approach and vast experience, we’ll will work with you to achieve your goals and exceed your expectations.