Perspective 01

Regulatory Strategy · October 2026 · 5 min read

Regulatory Is No Longer a Function at the End of Development

How the discipline is evolving from compliance and submissions toward product strategy, evidence, systems thinking, and organizational decision-making.

For much of its history, regulatory affairs has been treated as a function that becomes most visible near the end of product development.

Engineering develops the product. Clinical teams generate evidence. Quality establishes the systems and controls. Commercial teams define the market opportunity. And somewhere along the way, Regulatory determines the pathway, prepares the submission, and gets the product across the finish line.

That model has always been somewhat artificial. Increasingly, it is also inadequate.

Modern health technologies are becoming more interconnected, software-driven, data-dependent, configurable, and iterative. Products may span multiple indications, workflows, technical architectures, or markets. Artificial intelligence introduces questions about data, performance, change, and governance that cannot be separated neatly into individual functions. Connected products raise cybersecurity and privacy considerations alongside traditional safety and effectiveness questions. Evidence may come from clinical studies, real-world data, usability work, computational methods, and post-market experience.

In that environment, regulatory strategy cannot simply interpret decisions after they have already been made.

It has to help shape them.

Regulatory questions are often product questions.

Consider something as seemingly straightforward as intended use.

It is certainly a regulatory concept. But it is also a product-development decision.

Intended use affects who will use a technology, in what environment, for which patients, for what purpose, and under what conditions. Those choices influence product architecture, usability, risk controls, evidence requirements, labeling, claims, testing, and potentially the regulatory pathway itself.

The same is true of decisions about product configurations, accessories, software functions, automation, anatomical applications, or future indications.

An engineering team may view a change as technically small. A commercial team may see it as an attractive extension of the platform. A regulatory assessment may reveal that the same change alters the evidence burden, risk profile, validation strategy, or fundamental regulatory positioning of the product.

None of these perspectives is sufficient on its own.

The real work lies in understanding how they interact.

The earlier the questions are asked, the more useful the answers become.

Regulatory involvement is sometimes described in terms of “early engagement,” but timing alone is not the point.

A regulatory professional can attend every development meeting and still function primarily as a downstream reviewer.

What matters is the nature of the questions being asked.

What exactly are we trying to claim?

Which elements of the product are essential to that claim?

What assumptions are we making about users, workflow, clinical benefit, or technological performance?

Which of those assumptions will ultimately require evidence?

If we expand the product later, which decisions being made today will constrain that expansion?

Are we developing a single product, a family of products, or a platform—and does the evidence actually support the distinction?

What happens elsewhere in the system if one of these assumptions changes?

These are regulatory questions, but they are also questions of product strategy, evidence strategy, risk, and organizational decision-making.

Asked early, they can influence development.

Asked late, they often become explanations for why development has to be revisited.

The discipline is moving toward synthesis.

This does not mean regulatory professionals need to become engineers, clinicians, statisticians, cybersecurity specialists, quality experts, and business strategists simultaneously.

They do need to understand enough about each of those domains to recognize interdependencies.

That distinction matters.

Complex programs rarely fail because nobody in the organization knows anything. More often, expertise exists everywhere—but in pieces.

Engineering understands the architecture. Clinical understands the patient and evidence questions. Quality understands process and control. Commercial understands the customer. Regulatory understands the external framework.

The difficult decisions sit between them.

Someone has to ask whether those individual perspectives describe the same product, whether their assumptions are compatible, and whether the resulting strategy is coherent.

Increasingly, that ability to synthesize may be one of the most valuable capabilities within regulatory affairs.

Compliance remains essential. It is simply not enough.

None of this diminishes the traditional responsibilities of the discipline.

Organizations still need accurate submissions, sound regulatory interpretations, compliant processes, appropriate documentation, and effective interactions with authorities.

But compliance is the floor, not the full value proposition.

The more complex the technology, the less useful it becomes to separate “the regulatory strategy” from the product, evidence, risk, and development strategies surrounding it.

The strongest regulatory work helps an organization understand not merely what the rules require, but what those requirements mean for the choices it is making.

Sometimes that means identifying a viable pathway.

Sometimes it means challenging an intended use that has outpaced the evidence.

Sometimes it means recognizing that several seemingly unrelated technical changes actually create one larger strategic issue.

And sometimes it means concluding that the most important regulatory decision is not about a submission at all. It is about what product should be developed in the first place.

From gatekeeper to integrator.

The familiar image of Regulatory as the final gatekeeper is becoming less useful.

A better model is the integrator: a discipline positioned across product development, evidence, risk, quality, and organizational decision-making, helping teams understand how choices in one part of the system affect another.

That requires technical knowledge, certainly.

But it also requires curiosity, judgment, and the willingness to question assumptions before they become embedded in a development program.

For complex health technologies, regulatory strategy is increasingly not something applied to a finished product.

It is part of how a thoughtful organization decides what to build, what to prove, and how to move forward.