Clinical Product Is an Embedded Role, Not a Consulting Function

There's a common misconception about the use of clinicians within the product process: that it's a consulting function. It's easily treated as if it were a clinical expert who parachutes in, reviews something, gives an opinion, and leaves.

In reality, that's not how it works - or at least, that's not how it works when it's done well.

The most effective use of clinicians within the product process is through an embedded clinical product function. The role needs to sit within product teams, and they should have responsibility for the outcome of the product itself.

Consequences of the consulting setup

When clinical product operates as a consulting function, a few things tend to happen:

Clinical input arrives too late. The team has already made most of the decisions. You're asked to shout if there's anything critically wrong. Sometimes - and I speak from experience - you don't know where to begin with what's wrong.

If there's a problem, the cost of changing course is high, and the dreaded 'blocker' label gets applied to you. So you're requested (and incentivised) to only highlight truly clinically unsafe features, rather than shouting when something makes little clinical sense.

Accountability becomes diffuse. You give advice but aren't involved in the development of the product to ensure that advice was correctly interpreted. The product team drives the development based on their interpretation of your advice. When something goes wrong, it's unclear who owns it. Everyone has plausible deniability.

Clinical product review becomes a tick-box exercise. The relationship between the product team and you becomes transactional: "Can you sign this off?" rather than "What do you think?"

None of this is intentional, but it's what happens when clinical expertise is bolted on rather than built in.

What embedded actually means

Embedded clinical product means being part of the team - present in planning, involved in trade-offs, and accountable for what ships.

It means:

• Shaping the team's goals and the product's direction, not just reviewing the current ticket
• Understanding the constraints, not just the clinical ideal
• Being in the room when decisions are made, not being briefed afterwards
• Owning clinical risk as part of the product, not as an external reviewer

This doesn't mean the clinical product person makes all the decisions. It means clinical considerations are part of the decision-making process from the start - not something layered on at the end.

Why is 'consulting' acceptable for other functions?

Not every function needs to sit inside the product team. Legal and regulatory reviews, for example, often work well as a stakeholder checkpoint. So why is clinical product different?

The difference comes down to the nature of the work itself:

Regulatory requirements are codified. There's a written standard. You learn what terminology you can and can't use, what claims require what evidence, what disclosures need to appear where. The rules don't change from sprint to sprint. A regulatory reviewer can give input at ideation - is this idea feasible from a regulatory point of view? - and at near-finished product - has the product remained compliant? - against a known set of criteria.

In my team, clinical product leads are expected to understand these regulations too - MHRA Blue Guide, Advertising Standards, CQC and GPhC requirements, GDPR, medical device - and can give a lot of steer here. They're better informed in understanding when to bring in external stakeholders and can ensure they're consulted at the right time.

Clinical judgment isn't like that. There's no checklist that tells you whether a user flow makes clinical sense. No reference document that confirms whether an edge case is acceptable. Clinical risk lives in the detail - in how information is presented, in what happens when users behave unexpectedly, in the interaction between features that were designed separately.

Clinical review also isn't a one-time gate. Regulatory review happens at defined points, for example, before launch or before a major update, whereas clinical considerations are continuous. They surface in sprint planning, in design reviews, in QA, in post-launch monitoring.

Why this matters

When clinical product is embedded, it's not just about catching clinical risk earlier - it's about building clinically good products in the first place.

Embedded clinical product shapes products that deliver positive health outcomes, that give patients and clinicians a good experience, that fit sensibly into clinical pathways and workflows. It also means bringing innovative new technology into the product early - identifying where emerging tools or approaches could genuinely improve care, not just bolting them on as an afterthought.

Risk reduction is part of that, but it's a byproduct of good design, not the sole focus.

When clinical input comes early, problems surface when they're still cheap to fix. Trade-offs can be made deliberately, not discovered in QA. But more than that - the product gets better. It makes more clinical sense. It works the way patients and clinicians actually need it to.

Beyond the immediate benefits, trust builds too. Product teams learn what clinical risk actually looks like. Clinical product learns what delivery pressure actually feels like. The conversation shifts from "Can we ship this?" to "How do we ship this well?"

That shift is the difference between clinical product as a gate and clinical product as a partner.

The practical challenge

Embedding takes time. It requires clinical product to understand the product deeply - not just the clinical domain, but the technical architecture, the user flows and the edge cases. It requires presence: being available, being responsive, being part of the team's rhythm.

It also requires a shift from product managers who haven't worked in healthtech before. They may not be used to co-navigating product development with a clinical counterpart - having someone with equal stake in the direction of the product, whose input isn't optional. That adjustment goes both ways.

And it requires organisations to structure the role that way. One Clinical Product Manager spread across six teams isn't embedded in any of them. They're consulting by default, no matter what the job description says.

If you're building clinical product capability, start with the structural question: is this person genuinely part of the team, or are they being asked to advise from the outside?

The answer will determine what kind of clinical ownership is actually possible.

This post is part of a series on what Clinical Product actually is. Subscribe to be notified of new posts.