A medical-device development plan should connect the commercial problem, intended use, regulatory path, product risk, system architecture, evidence and manufacturing strategy from the beginning. Treating those topics as separate workstreams creates late surprises: a claim that requires different evidence, a user need that cannot be verified, a risk control that arrives after architecture freeze, or a prototype that cannot be manufactured consistently.
The lifecycle is iterative. Teams learn, prototypes expose assumptions and regulators may provide feedback. Control does not require a rigid waterfall. It requires clear decisions, approved baselines, traceable evidence and disciplined change.
Begin with the product definition
Before selecting components or building a polished prototype, define what the device is intended to do, for whom, under what conditions and with what clinical or operational claim. The initial definition should include intended users, patient population, use environment, interfaces, accessories, consumables, cleaning or reprocessing, service model and foreseeable misuse.
These statements influence device classification and regulatory controls. FDA’s How to Study and Market Your Device resource explains that U.S. classification is risk-based and that even devices exempt from a premarket submission still require the correct classification and applicable controls.
Write the early product definition as testable hypotheses. Separate what is known from what still needs clinical, market, regulatory or technical evidence. That distinction prevents a planning assumption from quietly becoming a design input.
Phase 1: feasibility and regulatory strategy
Feasibility should attack the uncertainties most likely to change the product architecture or business case. A useful feasibility plan ranks technical, clinical, human-factors, regulatory, supply-chain and manufacturing risk.
- Can the core sensing, actuation, imaging, algorithm or therapeutic principle achieve the required performance?
- What device classification, product code and submission pathway appear applicable?
- What predicates, special controls, recognized standards or clinical evidence may shape the design?
- Which hazards could make the proposed architecture unacceptable?
- What user tasks or environments create significant use-related risk?
- Which components, materials, manufacturing processes or suppliers have long lead times or qualification burdens?
Prototype only what is needed to answer those questions. A benchtop optical path, actuator load rig, thermal mockup, sensing chain or simulated workflow can produce more decision value than an integrated appearance prototype.
When a U.S. regulatory question could change the evidence plan, the FDA’s Q-Submission Program provides voluntary mechanisms for requesting feedback. A useful request asks specific questions and supplies enough technical context for meaningful FDA response.
Phase 2: development planning and design inputs
Translate user needs, intended use, risk analysis, standards, interface constraints and manufacturing assumptions into controlled design inputs. Each input should be unambiguous, achievable, verifiable or validatable, and consistent with the rest of the requirement set.
A system-level input such as “the device shall be portable” is not yet actionable. The team may need measurable limits for mass, envelope, setup time, battery runtime, carrying method, drop exposure, transport storage, ingress protection and cleaning. The product risk and use environment determine which details matter.
Plan verification while writing inputs. If the team cannot describe how it would objectively demonstrate a requirement, the requirement probably needs clarification. Link each requirement to its source and to applicable risk controls.
Phase 3: architecture and detailed design
Architecture assigns functions and risk controls to subsystems. It defines boundaries among mechanics, electronics, embedded software, application software, optics, disposables, accessories, manufacturing equipment and external systems. It should also define degraded and fault states, not only normal operation.
Review interface details early:
- mechanical datums, tolerance accumulation, loads and motion limits;
- power budgets, grounding, isolation, connectors and cable behavior;
- sensor range, accuracy, calibration, drift and diagnostic coverage;
- software data ownership, timing, state transitions and communication faults;
- thermal sources, paths, surfaces and environmental limits;
- cleaning, biocompatibility, sterility, packaging and material compatibility where applicable;
- user-interface states, alarms, labeling and training dependencies.
Maintain configuration control as prototypes evolve. A test result is useful only when the team can identify the hardware, software, calibration, fixture, procedure and deviations associated with it.
Phase 4: iterative engineering evidence
Engineering tests during development serve a different purpose from formal design verification. They characterize margin, compare options, tune algorithms, expose failure modes and improve test methods. Preserve enough information to inform design decisions, but do not confuse exploratory results with approved verification evidence.
Useful development evidence may include:
- tolerance and error budgets;
- thermal, structural, optical and electrical models correlated to measurements;
- motor, sensor or imaging characterization across operating corners;
- software unit, integration and hardware-in-the-loop tests;
- EMC pre-compliance work with production-intent cables and grounding;
- formative human-factors studies with representative users and tasks;
- fault injection and recovery testing;
- process development for assembly, calibration, inspection and test.
Phase 5: design verification
Verification provides objective evidence that design outputs meet design inputs. The verification plan should identify the requirement, method, sample or unit selection, equipment, environment, configuration, acceptance criteria, data handling and review.
Not every requirement needs a standalone physical test. Inspection, analysis, simulation or test may be appropriate depending on the claim and risk. Analysis needs validated assumptions and traceable inputs. Simulation should be correlated where model uncertainty could affect the conclusion. Test methods and fixtures need enough qualification for the measurement being made.
Failures should preserve the original result, investigation and disposition. Repeating a test after an unexplained failure can hide a design, method or configuration problem.
Phase 6: design validation and human factors
Validation evaluates whether the device meets user needs and intended uses. It uses production units or appropriate equivalents and actual or simulated use conditions. The validation strategy may include clinical evaluation, simulated-use work, usability validation, performance studies and other evidence appropriate to the device.
FDA’s 2026 human-factors guidance frames the device-user system around intended users, uses, use environments and interfaces. Human-factors validation is strongest when earlier formative work has already changed the interface and risk controls.
Phase 7: design transfer and process validation
Transfer converts the approved design into a reproducible product and production process. The team should resolve differences between development fixtures and production equipment, laboratory calibration and factory calibration, hand-built prototypes and controlled assembly.
| Transfer element | Question to answer |
|---|---|
| Product definition | Do drawings, specifications, software releases and bills of material fully define the approved configuration? |
| Suppliers | Are critical requirements, change notification and acceptance controls clear? |
| Assembly | Can operators and equipment reproduce the build without undocumented expert knowledge? |
| Inspection and test | Do methods detect the defects and performance limits that matter? |
| Calibration | Are references, algorithms, limits, records and recalibration behavior controlled? |
| Packaging and labeling | Are identity, storage, handling, expiration and user information correct and protected? |
| Process validation | Where output cannot be fully verified later, is the process validated and monitored appropriately? |
Phase 8: submission, launch and postmarket learning
The submission type and evidence depend on classification and the device. FDA lists 510(k), De Novo, PMA and other pathways in its premarket submission overview. Clearance or approval does not end design responsibility. Production, complaint, service, cybersecurity, supplier and field information may reveal new risk or trigger corrective action and design change.
Plan postmarket data flow before launch. Define product identification, complaint intake, escalation, investigation, adverse-event assessment, trend review, vulnerability handling and feedback to risk management. The quality system should make it possible to identify affected versions and reconstruct the decision history.
Use decision gates instead of calendar gates
A gate should close specific uncertainty. “End of prototype phase” is weak. “Core sensing feasibility demonstrated across the required range, remaining error budget approved, and unresolved optical risk assigned” is actionable. Each gate should state required evidence, decision authority, open risks and the approved next investment.
This keeps iteration compatible with control. Teams can run software, electrical, mechanical and manufacturing work concurrently while preserving system-level baselines and change impact.
Plan the lifecycle as one evidence system
The product definition drives risk and regulation. Risk drives architecture and requirements. Requirements drive outputs and verification. User needs drive validation. The approved design drives transfer. Production and postmarket evidence feed risk and change control. Breaking any of those links creates avoidable uncertainty.
Outer Reef’s medical-device product development work connects systems, mechanical, electrical, software, optics, verification and transfer around that evidence chain.
