Creating a meaningful product requirement that addresses both technical and user needs ultimately leads to a better end product and, in most cases, a quicker development time.

Tor Alden

Oft-cited stats state that 80-90% of startups fail. The odds are potentially even worse if your startup is developing a complex first-generation medical device. 

Among the most common reasons for such failure is a lack of understanding of the end-user’s true needs. There are often technical limitations or preconceived notions of how the device should be used, for example. For medtech startups, the challenge often lies in locking down the input requirements. There always seems to be a tradeoff between technical requirements and user requirements—a problem we like to call the chicken-and-egg problem.

Common Underlying Challenges

For the sake of this article, think of the chicken as user needs and the egg as technology needs. It’s a chicken-and-egg problem to develop meaningful product requirement specifications for first-of-kind complex systems, especially in the face of the four underlying challenges they typically share: 

1. They have few, if any, comparable predicate devices. Breakthrough medical devices, by their very definition, typically lack predicate devices on which to base a 510(k) submission. Consequently, companies with low-to-moderate-risk devices would likely pursue a de novo classification request to avoid automatic classification as a Class III device. 

2. They may require changes to workflow. By their very nature, first-of-kind devices may change the way users normally work. That can be problematic because hospitals and laboratories have established protocols for their workflows. Let’s be clear: Doctors, nurses, and technicians do not want to change their routine unless there is a significant benefit. The technology must thus adapt to the user, and either simplify or streamline existing workflows in order to be successful. 

3. They are almost always part of a larger complex system. When part of a much larger system, complex next-generation devices may have multiple solutions or outcomes mixed with heavy technical constraints. If not careful, there can be a tendency to complicate the problem and never reach the finish line. Or, in contrast, there can be a tendency to overly simplify the problem and miss critical components that make it work within the existing system or protocols.

4. They have an accelerated timeline. Innovation often springs from research or laboratory environments. This means that first-of-kind medical devices are generally either produced by a startup or at least have a startup mentality. Once a startup has received funding, the management team typically aims for commercialization within two years. Backers have allocated funds to get the product launched, and this funding can be perceived as rocket fuel. As in all successful space missions, however, an accurate flight plan is necessary to prevent the rocket from ending up off course. In the case of startups, the flight plan is focused on hitting the value proposition and meeting initial expectations. 

The Challenges of Technology Push

As is the case with other high-tech sectors, there is a tendency toward “technology push” in the medical device industry. Years are spent in R&D; but once out of the box, there is a pressure to commercialize the technology quickly without a real focus on the user’s primary needs. 

It’s particularly important for developers of first-of-kind complex medical systems to address users’ primary needs, however, because they are attempting to create a new standard of care. These new products need to strike a balance between cost and value to the end-user in order for them to be successful in the marketplace. The value proposition should be addressed early in the development—ideally alongside user research demonstrating that the technology also meets the needs of the user. 

As a result of many startups’ technology-push strategy, product briefs are often marred by unchallenged assumptions. In these cases, research was most likely conducted in a laboratory rather than the real-world environment. Over years of development, assumptions were made as to how the product should be used. 

Those assumptions ultimately evolve into conceptual requirements in the form of user requirements specifications (URS) or design requirements specifications—product requirement specifications (PRS) or software requirement specifications (SRS). These preliminary product requirements aim to address the should-have, must-have, and nice-to-have items the product needs for successful development. They are likely to have requirements listed as “must be easy to use” or “should be easy to clean.” 

But what does “must be easy to use” really mean?  Did the requirements really take all the user groups and use environments into account? And more importantly: Was the need of the product for the user group even addressed?  

Developers of a technology often develop tunnel vision and fail to recognize important factors in the context of the use environment that will determine the product’s success in the market. It’s important to remember that there are usually multiple solutions to complex problems, and in all likelihood, there is more than one solution to any given problem. This is where the chicken-and-egg problem comes in.

Fleshing out the user and technology requirements in a concurrent cross-functional team is a chicken-and-egg problem. The upfront design research team—including user researchers, UI/UX developers, industrial designers, and human factors engineers—needs to collaborate with engineering to develop the design input documents, focusing on addressing system architecture, use and usability, and the appropriate look and feel. The designers need to challenge preliminary requirement documents to ensure that they address the user needs and workflows, and not just the technology. The technology must then be prototyped and tested within the intended environment with actual users to verify it meets or exceeds expectations, thereby creating a value proposition for the user. This approach will not only satisfy FDA user needs requirements, it will also help improve the chances that the product fits within the environment, in turn increasing the chances it succeeds in the market.

Avoiding the God Complex and Going Lean

In a 2011 TED talk called “Trial, error and the God complex,” economics writer Tim Hartford notes that people who work on complex problems often fall into the trap of believing they understand the problem and convince themselves that they understand how the world works. He explains that the God complex goes something like this: “No matter how complicated the problem, you have an absolute, overwhelming belief that you are infallibly right in your solution.” 

Hartford believes in an evolutionary approach to solving complex problems grounded in the notion that trial and error is essential. Basically, you need to go through variation and selection. He cites Unilever’s struggle to develop a high-pressure valve for a dishwasher nozzle as an example. The company spent a tremendous amount of time and resources trying to determine the geometry that would allow the valve to work as desired. It eventually solved the problem by running hundreds of different models, building and testing the geometry until one worked. However, by the company’s own admission, it did not know why that specific geometry worked. 

The catch is that the evolution-based model Harford espouses can be perceived as antithetical to the accelerated pace of startups. Intended to expedite the evolutionary model and minimize interference from “the God complex,” the “lean startup” methodology forces developers to justify why the innovative product idea is needed and to validate that assumption in the market. 

Lean startup methodology creator Eric Ries states that: “Too many startups begin with an idea for a product that they think people want. They then spend months, sometimes years, perfecting that product without ever showing the product, even in a very rudimentary form, to the prospective customer.“ He recommends startups “pivot” until they find the right market or the right product fit for the market, trading off technology for market needs to create the value proposition. There are many similarities between Harford’s trial-and-error approach and Ries’s streamlined pivot strategy; the lean startup method speeds the process of evolution by constant iteration and early testing. 

The lean startup method also shares similarities with FDA’s waterfall design process. Most companies are aware that they need to incorporate user research and user testing, and most base their processes on the FDA waterfall. However, although the waterfall model is a useful tool for introducing design controls, it has its limitations. The waterfall model works best when applied to simple problems; it can break down during more complex problems or agile development. Additionally, it’s important to point out: FDA cares about safety, efficacy and usability—not whether the product is successful in the market. Simply doing contextual research or usability studies will not prove out market success. 

Conclusion

Whether a company has been in business six months or 20 years, new product development projects all begin with new team members, new assumptions, and new goals. Combining parts of the startup methodology with traditional contextual inquiry can go a long way: Work to quickly understand a problem then identify a solution and test it, modifying (pivoting) quickly and nimbly. Design, iterate, test and verify. Focus on identifying user needs as well as understanding the technology fit. 

An effective approach is integrating the lean start up methodology into the FDA waterfall process and concurrently testing user needs with “conceptual” product requirements while pivoting along the way. Current regulatory guidance points to the benefit of early contextual inquiry to verify user needs via formative testing. Blending contextual research with aspects of the lean startup methodology is a way of uncovering the unmet needs as well as meeting regulatory requirements. 

Creating a meaningful product requirement that addresses both technical and user needs ultimately leads to a better end product and, in most cases, a quicker development time. In order to verify that the value proposition is met, the team needs to create and test workflows in a real-world environment and be prepared to challenge earlier assumptions

There is a classic Yogi Berra quote that states, “When you come to a fork, take it.” Using a process to verify the user needs and technology requirements increases the odds that the development team chooses the right solution when they hit that fork, ultimately producing requirement documents that fully address all user groups and use environments.

Tor Alden, IDSA, MS, is a principal of HS Design, an ISO 13485-certified product development firm specializing in complex medical systems.