I learned product development in a field where a good idea cannot simply become a shipped product because a prototype looks promising. In medical devices, the team must understand the user, define what the design must do, test its claims, manage risk, and carry the design into repeatable production. That discipline can sound bureaucratic. Done well, it is a way to prevent expensive misunderstandings.
At Hospital for Special Surgery, I moved from orthopedic-device engineering into project management. That shift changed my view of design controls: the same decision had to remain understandable to the surgeon, designer, test team, quality team, and the person planning the next milestone. Traceability mattered because those people needed to act on one shared rationale, not because a template demanded more boxes. Later, my work on the LVAD program at BrioHealth reinforced how much a cross-functional team depends on that shared rationale.
My background spans orthopedic implant and surgical-instrument engineering, analysis, and later cross-functional program leadership. The lesson that traveled with me was not a particular form or acronym. It was the habit of asking: What need is this decision serving, and what evidence would change our minds?
The useful loop behind design controls
Under ISO 13485:2016, design and development are managed as part of a medical-device quality system. The U.S. FDA's Quality Management System Regulation, effective February 2, 2026, incorporates that edition of ISO 13485 by reference. The exact regulatory obligations depend on the product and market, but the underlying loop is broadly useful:
- Start with user needs and intended use.
- Translate those needs into measurable design inputs.
- Create design outputs that can be built and inspected.
- Verify that outputs meet inputs; validate that the product meets user needs in its intended context.
- Review risks, changes, and production readiness throughout—not just at the end.
Consider a hypothetical reusable surgical instrument. “Easy to clean” is a user need. A team might translate it into requirements for accessible surfaces, compatible cleaning methods, and measurable residue limits. Drawings and material specifications become outputs. Bench tests can verify dimensions and cleaning performance; representative users and use conditions can help validate that the instrument fits the actual workflow. Each step makes the next decision clearer.
This does not mean every consumer product needs a medical-device quality system. It means the reasoning is valuable wherever a mistaken assumption can become costly after release.
Evidence should trace in both directions
A requirement with no test is an unproven promise. A test with no user need may be a technically impressive distraction. Traceability connects the two. It lets a team ask which need a test supports, and which claims would be affected if a component changes.
| Decision layer | Question to answer | Useful evidence |
|---|---|---|
| User need | What must work for the person using it? | User research and intended-use context |
| Design input | What measurable requirement follows? | Reviewed requirement and acceptance criteria |
| Design output | What defines the product to build? | Drawings, specifications, or implementation |
| Verification and validation | Does it meet the input and the real need? | Test and representative-use evidence |
When I worked with finite-element analysis (FEA), a colorful stress plot was never the whole answer. The question was whether the load case, material assumptions, boundary conditions, and acceptance criteria represented the decision we needed to make. A model can reveal a weak point or compare options, but its value depends on the quality of the question. The same principle applies to software analytics, pilot programs, and customer interviews.
Risk is a design conversation, not a closing checklist
ISO 14971:2019 provides a process for managing risks associated with medical devices across the product life cycle. It does not set a universal acceptable-risk threshold. Teams must define their criteria and make defensible decisions in their own context. The FDA's QMSR incorporated ISO 13485, not ISO 14971 by reference; these standards play different roles.
Outside medtech, the practical question is still powerful: what could go wrong, how would it cause harm or loss, and what design change would reduce the risk? A risk register that only names hazards cannot replace that conversation. Nor can a successful test prove that an untested failure mode is impossible.
Two well-known failures show why interfaces deserve attention. NASA's Mars Climate Orbiter investigation identified a metric-versus-English-units mismatch amid broader weaknesses in communication and verification. Samsung's Galaxy Note7 investigation attributed the phone incidents to battery problems and described additional safety checks. Neither was a medical-device design-control case. Both illustrate how product risk can escape the boundaries of a single component or team.
Build a lighter version where you work
For a small product team, the useful version can fit on one page: the user need, the measurable requirement, the output or implementation, the verification method, the real-world validation plan, the top risks, and an owner for each decision. Keep it live as the design changes. At each review, ask what the latest evidence supports, what remains uncertain, and whether production or operations can deliver what the prototype demonstrates.
Design controls are sometimes caricatured as paperwork after engineering. At their best, they are engineering memory. They protect the logic behind a product long enough for other people to build it, test it, use it, and improve it.
As the series develops, browse the Engineering & Technical Work articles for related guides on requirements, risk, verification, and design transfer.
If your team is translating an early technical concept into a product program, see how to work with me. I enjoy discussing how much structure is useful for the decision at hand.
Leave a Reply