Product management in regulated environments

There’s a story product people tell about regulated industries, which is that nothing ships and everything takes eighteen months.

I’ve worked in fintech and in regulated enterprise, and the story isn’t wrong about the outcome. It’s wrong about the cause. What slows these organisations down is rarely the regulation itself. It’s that the regulatory work is discovered late, by people who weren’t in the room when the thing was designed.

What actually changes

You have to be able to show your work. This is the single biggest difference and most of the others follow from it. In an unregulated product, a decision exists in someone’s memory and a Slack thread. In a regulated one, it has to be demonstrable later to someone who wasn’t there, possibly years later, possibly hostile. That’s a design constraint, not a documentation task, and it’s much cheaper to satisfy if you decide it up front.

Some decisions leave your control entirely. There are things you cannot A/B test, can’t roll out to 10% of users, and can’t change without notice. Knowing which ones before you plan the release is most of the skill.

The definition of done moves. Built and working isn’t done. Done includes the control being in place, the evidence being capturable, and somebody in a second-line function having agreed that what you built matches what was approved.

Your architecture gets an audience. This is where DORA lands on AI systems for anyone in EU financial services. Data residency, retention, access, segregation. These are usually treated as infrastructure concerns and they’re product concerns, because they determine which features are possible at all.

What doesn’t change

Discovery still works. Users still don’t know what they want. Prioritisation is still the job. The regulated environment does not suspend product management. I say that because people arriving from unregulated products sometimes behave as though it does and become order-takers for the compliance function.

That’s a mistake in the opposite direction and it produces the eighteen-month timeline just as reliably.

The relationship that decides everything

Whether you’re fast or slow in this environment comes down almost entirely to when compliance and legal enter the conversation.

What does the slow pattern look like? Design the thing, build the thing, submit for review, discover a problem that invalidates a decision made four months ago, rework. Everyone blames the reviewer.

The fast pattern: bring them in while the options are still open, with a specific question rather than a finished artefact. "We are considering three approaches to this, and here is what each one does with customer data. Which of these creates a problem?" That conversation takes forty minutes and it’s the cheapest forty minutes in the project.

What makes this work is asking about options rather than seeking approval. Reviewers asked to approve a finished thing can only say yes or no. Reviewers asked which of three routes is problematic will tell you things you didn’t know to ask.

I’d go further: the compliance and legal people in a regulated organisation usually know more about how the product actually behaves than anyone outside the delivery team, because they see the complaints. Treating them as a discovery source rather than a gate is the single highest-return change available.

The fragmentation problem, which is getting worse

One practical thing that has changed recently and does not get enough attention in product circles.

High-level regulatory standards remain broadly global while implementation is fragmenting, with the US, EU, UK and Asia-Pacific taking distinct approaches. For a product team, that has an architectural consequence: the same feature increasingly needs to behave differently by jurisdiction, and if that variation isn’t designed in early it arrives later as a fork.

The EU AI Act’s Article 50 transparency obligations, applicable since 2 August 2026, are a live example. If you’re shipping into Europe, one region’s disclosure requirements now shape an interface that other regions don’t need. You either build for configuration or you build twice.

On the statistics in this field

A note, because I try to check what I repeat —

You will see a claim that the finance sector averages two hundred regulatory changes a day. It traces to a Thomson Reuters estimate from 2016. It may well still be directionally right and it’s a decade old, so I wouldn’t put it in a business case without saying so.

More broadly, most of the "regulatory burden" content aimed at product teams is published by firms selling compliance software or advisory services. That doesn’t make it wrong. It does mean the framing consistently favours buying something, and the actual constraint in most teams I’ve seen is when people talk to each other rather than which platform they own.

What I do differently here

I write the evidence requirement into the requirement. Alongside what the system does, what it will need to demonstrate afterwards. This is part of what makes a requirement survive delivery in this context.

I find out early which decisions are irreversible. Anything that can’t be rolled back changes how it gets released, and finding that out during release planning is too late.

I keep a register of what we decided and why. Not for the regulator. For the version of my team that’s asked in two years and can’t remember. The use-case register is a specific instance of this habit.

I ask what a supervisor would want to see. Not what the rule says, but what evidence would satisfy someone examining it. Those are different, and the second is the one that determines whether you pass.

The part people get wrong about speed

Regulated organisations aren’t slow because of controls. They are slow because the controls are discovered late and applied by people with no context, at the point where changing anything is expensive.

I’ve seen regulated teams ship faster than unregulated ones. The difference was never appetite for risk. It was that they knew, at design time, which constraints were real.

Common questions

Is product management different in a regulated industry?

The core work is the same: discovery, prioritisation, deciding what to build. What changes is that decisions must be demonstrable to someone who was not present, some choices cannot be tested incrementally or reversed, and done includes the control being in place and evidence being capturable, not just the feature working.

How do you ship quickly in a regulated environment?

Bring compliance and legal in while options are still open, asking which of several approaches creates a problem rather than presenting a finished design for approval. Most delay in regulated organisations comes from discovering constraints late, after decisions have been built on, rather than from the constraints themselves.

How should a product manager work with the compliance team?

As a discovery source rather than a gate. Compliance and legal functions typically see the complaints, which means they often understand how a product actually behaves better than anyone outside the delivery team. Asking them about options produces information; asking them to approve a finished artefact produces only a yes or a no.

What is the biggest mistake product managers make in regulated industries?

Two opposite ones. Treating compliance as a final gate, which guarantees expensive late rework, and becoming an order-taker for the compliance function, which abandons the product judgement the role exists for. Both produce the same slow timeline.

Do regulatory requirements affect product architecture?

Yes, and treating them as infrastructure concerns is a common error. Data residency, retention, access and segregation determine which features are possible at all. Regulatory implementation is also fragmenting across the US, EU, UK and Asia-Pacific, so the same feature increasingly needs to behave differently by jurisdiction, which is a design decision if made early and a fork if made late.

Is it true that the finance sector sees 200 regulatory changes a day?

That figure traces to a Thomson Reuters estimate from 2016 and is widely repeated without its date. It may remain directionally accurate, but it's a decade old and should be cited with that caveat rather than presented as current.

What does "done" mean for a feature in a regulated product?

Built and working, the required control in place, the evidence of its operation capturable, and a second-line function having confirmed that what was built matches what was approved. A feature that works but cannot be evidenced isn't finished.