Design Process
Starting the Design Process can be a bit daunting, especially for Med Device Startups, who have limited time, resources, and expertise—and are therefore concerned about ensuring design details are addressed correctly the first time.
If you have worked with a Design Firm in the past, your experiences might have indoctrinated you to this type of thinking; specifically, that your firm cannot move through the Design Process until everything you need is fully locked-down and documented.
If you followed the FDA Design Control waterfall faithfully (and avoided the pitfalls we warned you about), your firm will be in good shape, because you will have:
talked to all (or most) of your intended users
agreed upon the design inputs with key stakeholders
transformed design inputs into engineering requirements
Perhaps you used a competitive matrix (email us below for a template), to benchmark the features, benefits, and marketing strategies of your competition. If so, kudos for approaching the foundational work of the Design Process in a thorough and diligent way.
However, do not convince yourself that your labor has been completely exhaustive.
Or, to those on the opposite side of the confidence spectrum: do not convince yourself that you cannot move forward in the Design Process, believing that you haven’t exhaustively completed your requirements capture. This brings us to our first point of advice for those in Med Device Startups developing their first product.
Design Firms prefer to move forward only when all Design Inputs and User Needs are known, documented, and signed off. This reduces the risk of them uncovering a nasty surprise, like a missed feature that is suddenly crucial to the product’s build. (This could trigger a major design change, which could start a cascade of changes both upwards and downwards through the FDA waterfall.)
Pitfall 1: Do not assume you should delay the Design Process because you may not have captured all the requirements.
Iterations occur on every project, whether you are in a Startup or working for a large, multinational Med Device firm. You should expect that some requirements or design details will be missed along the way.
When you do find new requirements:
Simply go back and pass through that design review again to address the latest items from a risk or a design inputs perspective.
Be sure to prioritize the items that pose the most project or technical risk.
If you’re not feeling confident with these two points, reach out to us and we’ll help guide you.
While these processes are often depicted in a waterfall approach, they work best when you view them as parallel, continuous processes that persist until you reach launch (and in most cases, afterwards!)
Remember, the true first “hard-stop” comes once you complete Design Outputs (Design Freeze; a later phase) and move into the testing phase.
Testing should always start with a production-equivalent device.
However you define Production Equivalent for each feature of your design, be sure to define them as early as possible to pre-test (or formally test) before capital tooling is needed.
Design Freeze is valid only until something fails—failure will force you to iterate until there are no more challenges to work around.
Go fast and fail fast! Know that shortcomings or failures are inevitable and can lead to a better, more robust product at launch. Seek advice where needed and re-adjust to get back on track.
Failing fast leads us to Pitfall 2.
Pitfall 2: Not documenting changes (when you are failing fast).
The FDA describes how to handle design changes and address changes as they occur through the process. Document what happens and any resulting decisions, update your files, and create new records.
You can be strategic about this:
For example, are you capturing added details as design changes, or can you leave your design documentation in flux? (This is OK if the processes are closed out in the right order.)
You can also move forward with stages, even though change may occur:
For example: at some point, you decide planning is done; you hold a planning review. Later, you decide the Design Inputs are done; you hold an inputs review. You diligently complete the design reviews needed to freeze the design, then move onwards to testing, and then, something fails. (This is OK: Simply go back, and address some of those design reviews as necessary, keeping good documentation along the way.)
Evaluating the potential for success
There is no magical formula to follow when determining whether iteration will be successful, or whether your product ought to be fixed now or later, but this framework may help:
Do not plan for perfection. Plan for speed, compliance, and a product that will delight your customers.
Documentation is key to moving fast and efficiently. The design process is inherently complex; moving up and down the waterfall is part of the process. The mistake is assuming this is not natural.
If your Startup is struggling with product design, or wrestling with project gridlock, Concise Engineering can help!