Digital Therapeutics and Software as a Medical Device: PM for Products That Are the Treatment

Product managing a digital therapeutic (DTx) or software as a medical device (SaMD) means running two products at once: a software product that wants to ship weekly, and a regulated medical intervention where every user-facing claim needs clinical evidence and every algorithm change can trigger revalidation.

Quick Answer: Digital therapeutics product management means classifying the product against the FDA/IMDRF SaMD risk framework, deciding upfront whether the algorithm is locked or adaptive, and scoping every MVP around the smallest claim you can defend with evidence — not the smallest feature you can build.

Why Digital Therapeutics and SaMD Break the Normal Product Playbook

A DTx or SaMD product is a single artifact wearing two identities: a software release that users expect to improve every sprint, and a medical claim that a regulator, payer, and clinician all expect to stay fixed and provable. Every roadmap decision has to satisfy both audiences at once, not one after the other.

Most product instincts trained on SaaS actively work against you here. "Ship it and measure" assumes you can change behavior after release and learn from the result; in a regulated product, the behavior you shipped is frequently the thing that was evaluated, and changing it without a plan is itself a regulatory event. The habit to unlearn first is treating a claim like copy you can iterate.

The SaaS PM Instinct vs. the Regulated-Product Reality

The practical consequence is organizational, not just procedural: regulatory affairs, clinical, and quality need to sit inside the product decision from day one, as co-owners of scope, not as a gate that reviews what engineering already built. A PM who treats them as a downstream sign-off will spend far more time re-litigating scope after the fact than they would have spent involving them upfront.

This dual identity is a sharper version of a pattern that shows up across regulated life sciences generally; the complete guide to biotech and pharma product management covers how it plays out across devices, diagnostics, and drugs. The same evidence-first posture is reshaping adjacent biotech PM work too — AI is changing what a PM owns in drug discovery in a structurally similar way, where a model's output becomes a claim, and a claim becomes a regulated artifact with its own paper trail.

When Marketing Copy Becomes a Regulated Claim

The collision isn't only clinical versus engineering — it's marketing versus both. A growth team's normal instinct is to iterate landing-page copy freely, testing whichever headline converts best this week. For a DTx, a headline like "clinically proven to reduce anxiety" is a regulated claim, not a copy variant, and it needs the same substantiation the FTC expects of any health-related advertising claim: competent and reliable scientific evidence behind the specific wording, not just behind the product generally.

The FDA's own General Wellness policy, first issued in 2016 and updated in 2019, carves out enforcement discretion for low-risk products that make broad lifestyle claims ("supports a healthy sleep routine") without referencing a specific disease or condition. Cross that line — naming an actual disease, or implying diagnosis or treatment — and the product needs to be evaluated as SaMD, whatever the marketing team intended.

In practice, that means claims copy for a DTx belongs on the same review path as a clinical requirement. Regulatory and legal should be co-approvers of headline language, not a post-hoc check before a launch email goes out.

The FDA/IMDRF SaMD Risk Framework: Classify Before You Roadmap

Before writing a single user story, classify the product using the International Medical Device Regulators Forum's (IMDRF) SaMD risk framework, which the FDA has adopted as its working model. Risk rises with how directly the software's output drives a clinical decision, and how serious the underlying condition is — and that classification sets your evidence burden, your change-control obligations, and often your entire release cadence.

The Two Axes That Set Your Risk Category

The framework crosses two questions: how significant is the information the SaMD provides to a healthcare decision, and how serious is the healthcare situation or condition it touches?

A symptom-tracking app that helps a patient remember appointments for a mild condition sits at Category I — low evidence burden, mostly usability and safety data. A closed-loop algorithm that adjusts insulin dosing for diabetes sits at Category IV — a critical condition, treated directly — and the evidence expectations approach what you'd build for a Class III hardware device.

Where This Maps to FDA's Traditional Device Classes

The IMDRF categories are the international, product-agnostic layer; in the US they still translate into the FDA's familiar Class I, II, and III device classes, each with its own clearance pathway. Most prescription DTx today clear through 510(k) (relying on a predicate device) or De Novo (no predicate exists but risk is manageable through general and special controls), not the far heavier PMA pathway reserved for Class III devices. That's rarely an accident — sponsors scope their claims narrowly enough, on purpose, to land in a lower class.

Once you know your category, the FDA, Health Canada, and the UK's MHRA jointly published ten Good Machine Learning Practice guiding principles in 2021 that function as a practical checklist for how to generate that evidence responsibly — covering things like using representative datasets, involving multidisciplinary expertise, and monitoring for performance drift once deployed. Treat it as a companion document, not a separate compliance exercise bolted on afterward.

Locked vs. Adaptive Algorithms: The Decision That Shapes Your Whole Roadmap

A locked algorithm produces the same output for the same input every time it ships, so its clinical evidence stays valid until you intentionally change it and revalidate. An adaptive algorithm keeps learning after deployment, which means the version a regulator evaluated may not be the version a patient is actually using next month.

That single distinction decides whether you need a new submission for every meaningful change, or can operate inside a pre-approved change envelope — and it's arguably the highest-leverage product decision you'll make before writing any code.

Most DTx ship locked at first clearance, and for good reason: it's dramatically cheaper to defend a fixed artifact than a moving one, and adaptivity that isn't core to the value proposition just adds regulatory surface area for no product benefit.

The Predetermined Change Control Plan (PCCP) Pathway

If continuous learning genuinely is the value proposition — an algorithm that should get better as it sees more patients — the FDA's Predetermined Change Control Plan (PCCP) guidance, finalized in late 2024, gives sponsors a way to pre-specify what will change and how. A PCCP bundles two things: a description of the planned modifications (what the model is allowed to learn or adjust) and a protocol for how those changes will be controlled, verified, and documented, so bounded updates can ship without a fresh submission each time.

The catch is sequencing: a PCCP has to be written and cleared before the adaptive behavior ships, not retrofitted onto a model that's already learning in production. Practical implications for the roadmap:

• Lock the algorithm for your first submission unless adaptivity is the entire point of the product.
• Write the change protocol before you build the feature, since a PCCP submitted after the fact doesn't cover behavior already deployed.
• Version every model artifact with the same rigor you'd version a controlled document, including training data lineage.
• Treat "retrain" as a regulated event, not a routine deploy — the same discipline covered in our guide to computer system validation and Part 11 for PMs, applied to a model instead of a database.

The training data behind any adaptive model is itself a product requirement, not a data-science implementation detail — provenance, completeness, and auditability of that data need to be specified with the same care as a functional requirement, which is exactly the territory covered in data integrity as a product requirement in life sciences.

Scoping an MVP That Still Clears the Evidentiary and Claims Bar

Scope a DTx MVP around the smallest claim you can substantiate with existing literature plus your own usability and adherence data — not around the smallest feature you can build. A prescription digital therapeutic for chronic insomnia, for instance, can ship v1 as a locked, script-based delivery of cognitive behavioral therapy for insomnia (CBT-I) with a mechanism-level claim, deferring a harder outcome claim to the pivotal trial that follows.

This isn't hypothetical: Somryst, a prescription DTx from Pear Therapeutics, was cleared by the FDA in 2020 to deliver CBT-I for chronic insomnia, built on a mechanism with decades of independent clinical literature behind it rather than a novel therapeutic claim invented from scratch. Leaning on an already-validated mechanism is precisely what makes a defensible MVP possible in a category where a from-scratch efficacy claim would otherwise take years to support.

A Practical Scoping Sequence

Consider how a team following that pattern might sequence its own roadmap:

1. Anchor the claim to a mechanism already validated in peer-reviewed literature — CBT-I's efficacy for insomnia is well established — instead of a novel outcome claim that would need its own dedicated trial.
2. Ship the MVP as a locked, non-adaptive delivery engine. Content sequencing, not personalization ML, so the evidence file only has to cover one static version.
3. Separate the mechanism claim from the outcome claim. "Delivers CBT-I as designed" is defensible with existing literature and a usability study; "reduces sleep-onset latency by N minutes" needs a powered trial of your own — launch on the first while designing the second.
4. Bake risk management and software lifecycle documentation into the MVP scope itself, following standards like ISO 14971 and IEC 62304, rather than treating them as phase-two cleanup.
5. Write the claim and its supporting evidence into the spec before a single screen is designed, so design work and evidence generation move in lockstep instead of design outrunning what you can prove.

What stays out of the MVP matters as much as what's in it. Adaptive personalization, EHR integrations, and novel sensing all expand either the risk category or the change-control burden without necessarily strengthening the core claim — each deserves its own deliberate scoping decision later, not a default inclusion now because it's technically easy to build.

Ground the Claim in a Real Job, Then Keep It Traceable

The MVP scoping above only holds up if the claim traces back to a job the patient or clinician actually has, and if every requirement, claim, and piece of evidence stays linked as the spec evolves through the rest of development. That's the connective tissue between clinical strategy and everyday backlog work.

Mapping that same patient's emotional arc across onboarding, adherence dips, and eventual outcome — the kind of work covered in our customer journey mapping guide — tends to surface where adherence actually breaks down well before a real-world evidence study would.

Readiness gates are designed to hold a spec back until the evidence linked to a claim is actually present — the same discipline a design history file demands, applied to the document your team is already writing in.

Key Takeaways

• Classify first, build second. Run every SaMD idea through the IMDRF/FDA risk framework before scoping features — the category sets your evidence and change-control burden.
• Lock unless adaptivity is the product. Ship v1 as a locked algorithm and reserve the PCCP pathway for cases where continuous learning is genuinely core to the value proposition.
• Separate mechanism claims from outcome claims. An MVP can defensibly claim it delivers a validated mechanism while deferring a harder efficacy claim to its own dedicated trial.
• Treat every algorithm change as a regulated event. Version, document, and validate model updates with the same rigor as a computer-system-validation record, not as a routine deploy.
• Write claims into the spec before the UI. Requirements, claims, and evidence should be traceable in one place so a design change can never silently outrun what you can prove.
• Start from the job, not the mechanism. Ground the therapeutic claim in a real job-to-be-done so the evidence you eventually generate answers a question patients and clinicians actually asked.