Category Archives: Design Input Requirements

What Comes First: Design Input Requirements or Prototype?

Okay, this is kind of a trick question. Actually, what should come first the the unmet clinical need. But once you've identified the unmet clinical need, what do you do next? Do you define the product's design inputs? Or do you proceed to building some type of prototype? I've taken both approaches. And I've often wondered which is best--which is correct. I think I now know which approach makes the most sense. Build the prototype first. Why? A prototype is so much better at communicating than words can ever be. Put a prototype in the hands of end-users, and they can tell you everything that is right about it. More importantly, they can tell you everything that is wrong too. Capturing and documenting design input requirements becomes so much easier when end-users are able to conceptualize the...

Ideas vs. Execution

I came across this blog by Seth Levine in which he encourages usage of some of the same principles that we try to persuade you to instill with our Building The Business Case document. Mr. Levine states, “Ideas are great. But they’re not as valuable as most people make them out to be, and by correlation, execution is almost universally underrated and in hindsight taken for granted as a given once a company has become successful (and rarely given the credit it deserves).” I was especially interested when, in referring to what we consider market leaders, he states “Many weren’t the first or only ones to come up with the idea that made their company. What separated them from their competitors was their ability to out execute everyone else in a way that...

Simplifying Medical Device Design Controls

If you are like most medical device companies, the term "design control" is usually met with a cringe or two. I also suspect your product development process and design control deliverables might be more cumbersome and quirky than you'd like--especially since you are expected to complete your medical device product development efforts as quickly as possible. And what happens once the product development project is complete? Do you file the design control records away in a design history file (DHF) and archive them in some file cabinet or electronic record system? How easy are these to retrieve and access for future projects? Do other groups, such as regulatory affairs have access to DHFs in order to compile regulatory submissions such as 510(k)s and technical files? What if you had a software solution to document...

How Do You Explain Regulatory Compliance?

When I was writing the last blog post for Building a Business Case, I really struggled with how to emphasize the importance of understanding regulatory and certification requirements ahead of time so that you could design your product around any codes or standards you need to meet.  Afterwards, I came across “Designing for Regulatory Compliance”.  It really goes into detail on the subject and explains how essential this concept is. “Let’s start by understanding the goals of the regulatory processes. In general, they exist to ensure that safe and effective products are delivered into the market place with appropriate risk-benefit ratios. Every manufacturer, designer, regulatory professional, medical practitioner, and consumer has this as a common goal. However, if this is the case, why are there continually issues?  The issues...