What you will learn
By the end of this topic, you should be able to explain the product manager's role in a medical-device organisation, control the connection between opportunity and intended purpose, make evidence-aware product decisions, recognise the interfaces that require specialist ownership and maintain product intent from discovery through post-market support.
The product manager's role
Medical-device product management sits between user value, clinical purpose, commercial viability and controlled development. The role is not simply to collect feature requests or maintain a roadmap. It is to help the organisation decide which problem to solve, for whom, with what product and claims, and with what evidence and lifecycle commitment.
Understand value
Identify the clinical, user and organisational outcomes that would make the product worth adopting.
Control product intent
Keep purpose, users, use environments, claims, product boundary and variants coherent as learning grows.
Enable sound decisions
Make benefits, risks, evidence, dependencies, uncertainty and commercial consequences visible before scope decisions.
Own lifecycle coherence
Connect development, launch, support, improvement and retirement around the same controlled product intent.
Product Management should drive clarity and alignment, but regulatory classification, clinical conclusions, risk acceptability, technical approval and product release require the competent functions and authorities defined by the organisation.
Control product intent before controlling the backlog
A backlog cannot compensate for an unclear product. Before detailed prioritisation, establish a controlled description of what the organisation is proposing to place on the market.
- The medical purpose and the clinical or operational problem addressed.
- The intended patient population, users and use environments.
- Indications, contraindications, limitations and foreseeable use scenarios.
- The product boundary, accessories, software, services, consumables and external dependencies.
- The benefits, performance claims and outcomes that evidence must support.
- Target markets, likely qualification and classification, and the regulatory route.
- Variants, configurations, business model and expected support lifetime.
Product Management should help maintain this definition with Regulatory, Clinical, Systems Engineering and Quality. A change in claims, users, environment, workflow, connectivity or market can change requirements, risks, evidence and regulatory obligations—even when the visible feature appears small.
See MTL-102 — Intended Purpose, Users and Use Environments for the foundations of a controlled intended-purpose statement.
Discovery must create decision-quality evidence
Early discovery is still exploratory, but it should not be casual. Separate observations from interpretations and assumptions. Record who was consulted, which context was studied, what was learned, what remains uncertain and what decision the evidence supports.
Prototype feedback is not automatically validation, and customer enthusiasm is not clinical evidence. Early research can reduce uncertainty and shape user needs, but formal validation requires a controlled design, representative users and conditions, predefined methods and objective acceptance criteria.
See MTL-103 — User Needs and Design Inputs for translating outcomes into controlled requirements.
Prioritisation and trade-offs
Conventional product-management methods remain useful, but medical-device priorities cannot be reduced to customer demand, revenue and development effort. Safety, regulatory, clinical, usability, cybersecurity, manufacturing and support obligations constrain what may be deferred or traded.
User and clinical value
Does the item materially improve the intended outcome, reduce burden or enable safe and effective use?
Risk and compliance
Is it a risk control, regulatory obligation, essential-performance need or condition of an approved claim?
Evidence impact
What requirements, analyses, verification, validation, clinical evidence or submissions will change?
Lifecycle burden
What continuing support, surveillance, training, supplier, security or obsolescence commitment follows?
A minimum viable product is not a minimum compliant product. Every released configuration must satisfy its applicable requirements and have adequate evidence. Scope can be reduced by narrowing intended purpose, claims, users, environments, markets or functionality—but only through an explicit, controlled decision.
A high-value early activity may produce no user-visible feature. Resolving classification, clinical evidence, architecture, usability, supplier or safety uncertainty can protect the entire investment.
Contribution across the lifecycle
The product manager maintains the product narrative and decision context across seven connected areas.
Opportunity and problem
Understand the clinical or operational problem, affected people, current pathway, alternatives, unmet need and conditions required for meaningful value.
Typical evidence: Problem statement, stakeholder map, research findings, opportunity assumptions and decision rationale.Product definition
Shape the intended purpose, users, patient population, use environments, claims, product boundary, variants and target markets with clinical and regulatory specialists.
Typical evidence: Controlled product concept, intended-purpose input, claim set, use scenarios and market assumptions.Requirements and evidence
Ensure user needs are translated into approved design inputs and that the evidence strategy can support safety, performance, usability and the proposed claims.
Typical evidence: Prioritised user needs, acceptance rationale, traceability expectations and evidence roadmap.Development and decisions
Maintain product intent while teams resolve architecture, risk controls, feasibility, usability and manufacturing constraints. Make scope decisions through controlled governance.
Typical evidence: Product decisions, approved trade-offs, review inputs, assumptions, change records and updated roadmap.Validation and readiness
Confirm the complete device, labelling, training and support model meet user needs and intended use—not merely that features have been implemented.
Typical evidence: Validation inputs, representative-use rationale, launch criteria, training and support readiness.Launch and adoption
Align approved claims, market access, supply, training, service, customer support and commercial material with the released configuration and available evidence.
Typical evidence: Launch checklist, approved content, release configuration, market restrictions and escalation routes.Lifecycle learning
Use complaints, service, usage, clinical, security and commercial information to reassess assumptions, priorities and product changes throughout the supported life.
Typical evidence: Post-market inputs, product reviews, change proposals, benefit–risk considerations and retirement plans.Working across functions
Clinical and medical
Define the clinical context, meaningful benefit, claims and evidence needed to support the intended purpose.
Regulatory
Assess qualification, classification, markets, submission strategy, claim boundaries and regulatory impact of change.
Systems and engineering
Translate needs into requirements, architecture and feasible solutions while making interfaces and trade-offs explicit.
Risk, quality and usability
Integrate foreseeable harm, process controls, user research, risk controls, validation and objective records.
Manufacturing and supply
Align the product definition with production capability, supplier constraints, cost, traceability and continuity.
Commercial, service and support
Ensure claims, training, deployment, service, customer communication and support match the approved product.
Useful product governance makes decision rights explicit. Product Management may propose scope and priorities, but safety and compliance concerns require defined escalation and cannot be overruled through backlog priority alone.
Roadmaps, change and lifecycle ownership
A medical-device roadmap must account for more than planned features. It should include evidence generation, regulatory submissions, supplier and component changes, manufacturing improvements, platform dependencies, cybersecurity maintenance, complaint learning and end-of-support obligations.
- Define the released product configuration and which markets, claims and evidence apply to it.
- Assess proposed changes against intended purpose, risk, usability, clinical evidence, security and regulatory status.
- Plan regression and revalidation based on impact rather than the apparent size of the change.
- Keep commercial material, labelling, training and support content aligned with approved claims.
- Monitor whether real-world performance supports the original value and benefit assumptions.
- Fund maintenance, vulnerability response, supplier changes and regulatory commitments throughout support.
- Plan withdrawal and retirement, including users, data, consumables, service and installed product.
Post-market data can reveal that the product problem was misunderstood, a benefit is not being realised, a workflow creates new risk or a feature is used differently from expectation. Product Management should bring this learning back into controlled product decisions.
Common misconceptions
“The product manager owns the requirements.”
Product Management is a major source and steward of product intent, but controlled requirements need multidisciplinary authorship, review, approval and traceability.
“Regulatory will tell us what product to build.”
Regulatory specialists advise on obligations and pathways. Product and clinical strategy must still define a coherent, valuable and supportable proposition.
“A small feature is a small change.”
A simple interface or software change can affect risk controls, usability, claims, cybersecurity, evidence and regulatory status.
“The roadmap is a delivery schedule.”
It should also expose evidence, approval, manufacturing, support and lifecycle dependencies that determine whether value can actually be delivered.
“Launch proves product success.”
Safe adoption, realised benefit, reliable supply, supportability and post-market performance determine whether the product succeeds over time.
Product manager's practical checklist
- Start with a real clinical, user or operational problem—not a preferred solution.
- Keep intended purpose, users, environments, claims, markets and product boundaries controlled.
- Translate discovery into approved user needs and testable design inputs.
- Prioritise safety, compliance, evidence and lifecycle obligations alongside customer value.
- Make assumptions, uncertainty, dependencies and decision rights visible.
- Use controlled change assessment before altering scope, claims or released functionality.
- Align launch material and support with the approved product and available evidence.
- Use post-market learning to reassess value, benefit, risk and roadmap decisions.
Authoritative starting points
- ISO 13485:2016 — Medical-device quality-management systems
- ISO 14971:2019 — Application of risk management to medical devices
- US FDA Quality Management System Regulation
- US FDA — How to study and market a medical device
- Regulation (EU) 2017/745 on medical devices
- European Commission — MDCG-endorsed guidance
Specific responsibilities depend on the organisation, device, legal manufacturer, markets and governance model. Product Management should work through the organisation's approved quality processes and involve competent clinical, regulatory, risk, quality and technical specialists.