Having a successful product is a growth requirement for any company and to achieve this, it revolves around the product manager, the development team, as well as the final “consumers”.
In the process of medical device development, the definition of proper requirements is critical to develop a product which brings value to the customer.
The role of the product manager is to constantly unveil the customers’ perspective to the company and he/she must be obsessed with user requirements.
What Are User Requirements?
User requirements have to do with the functionalities, characteristics, attributes, and capabilities of your product.
And user needs, product requirements, design requirements, customer requirements, are all synonyms of user requirements.
With that being said, the basic user requirements of a medical device, consist of:
- What your product do
- How it is going to be used
- The intended use
- The indication for use
Other Factors To Consider About User Requirement
One of the most important elements in user requirement definition is that it specifies what your product should do, but not how.
Another factor to consider in user requirements definition is that one user requirement can lead to multiple design inputs.
The 5W1H method highlighted below is a simple and versatile methodology to better define the user requirements:
- Who will use the device?
- What will the device do?
- When will the device be used?
- Why will the device be used?
- Where will the device be used?
- How will the device be used?
Who are the users?
Users in this case, are frequently a combination of users only I.e the “end user” and few external stakeholders.
An example of this is: the surgeon (end user), the scrub and circulating nurses (external stakeholders).
However, I prefer to consider the term users in a much broader way, and to include all the internal and external stakeholders as users.
In this way no one is forgotten, and the product will satisfy the requirements of a vast group of stakeholders.
For better understanding: in the case of a serviceable product, the service & repairs department is an internal stakeholder and must be involved from the beginning to avoid overlooking any important requirement.
While for reusable devices, the central sterilization service is a key external stakeholder, which should be included in requirements generation.
How To Have A Complete Set Of User Requirements?
In order to cover the complete spectrum of requirements, it can be helpful to use the Garvin 8 basic dimensions of quality.
And to do that, you need to have user requirements that address all the points below, if relevant for your device:
- Performance: Performance is the primary operating characteristics.
- Features: Features are additional characteristics that increase the basic functions of the product for the user.
- Reliability: Reliability is the probability that a product will not fail within a specific time.
- Conformance: Conformance is the degree to which the product or service meets the specified standards and customer expectations.
- Durability: Durability measures the length of a product’s life.
- Serviceability: Serviceability is the speed and ease with which the product can be put into service after breakdown.
- Aesthetics: Aesthetics represent the individual’s personal preference.
- Perceived Quality: Perceived Quality is the quality attributed to a good or service based on reputation.
How To Prioritize User Requirements?
Is it really necessary to prioritize user requirements and how can you achieve this?
Well, you’re about to find out:
The list of user requirements must be as complete as possible and prioritized.
The reasons for this includes:
- Alignment of the development team on key requirements
- Appropriate use and allocation of limited resources
Maybe, there are several methodologies to categorize the user requirements under, but I know only 2 that I think are quite straightforward.
And here they are:
The Kano model
The Kano model is one that classifies product attributes into 5 categories:
Must-be
This involves the requirements that the customers expect and are taken for granted.
The presence is when you are not creating customer satisfaction, while the absence results in dissatisfaction.
One-dimensional
These attributes result in proportional satisfaction; when fulfilled, and proportional dissatisfaction; when not fulfilled.
Attractive
These are attributes that are not normally expected. The presence creates customer satisfaction, while the absence will not result in dissatisfaction.
Indifferent
Customers do not care about these attributes.
Reverse
Presence causes customer dissatisfaction and absence creates satisfaction.
The MoSCoW principle
MoSCoW stands for must, should, could and would:
M – Must-have requirements are critical and fundamental to meet the customer and business needs.
S – Should-have requirements are important, but vital project success does not rely on them.
C – Could-have requirements are desirable, but may not necessarily or typically be included, unless time and resources permit.
W – Would-like to have requirements; are still possible but unlikely to be included, as delivery won’t be this time.
Risks In User Requirements Definition
Poorly defined user requirements can produce the following:
a. Rework/redesign (in the worst-case at the end of the development process)
b. Longer development time
c. Product not competitive on the market
d. Unhappy/dissatisfied customer
e. Unhappy/unmotivated development team
f. Quality issue (in the worst-case product recall)
Common Pitfalls In User Requirements Development
Highlighted below are some of the most common pitfalls:
- Time to collect information (insufficient VOC)
- Time to refine the scope of the project
- Developing useless functionalities (not supported by a solid VOC)
- Confusion between requirements and design inputs
- Ambiguous or unclear requirements
- Requirements not prioritized
- Focus is on design inputs instead of real customer needs.
Conclusion
The new product development process is by far a cross functional activity; accordingly, communication and integration of all the actors is key.
Here’s my advice:
To minimize frustration and failure during the time of development, the complete team should be involved in the user requirements defining process from the beginning.
After all, the goal of the development team, which is to focus on customer satisfaction, user requirements definition and translation in design inputs; is the first step.
Very nice summary of the topic!
There are two remarks I would like to give.
When starting to define the requirements for a new medical device, I often struggle with the templates used in the different companies. They are often only focusing on the user requirements but completely ignoring all other requirements which are essential if you want to develop a competing product. Of course there are the regulatory requirements which need to be fulfilled. Here its important to define the target markets in order to give the regulatory affairs department the framework to the define the regulatory requirements accordingly. More often forgotten are the “market requirements” which often have a competitor benchmark as a base. These are requirements which are not directly derived from a customer interview but more the state of the art specifications for your product. For example: If all competition have a 15inch in build screen, you should also have a similar sized screen although this requirement can not be seen from a customer interview. In my opinion it is important to define such requirements at a very early stage of the process. In my experience, you often end up with discussions with the R&D department, because these are technical solutions and not user requirements. In this case, as a product manager, you have to argue with R&D. It would be much easier if the requirements are categorized at the beginning and a common understanding is developed.
The second topic which is very important when it comes to medical device development is the usability engineering, which is also related with defining the user requirements. According to the regulations, the main goal of usability is to mitigate the patient risk due to misuse of the product. So if you go through your use scenarios, always think of what could go wrong and use this information as an input for the risk management file.
I often struggle with the contact points between user requirements, usability engineering and risk management. An article about these topics would be very interesting.
Thank you for the great remarks and the detailed contribution. I agree with everything; the templates used in the different companies don’t always simplify the job of the product manager to list all the requirements. Probably the best term could be stakeholder requirements instead of user requirements to have much broader source of inputs; however, in literature the most common word used is user requirements. As said any internal or external stakeholder should be considered. In order to avoid forgetting regulatory requirements and “market requirements” the Conformance (Garvin 8 dimensions) could be helpful. I will soon post about the VOC (voice of the customer) and the different techniques to collect it. Interviews are important but are not the only method and competitive benchmark is complementary.
Thank you for the suggestion about usability, user requirements and risk management I will consider it.