Fractional AI Product Manager · Boston, MA

Hire an AI product manager in Boston.

Boston's medtech and biotech sector: Boston Scientific, Insulet, Rapid7, the biotech corridor along Route 128, builds AI products where the regulatory pathway determines the product strategy. An AI tool that influences a clinical decision may be a Software as a Medical Device under FDA guidance. A PM who does not know this writes a spec for a product that requires 510(k) clearance without knowing it. That is an 18-month delay.

A fractional AI PM for regulated industries owns the regulatory pathway analysis, writes the IRB determination memo, and includes failure mode handling in the spec before engineering touches the feature. The compliance work is not added after the fact. It is the first section in the spec.

Fixed engagement, fixed price, scoped to your product. Scope agreed before work starts.

How we work

Tell us about your regulated AI product challenge.

What AI product management requires in regulated industries.

Consumer AI product management focuses on adoption metrics, A/B test results, and model performance benchmarks. Regulated industry AI product management adds three requirements that consumer products do not face.

Regulatory pathway ownership: the PM determines whether the product is a regulated device before the spec is written, not after. FDA's SaMD framework classifies AI tools that process patient data or influence clinical decisions. An AI tool that analyzes imaging data and highlights areas of concern for a radiologist is almost certainly a device. A spec written without knowing this fact will not match the clearance requirement.

Design controls: FDA requires that software products follow a documented design control process that includes design inputs, design outputs, verification, and validation. The PM owns the design control documentation, not just the feature spec. These are not the same document.

Risk management: ISO 14971 requires that medical device manufacturers identify hazards, estimate the probability and severity of harm, and implement risk controls. For an AI feature, the risk analysis includes both the hazards of correct outputs used inappropriately and incorrect outputs used as intended. The PM writes the risk analysis in parallel with the feature spec.

FDA SaMD pathway ownership.

The PM determines the regulatory classification before engineering starts. Every other spec decision depends on it.

SaMD classification analysis

A written determination of whether the AI feature meets the FDA definition of Software as a Medical Device, which classification applies, and whether 510(k) clearance, De Novo review, or the CDS exemption is the appropriate pathway.

Intended use and indications for use

Two distinct documents that the FDA distinguishes. Intended use describes what the product does. Indications for use describes which patients, conditions, and clinical settings the product is designed for. Both are written before engineering starts.

Predicate identification for 510(k)

If the product requires 510(k) clearance, the PM identifies the predicate device or devices the submission will rely on. Predicate selection is a product decision with regulatory consequences. Engineering cannot make it.

Design control plan

A plan for how the design control process will run: who owns each design control activity, what the review checkpoints are, and what documentation will be submitted in the 510(k). Written before the first sprint.

IRB review and clinical failure mode requirements.

IRB review is required when an AI tool involves research with human subjects. The PM owns the IRB determination, which means the PM writes a memo that analyzes the 45 CFR 46 criteria and reaches a reasoned conclusion. Asking the IRB whether review is needed without that memo produces a slower answer and occasionally a more conservative determination.

Boston-area teaching hospitals including Mass General and Brigham and Women's have IRB offices that review AI deployment requests with increasing frequency. A PM who has submitted an IRB determination memo before moves faster through that process than one doing it for the first time.

Clinical AI failure mode specifications differ from consumer failure mode specifications in one critical way. When a consumer AI feature is wrong, the user is inconvenienced. When a clinical AI feature is wrong, the consequence may include a delayed diagnosis or an inappropriate treatment decision. The failure mode spec must define what the AI does when it is uncertain, and the answer must favor the clinician's judgment, not the model's confidence score.

Every clinical AI spec should include a section titled "What the AI does when it does not know." That section is reviewed by the quality team and the clinical advisory board before the feature enters development. At Insulet, the diabetes management context makes failure mode analysis a design control artifact, not just a product document.

How we work.

Regulatory pathway first

The first deliverable is the regulatory classification memo. Everything else follows from that determination. We do not write functional specs before the regulatory pathway is clear.

Documentation that survives review

Specs are written to satisfy both the engineering team and the regulatory reviewer. Two audiences, one document structure. No separate compliance documents added after the fact.

Fixed scope, no surprises

Written scope and fixed price before work starts. Regulatory work is scoped conservatively to account for review cycles. Change orders for scope changes, not for regulatory complexity that was visible at scoping.

Questions from Boston regulated-industry product teams.

What FDA SaMD classification applies to a clinical decision support AI tool?: FDA Software as a Medical Device classification for a clinical decision support AI tool depends on two factors: the seriousness of the condition the tool addresses and the significance of the tool's role in the clinical decision. Under the FDA's 2022 Clinical Decision Support guidance, an AI tool that analyzes patient-specific data and provides a recommendation that a clinician is expected to rely on without independent review is likely a device. An AI tool that provides general reference information a clinician can independently verify using standard medical knowledge may qualify for the non-device CDS exemption. The line matters: a tool that incorrectly claims the non-device exemption has marketed an uncleared device, which triggers enforcement risk. Boston Scientific and Insulet ship products in categories where this distinction determines whether a product needs 510(k) clearance. The PM owns the regulatory pathway determination. Writing a spec for a clinical AI tool without knowing the classification is writing a spec for an unknown product.
When does an IRB need to be involved in reviewing an AI tool a hospital wants to deploy?: IRB review is triggered when an AI tool involves research with human subjects, defined by 45 CFR 46 as a systematic investigation designed to develop or contribute to generalizable knowledge that involves human subjects. Three scenarios relevant to hospital AI deployments: first, if the AI tool is being evaluated in a clinical study where patient outcomes are collected to validate model performance, IRB review is required. Second, if the AI tool processes identifiable patient data and the vendor or institution intends to publish or generalize findings, IRB review is likely required. Third, if the AI tool is deployed as a standard of care without a comparative study, IRB review may not be required but the institution's IRB should make that determination, not the product team. The PM owns the regulatory pathway, which means the PM writes the IRB determination memo, not the legal team. Boston-area teaching hospitals including Mass General and Brigham and Women's have their own IRB processes that differ from community hospital requirements.
What does failure mode handling look like in a healthcare AI product spec?: Failure mode handling in a healthcare AI product spec covers three levels. Model-level failure: what the feature does when the model confidence score falls below the defined threshold. The spec must state whether the feature surfaces the confidence score to the user, what the display text is, and whether the feature recommends a human review rather than an AI output. System-level failure: what the feature does when the model API is unavailable, when input data is missing or malformed, or when a downstream data feed is stale. The spec must define whether the feature fails open (shows a best-effort output with a warning) or fails closed (blocks output and routes to a human). For clinical AI tools, failing closed is almost always the correct choice. User-level failure: what happens when the clinician disagrees with the AI output. The spec defines the override path, the override log entry, and what information is retained for model improvement. At Boston Scientific and Insulet, the failure mode spec is reviewed by the quality management team as part of design controls before the feature enters development.
How do you write a product spec that satisfies both the engineering team and an FDA reviewer?: A product spec that satisfies both engineering and an FDA reviewer uses a layered structure with distinct sections for each audience. The functional requirements section describes what the feature does in user-facing terms: inputs, outputs, user workflows, and success criteria. The design controls section documents the intended use, the indications for use, the user population, the use environment, and the risk analysis. The verification and validation section defines the test protocol, the test dataset, the acceptance criteria, and the methodology for measuring model performance. The risk management section references the applicable standards (typically ISO 14971 for medical devices) and documents the identified hazards, the severity and probability estimates, and the risk controls implemented. An FDA reviewer reading the design controls and V&V sections should be able to determine the product's intended use, the evidence of its performance, and the controls in place to manage known risks. An engineering team reading the functional requirements section should be able to build and test the feature without asking for clarification. A spec written only for engineers will not survive regulatory scrutiny. A spec written only for regulators will produce a product that does not match what users need.

Start with the regulatory pathway question.

Describe the AI feature you are building and what you already know about its regulatory context. We reply within one business day.

Hire an AI product manager in Boston.

Fixed engagement, fixed price, scoped to your product. Scope agreed before work starts.

What AI product management requires in regulated industries.

FDA SaMD pathway ownership.

The PM determines the regulatory classification before engineering starts. Every other spec decision depends on it.

SaMD classification analysis

Intended use and indications for use

Predicate identification for 510(k)

Design control plan

IRB review and clinical failure mode requirements.

How we work.

Regulatory pathway first

The first deliverable is the regulatory classification memo. Everything else follows from that determination. We do not write functional specs before the regulatory pathway is clear.

Documentation that survives review

Specs are written to satisfy both the engineering team and the regulatory reviewer. Two audiences, one document structure. No separate compliance documents added after the fact.

Fixed scope, no surprises

Questions from Boston regulated-industry product teams.

What FDA SaMD classification applies to a clinical decision support AI tool?

FDA Software as a Medical Device classification for a clinical decision support AI tool depends on two factors: the seriousness of the condition the tool addresses and the significance of the tool's role in the clinical decision. Under the FDA's 2022 Clinical Decision Support guidance, an AI tool that analyzes patient-specific data and provides a recommendation that a clinician is expected to rely on without independent review is likely a device. An AI tool that provides general reference information a clinician can independently verify using standard medical knowledge may qualify for the non-device CDS exemption. The line matters: a tool that incorrectly claims the non-device exemption has marketed an uncleared device, which triggers enforcement risk. Boston Scientific and Insulet ship products in categories where this distinction determines whether a product needs 510(k) clearance. The PM owns the regulatory pathway determination. Writing a spec for a clinical AI tool without knowing the classification is writing a spec for an unknown product.

When does an IRB need to be involved in reviewing an AI tool a hospital wants to deploy?

IRB review is triggered when an AI tool involves research with human subjects, defined by 45 CFR 46 as a systematic investigation designed to develop or contribute to generalizable knowledge that involves human subjects. Three scenarios relevant to hospital AI deployments: first, if the AI tool is being evaluated in a clinical study where patient outcomes are collected to validate model performance, IRB review is required. Second, if the AI tool processes identifiable patient data and the vendor or institution intends to publish or generalize findings, IRB review is likely required. Third, if the AI tool is deployed as a standard of care without a comparative study, IRB review may not be required but the institution's IRB should make that determination, not the product team. The PM owns the regulatory pathway, which means the PM writes the IRB determination memo, not the legal team. Boston-area teaching hospitals including Mass General and Brigham and Women's have their own IRB processes that differ from community hospital requirements.

What does failure mode handling look like in a healthcare AI product spec?

Failure mode handling in a healthcare AI product spec covers three levels. Model-level failure: what the feature does when the model confidence score falls below the defined threshold. The spec must state whether the feature surfaces the confidence score to the user, what the display text is, and whether the feature recommends a human review rather than an AI output. System-level failure: what the feature does when the model API is unavailable, when input data is missing or malformed, or when a downstream data feed is stale. The spec must define whether the feature fails open (shows a best-effort output with a warning) or fails closed (blocks output and routes to a human). For clinical AI tools, failing closed is almost always the correct choice. User-level failure: what happens when the clinician disagrees with the AI output. The spec defines the override path, the override log entry, and what information is retained for model improvement. At Boston Scientific and Insulet, the failure mode spec is reviewed by the quality management team as part of design controls before the feature enters development.

How do you write a product spec that satisfies both the engineering team and an FDA reviewer?

A product spec that satisfies both engineering and an FDA reviewer uses a layered structure with distinct sections for each audience. The functional requirements section describes what the feature does in user-facing terms: inputs, outputs, user workflows, and success criteria. The design controls section documents the intended use, the indications for use, the user population, the use environment, and the risk analysis. The verification and validation section defines the test protocol, the test dataset, the acceptance criteria, and the methodology for measuring model performance. The risk management section references the applicable standards (typically ISO 14971 for medical devices) and documents the identified hazards, the severity and probability estimates, and the risk controls implemented. An FDA reviewer reading the design controls and V&V sections should be able to determine the product's intended use, the evidence of its performance, and the controls in place to manage known risks. An engineering team reading the functional requirements section should be able to build and test the feature without asking for clarification. A spec written only for engineers will not survive regulatory scrutiny. A spec written only for regulators will produce a product that does not match what users need.

Start with the regulatory pathway question.

Describe the AI feature you are building and what you already know about its regulatory context. We reply within one business day.