Medical device development is a coordinated system of distinct domains operating under regulatory constraint. When that system performs well, progress feels disciplined and predictable. When it struggles, the issue is often not capability but structure.
Sustained execution requires clear separation between three domains: Product Management, Engineering, and Quality. These domains are interdependent but not interchangeable. When their responsibilities are defined precisely, development proceeds with greater clarity, accountability, and control.
Product Management: Owning Intent
Product Management determines what should be built and what success means.
Product Management may own the product definition phase, but it does not operate in isolation. Effective product definition draws input from multiple disciplines, including engineering, clinical experts, regulatory specialists, and senior leadership. Product Management’s role is to integrate these perspectives and translate them into a coherent set of User Needs and product objectives.
This domain translates market need and clinical workflow into structured User Needs. It defines use scenarios, clarifies the value proposition, and establishes high-level product requirements. It also considers regulatory pathway implications early, ensuring the concept aligns with the realities of a regulated market.
Product Management sets direction. It defines what must be achieved, not how it will be achieved.
When this boundary is respected, engineering can focus on realization rather than interpretation. When it is not, problems emerge quickly. If Product Management begins prescribing specific technical solutions, it constrains engineering prematurely and reduces optionality. If it fails to clearly articulate User Needs, engineering fills the gap with assumptions, often optimizing around incomplete intent.
Strong product definition creates clarity at the front end of development. It reduces ambiguity without dictating implementation.
Engineering: Owning Realization
Engineering transforms defined intent into a technically viable and producible system.
This includes system architecture, technical feasibility analysis, detailed design execution, prototype iteration, and verification planning and execution. Engineering generates the Design Outputs and produces the technical evidence that demonstrates the product performs as intended.
Realization must also account for production viability. Manufacturing considerations cannot be deferred until transfer. Engineering therefore operates as a unified realization domain that integrates both design discipline engineering and manufacturing engineering from early in development. A65 has addressed this structural integration in greater depth elsewhere (see other discussion blogs regarding Manufacturing Engineering in Design for Manufacturing and Designing the Product and Process Together). Here, they are treated as jointly responsible for technical realization.
Engineering owns execution. It does not redefine User Needs. It also does not govern the development system itself. Its responsibility is to create a product that works, can be verified, and can be produced consistently.
When these boundaries are clear, technical decision-making accelerates. When they are not, engineering effort is diluted by directional uncertainty or procedural ambiguity.
Quality: Owning System Integrity
Quality governs the development framework within which Product Management and Engineering operate.
This includes Design Controls, risk management under ISO 14971, traceability between User Needs, Design Inputs, and Design Outputs, change control, documentation architecture, and verification & validation oversight. Quality ensures that development occurs under control and that decisions are documented, traceable, and defensible.
Engineering owns technical risks. Quality governs the structure through which risks are identified, evaluated, mitigated, and documented.
Quality does not design the product. Its role is to preserve system integrity. When Quality attempts to solve engineering problems directly, innovation slows and responsibility blurs. When Quality is reduced to reconstructing documentation after the fact, risk governance weakens and audit exposure increases.
At its best, Quality creates disciplined boundaries that allow Product Management and Engineering to move with confidence.
Integration: Structured Collaboration Without Role Collapse
Clear separation does not imply isolation. These domains must operate in deliberate coordination.
User Needs originate during product definition. Design Outputs originate in Engineering. The risk structure is governed by Quality. Each domain owns its artifacts, yet integration occurs continuously. Risk analyses evolve as the design matures. Manufacturing considerations inform architecture decisions early. Review points align intent, execution, and compliance at defined stages.
Integration works when interfaces are explicit. It begins to fail when authority and ownership become ambiguous across domains.
Structured collaboration does not require blended roles. It requires defined interfaces.
Conclusion
Product development does not improve when disciplines are collapsed into one another. It improves when each domain owns its responsibility fully and interacts through clear interfaces.
Product Management defines intent. Engineering realizes it. Quality governs the system that makes it defensible.
Organizations that clarify these roles reduce ambiguity, sharpen accountability, and create development systems that are as deliberate as the products they produce.
Free Team Operating Model Assessment
If your development programs feel slower than they should, the issue may not be capability. It may be structure.
A65 works with leadership teams to clarify role ownership, artifact accountability, and decision rights across Product Management, Engineering, and Quality. A focused structural review often reveals hidden ambiguity that quietly drives delay and rework.
If you would like an objective assessment of your current operating model, we welcome the conversation.
Email: sdonnigan@a65consulting.com
Or schedule your review online
References
- ISO. ISO 13485:2016 — Medical devices — Quality management systems — Requirements for regulatory purposes. International Organization for Standardization.
https://www.iso.org/standard/59752.html - ISO. ISO 14971:2019 — Medical devices — Application of risk management to medical devices. International Organization for Standardization.
https://www.iso.org/standard/72704.html - U.S. Food and Drug Administration. 21 CFR Part 820 — Quality System Regulation.
https://www.ecfr.gov/current/title-21/chapter-I/subchapter-H/part-820 - U.S. Food and Drug Administration. Design Control Guidance for Medical Device Manufacturers. March 11, 1997.
https://www.fda.gov/regulatory-information/search-fda-guidance-documents/design-control-guidance-medical-device-manufacturers