---
title: The Subtraction Audit for Regulated Products
description: A subtraction audit for MedTech: cut every feature that does not improve experience, speed, revenue, or regulatory necessity before it eats your budget.
authors: Tibor Zechmeister, Felix Lenhard
category: MedTech Startup Strategy & PMF
primary_keyword: subtraction audit regulated product MDR
canonical_url: https://zechmeister-solutions.com/en/blog/subtraction-audit-regulated-products
source: zechmeister-solutions.com
license: All rights reserved. Content may be cited with attribution and a link to the canonical URL.
---

# The Subtraction Audit for Regulated Products

*By Tibor Zechmeister (EU MDR Expert, Notified Body Lead Auditor) and Felix Lenhard.*

> **A subtraction audit asks one question of every feature in your MedTech product: does it improve user experience, time-to-ship, revenue, or regulatory necessity? If it fails all four tests, cut it. Under MDR, every kept feature expands your intended purpose, classification risk, verification and validation burden, and post-market surveillance obligations. Scope is not free.**

**By Tibor Zechmeister and Felix Lenhard.**

## TL;DR
- Every feature in a MedTech product carries recurring regulatory cost, not just build cost.
- Under MDR Article 10 and Article 52, conformity obligations scale with the scope of what you place on the market.
- A feature that broadens intended purpose (Article 2(12)) can jump your device into a higher class under Annex VIII.
- The subtraction audit uses four questions: experience, speed, revenue, regulatory necessity.
- A feature that fails all four is not neutral. It is a tax on certification, V&V, risk files, and post-market surveillance.
- Shipping a smaller device faster beats shipping a bigger device eventually.

## Why scope is the most expensive decision you will make

Most MedTech founders treat feature decisions the way software founders do: add it if it is cheap to build, cut it if it is expensive. That calculation breaks under the MDR.

In regulated products, the cost of a feature is not what it costs to write the code or source the component. The cost is the weight it adds to your technical documentation (Annex II), your general safety and performance requirements mapping (Annex I), your risk file (EN ISO 14971:2019+A11:2021), your verification and validation evidence, your usability engineering file (EN 62366-1:2015+A1:2020), your clinical evaluation, your labelling, and the post-market surveillance plan you will carry for the life of the product (Annex III, Articles 83-86).

One feature is rarely one feature. A measurement you display is a claim. A claim is evidence. Evidence is testing. Testing is a report. The report becomes part of the file the notified body reviews, the auditor challenges, and the vigilance authority scrutinises if anything goes wrong.

The founders who ship fastest are not the ones who build fastest. They are the ones who decided not to build most of what they originally scoped.

## What MDR actually says about scope

Scope under the MDR is defined by your intended purpose. Article 2(12) of Regulation (EU) 2017/745 defines intended purpose as *"the use for which a device is intended according to the data supplied by the manufacturer on the label, in the instructions for use or in promotional or sales materials or statements and as specified by the manufacturer in the clinical evaluation"*.

This sentence has teeth because of what connects to it:

- **Annex VIII classification**. Your risk class is determined by rules that read the intended purpose. More intent, more contact, more duration, more claims. Higher class. A Class IIa pivot to Class IIb doubles the evidence and adds a notified body audit of your technical documentation per device type.
- **Article 10 obligations**. These attach to whatever you place on the market. Every additional feature expands the obligations: QMS scope, risk management, clinical evaluation, technical documentation, post-market surveillance, vigilance, registration.
- **Article 52 conformity assessment**. The route you choose depends on class, which depends on intended purpose, which depends on what features you kept.
- **Annex I GSPR**. Every relevant general safety and performance requirement must be addressed for the device as specified. A wider specification means more GSPRs apply and more evidence is needed to demonstrate conformity.

The loop is simple. Feature → claim → intended purpose → classification → conformity assessment → evidence → documentation → post-market burden. You pay for every feature four times: once in engineering, once in evidence, once in audit exposure, once in lifecycle maintenance.

## The four-question subtraction audit

Run every feature through these four questions. The feature must pass at least one to stay in the product. If it fails all four, it leaves.

**1. Does it measurably improve user experience for the beachhead user?**

Not "nice to have". Not "users might like it". Measurable improvement for the specific clinical user or patient you are targeting first. If you cannot describe the improvement in one sentence that a clinician would recognise, the feature does not pass.

**2. Does it accelerate time-to-first-revenue?**

Shipping a device three months earlier often matters more than any single feature. If cutting a feature compresses the certification path. Fewer test reports, less clinical evidence, shorter notified body review. That is real, quantifiable speed.

**3. Does it unlock revenue that justifies its full lifecycle cost?**

Not launch revenue. Lifecycle revenue. A feature that adds €40,000 in testing and €15,000 per year in post-market surveillance effort needs to clear that bar across five years before it earns its place.

**4. Is it regulatorily necessary?**

Some features you cannot cut. An alarm required by EN 60601-1-8 for a specific device type is not optional. Cybersecurity controls required by MDR Annex I §17.2 and §17.4 are not optional. Safety-critical error handling required by the device's intended use is not optional. This question exists so you do not accidentally remove something safety-essential in the zeal of subtraction.

If a feature fails questions one, two, and three, and is not regulatorily necessary, it gets cut. Not "phase 2". Not "backlog". Cut from the intended purpose statement, the claims, the labelling, the software requirements, and the risk file.

## A worked example: the SaMD that almost shipped two devices

A digital health startup we worked with built a software platform for post-surgical recovery monitoring. The original scope had eight core features. Two are illustrative here:

- **Feature A**: recovery pain trend display for the patient, used to guide self-reported follow-up.
- **Feature B**: a threshold-based alerting mechanism that would notify the clinician if pain scores exceeded a configured level, with escalation logic and documented response tracking.

Feature A is essentially an information display sourced from patient self-report. It qualifies as a medical device under Rule 11 of Annex VIII and classifies at a modest level (we will not anchor the exact class here since software classification under Rule 11 depends on the specifics of the decision being supported. See MDCG 2019-11 Rev.1).

Feature B is different in kind. Alerting tied to clinical escalation and documented clinical response turns the software into something that directly drives clinical decisions, with the associated classification and evidence weight. It meaningfully expanded the intended purpose and pulled in additional clinical evaluation requirements, usability considerations under EN 62366-1:2015+A1:2020, and a heavier software safety classification under EN 62304:2006+A1:2015.

The founders ran the four-question audit on Feature B:

1. **Experience**: yes, some clinicians said it would be useful, but the primary beachhead user (post-surgical nursing coordinators) said it would create alarm fatigue and they would disable it.
2. **Speed**: cutting Feature B compressed the clinical evaluation scope, reduced the software safety class justification burden, and removed an entire usability evaluation pathway. Estimated time saved to CE mark: four months.
3. **Revenue**: no customer had made the alerting feature a purchase condition. The buyers wanted the monitoring platform; alerting was a "maybe later".
4. **Regulatorily necessary**: no. Without the feature, the device still served its intended purpose safely.

Feature B was cut. The intended purpose was rewritten without it. The CE mark arrived months earlier. Feature B was added back eighteen months later as a scoped-in design change. By which point the company had revenue, PMS data from real use, and a much cleaner evidence basis for adding it.

This is the point: subtraction is not refusal. It is sequencing. You ship the narrower device, you learn from it in the market, and you add the next thing with the benefit of real evidence and real money.

## The Subtract to Ship playbook for a feature audit

Here is how to run the audit on your current feature list this week.

**Step 1. List every feature as a claim, not a capability.** Rewrite "displays heart rate" as "claims to display heart rate accurate to X bpm for Y population". Features become claims when you ship them, so write them as claims now.

**Step 2. Map each claim to the MDR machinery it triggers.** Does it expand intended purpose? Does it pull in a classification rule you were not in before? Does it require new GSPR evidence? Does it increase software safety class? Does it add a usability risk? Does it require clinical data you do not have?

**Step 3. Score each claim against the four questions.** Be honest. "Users would like it" is not experience improvement. "We already built it" is not a reason to keep it.

**Step 4. Cut everything that fails all four.** Update the intended purpose statement. Update the labelling drafts. Update the software requirements. Update the risk file. Update the clinical evaluation plan. Subtraction is only real when it reaches the documentation.

**Step 5. Write down what you cut and why.** This is your subtraction log. When a stakeholder or investor asks "why does it not do X?", you have the answer. When you later want to add X back, the log tells you what changed and what you need to re-evaluate.

**Step 6. Re-run the audit every quarter.** Scope creep is the default state of MedTech development. The only defence is an explicit, repeated counter-force.

## Reality Check

Answer honestly.

1. Can you state your intended purpose in two sentences without using the words "and", "or", or a bulleted list?
2. For every feature in your current build plan, can you name which of the four questions it passes?
3. Have you mapped each feature to the specific GSPRs, classification rules, and evidence it triggers?
4. Have you cut any feature in the last 90 days? If not, your scope is almost certainly still too wide.
5. Do you have a subtraction log that captures what was cut and why?
6. Is there a feature on your list that no customer has ever made a purchase condition?
7. If you removed your three most controversial features, would your beachhead user still buy the device?
8. What is the cheapest certifiable version of your product, and why are you not building that first?

## Frequently Asked Questions

**Is subtracting features the same as dumbing down the product?**
No. Subtraction targets features that do not pay for their lifecycle cost. A narrower intended purpose with strong evidence beats a broader intended purpose with thin evidence every single time under MDR review.

**What if investors want to see a broad feature set?**
Most MedTech investors who have funded more than one device know that scope discipline is a positive signal. If an investor is pushing you to widen scope before CE mark, they are pushing you toward slower certification, higher burn, and higher audit risk.

**Can we add features back later?**
Yes. Significant changes trigger a conformity assessment update under Article 120 and the relevant annexes, and software changes are assessed against established significant change guidance. But adding from a certified baseline is structurally easier than shipping a bloated first version.

**Does subtraction apply to Class I devices too?**
Absolutely. Class I self-certification still requires technical documentation, GSPR mapping, risk management, and PMS. Every feature in a Class I device carries real cost. The notified body is just not the one collecting it.

**How do we know if a feature is regulatorily necessary?**
Look at the applicable harmonised standards, the device-specific guidance, and the intended use safety analysis. If removal creates an unacceptable risk that cannot be mitigated by other means, it is necessary. If removal only removes a "nice to have", it is not.

**What if the engineering team objects to cutting work already done?**
Sunk cost is not a reason to ship. The cost of keeping a feature is not what you already spent. It is what you will spend on evidence, audit, and PMS for the life of the product.

## Related reading
- [The Subtract to Ship framework for MDR](/blog/subtract-to-ship-framework-mdr) – the underlying methodology this audit operationalises.
- [Subtract to Ship applied to MedTech](/blog/subtract-to-ship-applied-medtech) – how the general framework maps to regulated products.
- [Define intended purpose without over-constraining](/blog/define-intended-purpose-without-over-constraining) – why narrow scope and future optionality are not in conflict.
- [Minimum viable regulatory strategy for a CE mark with limited resources](/blog/minimum-viable-regulatory-strategy-ce-mark-limited-resources) – the counterpart discipline on the regulatory side.
- [Classification and startup pivots](/blog/classification-startup-pivots) – what happens to classification when scope changes.

## Sources
1. Regulation (EU) 2017/745 on medical devices, consolidated text. Articles 2(12), 10, 52; Annex I, Annex II, Annex III, Annex VIII.
2. MDCG 2019-11 Rev.1 (October 2019, Rev.1 June 2025). Guidance on qualification and classification of software.
3. EN ISO 14971:2019+A11:2021. Medical devices. Application of risk management to medical devices.
4. EN 62304:2006+A1:2015. Medical device software. Software life cycle processes.
5. EN 62366-1:2015+A1:2020. Medical devices. Application of usability engineering to medical devices.

---

*This post is part of the [MedTech Startup Strategy & PMF](https://zechmeister-solutions.com/en/blog/category/startup-strategy) cluster in the [Subtract to Ship: MDR Blog](https://zechmeister-solutions.com/en/blog). For EU MDR certification consulting, see [zechmeister-solutions.com](https://zechmeister-solutions.com).*