MPR Associates, a design and development engineering firm, will host a workshop at OneMedForum SF 2012 focusing on product development. Below, Christian Haller, VP of Product Development, and Eric Claude, General Manager of Product Development discuss the process of “going slow in order to go fast.”
Click below to hear audio and see following full interview transcript.
Brett Johnson: Welcome, I’m Brett Johnson with OneMedRadio. Today, we are interviewing Christian Haller and Eric Claude from the medical device group, MPR Associates, an international product design development engineering firm. Today’s interview is part of a series on compressing product development in the medical devices field. Today, we’re talking about organization and how structure of the design group impacts speed and efficiency by which products can be developed and brought to market. Christian, let’s start with you. Can you tell us about some of the traditional problems that the traditional approaches have in product design?
Christian Haller: Sure. That’s where one of my passions is and what we see is there are typically three things that people tend to either fail to appreciate their importance or don’t do it in sufficient detail. The first one is to recognize that the really good products come from three areas. One is of course the technical content. You know, this is what you might call the guts of the machine or the core technology of the inventor of the company and most people do a pretty good job at that, but then they fail to recognize the other two pieces.
The second cornerstone of really effective products are the business model. So that’s the business model, not just the guy who’s making it, but it’s also the business case for the guy who’s buying it. So you need to understand who the guy who’s going to buy it and how he’ll make money with it and likewise from the business side, how are the people in your company going to promote it. And so there’s the interaction between the design of the device and designing features in so it can be promoted effectively so those two interact.
And then the third thing and, you know, this is where the Apples of the world are, understanding the industrial design in the entire user experience. And the user experience has a tremendous impact on the quality of the devices as perceived by the user, therefore, their desire to go buy it. But it also has a lot of interplay with the other two aspects and so you have to factor all those in together because they’re interactive. So the big mistake number one is people treat those as serial objective. You define the business then you do the technical content then you do a nice package around it and that is what drives you into a big iterative process as new things come up and it drives you to cycle back and forth and that makes it very expensive and very long. So failure to recognize those three things interacts at a much more evolved way than most people may perceive. So that’s number one.
The second thing is not coming up with a program for risk management. You know, every product development process some of the major phases are pretty common across most places. But if you really want to get it done effectively and get it done right is to really spend a lot of time making sure you understand what are going to be the major decision points, what are your options likely to be based on a lot of experience, and what’s your backup plan to each one of those if it doesn’t go the way you think and what’s your backup to the backup plan. And those three things are what’s going to — when you run into a problem, you’re going to get to the other side of that problem very quickly without causing a big delay across all the entire program. You’re just burning money during those time periods, you’re losing your market window. So that’s traditional problem number two that we see over and over again is not being ready for the inevitable things that are going to creep into it.
And then the third thing that Eric and I, you know, we see all the time is that we use a process where we go through a lot of use cases, which is a deep vertical slice about how the product is going to be used, how it’s going to be sold, how it’s going to be bought, how it’s going to manufactured. And so it’s thinking through all those details upfront before you do anything to the product. And what you’ll find is that if you go through those mental exercises and paper exercises then go through these cases, you reveal, you unveil a lot of latent problems with the design concept, the promotion plan, how it’s going to be used or how people want to use the product. So you want to go to a lot of detail in these use cases upfront, which can seem nerve-wracking especially to investors, because they just want to get on with it. But if you do this upfront and you answer most of these questions, you can virtually I wouldn’t say eliminate but dramatically reduce any need to recycle. So you break the iterative model and you switch to a more of a once through mode of product development. Those are the three things that we see over and over again, Brett.
Brett Johnson: Is it because people organize along departments and through silos as you’re developing? Can you talk a little bit about the structural issues of setting up problems with the departmental approach or an integrated approach?
Eric Claude: Sure, so particularly in larger firms that tends to be how they’re organized internally. And it sort of is easy from the standpoint of putting a label on the kind of people that you need but that creates inefficiencies when work flows across boundaries and sort of forcing all the work to flow inside departmental boundaries just creates more handoffs. So the alternative is to avoid that departmental structure and what you really need is an interdisciplinary approach to product development not just on the technical side but getting at some of the issues that Christian mentioned in relation to design and understanding the business plan for the product and the customer.
Christian Haller: Right. And let me add just a little bit to that. We call that approach project centric. What that means is that all the resources to the job are assigned to and report up to the project manager for the project and that means everybody in the project is if you will in the same life raft and they have a common fate. And so that really does change the dynamic.
If you go back to that departmental model, the resources really are, you know, they’re contributing to the project, but they actually report to the boss of the department. And all those bosses have different agendas and different goals and so you have a lot of incongruencies between what the project manager is trying to accomplish getting this product out of the door and the goals and objectives of the individual departments, which aren’t aligned and now you’ve got a problem. And that’s what we see over and over again particularly in a larger company.
Brett Johnson: And so how do you guys get around them? Can you give an example of how you guys do that?
Eric Claude: Sure. So two aspects: One is in relation to how people are trained. You really need to have folks that are cross trained and able to be agile, work on different parts of the project. So for example, if have mechanical engineers when a design iteration is done, they’ve got to be able to jump on some other piece of work. So whether that’s working on usability studies or risk analyses. Having people that are flexible and agile lets you be more effective and efficient in how jobs are staffed, how projects are staffed, and how resources are used so that there are fewer starts and stops and handoffs between individuals.
But then managing that kind of a structure is a little bit of a difference challenge. Christian talked about the project-centric structure of the organization, which is critical. Supporting that, what you have is a “center of excellence” structure, which is secondary to the project organization but led by individuals who have high levels of technical competence in those center of excellence skill sets. And they’re responsible for the continued development and improvement of individuals to really drive that cross training expertise that you need.
Brett Johnson: Can you talk a little about sort of a typical medical device development project, how many people would be involved in something like that.
Eric Claude: Sure. Well typically, in a lot of companies, you’re talking about anywhere from 10 to 20 people, maybe more, for a typical development project. Where we’ve seen this multidisciplinary approach work effectively, you can get that work done with as few as 6 or 8 or 10 people. So it really makes a significance difference in resourcing of these kinds of activities.
Brett Johnson: So is your experience that the fewer people you have involved sort of the more efficient and how fast it goes?
Eric Claude: Yes, it is because the workload is more leveled over time among a smaller group of people rather than being parceled out to a larger group where, you know, their activity goes for a certain duration that’s not the entire project then they’re done they hand off to somebody else. So the larger team size creates more starts and stops and more handoffs.
Christian Haller: And I think there’s one other piece of that which is that Eric has mentioned this multidisciplinary approach and it really is important. For example, the project engineers have vocabulary in the business aspects of new products and industrial design and other things. So that the way you gain big efficiencies, everyone’s not struggling with their own if you will technical or skill based agenda. They understand, they’re fluent in where the other guy is coming from and what his objectives are so you really can eliminate a lot of time and effort and therefore people time required to just get your day-to-day communications done.
Brett Johnson: So if you had an idea for a medical device and you had some experience, now you had to go find some organization or someone to help you do it, what would be the key things you would look for if you’re interviewing a design engineering consulting kind of organization?
Christian Haller: That’s a really good question because this comes up all the time. And, you know, there’s a handful of things that I would point out. First of all, I really do want a company that’s been around a while. You know, there’s a lot of cases out there where people who have — you know and I mean by being around a while not just being in the industry for a long time, but being in the business of providing product design and engineering as a service. Because it’s one thing to do it within an organization as say part of a large company. It’s a very different thing to provide it as a service to somebody else. So you want people who have been providing this as a service, a minimum of 15, 20 years because they’ve got the mistakes through good times and bad so they’ve learned from those hopefully.
The second thing is you want people that are really dedicated to this. Where a lot of guys get into trouble is their, you know, product design is a secondary thing for the company they’ve hired. And one of the greatest examples of this is in the area of a lot contract manufacturers also offer product design and it’s very compelling sometimes from a cross basis. So you look at it there, what you can do is most of the contract manufacturers is they will allow you to take the cost of development and deal with that in the backend of the deal and amortize it over the production run. Well the problem is, is that the guy who gets the design upfront, you know, the company doesn’t get paid the money upfront. They’re paying themselves through the backend through the bill and so, you know, you may have committed a million dollars to the product development, but the guy’s budget inevitably in that situation is far, far less than that. So he’s always being forced in the direction of the cutting cost now so that they get it in production so they can get paid as a example.
Secondly, what we see a lot of times is you’ve got to get a company that’s large enough that they really can handle your job. So you know, you talk about a job that as Eric mentioned takes 10, 12 people. If you’ve only got 20 people in your organization, you just cannot have the breadth of experience and different technical capabilities to really cover most projects. Likewise when the company has half their company committed to a single job, that makes you, the buyer, and them, the seller of services, both in very vulnerable situations, which doesn’t give you much room to maneuver.
For example, so if you’re in that situation and the project gets delayed for three weeks, the guy that’s providing that service has got to reassign his people right away or he’s going to go out of business. And if you, as the buyer, has a blip come out on your where all of a sudden you need extra resources to support a change in your clinical trial schedule, those guys typically with small staff typically don’t have the bandwidth if you will to pile on and help you out.
Eric those are the two that I’ve worked with. What are some others that you’ve seen?
Eric Claude: Sure. A couple of other things. I think you mentioned experience, I think not just experience in the business, but looking for firms that have a team that has a significant amount of experience working together. Because it really is the effectiveness of a team organization that reduces a lot of inefficiency in the challenges that happen in various hand offs. I also think that it’s important to look for a partner that has a well defined development process. A lot of firms, you know, will say I have a process, but that has milestones with clearly defined deliverables that are aligned with the their customer’s business and the value creation points in the customer’s business. So that as the development process goes forward, the customer has a clear understanding of the end result in each phase of development and how each phase is going to add value to their business.
Brett Johnson: I see. So if you were just to give someone sort of a tip sheet or I guess an understanding, like what is the typical process when someone comes to you with an idea? Can you take us through the steps? I mean I assume you do it an evaluation and there’s a back and forth. I mean what does it look like this whole process of getting started in a design project?
Eric Claude: Sure, good question. I think there is obviously an initial period of information exchange and coming to a common understanding of what the goals are. Most importantly, the goals in terms of what the product needs to be to satisfy the market needs. So it’s, you know, the old saying of begin with the end in mind. If you can’t get to a point of having a common understanding of the end, then you’re not ready to start.
Brett Johnson: And how long does that typically take to kind of come to a common agreement on something like that?
Eric Claude: Typically, it depends on how well prepared a customer is. But if a customer has their facts together then we typically converge on a common understanding of the endpoint within a couple of weeks and then a detailed plan can be mapped out for subsequent phases of the product development process.
Brett Johnson: I see. And then what’s the nature of how long these kinds of things take typically and what are the key milestones?
Christian Haller: Well, let me talk about the duration first and I think Eric probably can talk about some of the key milestones and add to it. But, you know, kind of in his industry, it’s interesting because there’s a broad span of types of products which are out there from simple little nonmovable highly technical pieces of plastic with no moving parts and they’re in their package to very complex pieces of machinery with fluidic systems and everything else. And so it’s difficult to say here’s a benchmark that everybody meets. But if I was to tell you that in an industry, typically it’s three to maybe seven years depending on what it is with some imaging and tends to be on the high end and simple surgical stuff tends to be on the low end in our experience. The process we’re using right now we’ve done class 3 devices in as little as I think six months.
Eric Claude: Yeah.
Christian Haller: And we’ve done a typical like a big multi-physics unit like a liposuction system or, you know, flood analyzer or something like that could take I don’t know between 10 and 14 months using some of the efficiencies we’ve described here.
Brett Johnson: So you are talking about a pretty significant decrease in amount of time needed using this integrated team approach?
Christian Haller: Well right, you’re right. And it’s really the only way because when you start out, you know, you’re aiming for a specific market and that market has a window because of the reimbursement issues, the regulatory issues and the market needs. And if you take too long, we see those often, you know, by the time that you get done, the window has changed, the target has moved and now you’re forced to iterate together or fold up your tent and go home. And so going fast it’s not just because you get to market sooner so you get revenue sooner, but you’re really — you know, these days in particular, big concerns about hitting your window. Now regarding the major milestones, Eric maybe you can talk about where you hit some of these key things.
Eric Claude: Sure. So the way we approach the process is to first spend typically six, eight, ten weeks, somewhere in that range on product definition process and that is what we call going slow to go fast. It is really putting the level of detail around the endpoint that you need to know in order to move at these speeds that we go. So there’s a lot to it. It’s not just product specifications, it’s understanding the business case, as Christian described earlier, what the customer’s needs are from a business standpoint as well as the end users. It’s understanding the use case, the usability issues, human factors issues that maybe involved. It’s starting a risk management process. So all of those things have to be addressed in this initial phase of effort to really define what the product is going to be and how the rest of the process is going to roll out. So as I said, that product definition phase typically lasts six to twelve weeks. What you come out of that with is a clear understanding of the end product that you’re looking to develop and an understanding of what the challenge is from a design and technical standpoint are going to be.
Then the next phase of work is focused on addressing those individual challenges. So you might call it the proof of concept phase. That can be anywhere from three to say six months. That’s really the heavy-duty engineering to solve the technical problems and in parallel with that, the industrial design to solve the user experience challenges.
Next coming out of that phase at that milestone, now basically you have confidence that you’ve solved the challenges. You know how to create the user experience, look and feel that you want, you know how you’re going to solve the technical problems so the third phase of work is really the integration of all those pieces. A lot of heavy-duty engineering through that. This is where prototypes are being fabricated, alpha and beta prototypes that really represent what the actual finished product is going to look like. That all comes together typically six to eight months with a number of, you call them, “looks-like” and “works-like” prototypes that the client can use for usability studies, clinical trials, verification testing. Such that at that point, now, you know, typically a year to a year and half in, you’ve got all the data that you need to submit say a 510K for FDA clearance.
Then the final phase of the development process is while the FDA review process is going, you start working on the transfer into manufacturing and the production scale up.
Brett Johnson: Interesting. Well it seems like certainly bringing a medical device to market is a rather complicated or not an easy project at all, but it sounds also that with a lot of energy is spent in the front end and the planning process, you can really make it happen more quickly. And I think particularly the notion of going slow to go fast I think is very instructive. Thanks so much for sharing your thoughts and ideas here on the product development today with us, gentlemen.
Eric Claude: You’re welcome. It’s been our pleasure.
Brett Johnson: That is Christian Haller and Eric Claude from the medical device group MPR Associates, which is a design development firm focused on the medical device space. Thanks for joining us. This is Brett Johnson of OneMed Radio.