Below Christian Haller and Marcus Hadley of MPR Associates discuss successful product development processes. They note three main characteristics: 1) clear direction and leadership from the organization’s decision-makers, 2) dedicated design teams with ultimate responsibility for all technical decisions, and most importantly, 3) a process with the inherent goal of reducing risk and creating value during all phases of development.
Click below to hear full audio interview.
Brett Johnson: This is Brett Johnson in New York City with OneMed Radio. Today, we are with Marcus Hadley and Christian Haller with MPR Associates, an international design firm that spends a lot of their energies in the area of medical devices. They’ve been part of the series we’ve done, an expert series on accelerating the rate of bringing medical devices to the marketplace. They’ll be presenting at the OneMed Forum in San Francisco in January 10th and 11th. Thanks for joining us today, guys.
Christian Haller: How are you doing?
Marcus Hadley: Thanks.
BJ: So can you start off by telling us a little bit about sort of the important characteristics in terms of reducing a risk? On our last session, you talked about risk management and how one brings these devices to market efficiently. Can you tell us about sort of this risk, this concept of risk in all phases of development of a new device?
MH: Sure. The ideal product development process suggests that the highest risk item is inherent in the technology early in development. These activities are done while the total investment on the device is still low. By identifying a device’s greatest risk in the preliminary phases and engineering feasible solutions to solve these risks, there’s substantial evidence that support any business decision that exponentially increases the probability of success. While this process takes time, designing a device that incorporates these solutions early in development is significantly cheaper and more productive than attempting to incorporate these same solutions into a fully developed product. When effectively managed, technical risk is greater than the value.
BJ: So can you give us sort of examples of how this happens and, you know, kind of real life examples of this?
MH: Sure. There was one device that we are developing that included a pH probe that was extremely susceptible to noise. We had grounded and shielded the probes to the best of our ability without much success. In an attempt to further shield the probe from noise, we installed the probe into a synthetic shell within the device and the problem was solved. By installing the component into its final configuration, the component performed within specs that otherwise it would not have and allowed the development to continue. Had the component performed outside of specs, the development team would have been able to identify this as a high risk item and begin to mediate these issues.
CH: Yes. And, Brett, let me add on to that just a little bit because I think this is really important. You know, Marcus has mentioned a technical area of risk and the other way we look at it here is any unanswered question, any unmade decision is a form of risk and until it’s resolved, you know, it’s an outlier and you don’t know. So for example, the other kinds of risk you’ll see is in the marketplace, in the market assessment and so early on we try to bring in for example the marketing people to get a lot of market issues resolved. Because if you don’t design your product in order to be promoted, so how are you going to promote the product, if you don’t know that and then adjust the product accordingly to fit that promotion program, then you have a real problem. You may have to actually make real design changes to the hardware in order to support even a marketing program.
And I’ll give you an example. We worked on a product before to get to the specific, that it turns that originally it was anticipated, this is a surgical device that it was going to be used because its safety was much lower. So the fatality rate was dramatically lower than the existing products in the market and so the original promotion plan was to focus on it that way. But very early on, we tested that theory and we found that doctors, physicians didn’t care so much — I mean I hate to say but while lower fatality rate was fine, they had actually come to accept that. What they were really interested in this product is it allowed them to perform the same procedure in half the time and therefore half the amount of cost both to them and to the patient. That was a whole different way of looking at the thing. We tested it early, got that question answered, resolved early, and changed very much how the product was put together. So that’s just another example. It’s not just technical risk and technical design decision, it’s all decisions relating to the product which impact risk.
BJ: Yeah, you talked in our previous discussion about how to identify some of these early risk items or these high risk components of the process. What is your sense about how a designer figures out which is the high risk items and issues?
MH: So one way that we do identify those high risks is that both specifications of all requirements is needed and in fact when you use that TBD then rather than guessing at quantitative specifications, these TBD items are indicative of the need for development activities, develop a technical basis for those items. It’s also important to specify how these requirements to be tested as they are defined. This helps ensure that they will be in fact testable and then the project teams can use these product requirements specifications as a product management tool to gauge the impact of requested design changes later in development.
BJ: I got you. So how does a device with components designed on — I mean you talked about first principles, sort of some things you — can you talk about the whole notion of first principles?
MH: Absolutely. Simplifying a complex requirement was the first principle, allows creative solutions to be based on proven technology. Our first principle is the basic assumption that it cannot be deduced from any other assumptions. Developers have been able to translate user needs into product specifications earlier in development based on these first principles.
CH: Right. So for example, you know, if you have a complex technical like a system, you break it down into its individual components and then you can write performance requirements on the component, but then there’s sub elements. You know, for example in a pump, you have the bearings, you have an impeller, you have a motor, you have a housing and you can put performance specifications on those and model each one of those. So you break it down into its most fundamental pieces and you find out, you know, what the bearing loads have to be then you build that up and then you can turn into pump specifications.
Likewise again, you can do this in other non-technical areas. To come back to marketing, if you don’t know the value proposition as to why people want to buy it and how they make money with your products, those are the first principle issues that have to be addressed on that side. If you don’t know those as Marcus points, you end up with TBD or an unmade decision and all those do is they just push risk out into the future rather than resolving it now.
BJ: Okay. So does this create significant delay in the process of, you know, having to test these first principles out and how does this change the speed at which you bring new products to market?
MH: This goes back to the example I said with the pH probe. Our favorite saying around here is to do it like you’re going to do it as soon as you can do it. That’s to basically say implement the components into the device and test their performance based on requirements as soon as possible. Understanding the functionality of each component independent of the device is essential to designing a successful product, but ultimately the component will not operate independent of that product. Implementing these components earlier than is typically done in development and testing them against system requirements identify high risk items earlier and allow planning of required mitigating activities.
CH: Right, yeah, and it’s a good point because you might think, you know, that to do all this takes time. Another phrase we use is you’ve got to go slow to go fast. So in fact at the beginning of the project, you are going slower maybe than the norm, but once you have all this stuff resolved, all these different issues resolved then it does enable a process where you can now go very fast. As a consequence of that is that a typical class 2 or class 3 device around here that typically takes from project ideation through filing with the FDA between 6 and 18 months, which is, you know, for the industry relatively fast. So half of the project maybe solving these initial questions and when once that’s done, you can move out, what we call move out promptly.
BJ: Interesting. So can you talk just a little bit about the timeframe on these initial stages of development?
CH: Well, you know, we have four fundamental phases, which we use beginning with 0 and then, 1, 2, 3 of course and it’s this initial, this thinking phase if you will where most of the unknown questions get addressed is our phase 0 and that is where you do all the planning and you bring together all the different resources. So you have the technical people, the engineers, we have the industrial designers, you have the marketing people along with the regulatory folks and any IP people that you might need. What we do we call — go through it we call use cases. So this is where you actually imagine. It’s like a mental exercise where you do a vertical slice through the product use, how it’s going to be operated, how it’s going to be maintained, how it’s going to be sold, how it’s going to be disposed of, how it’s going to be manufactured and you answer all those questions. So that process does take probably, Marcus, what? Between a month for simple things to as much as, you know, maybe three months for very complex things to get things going.
Again, there’s no hardware in the lab at this point. There’s nothing going on in terms of on the workbench, it’s a lot of paper studies. But what that does do is now when you get to your rapid prototyping, your phase 1 that takes place over a period of between again one month to again maybe three months for hard things and then your detailed engineering. This is where it gets to be a snap because you’ve answered all those things now your detailed engineering phase, you’ve got that in flight throughout the whole project. You can get that done typically again in another three months because most of the questions the engineers run into that need to be answered and iterated on, you know, you’ve got that done. Again, maybe a very complex project with a disposable, a manufacturing line and a durable might take six months to get through it all, but it’s pretty fast. Because you’ve got the regulatory people in upfront and the marketing people, a lot of things that you might have to do is serial in one of these typical projects, they’ve all been done in parallel now so when you get to that endpoint where you’re filing with the FDA, you know, all your questions are answered to that point so.
BJ: So I was just going to sort of finish with if I’m adapting these principles into the development process as you’ve described them so how do I know that I finally got it right and that I’ve really optimized my development process?
MH: Well you never will be completely optimized. Successful process improvement is continuous and it cannot be limited in scope. The success of any one initiative must be constantly compared to the baseline data from the previous stage of development. When the initiative is successful, great, maintain that momentum and continue identifying areas needing improvement. But more importantly when the initiative is a failure, however capture any lessons learned from that experience and leverage that knowledge moving forward.
CH: Yes. So what we would say about here with our clients or with our own work is related to that is that once you’ve solved one area and you reduce that risk, there’s always something else — something is always the highest risk item. This is true with our clients and with ourselves, once we’ve taken care of one high risk area and kind of threaded that through the whole process so it’s in all of our best practices, well then now you go after the next one. Eventually, you know, once that’s resolves something else will still be the highest risk item and then we’ll go work in on that. So, you know, we think we’ve run most of the — year to year, you think you’ve got most of the juice that you can get out of it, but when you look ten years back, it’s shocking the amount of improvement we make when you look at it a longer period. I think that’s where you want to get to this continuous and incremental improvement year over year. Over time, you’re going to find that you’ll get startling results.
BJ: Right. Well that’s an interesting point because MPR has been around for some time now. Can you talk about a little of the background of MPR and how long you guys have been doing this?
CH: Well, you know, it’s an interesting story. The company was founded in 1964 so I guess that’s coming on — we’ll be 50 years in a couple of years, but yeah, about 47, 48 years now. The founders of the company were involved in a different kind of large product development program. They were developing the first nuclear submarine and that was done over a period of say three years, Greenfield. So at that point, in time back in ’40s, they developed some of these product development processes, which we still use today. And then, particularly they used this first principle technique, developed this first principles engineering technique and the reason they did it was not so much for efficiency, Brett, it was really a different reason and that is that they were developing a program, which is like the Apollo space program where a lot of lives were at risk. So they said, hey, the only way we’re going to make sure this goes right and not have much of fatalities during the development program is to really make sure that everything really works the first time. They did feel, they were inspired, they felt like they really were in race against well then the Soviet Union, now our allies, right. So they felt like, you know, speed was also the essence, but it had to work right the first time
So they developed these techniques in order to get that program moving and underway in as little time possible. In fact, the very first prototype ship, which was built stayed in service for over 40 some years. The Nautilus was actually retired I think about a decade ago so it stayed in service for many, many years of active duty service as a successful member of the fleet there, if you will. That’s the same process we use today, which is, you know, even now typically our first prototype actually ends up in a clinical setting and approved by the FDA.
So, you know, we went from submarines to a lot of those guys right out into the marketplace and so they went to the medical field, which is high technology and that actually got us involved in 1965 in the first artificial heart program. So, you know, through that and some pharmaceutical work, we’ve got people who approached us, it just grew into the business we have today.
BJ: Terrific. Well terrific. It sounds like you clearly have some great experience in this and we really appreciate your thoughts and for joining us today.
CH: All right. Thank you, Brett.
MH: Thank you.
BJ: Okay that is MH and CH with a medical device group at MPR Associates, which is an international design firm. They will actually be at the OneMed Forum in San Francisco running a workshop on techniques to accelerate the development of medical devices and bring them to market. Thanks again for joining us. This is BJ of OneMedRadio in New York.