Regulatory Open Forum

​In other recent discussions in this Forum, members have inquired about the relationship between user needs and design inputs. I offer an introductory icebreaker herein.  Like other Forum members, I'd be very interested in hearing others' related thoughts, experiences, and suggestions.


The ultimate goal of the design and development process is to realize a medical device design that meets user needs and intended uses. As I note in my prior related Forum commentaries, proper construction of design inputs is an imperative step in this process.  But how do design inputs get properly developed?  Edwin Bills and Rem Siekmann are spot-on in directing this question toward understanding user needs.


Though maybe not immediately obvious upon first review, FDA in its 1997 design control guidance document provides a nice bridge between user needs and design inputs. It hinges on the notion of product "concept". In a nutshell, many firms will generate something often called a "Customer Requirements Document", "Product Requirements Document", or the like.  Similarly, I've adopted the practice of developing a document I call a "Product Concept Document (PCD)".  An overview is given below.


The marketing staff oftentimes holds the most organic understanding of customer and user needs. But the need for a new or revised product might arise from other sources such as scientific literature, general research, the manufacturing staff, or experience from prior device variants.  If pondering the feasibility of a particular product idea, then such intelligence should be memorialized and assessed prior to formal initiation of the regulated design & development process.  This should be done via a PCD championed by the "idea-initiator" to capture the targeted conceptual characteristics and basis for design of the product.


FDA's notion of "concept" as well as other principles for creation of a PCD are provided below:

• Product Concept Documents may not be technically comprehensive and should not be expected to be so.
• The use of general and qualitative terms in the PCD is both appropriate and practical.
• The PCD identifies the user needs / customer requirements, which will often be stewarded by the marketing staff based on various methods and sources such as, but not limited to, Voice of the Customer (VOC), personal conversation with customers, focus groups, surveys or questionnaires, literature review, "show and tell" sessions with customers, previous experience/precedents, direct observation of customers in the clinical work environment, lectures, presentations, etc.
• As Edwin Bills points out, there can be multiple types of "user" or "customer", so be sure the needs of all potential stakeholders (internally and externally) are considered.
• The user needs / customer requirements should be ranked, at the very least as "Essential" vs. "Nice to Have".
• The PCD is a preliminary starting point for development, but is not to be confused with design inputs, which are derived later in due course by elaborating, expanding, quantifying, and transforming the PCD into a complete set of design input requirements written in measurable terms to an engineering level of detail.
• Upon completion of the PCD, formal feasibility assessments may be performed using techniques such as Proof of Concept, rapid prototyping, preliminary hazard analysis, etc., in order to justify the feasibility of the proposed concept.

​In other recent discussions in this Forum, members have inquired about the relationship between user needs and design inputs. I offer an introductory icebreaker herein.  Like other Forum members, I'd be very interested in hearing others' related thoughts, experiences, and suggestions.


The ultimate goal of the design and development process is to realize a medical device design that meets user needs and intended uses. As I note in my prior related Forum commentaries, proper construction of design inputs is an imperative step in this process.  But how do design inputs get properly developed?  Edwin Bills and Rem Siekmann are spot-on in directing this question toward understanding user needs.


Though maybe not immediately obvious upon first review, FDA in its 1997 design control guidance document provides a nice bridge between user needs and design inputs. It hinges on the notion of product "concept". In a nutshell, many firms will generate something often called a "Customer Requirements Document", "Product Requirements Document", or the like.  Similarly, I've adopted the practice of developing a document I call a "Product Concept Document (PCD)".  An overview is given below.


The marketing staff oftentimes holds the most organic understanding of customer and user needs. But the need for a new or revised product might arise from other sources such as scientific literature, general research, the manufacturing staff, or experience from prior device variants.  If pondering the feasibility of a particular product idea, then such intelligence should be memorialized and assessed prior to formal initiation of the regulated design & development process.  This should be done via a PCD championed by the "idea-initiator" to capture the targeted conceptual characteristics and basis for design of the product.


FDA's notion of "concept" as well as other principles for creation of a PCD are provided below:

• Product Concept Documents may not be technically comprehensive and should not be expected to be so.
• The use of general and qualitative terms in the PCD is both appropriate and practical.
• The PCD identifies the user needs / customer requirements, which will often be stewarded by the marketing staff based on various methods and sources such as, but not limited to, Voice of the Customer (VOC), personal conversation with customers, focus groups, surveys or questionnaires, literature review, "show and tell" sessions with customers, previous experience/precedents, direct observation of customers in the clinical work environment, lectures, presentations, etc.
• As Edwin Bills points out, there can be multiple types of "user" or "customer", so be sure the needs of all potential stakeholders (internally and externally) are considered.
• The user needs / customer requirements should be ranked, at the very least as "Essential" vs. "Nice to Have".
• The PCD is a preliminary starting point for development, but is not to be confused with design inputs, which are derived later in due course by elaborating, expanding, quantifying, and transforming the PCD into a complete set of design input requirements written in measurable terms to an engineering level of detail.
• Upon completion of the PCD, formal feasibility assessments may be performed using techniques such as Proof of Concept, rapid prototyping, preliminary hazard analysis, etc., in order to justify the feasibility of the proposed concept.

​In other recent discussions in this Forum, members have inquired about the relationship between user needs and design inputs. I offer an introductory icebreaker herein.  Like other Forum members, I'd be very interested in hearing others' related thoughts, experiences, and suggestions.


The ultimate goal of the design and development process is to realize a medical device design that meets user needs and intended uses. As I note in my prior related Forum commentaries, proper construction of design inputs is an imperative step in this process.  But how do design inputs get properly developed?  Edwin Bills and Rem Siekmann are spot-on in directing this question toward understanding user needs.


Though maybe not immediately obvious upon first review, FDA in its 1997 design control guidance document provides a nice bridge between user needs and design inputs. It hinges on the notion of product "concept". In a nutshell, many firms will generate something often called a "Customer Requirements Document", "Product Requirements Document", or the like.  Similarly, I've adopted the practice of developing a document I call a "Product Concept Document (PCD)".  An overview is given below.


The marketing staff oftentimes holds the most organic understanding of customer and user needs. But the need for a new or revised product might arise from other sources such as scientific literature, general research, the manufacturing staff, or experience from prior device variants.  If pondering the feasibility of a particular product idea, then such intelligence should be memorialized and assessed prior to formal initiation of the regulated design & development process.  This should be done via a PCD championed by the "idea-initiator" to capture the targeted conceptual characteristics and basis for design of the product.


FDA's notion of "concept" as well as other principles for creation of a PCD are provided below:

• Product Concept Documents may not be technically comprehensive and should not be expected to be so.
• The use of general and qualitative terms in the PCD is both appropriate and practical.
• The PCD identifies the user needs / customer requirements, which will often be stewarded by the marketing staff based on various methods and sources such as, but not limited to, Voice of the Customer (VOC), personal conversation with customers, focus groups, surveys or questionnaires, literature review, "show and tell" sessions with customers, previous experience/precedents, direct observation of customers in the clinical work environment, lectures, presentations, etc.
• As Edwin Bills points out, there can be multiple types of "user" or "customer", so be sure the needs of all potential stakeholders (internally and externally) are considered.
• The user needs / customer requirements should be ranked, at the very least as "Essential" vs. "Nice to Have".
• The PCD is a preliminary starting point for development, but is not to be confused with design inputs, which are derived later in due course by elaborating, expanding, quantifying, and transforming the PCD into a complete set of design input requirements written in measurable terms to an engineering level of detail.
• Upon completion of the PCD, formal feasibility assessments may be performed using techniques such as Proof of Concept, rapid prototyping, preliminary hazard analysis, etc., in order to justify the feasibility of the proposed concept.

​In other recent discussions in this Forum, members have inquired about the relationship between user needs and design inputs. I offer an introductory icebreaker herein.  Like other Forum members, I'd be very interested in hearing others' related thoughts, experiences, and suggestions.


The ultimate goal of the design and development process is to realize a medical device design that meets user needs and intended uses. As I note in my prior related Forum commentaries, proper construction of design inputs is an imperative step in this process.  But how do design inputs get properly developed?  Edwin Bills and Rem Siekmann are spot-on in directing this question toward understanding user needs.


Though maybe not immediately obvious upon first review, FDA in its 1997 design control guidance document provides a nice bridge between user needs and design inputs. It hinges on the notion of product "concept". In a nutshell, many firms will generate something often called a "Customer Requirements Document", "Product Requirements Document", or the like.  Similarly, I've adopted the practice of developing a document I call a "Product Concept Document (PCD)".  An overview is given below.


The marketing staff oftentimes holds the most organic understanding of customer and user needs. But the need for a new or revised product might arise from other sources such as scientific literature, general research, the manufacturing staff, or experience from prior device variants.  If pondering the feasibility of a particular product idea, then such intelligence should be memorialized and assessed prior to formal initiation of the regulated design & development process.  This should be done via a PCD championed by the "idea-initiator" to capture the targeted conceptual characteristics and basis for design of the product.


FDA's notion of "concept" as well as other principles for creation of a PCD are provided below:

• Product Concept Documents may not be technically comprehensive and should not be expected to be so.
• The use of general and qualitative terms in the PCD is both appropriate and practical.
• The PCD identifies the user needs / customer requirements, which will often be stewarded by the marketing staff based on various methods and sources such as, but not limited to, Voice of the Customer (VOC), personal conversation with customers, focus groups, surveys or questionnaires, literature review, "show and tell" sessions with customers, previous experience/precedents, direct observation of customers in the clinical work environment, lectures, presentations, etc.
• As Edwin Bills points out, there can be multiple types of "user" or "customer", so be sure the needs of all potential stakeholders (internally and externally) are considered.
• The user needs / customer requirements should be ranked, at the very least as "Essential" vs. "Nice to Have".
• The PCD is a preliminary starting point for development, but is not to be confused with design inputs, which are derived later in due course by elaborating, expanding, quantifying, and transforming the PCD into a complete set of design input requirements written in measurable terms to an engineering level of detail.
• Upon completion of the PCD, formal feasibility assessments may be performed using techniques such as Proof of Concept, rapid prototyping, preliminary hazard analysis, etc., in order to justify the feasibility of the proposed concept.

​In other recent discussions in this Forum, members have inquired about the relationship between user needs and design inputs. I offer an introductory icebreaker herein.  Like other Forum members, I'd be very interested in hearing others' related thoughts, experiences, and suggestions.


The ultimate goal of the design and development process is to realize a medical device design that meets user needs and intended uses. As I note in my prior related Forum commentaries, proper construction of design inputs is an imperative step in this process.  But how do design inputs get properly developed?  Edwin Bills and Rem Siekmann are spot-on in directing this question toward understanding user needs.


Though maybe not immediately obvious upon first review, FDA in its 1997 design control guidance document provides a nice bridge between user needs and design inputs. It hinges on the notion of product "concept". In a nutshell, many firms will generate something often called a "Customer Requirements Document", "Product Requirements Document", or the like.  Similarly, I've adopted the practice of developing a document I call a "Product Concept Document (PCD)".  An overview is given below.


The marketing staff oftentimes holds the most organic understanding of customer and user needs. But the need for a new or revised product might arise from other sources such as scientific literature, general research, the manufacturing staff, or experience from prior device variants.  If pondering the feasibility of a particular product idea, then such intelligence should be memorialized and assessed prior to formal initiation of the regulated design & development process.  This should be done via a PCD championed by the "idea-initiator" to capture the targeted conceptual characteristics and basis for design of the product.


FDA's notion of "concept" as well as other principles for creation of a PCD are provided below:

• Product Concept Documents may not be technically comprehensive and should not be expected to be so.
• The use of general and qualitative terms in the PCD is both appropriate and practical.
• The PCD identifies the user needs / customer requirements, which will often be stewarded by the marketing staff based on various methods and sources such as, but not limited to, Voice of the Customer (VOC), personal conversation with customers, focus groups, surveys or questionnaires, literature review, "show and tell" sessions with customers, previous experience/precedents, direct observation of customers in the clinical work environment, lectures, presentations, etc.
• As Edwin Bills points out, there can be multiple types of "user" or "customer", so be sure the needs of all potential stakeholders (internally and externally) are considered.
• The user needs / customer requirements should be ranked, at the very least as "Essential" vs. "Nice to Have".
• The PCD is a preliminary starting point for development, but is not to be confused with design inputs, which are derived later in due course by elaborating, expanding, quantifying, and transforming the PCD into a complete set of design input requirements written in measurable terms to an engineering level of detail.
• Upon completion of the PCD, formal feasibility assessments may be performed using techniques such as Proof of Concept, rapid prototyping, preliminary hazard analysis, etc., in order to justify the feasibility of the proposed concept.

​In other recent discussions in this Forum, members have inquired about the relationship between user needs and design inputs. I offer an introductory icebreaker herein.  Like other Forum members, I'd be very interested in hearing others' related thoughts, experiences, and suggestions.


The ultimate goal of the design and development process is to realize a medical device design that meets user needs and intended uses. As I note in my prior related Forum commentaries, proper construction of design inputs is an imperative step in this process.  But how do design inputs get properly developed?  Edwin Bills and Rem Siekmann are spot-on in directing this question toward understanding user needs.


Though maybe not immediately obvious upon first review, FDA in its 1997 design control guidance document provides a nice bridge between user needs and design inputs. It hinges on the notion of product "concept". In a nutshell, many firms will generate something often called a "Customer Requirements Document", "Product Requirements Document", or the like.  Similarly, I've adopted the practice of developing a document I call a "Product Concept Document (PCD)".  An overview is given below.


The marketing staff oftentimes holds the most organic understanding of customer and user needs. But the need for a new or revised product might arise from other sources such as scientific literature, general research, the manufacturing staff, or experience from prior device variants.  If pondering the feasibility of a particular product idea, then such intelligence should be memorialized and assessed prior to formal initiation of the regulated design & development process.  This should be done via a PCD championed by the "idea-initiator" to capture the targeted conceptual characteristics and basis for design of the product.


FDA's notion of "concept" as well as other principles for creation of a PCD are provided below:

• Product Concept Documents may not be technically comprehensive and should not be expected to be so.
• The use of general and qualitative terms in the PCD is both appropriate and practical.
• The PCD identifies the user needs / customer requirements, which will often be stewarded by the marketing staff based on various methods and sources such as, but not limited to, Voice of the Customer (VOC), personal conversation with customers, focus groups, surveys or questionnaires, literature review, "show and tell" sessions with customers, previous experience/precedents, direct observation of customers in the clinical work environment, lectures, presentations, etc.
• As Edwin Bills points out, there can be multiple types of "user" or "customer", so be sure the needs of all potential stakeholders (internally and externally) are considered.
• The user needs / customer requirements should be ranked, at the very least as "Essential" vs. "Nice to Have".
• The PCD is a preliminary starting point for development, but is not to be confused with design inputs, which are derived later in due course by elaborating, expanding, quantifying, and transforming the PCD into a complete set of design input requirements written in measurable terms to an engineering level of detail.
• Upon completion of the PCD, formal feasibility assessments may be performed using techniques such as Proof of Concept, rapid prototyping, preliminary hazard analysis, etc., in order to justify the feasibility of the proposed concept.

​In other recent discussions in this Forum, members have inquired about the relationship between user needs and design inputs. I offer an introductory icebreaker herein.  Like other Forum members, I'd be very interested in hearing others' related thoughts, experiences, and suggestions.


The ultimate goal of the design and development process is to realize a medical device design that meets user needs and intended uses. As I note in my prior related Forum commentaries, proper construction of design inputs is an imperative step in this process.  But how do design inputs get properly developed?  Edwin Bills and Rem Siekmann are spot-on in directing this question toward understanding user needs.


Though maybe not immediately obvious upon first review, FDA in its 1997 design control guidance document provides a nice bridge between user needs and design inputs. It hinges on the notion of product "concept". In a nutshell, many firms will generate something often called a "Customer Requirements Document", "Product Requirements Document", or the like.  Similarly, I've adopted the practice of developing a document I call a "Product Concept Document (PCD)".  An overview is given below.


The marketing staff oftentimes holds the most organic understanding of customer and user needs. But the need for a new or revised product might arise from other sources such as scientific literature, general research, the manufacturing staff, or experience from prior device variants.  If pondering the feasibility of a particular product idea, then such intelligence should be memorialized and assessed prior to formal initiation of the regulated design & development process.  This should be done via a PCD championed by the "idea-initiator" to capture the targeted conceptual characteristics and basis for design of the product.


FDA's notion of "concept" as well as other principles for creation of a PCD are provided below:

• Product Concept Documents may not be technically comprehensive and should not be expected to be so.
• The use of general and qualitative terms in the PCD is both appropriate and practical.
• The PCD identifies the user needs / customer requirements, which will often be stewarded by the marketing staff based on various methods and sources such as, but not limited to, Voice of the Customer (VOC), personal conversation with customers, focus groups, surveys or questionnaires, literature review, "show and tell" sessions with customers, previous experience/precedents, direct observation of customers in the clinical work environment, lectures, presentations, etc.
• As Edwin Bills points out, there can be multiple types of "user" or "customer", so be sure the needs of all potential stakeholders (internally and externally) are considered.
• The user needs / customer requirements should be ranked, at the very least as "Essential" vs. "Nice to Have".
• The PCD is a preliminary starting point for development, but is not to be confused with design inputs, which are derived later in due course by elaborating, expanding, quantifying, and transforming the PCD into a complete set of design input requirements written in measurable terms to an engineering level of detail.
• Upon completion of the PCD, formal feasibility assessments may be performed using techniques such as Proof of Concept, rapid prototyping, preliminary hazard analysis, etc., in order to justify the feasibility of the proposed concept.

Over the last 24 years I've certainly worked at a number of large companies, but mostly small companies (i.e., 1-25 employees).  During that tenure I've repeatedly seen the small companies document user/customer requirements in some kind of PRD, CRD, PCD, or other type of document. (Oftentimes I've found that such information has to a degree, already been characterized by sales/marketing in the corresponding general business plan). Many of the firms were already doing PRD/CRD/PCD's before my arrival and coaching. So, the frequency of the practice, even in small companies, seems to be more than that of a rare or endangered species.

Remember that, by definition, this step of the process can be less formal than when the concept information is later translated into actual design inputs.  What I've seen be successful, and thus continue to recommend, is a template that is just 1-2 pages in length.  It should ask, say, 8-10 questions aimed at pinpointing topics like the proposed intended used / indications, the itemized/ranked user needs (often just worded in layperson or informal voice-of-customer terms), the targeted advertising claims, etc.  This approach gives companies wide liberty in the degree of information recorded in the document, thereby making it scalable for small and large companies alike.

Though some companies or stakeholders may balk at this step, the work is likely already being done in some fashion. If you can persuade them to formalize the step a bit more, then the compliance and business dividends can be huge. I believe approaching the concept / user needs in this fashion will help soften the perception that the step is too burdensome.

​In other recent discussions in this Forum, members have inquired about the relationship between user needs and design inputs. I offer an introductory icebreaker herein.  Like other Forum members, I'd be very interested in hearing others' related thoughts, experiences, and suggestions.


The ultimate goal of the design and development process is to realize a medical device design that meets user needs and intended uses. As I note in my prior related Forum commentaries, proper construction of design inputs is an imperative step in this process.  But how do design inputs get properly developed?  Edwin Bills and Rem Siekmann are spot-on in directing this question toward understanding user needs.


Though maybe not immediately obvious upon first review, FDA in its 1997 design control guidance document provides a nice bridge between user needs and design inputs. It hinges on the notion of product "concept". In a nutshell, many firms will generate something often called a "Customer Requirements Document", "Product Requirements Document", or the like.  Similarly, I've adopted the practice of developing a document I call a "Product Concept Document (PCD)".  An overview is given below.


The marketing staff oftentimes holds the most organic understanding of customer and user needs. But the need for a new or revised product might arise from other sources such as scientific literature, general research, the manufacturing staff, or experience from prior device variants.  If pondering the feasibility of a particular product idea, then such intelligence should be memorialized and assessed prior to formal initiation of the regulated design & development process.  This should be done via a PCD championed by the "idea-initiator" to capture the targeted conceptual characteristics and basis for design of the product.


FDA's notion of "concept" as well as other principles for creation of a PCD are provided below:

• Product Concept Documents may not be technically comprehensive and should not be expected to be so.
• The use of general and qualitative terms in the PCD is both appropriate and practical.
• The PCD identifies the user needs / customer requirements, which will often be stewarded by the marketing staff based on various methods and sources such as, but not limited to, Voice of the Customer (VOC), personal conversation with customers, focus groups, surveys or questionnaires, literature review, "show and tell" sessions with customers, previous experience/precedents, direct observation of customers in the clinical work environment, lectures, presentations, etc.
• As Edwin Bills points out, there can be multiple types of "user" or "customer", so be sure the needs of all potential stakeholders (internally and externally) are considered.
• The user needs / customer requirements should be ranked, at the very least as "Essential" vs. "Nice to Have".
• The PCD is a preliminary starting point for development, but is not to be confused with design inputs, which are derived later in due course by elaborating, expanding, quantifying, and transforming the PCD into a complete set of design input requirements written in measurable terms to an engineering level of detail.
• Upon completion of the PCD, formal feasibility assessments may be performed using techniques such as Proof of Concept, rapid prototyping, preliminary hazard analysis, etc., in order to justify the feasibility of the proposed concept.