![podcast_therese graff]()
On today’s episode of the Global Medical Device Podcast, Jon Speer and his guest Therese Graff talk about the importance of incorporating business elements into your medical device product development process.
When firms focus only on design controls, they may not experience the growth expected, which can lead to a surprisingly low bottom line.
Today we are discussing this situation with Therese Graff, a partner with Strategy 2 Market, which is a boutique consulting firm located in Chicago specializing in new product development.
Therese has an impressive background in project management and project consulting. She earned her Bachelor of Science at the University of Illinois and her MBA at the University of Chicago.
She’s currently a project management professional, certified with the Project Management Institute, and a new product development professional, certified by the Product Development Management Association.
Her career history includes working with complex instrument project management, working as a project consultant for design teams, and, most recently, working with a Fortune 200 medical device firm to streamline design control processes.
Listen Now:
Like this episode? Subscribe today on iTunes or Spotify.
Some highlights of this episode include:
-
Factors to keep in mind as you begin the product development process. These include questions about your overall marketing strategy, reimbursement, and the regulations and standards of other countries (if you plan to eventually launch outside of the USA).
-
How to determine whether a particular product or design will make economic sense before you begin investing time and money into the project.
-
Free or inexpensive resources for small businesses, entrepreneurs or new product developers who might not have a team of experts or unlimited funds.
-
A sensible approach toward building a business case, including design control, documentation and prototyping.
Additional Resources:
Strategy 2 Market
Therese Graff on LinkedIn
Google Patents
Memorable quote from this episode:
“Design control is just good engineering practices... engineering common sense... The business case... allows me to define whether it makes economic sense to build the product.” - Therese Graff
Transcription:
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 worlds leading medical device experts and companies.
Jon Speer: How many of you treat your product development process separately from your design control, process? Good question, something to consider. Should medical device product development include business elements or should it all be about satisfying the regulations? Today, on this episode of The Global Medical Device Podcast, I speak with Therese Graff. Therese is with Strategy 2 Market and Therese shares some thoughts and ideas about how to integrate business elements into medical device product development. So be sure to listen to this episode of The Global Medical Device Podcast.
Jon Speer: Hello, and welcome to another episode of The Global Medical Device Podcast as always, I'm your host, the founder and VP of Quality and Regulatory, at greenlight.guru, Jon Speer. Today I have with me Therese Graff. Let me tell you a little bit about Therese before we get started in today's session. Therese is a partner with Strategy 2 Market, a boutique consulting firm specializing in new product development processes. Their approach to helping their clients increase growth, and decrease complexity, integrates the elements of strategy and portfolio with the product development process, supported by the organization and culture, customer understanding, and the metrics to build a sustainable system. Therese has an extensive experience in IVD, In Vitro Diagnostics and single use medical devices. Her expertise includes streamlining the product development process, and integration with quality and design control systems. Therese began her career at Abbott Laboratories launching multiple diagnostic products.
Jon Speer: She transitioned from assay development to complex instrument project management, including hardware and software. Her work in Project Management Organization included project consulting with design teams across the division. After joining Hollister Therese managed the post launched product support group, followed by management of the phased and gated product development process. She also completed green belt projects to streamline internal processes for product development and product introductions to additional countries. Most recently, Therese worked for a Fortune 200 medical device firm, to streamline their design controls process and documentation. At a mid-size company she implemented PLAYBOOK, a web based a project management tool built across lean and agile techniques. Therese earned her Bachelor of Science from the University of Illinois Urbana-Champaign with concentrations in chemistry and biochemistry. And an MBA from the University of Chicago. Therese is a certified project management professional, by the Project Management Institute, and as a new product development professional from the product development management association. Therese!
Therese Graff: Hello.
Jon Speer: I am very excited to talk with you today as we got prepared for this conversation, and I learned a little bit about you. I knew we were gonna have a good time today.
Therese Graff: Hi Jon, I'm so excited to be here today, I'm looking forward to a great discussion.
Jon Speer: Alright, well, today I'd like to throw something at you. I'd like to talk a little bit why integrating business elements into your medical device product development is so important. Sound okay with you?
Therese Graff: Absolutely.
Jon Speer: Any opening thoughts on that topic before we dive into some details?
Therese Graff: Sure, Jon. When we work with medical device firms, we often find that they think only about design controls and the reality is to be successful and to deliver successful products to the marketplace. You need to also include a lot of business elements into your product development process. Design controls are just one element of the entire process. And so what I hope to cover today is to help people gain an appreciation of what some of those other business elements are and why they are so important to your product development process.
Jon Speer: Okay. Alright, I'll tell you a little bit about a story from, I guess, long ago in my career, where I can remember having a lot of people from a bigger med device company all in the same room and we were talking about, or kinda debating, or maybe arguing about design controls versus business processes, and we needed to stay focused on design controls and don't worry about those business processes, it's not any of the FDAs business anyway. Do you have any thoughts about that?
Therese Graff: Well, you are correct that the FDA doesn't need to get into the business processes, but if all you focus on are your design controls how do you make sure that as a company, you're delivering a product that the customer actually cares about and that they want to purchase?
Jon Speer: Yeah, I'm with you. I'm not saying I ascribe to a complete and separate delineation between design controls and business processes, because if you think about design control the whole purpose of that... It really starts with user needs.
Therese Graff: Exactly.
Jon Speer: Right, and if your user needs really do align, with the customer and the patient then there's some business elements to that, right?
Therese Graff: Yes, of course, there are. And from a design control perspective with design validation, you still have to look at what are those customer needs and have you delivered them.
Jon Speer: Right, right. So you've been doing this for some time, you've got quite the impressive background when it comes to product development process, as a project management, and you've got all the certifications that go along with it, so I'm guessing that people call you for... They say, "Therese, I'm really struggling here, I need some help." What is the most common mistake or issue that you're brought in to help alleviate?
Therese Graff: The most common issue is that the company is not getting the growth out of the business that they expected, so they've spent all this time and energy to develop products, yet they're not seeing the gain in their bottom line or in their sales numbers, which as we all know that's what pays our salaries. So we have to look at what are the other pieces around what they're doing in their product development system, to make sure that they're getting the results they actually want. So we look at things like what is their strategy, how does their product selection, their portfolios, how does that fit within the strategy that they've defined for the organization, how can we streamline their product development process, and what are some of the elements that go into that to make sure that they are as effective as possible?
Jon Speer: Right? So when you talk about strategy, I can imagine there's a lot of facets or parts to that strategy that you're evaluating. I often gravitate or lean towards things like regulatory perspective, so I'm sure that's one factor, but what are some of the other key factors? Obviously market need, it seems like if customers are calling you because their business strategy, well, need some help then what is it that they're missing what are the key points that they're missing?
Therese Graff: Well, some of the points, they're often missing are what are the market segments they want to play in, have they defined products, that makes sense for that market segment, are they primarily working on me too products, or are they striving for innovation, and then if they're striving for something very innovative, are they building into that plan? The additional time elements that are required, where regulatory perspective may switch you say from a 510 [K] up to a PMA or you need additional documentation to make it work. But the other piece is, am I looking at changing the reimbursement on my product, what kinds of evidence do I need in order to support the additional reimbursement that I would like to get. And if all you focus on is design controls then you may never ask that question.
Jon Speer: Right. And at the same time I look at that design control being key. But you're right about the reimbursement, if nobody is going to pay for my product at the end of the day, that's... What's the point, right? If nobody's gonna use it, nobody's gonna pay for it. I'm guessing those are the strategy elements that companies... Seems very obvious, but I'm guessing a lot of companies miss the mark.
Therese Graff: They do miss the mark. Some of the other things they forget to look at is they'll only look at say the requirements for launch in the United States, yet they still plan to launch outside the US and they don't necessarily look at the additional either registration requirements, labeling requirements, even standards that might be applicable in those other countries and those then influence your product requirements or design inputs.
Jon Speer: Right. It certainly is very important to look at the global picture, for sure. That's one of the things that when companies contact me and want to understand how their product is gonna be classified from a regulatory perspective, often times they're looking at US market first, but sometimes there are better opportunities outside the US, but it is definitely, you have to take a holistic point of view. So let's talk a little bit about the design control kind of being part of, but not all of the entire product development process. I know today we are an audio program and there's no visual component but I always looked at... At a Venn diagram and the big circle is the product development process and design control is a little circle fitting entirely within that product development process, but there's a lot of other parts and pieces of that, right?
Therese Graff: Oh, absolutely. Other things you need to consider are things like what markets are you going into? Again, countries of launch, what kind of forecast do you need? How do I get my production group up and running and so that they can reproducibly make my product? Reimbursement, product cost targets, what kinds of margins, so a lot of those business elements that you need, maybe your market timing requirements, how about things like legal requirements, contracts, patents, freedom to operate, all of those are different kinds of elements that go into that whole product development process.
Jon Speer: Let's talk about the business needs and elements from a couple of different perspectives. It's all of that list that you just shared a very complete list. Of course, there are many more elements that one needs to consider as part of product development, but all of those things, if I'm a big company that has all of these different resources at my disposal, it's very easy from, or easier, I should say, for me to address all of those different parts. But let's imagine for a moment that I'm this startup and I'm a technical person, and I have an idea for our technology and I've never developed a medical device before, let alone run a business. What are some key tips and pointers that you can provide to the person that might be in that situation?
Therese Graff: The first thing to do would be to understand who your customer is, what their needs are, and whether you have a viable business opportunity. There are a number of tools out there such as the business canvas or even things like a traditional business case. Think of how you would pitch your product to a venture capitalist thinking about, why would they want to invest in this product and why would somebody actually want to buy my product, if then you need to start looking at how can I get more information very quickly in terms of, is this the right product, is somebody willing to buy it? And at that point you're starting to make early prototypes. I generally don't start design controls quite yet because I'm still really trying to understand whether I have a market and a product that somebody might use, I tend to look at bringing in my even an early legal team to start looking at, if this is... Are there other products out there, which I might have a problem with. A high level search, even Google Patents provides an easy way for people to go in and look and try to understand what's out there and whether they might have a problem.
Jon Speer: Right, right.
Therese Graff: So, I start with the design elements and the business case, which allows me to define whether it makes economic sense to build this product.
Jon Speer: Sure, so let's explore that a little bit. So let's talk about building a business case if you will. Building a business case, I think you hit on a lot of key things, keeping in mind that if I'm a startup, I may have limited funds. I think you hit on a couple of really important things that if I have some resources that I can tap into from a legal perspective, certainly, that might make good sense, but also realizing sometimes that could be a little expensive. The Internet today is so crazy what you can find and you just mentioned Google Patents, that tool alone is a bit of a game changer especially for that startup that has very limited capital, but knowing what is out there is so important, knowing how that product is going to be classified is so important and there's a lot of due diligence that entrepreneur that small company with limited funds can do for little or no cost. I think that's very, very key. But you keep hitting on it, and let's keep hammering it, there has to be a need that has to be addressed. If I'm trying to solve a problem that really doesn't need a solution then it's really gonna be hard for this technology or this idea that I have to ever make it from a business standpoint.
Therese Graff: Absolutely. And that's why it's so important to understand those customer needs. Without that, what's the point in doing the product?
Jon Speer: Yeah, so let's talk about... You mentioned something about prototyping and you also talked about when design controls begin, so let's explore, or dive into those two areas just a little bit more, 'cause that's a common thing that I hear often, I talk to medical device companies, all day every day and there's always confusion, well, sometimes there's confusion about what design controls even are. There's a perception, there's conventional wisdom that suggests that design controls are painful and overly burdensome and just a real pain and we try to dispel that conventional wisdom all day every day. That's one of the reasons why we developed greenlight.guru is to make that design control process smooth, and easy, as it can possibly be, but let's talk about that a little bit, 'cause there is a conception that design control needs now it's rigorous, it's structured, it's heavily documented, it's overly burdensome. Let's talk about that a little bit.
Therese Graff: Okay, so first of all, I consider design control's just good engineering practices. You wanna understand what your customer and product requirements are. Okay, before you ever start developing something, that's common sense, really. Then you start developing your stuff and you record what you're actually doing, and then you test it to see did you develop what you said you were going to. So, like I said, I consider that engineering common sense. The biggest difference in some people's minds is, "Do I have to document it, or I'm just waving my magic wand and, sure I tested it, that's all there is. I don't need to go back and document it." And the reality is, it's better for you as a product developer, to document what you've done. One, the FDA expects it, and so does your international regulatory body, but it also allows you to go back and understand what you've done, how you've done it. What did I learn? How could I make a case for, "This isn't quite working the way I expected. Well, how did I get where I am today?"
Therese Graff: If you have to go back and make changes to the product, it's a whole lot easier if you have all that information documented. I've been on the post launch support side, and for products that have been in the market for a long time, a lot of that documentation is hard to find, or in some cases doesn't exist because those products were developed before design controls went into place, and the amount of work that my team has had to do to recreate information has been extraordinary, because we haven't had that data behind us.
Jon Speer: Right. Yeah, I too have been brought in from time to time to do retrospective design control activities and I guess it's better to at least take that challenge on and establish some semblance of a design history file, even if it's after the fact. But you and I both agree that the best practice is to do it from the very beginning and capture that learning as you go. So let's talk a little bit about this, you mentioned prototyping and I know that term has a lot of different connotations, and can mean a lot of different things depending on where you are and, really, what you hope to accomplish through those prototypes. There are proof of concept prototypes and things that you would do earlier on to basically try to capture and establish and communicate what problem you're trying to solve, and then you get to much later when you get into functional prototypes, and you get to pilot production, and all those sorts of things. So let's talk about some of those earlier prototypes and how those can be used to help build that business case.
Therese Graff: Okay, to build the business case you obviously need to truly understand the customer needs and I have used a lot of prototypes and these can be very simple mockups that give people an idea of where you're going or what you're trying to accomplish. They are in no way really the final product, but they give you something tangible maybe to show a focus group, or a physician, or a potential user, "Hey, here's what I'm thinking, what do you think? Am I going in the right direction? Am I not going in the right direction?" I also use them very often, for early technical feasibility still prior to design controls just because I don't even know if I have a technology that works or I'm trying to evaluate maybe two, three, four different potential solutions to an idea, or to a problem and I need some help figuring out, will this even work before I start spending all the time and effort to pull in a lot of other functions in the organization?
Jon Speer: Right, right. Well, I think that's very helpful and makes a lot of sense. So Therese, we're getting towards the end of our podcast today, and I want you... Obviously, we all know what design controls are and if not, as you've clearly articulated, it's certainly something that is expected not only from the FDA but any other regulatory body pretty much in the medical device world is going to expect that you document design controls and design and development activities and that's pretty well defined as to what that might be, but I think there might be some, little less clarity, let's say on what would be expected or what would be recommended as best practices from the overall product development process. And one more short story, I used to work for this company and I worked as an engineer, a product development engineer and the company, basically made the determination that engineering was synonymous with product development. And I'm sure you can see a lot of mistakes... Yeah, you're laughing. I'm sure you...
Therese Graff: Yeah, I've seen that happen.
Jon Speer: Yeah. And so obviously there's some problems with that, and I'm sure you can highlight a few of what those problems are. What are your thoughts about engineering and product development being used as synonyms?
Therese Graff: Well, I think it's a bad idea.
Jon Speer: Come on, I was a good engineer, right?
Therese Graff: But product development is more than just the engineers that do the work. It is a cross functional effort. You obviously need marketing to help you define what your market is. They should understand what your customer needs are, they are also your interface into your countries and your forecast, your business requirements for the product. I also make quality a partner in my projects because ultimately they're the ones that help me make sure that things are, I'll say ticked and tied so that my product can launch successfully. I pull in somebody from operations or global engineering, whatever your company calls that person so that I can get early input into my processes, maybe some potential ways to design the product in a way that makes it easier and safer to assemble so that all of those groups have a say, because the reality is, it starts with an idea from the market side, but manufacturing ultimately has to be able to make the product and deliver it. I pull in regulatory and it really depends on the organization.
Therese Graff: Some organizations regulatory really wants to be part of the core product team and I've seen other organizations where regulatory has said, "I need to tell you what the strategy is, and then I'll handle your filings, but unless there's something specific I choose not to be involved in all the other product decisions," and that's fine, it's just whatever works best for your company, but you need to include them, plus whoever else is important in your entire product development organization.
Jon Speer: Okay, so to reassess as we start to wrap up, we know what design control deliverables need to be, but let's talk about some of those other product development deliverables. We've kinda... We've talked a lot about the importance of that user and the market and the business aspects, but can you provide some guidance or direction or advice to our listeners on some other deliverables or work products or documents or however you wanna kind of view this? What are other key things that I should be capturing as part of my product development process? What are those deliverables and what do they look like?
Therese Graff: Okay, first and foremost, I would include a business case of some kind, something that demonstrates why this product should be invested in by the company. But also looks at the project from a technology standpoint and manufacturing standpoint, the regulatory standpoint, so all those elements as a complete package to justify why the project makes sense.
Jon Speer: Okay.
Therese Graff: The second thing I would insist on is a project risk file, so separate from your risk management file, which you need to show safety for the customer and the user. I'm talking about something that helps you understand what are the risks of developing this project, and the product?
Jon Speer: Okay.
Therese Graff: And that often also looks at some of those same elements but also may include what's my supplier availability, what are the risks around that, maybe what are some of my shipping risks, what are technical risks? All those different pieces that aren't necessarily captured in a risk management file.
Jon Speer: Okay.
Therese Graff: Okay? The other big piece that I tend to look at is my forecast and my financial analysis. So sometimes people put that in their business case, sometimes people pull that out as a separate piece, but how does your company decide to fund products and what are the financial hurdles you might need to meet, what is the payback period you're looking for, how is this going to be integrated into my factories, am I going to have it made by somebody else, do I have to develop all of my own manufacturing locations, things like that. So those are all those additional elements that I always ask for.
Jon Speer: Okay, I think that's excellent advice, excellent recommendations. And I think with all of those parts and pieces that you just described, those other elements that I should be capturing and documenting those are not set in stone things. Those are things that you revisit throughout the product development process, and keep up to date and current because things change as you go through the product development process.
Therese Graff: Absolutely, just like when you develop a product, your product requirements may change over time, as you gain more information. Same thing with these different business elements that you need to revisit them periodically, update them, and also be willing to kill the project if it no longer makes sense.
Jon Speer: Right, right. Well, Therese, thank you for being our guest on today's episode of The Global Medical Device Podcast. For those of you listening who wants to learn more about Therese Graff and Strategy 2 Market, you can find more about her and her company at strategy number two market dot com. Therese, you can spell... Her name is spelled THERESE, last name Graff, GRAFF. You can find her on LinkedIn. Therese, any other ways that you want people to reach out to you?
Therese Graff: No, I think that will be fine. And we certainly have contact information on our website, please feel free to contact us if you have any questions.
Jon Speer: Great, I appreciate you being our guest. Once again, this is Jon Speer, the founder and VP of Quality and Regulatory at greenlight.guru. Greenlight.guru has developed a software solution to help you manage your design control, which as we've talked about today is important part of your product development process, not the only, but definitely an important part of your product development process. We also capture, allow you to capture your risk management, product risk management details, to demonstrate that your product is safe. So, please reach out to us at greenlight.guru, request a demo, learn more information about our product, and again, thanks to Therese Graff from Strategy 2 Market. This has been Jon Speer, and you have been listening to The Global Medical Device Podcast.
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.
