Are you 'Team Waterfall' or 'Team Agile' for your product development methodology of choice?
The waterfall methodology used to be the industry norm for medical device product development until an alternative approach known as the agile methodology emerged, leading to competing opinions over which product development approach is best.
In this special 200th episode of the Global Medical Device Podcast, host Jon Speer and his guest Devon Campbell, founder and CEO at Prodct, discuss the waterfall and agile methodologies for medical device product development, how they were first introduced and how they are interpreted and used today, while also dispelling common myths about the two approaches.
Listen as the battle between the methodologies is finally laid to rest by Jon and Devon, with one key theme emerging: the name of your chosen methodology is not nearly as important as the defined processes you follow during product development and throughout the course of your medical device project.
LISTEN NOW:
Like this episode? Subscribe today on iTunes or SoundCloud.
Some highlights of this episode include:
- The FDA’s Design Control Guidance for Medical Device Manufacturers is outdated and includes the waterfall design process. However, medical device manufacturers do not have to follow the waterfall approach.
- Industry norm? Read the entire guidance before making an incorrect assumption. The waterfall approach is one way, but the guidance offers other approaches and best practices to consider or follow.
- The waterfall approach was not revolutionary, but it did serve a lot of good for a lot of people. It helped companies establish infrastructure and understand how to develop medical devices in a safe and efficacious manner to meet patient needs.
- The term, ‘agile,’ as far as a product development methodology, didn’t exist until 2001 with the Agile Manifesto. There were huge gains in efficiency, productivity, and customer satisfaction for software companies using this shiny new approach.
- What does a good prototype look like? It might be a misconception that one approach is slower or faster than the other. Embrace and acknowledge the idea of continuous change and iteration. Document early, revise often.
- However, a certain order of operation needs to be followed for verification, validation, traceability, and flow of requirements, regulations, and other factors.
Links:
FDA - Design Control Guidance for Medical Device Manufacturers (Waterfall Diagram)
FDA - Quality System Regulation, Part 820
Agile Manifesto
Scaled Agile Framework (SAFe)
Large-Scale Scrum (LeSS)
Software as a Medical Device (SaMD)
ISO 13485 - Medical Devices
Prodct LLC
Devon Campbell’s Email
Devon Campbell on LinkedIn
Devon Campbell on Twitter
Project Medtech Podcast with Duane Mancini
Easy Medical Device Podcast with Monir El Azzouzi
Greenlight Guru Academy
MedTech True Quality Stories Podcast
Greenlight Guru True Quality Roadshow
Greenlight Guru
Memorable Quotes from this episode:
“The big confusion about medical device product development is exacerbated by the infamous waterfall diagram that’s published in the FDA guidance.” Jon Speer
“Incorrect impression: Well, the FDA says we have to do this, and therefore, we shall do this. They’ve given us a model. This is the way we have to do it. It doesn’t say that.” Devon Campbell
“People, they just see this waterfall approach and use it. Kind of blindly, almost.” Devon Campbell
“You start seeing huge gains in efficiency and productivity and customer satisfaction for software companies where they are using this approach.” Devon Campbell
Transcript:
Announcer: Welcome to the Global Medical Device Podcast, where today's brightest minds in the medical device industry go to get their most useful and actionable insider knowledge, direct from some of the world's leading medical device experts and companies.
Jon Speer: Number 200. It's just hard to think about and hard to believe that 200 episodes ago, all those years ago, we started the Global Medical Device Podcast. Thank all of you for being listeners and following along through this journey. Just the whole Greenlight experience has been fantastic. The fact that we've developed the world's best medical device success platform to help medical device companies design safer, more effective products that are going to impact the quality of life in a good way is in and of itself, freaking amazing. And the fact that I get to do and host the Global Medical Device Podcast, so much fun. Don't tell anybody that I'm working when I do these, but I do enjoy the opportunity to connect with so many awesome people in our industry, on so many important, impactful topics. And I've just been blessed to be able to do this for all these years. So thank you again, so much. I'm so appreciative. I'm so grateful. On this episode of the Global Medical Device Podcast, I get to talk to a friend of mine that a friendship, frankly, that emerged as part of this Greenlight journey, someone who thinks about medical device product development and working with startups in a way that very much aligns with my own philosophy and my own approach. And we have a great time riffing and collaborating off of each other. That guest is Devon Campbell with Prodct, P- R- O- D- C- T. And in this episode, he and I talk a little bit more in depth about waterfall versus agile, with respect to your product development approach and process and methodology. So enjoy this episode of the Global Medical Device Podcast. Hello and welcome to the Global Medical Device Podcast, powered by Greenlight Guru. This is your host and founder at Greenlight Guru, Jon Speer. Joining me today is Devon Campbell. Devon is the Founder and CEO at Prodct, P- R- O- D- C- T. Devon, welcome.
Devon Campbell: Thanks. Happy to be here.
Jon Speer: Devon, special surprise for the listener. Oh yeah, by the way, we're on video now. So some folks maybe haven't picked that up, but we incorporated video recently on the Global medical device podcast. Don't worry if you're listening to us and you are taking a stroll through the neighborhood. You can still check it out on audio, but it is on YouTube. We do have video incorporated into that as well. But, Devon, a special episode today. This is number 200. Can you believe it? It's crazy.
Devon Campbell: Yay.
Jon Speer: I know you and I have had quite a few thrilling conversations on the Global Medical Device Podcast in the past, as well as just things that we didn't record, but a lot of great guests over the years, a lot of great topics of conversation. Do you remember the first time that we met in person?
Devon Campbell: Yeah, you were doing True Quality Roadshow in Boston and I was on your panel.
Jon Speer: Yeah. And it's like...
Devon Campbell: And then we went out for dinner afterwards. Yeah.
Jon Speer: Yeah. And I was like, " Man, I felt like I just met a kindred spirit, somebody that I could just riff off of." We have completely different upbringing. Well, not completely, but enough different upbringing in the industry. But at the same time, it's like philosophically and just the way we think about things was pretty similar. And I really have appreciated bouncing things off of you over the years. So thank you for being a collaborator. Thank you for being a friend. And so many different opportunities and guests to consider for number 200, but who better than Devon Campbell with Prodct?
Devon Campbell: I'm happy to be here.
Jon Speer: And I thought, since this is such a special episode and I don't know how passionate you are about medical device product development and working with startups, I share that similar passion, I thought we could dive into this topic that's still very confusing for people on medical device product development. And specifically, I thought we could unpack some myths and maybe bust a few minutes about waterfall and agile methodology, with respect to product development. What do you think?
Devon Campbell: Yeah, I think it's fun. It'll be a slight deviation, slight, from our normal conversations where we're focusing more specifically on culture of quality and implementation of quality, primarily with emerging entrepreneurs and earlier startups dipping their toes in this space and looking at it with timid eyes. And we thought let's not focus just on quality, because we're both product development nerds in the medical device space. That's what you and I do. And we thought let's step back a little bit and look at the more holistic picture of which quality is a piece of, but obviously, we won't be able to divorce ourselves from quality within the conversation. But we'll try to look at the bigger picture.
Jon Speer: Yeah. So I actually had the opportunity recently, to be a guest on a couple of other podcasts. One was Project MedTech, from Duane Mancini, and then another was the Easy Medical Device Podcast, with Monir El Azzouzi. And I think on both of those, I talked a little bit about product development because I've been this space for going on 23 years. And I think there's a lot of confusion.
Devon Campbell: Me as well. Yeah.
Jon Speer: And I think that the big confusion about medical device product development is exacerbated by the infamous waterfall diagram that's published in the FDA guidance. And I think that there it is, that's it.
Devon Campbell: Excellent.
Jon Speer: Wow. I think that creates a lot of confusion, especially for startups who maybe are quick and nimble and want to be more agile in their approach and methodology. I think it's especially confusing for software as a med device companies. They're like, " Ah, those regulations, they are antiquated, they're out of date and that sort of thing." But there's this perception that thou shalt do waterfall if you are a medical device company. What are your thoughts about that?
Devon Campbell: Well, it's not in 820 itself. It's written into the guidance documents where that picture shows up, the picture that shows the waterfall approach. For listeners, if you pull up the guidance documents for 820, it's only just a few pages into the overall document where it talks about application design controls, and shows you that figure that moves from user needs all the way down to medical device. And a lot of people see that and they see the picture, the picture resonates and stays with them without necessarily reading through all of the rest of the guidance document. And they walk away with this impression, this incorrect impression that, well, the FDA says, we have to do this. And therefore, we shall do this. They've given us a model. This is the way we have to do it. It doesn't say that. If you read it, it tells you in the guidance document that this is an illustration of one way to do it. And it's a culmination of best practices at the time, which was 1997. No. Yeah, 1997. So about the same time I was getting into the medical device field. And so people, they see this waterfall approach and they just use it, blindly almost. And it's what has been in the industry and it's what people use. You bounce around from company to company, everyone basically has a stage- gated or a space- gated waterfall approach to product development. And you just walk away as you move around a bit to say, " Well, this is industry norm. This is just how we do things." And don't necessarily think to challenge it. You can do all the research you want online, looking at medical device product development processes, and most of the time you're going to find versions of that picture. In documents that companies put out, they say, " No, this is how you do it." You're going to find deviations at that picture, and you don't see a lot saying there are other ways to do it.
Jon Speer: Yeah. Well, a couple of things. So I remember in my formative years in medical device product development, just coming right out of school, being a product development engineer for a relatively large medical device company. Well, first and foremost, the term agile, as far as a product development methodology, didn't exist when I started in the industry. I think the agile manifesto was published like 2, 000 or something like that, right?
Devon Campbell: 2001.
Jon Speer: 2001?
Devon Campbell: 2001.
Jon Speer: Yeah. So FDA, design control regulations became and it went into effect in, I think, 1996. The guidance that you mentioned was 1997, so that's a few years ahead of time. But I guess when I've looked at it, I didn't understand the whole phase versus agile and that sort of thing when we did development. I just knew that first and foremost, I love prototyping, getting hands- on, because as an engineer, man, that's fun. You get to put things together. You get to do some tests. You get to break things and see how things work. But looking back, I think I was really agile in my approach, even though we had a procedure, we had a system that was more or less, I'll say waterfall- esque in its intent and design, or maybe a stage- gate type of approach. But even with that, there were things that I was doing as a product development engineer that I would label as agile today. Why do you think that became so ingrained as the conventional wisdom in the industry? Do you think it was just that point where people saw the picture and said, " Hey, that's what FDA wants, I'm not going to read any further and let's architect the system that way"?
Devon Campbell: Yeah. You're given an example and told that there are other ways to do it, but you are given an example. And so it's a very obvious leap to say, " Well, the FDA gave me this example. They didn't dive into detail on other ways to do it. I'm just going to follow that."
Jon Speer: Yeah.
Devon Campbell: But I think it's the natural consequence of providing a single example.
Jon Speer: Yeah. And I remember, too, we had hired an outside firm. Their name escapes me for the moment, but there were two gentlemen who were, I think, they were noted as the fathers of stage- gate or something like that. And they weren't unique to med device. So I think this is a challenge that presents itself in numerous industries, not just med device. But we actually hired this company to come in and they put in all these stages and these gates, and all these sorts of things. And it was presented as, " Hey, this is a better way for our business to operate." Incorporate it in the governance and you have to have entrance criteria, exit criteria and that sort of thing. But man, in hindsight, it didn't seem very effective. It didn't seem to align with what was important for us as a business.
Devon Campbell: And it was still a waterfall approach.
Jon Speer: It was still waterfall. Yeah, absolutely.
Devon Campbell: Yeah, it's still waterfall, just with different buzzwords.
Jon Speer: Sure.
Devon Campbell: And different marketing opportunities. So yeah, there was not necessarily though, a revolutionary type approach. But it served a lot of good for a lot of people and helped a lot of companies get some infrastructure established. Helped them get their arms around how they're going to develop medical devices in a very safe and efficacious manner that will satisfy the needs of patients and of customers, and the FDA and regulators. So not throwing any shade on any of that. It was very helpful. But again, you saw at that time, the industry really swinging. Everyone's all in on that kind of approach, and you see all the companies starting to do it. And then you started to see the same trend, as after the agile manifesto comes out in 2001. And then specifically for software development, you start seeing huge gains in efficiency and productivity, customer satisfaction for software companies where they're using this approach. And it creates this natural tension between like, here's something new, it's shiny and new, and it has all of its own buzzwords and special lingo, like scrum master and sprints and all these things. Right. Right. But you see that it's working. And then, so it creates this tension in our industry. Like, how do we start to do that? We want to do that. And so you started to see software development, not just software as a service type options, or software as a medical device options, but just even software development for larger devices that employ software and firmware, you start seeing those teams start doing it. And then you had this kind of disconnect between the rest of the team. And then I'm from more of the in vitro diagnostic world, so I have not just the hardware and software development, but also chemistry and assay development side of things. So you've got hardware, chemistry, assay, consumables, you have all of this work happening. And then the quality systems and the internal teams that are governing how we do all that, doing all of that the way that they normally do. And then you had the software team over here doing something different. And it created this interesting dynamic of, how do we let you do your thing and be fast? And have, what are you going to do, weekly or biweekly sprints? What does that mean in the context of a larger medical device? We can't make hardware in two weeks. Prototyping wasn't as readily accessible as it is now. 3D printers weren't everywhere, but it created this interesting tension. Did you experience that at all in your path?
Jon Speer: Yeah. And I'm glad you brought up the word fast, because I think that is... Well, my experience is that's also a myth. I think the myth is that agile product development is faster than waterfall, which it can be true. And I've seen it be false as well. To me, it's less about what methodology that you use and more about, I guess, how you architect those processes and those systems. But yeah, I saw that a lot where it's a head scratch. It was a head scratcher at the time. It was like, wait. And working on an electromechanical device is extremely challenging because you have that hardware component. Especially like you said, before 3D printing, getting a printed circuit board, man, that took a long time to lay out schematics. And you got Gerbers and all these sorts of things, and the lead time to get those. Meanwhile, the firmware team is doing a lot of work on some breadboards maybe, or maybe even some simulated printed circuit boards.
Devon Campbell: Right. Right.
Jon Speer: They could iterate so much faster. And then once the hardware team got the first front of boards and they figure out, " Okay, well, we need to edit here and modify there," there's all these jumper wires all over the damn thing. And it's like this is crazy. But I think that's the drawback of being more like a tangible good, like a printed circuit board or a mechanical product is that ability to iterate is so much slower. And I think that puts some constraints. But yeah, for sure, I had similar experiences.
Devon Campbell: So I think that it might be a misconception that it's slower in one versus the other. It's really a matter of trying to define, what does good look like and saying, " All right, well, we're not going to develop hard electromechanical hardware in one week sprints." The software team can do their stuff really quickly, or maybe even a two- week sprint. But we can think through, how are we going to deliver something of value that someone can then test to move us along? The whole idea there is don't just give me a bunch of requirements and lock me up in a room and I just develop something. And then three months later, I say, " Here's the prototype." You really need to embrace this idea of continuous change. That's one of the 12 tenants of the original manifesto. It's acknowledging and embracing that change in requirements happen, and not try to fight it. But instead, work with it. And this idea of, well, what can we do? Maybe I can prototype something, one piece of it, to get some customer involvement or some user involvement early. If it's a surgical tool, maybe I don't have the whole thing done, but maybe I could start working on the piece that the surgeon is holding. So we can start getting some customer feedback. How does it feel in their hand? How does the weight balance feel like? Things like that. So you can get that feedback and do the constant iteration, which agile is famous for. You see the little line that goes up, and then it circles around and goes back forward. And you just keep doing that. You can deploy that kind of thinking as long as you're flexible enough or agile enough in how you approach things, even on the electromechanical side. And I've had success doing that in the past.
Jon Speer: Yeah. And I've had it on purely mechanical products. And like I said, I didn't know that I was being agile at that point in time where I was doing it.
Devon Campbell: Right. Right.
Jon Speer: But we had machining equipment. We had a lathe in our engineering department and an in- mill, and all these sorts of things, and some bar stock and some just chunks of plastic. And I would go on machining different components. Now, we weren't going to machine the part in the end, but you can machine things and grab a few parts and pieces, and glue... I did a lot of catheter development in early days, but you can hack some things together to make some crude prototypes, to your point, just to get it in the hands of the end user. Not from a procedural standpoint, but get their feedback. Is this about the right size? Is this the right orientation? And those sorts of things. So I think that's the thing that a lot of mechanical people get hung up on, is they back load those types of events until much further along in the development cycle. And then once you do that, you've already invested a ton of time, a ton of money, a ton of resources. And now, change has become expensive, right?
Devon Campbell: Right.
Jon Speer: Yeah. I don't know what the rule is called, but I remember hearing it, the 110- 100 Rule. Have you heard of this?
Devon Campbell: No. Tell me.
Jon Speer: Okay. So if you make a change and let's just say, and I'm going to over simplify a product development process as the beginning, middle and end, but if you make a change in the beginning, it costs you a dollar. If you make a change in the middle, it costs you $2. If you make a change at the end, it's going to cost you a $ 100, and so on and so forth. So it's the Rule of 10, I think, is what it's called.
Devon Campbell: Or maybe even a 1, 000. Yeah.
Jon Speer: Or a 1, 000, right? So it's to your advantage to iterate. Make those changes, to your point, realize that those requirements are very fluid, and use prototyping or different things, different methodologies and approaches to help you refine and fine- tune those requirements. And do that early and often.
Devon Campbell: Right. Right. Right. Yeah. It's been done. So we're talking about in the past, and we're also bemoaning a little bit that the industry still seems very stuck on that waterfall approach, which I appreciate its value and some positive things that it brings to governance and overall product development processes. Agile is highly valuable as well, and that approach and that methodology is seen starting in software, but you can apply it to a much broader space. But there's lots of people that have been applying it and trying, like I tried it, to bring it into medical devices and the electromechanical side, not just the software side. And there are a number of different approaches out there right now, that people can still take a look at. There's SAFe and there's Large- Scale Scrum, and this is the Scaled Agile Framework. There's just a number of different ways that you can take these scrum ideas that people have tried applying them and say, " Okay, well, I'm going to take the manifesto and make it our own in this space." And this is what our company does that was working. It worked really well. And then maybe you productize it and it becomes something that you can then go out and market, and sell to people, and you have your own new buzzwords and your own new approaches. There's a lot of good models that are out there, and I think one key takeaway that I want people listening to us, talking to this conversation to at least walk away with one thing, to just know that there is something different than the waterfall approach. And there are lots of hybrid approaches that blend agile and waterfall very effectively. And there's some good examples of people doing it in the medical device space. What's important though, whenever a company is looking at this and saying, especially in my space where I really focus on emerging entrepreneurs and earlier startups, they say, " Okay, how are we going to do this development, to look at these different models that are out there?" Look at what the FDA still has on their guidance document that is much older now, and look at these different documents that are out there and these different websites. Agile is very, very open- source, so lots of different ways that you can look at it, and people freely share these ideas. But what's important is to acknowledge there are different ways to do it. Read about them, learn about them. Maybe bring in some experts that have experience with some of them, but don't just pick one and blindly follow it.
Jon Speer: Yeah.
Devon Campbell: Right. Just to say, " Okay, this is the approach and I'm going to go all in with this methodology and I'm going to..." Okay. Well, we have to use these terms, and we have to do everything. In my experience, when I've seen that happen. It's met with some level of resistance within the team. And I think it's important to understand the culture of the team, the culture of the organization. How much can they take? How different from normal could they... If they have a few people on a startup company that have been in the industry, all they know is one approach, well, then those, they might even be on the leadership teams for these startups. So they're going to have a little bit of trouble adopting. So looking at hybrid approaches. But then personalizing them and making them your own? That's really what's important. And that's going to be how you will ultimately be able to realize the best hybrid blend of efficiency between the two, and help satisfy all of the key stakeholders in your product development processes.
Jon Speer: Yeah. Yeah, absolutely. I've talked, and I'll go back to that myth, especially as it relates to software as a medical device, I think they're like, " Well, we're pure agile. We follow with the manifesto to the T." And then there's others like, " Oh, well, FDA is sacrosanct about being waterfall. We've followed that to a T." I think that's a mistake. You can't just follow something blindly. And I think it's really important, to your point, to understand who's on your team, what experiences do they have. But define and architect a system that works for your company, for your resources, for the types of products that you're developing. And my current experience, somewhat related to how we develop a software at Greenlight, is I think there's a good blend that's important. I think it is important to have gates if you will, for certain milestones or events. But in between those, iterate like crazy. Use the agile approach, but there are points where the business needs to make a decision about, is this a go or a no- go? So yeah, my current thing, I think it's great to have better, or it makes more sense to have a blend of those concepts.
Devon Campbell: Yeah. So, what would you say to people that would push back? Because I've heard this before. They'll push back and say, "Well, there's no way a quality system." Forget about the waterfall approach that's in there. They just say, " There's no way that that works in a 820 environment, or in an ISO 1345 environment. There's no way that works in this environment." You document your requirements, you build out your DHF, you connect user needs to product requirements. You start decomposing those further, and you just march through the process and go through the systems. It's a natural process. And that's just what you have to do for quality, because you have to be able to tie back and have this test case, this verification or these validation studies, proves out these requirements or user needs. And that's just you work through it. And several months or years later, you start doing your verification studies to prove all that stuff. What do you say to the folks that say, "No, there's no way you can use this kind of thinking in the strict confines of medical device quality systems"?
Jon Speer: Well, my first reaction is, in my 23 years of doing this, I don't share that experience. I have a different experience that suggests that there is a more flexible way to do this. And I would encourage someone to read that guidance document past the waterfall diagram, where FDA talks about the product development methodologies and approach. And to your point, I think you mentioned this at the beginning, they say, " This is a way, this is not the only way." I'm certainly paraphrasing here. And they-
Devon Campbell: I can give you the exact word, because I have it here. " The development process depicted in the example is a traditional waterfall model. The design proceeds in a logical sequence of phases or stages. The requirements to develop the device is designed to meet that." And it goes on to say, " But this is an example."
Jon Speer: Yeah.
Devon Campbell: The keyword there is the example.
Jon Speer: Yeah.
Devon Campbell: Meaning there are others.
Jon Speer: And further on in that document, too, it talks about concurrent engineering, which my interpretation of concurrent engineering is, it's agile methodology before the term agile methodology was even coined as crosstalk. Yeah. I think there are some absolutes though. I think there are certain order operation. I think you shouldn't be doing final verification and/ or validation activities without understanding what your user needs and your requirements are.
Devon Campbell: Sure. true.
Jon Speer: I think it's hard for you to have final outputs and specifications without knowing what your requirements were.
Devon Campbell: Right.
Jon Speer: So I think there is a certain order of operation that... And I think this is where traceability is so important. And frankly, this is what drove me to conceptualize a better way of design controls and traceability, making it more common practice rather than a thing that some folks did. Let's make this the key thing. If you can show that chain of custody, that traceability, that flow, then to me, you can break your device into a 1, 000 different mini projects, if you will. Just showing how all of those things are. Maybe you're just having, to your point earlier about the surgical tool, maybe you just want to figure out the shape and size and the ergonomics of that handle. You're not worried about all the rest of it. Well, then just focus on that and show the flow. And so I can do a verification activity on just that shape and that design, and I may not have even chosen the materials for the rest of it yet. And I think that's okay.
Devon Campbell: Right. Right.
Jon Speer: Yeah.
Devon Campbell: So one thing I would add to that response. So I also don't share the opinion that I suggested. What would you say to the people that say this? Clearly, I was setting us both up. Not only do the regulations not say that you have to do this right, but if someone says, " Well, quality systems just won't allow it," the pushback is really, you need to take a good, hard look at your quality system.
Jon Speer: For sure.
Devon Campbell: The documentation that you've written that governs how you do things, it may be the case that someone says, " Well," for example, " I can't process a change that fast." So I don't want to bump a rev on something. And then I have gone Queen and Country, everyone has to sign off on this change order before I can do it. And I say, " Well, implement a new change, or an alternative change order system." Use that as your final change order, but you can do interim change orders. And we've talked on one of our earlier calls, I don't know, in the course of the last year or two, about when to start a QMS. And I'm very firm on start as early as you possibly can. And I'm a big proponent of document early, revise often. There's nothing wrong with when you go to market, the rev of a component in your system is rev 17. There's nothing wrong with that. In fact, it actually illustrates that you've done a lot of testing along the way. And you've learned from what's going on, you've made improvements instead of just launching your product and everything's at rev zero.
Jon Speer: Yeah. That's the eyebrow raiser is if that were the case like, " Oh. Really? You came to market with a one rev of your product?" That's a head- scratcher. I have two other reactions, too. I've heard for years how engineers hate design controls. And my reaction to that statement is no, if you feel that way, it's probably because your design control and product development system is too cumbersome and onerous.
Devon Campbell: Right.
Jon Speer: And then related to that is a lot of people don't want to issue a change order, or make a rev to something because the process that they have for making changes is too cumbersome as well. So if that's how you feel when you're going through design control, product development, change management, those sorts of things, that it's too burdensome, take a look at your system. Take a look at your approach because it's too rigid. It's just too rigid.
Devon Campbell: Right. Right. Yeah, it's completely a fallacy that a QMS will not support. Even a full agile approach, your QMS in a medical device context can absolutely still support that. Yeah.
Jon Speer: Well, yeah.
Devon Campbell: It is interesting. As engineers, and I'm a mechanical here, we generally always do rev control on our own. You might come up with three versions of a model in one day, and you're going to call them whatever your rubric is. It may be the date dot one, dot two, dot three or something. But because we know and we appreciate the value of being able to go back and understand which one did we do testing with and whatever, so it shouldn't be the case that you can't have a quality system that allows you to do that in a way that you can take credit for it.
Jon Speer: And I think that's part of the challenge. Most engineers are systematic enough to have that sort of rubric and approach.
Devon Campbell: Right.
Jon Speer: But oftentimes, it's buried in their own log book. And that's unfortunate because this is potentially, institutional company knowledge that will never, never surface. But what if it did? What if you could track and manage all of these iterations and play some of those out a little bit? And say, " Well, I don't know if the dot one, the dot two, or the dot three has merit, but I need to do more discovery to find out." But if you only pursue, or you only capture that in your log book, and then you only pursue the one that was the winner through that discovery, what happens post- market? And now, you need to update something and somebody's like, " Oh, we should change this thing to that other thing." And it was something that was discovered early on in development, but nobody knows it because it's buried.
Devon Campbell: Right.
Jon Speer: It's hidden.
Devon Campbell: Yeah, open and transparent is the best way to do it.
Jon Speer: Yeah. Well, any other thoughts or tips or pointers on this exciting topic of product development that you think is important to leave the audience with today?
Devon Campbell: Just think for yourself. Go look at different ways of doing it, know that there's more than one way. Look at them, talk to experts. Talk to folks like Jon and I that have done it before in the past, and seen it go really well and seen it go poorly, and internalize that information and come up with your own approach. And don't let arbitrary bureaucracy or the specter of QMS hold you back. It is absolutely not the case. You can't have your cake and eat it, too, in this situation. You can be full agile. You can be hybrid agile. You can do what you want in your quality systems, as long as they're flexible enough, can support it. And you can bring products to market with better quality, better delight for your customers and for your users, better patient outcomes, better efficacy, lower costs for development. There's a lot of benefits to opening your eyes and taking a good look, and doing some planning before you jump in and attack, and questioning the industry norms.
Jon Speer: Absolutely. And I'll leave it with waterfall can work, agile can work. Some other method that you come up with can also work. There is a stigma, but there's no criteria that says thou shalt use this or that. It is really up to you. I think the key thing to keep in mind is design controls are an outcome of the process. These are the evidence, the proof that demonstrates that your product is safe and effective, and meet your indications for you.
Devon Campbell: Right.
Jon Speer: So this is what a traceability matrix, how it serves. This is the intent behind the design history file. And that sort of thing is that demonstration, that what you did meets the needs of the end user. And what you did is safe, what you did is effective. That's the whole premise behind design controls.
Devon Campbell: Different ways to get to the same destination, but they're all equally valid.
Jon Speer: Absolutely. Devon, to wrap things up today, I'm so glad that we had that opportunity to meet in Boston those years ago. And every time we chat, I always wrap up the conversation smiling and laughing. And just, we have a good time. So thank you for your friendship over the years, and looking forward to collaborating years ahead as well. So thank you so much.
Devon Campbell: Yeah. Thank you.
Jon Speer: And of course, I also want to thank you for being a guest, Devon Campbell with Prodct. You can check out more about Prodct. Follow him on LinkedIn. Check out his website, PRODCt.devV. So check that out. He works with a lot of startup companies, from electromechanical devices to IVD, just a really great resource to have in your corner. So reach out to Devon and tap into his years of wisdom on medical device product development. And as always, thank you for being listeners and now viewers of the Global Medical Device Podcast. We could not have gotten to number 200, and soon beyond, without you, the listener. Thank you for keeping us as the number one podcast in the medical device industry. As always, this is your host and Founder at Greenlight Guru, Jon Speer. We'll talk to you again real soon.
ABOUT THE GLOBAL MEDICAL DEVICE PODCAST:
![medical_device_podcast]()
The Global Medical Device Podcast powered by Greenlight Guru is where today's brightest minds in the medical device industry go to get their most useful and actionable insider knowledge, direct from some of the world's leading medical device experts and companies.
Like this episode? Subscribe today on iTunes or Spotify.
