Building in regulated environments: what changes
Compliance is not the enemy of good product work. But it will expose every shortcut you were planning to take.
5 min read
Regulated environments have a reputation for being where good product work goes to die. Slow approvals, legal sign-off on every change, compliance teams who seem to exist purely to say no. If you have only worked in fast-moving consumer tech, the first time you hit a genuine regulatory constraint it can feel like the ground has disappeared.
But most of that reputation is earned by teams who treat regulation as an obstacle rather than a constraint to design around. There is a difference.
The constraints are real, the excuses are not
Working in insurance, banking, or government software means some things genuinely cannot move fast. A legal review that takes three weeks is not bureaucratic laziness, it is a real dependency with real consequences if skipped. Accepting that early saves a lot of frustration.
What is not acceptable is using regulation as a blanket excuse for slow thinking, poor prioritisation, or lack of clarity on what actually requires sign-off and what does not. In most regulated environments, the majority of product decisions do not touch compliance at all. The teams that struggle are the ones who route everything through the same cautious process regardless.
Know exactly where the line is
The most useful thing you can do early in a regulated environment is map out precisely what requires formal approval and what does not. This sounds obvious. Most teams do not do it with any rigour.
When you know the line, you can move fast on everything that sits clearly on one side of it, and plan properly for the things that do not. The mistake is treating the whole product surface as equally constrained when it rarely is.
Compliance people are not your enemy
The best regulated product work happens when legal and compliance are brought in early rather than at the end. Not because it speeds up their review, but because it changes the nature of the conversation.
When compliance sees a half-finished idea, they are assessing risk with incomplete information. When they are part of shaping the idea from the start, they can tell you where the real exposure is and where you have more room than you thought. That is genuinely useful and most product teams never get access to it because they treat the relationship as adversarial.
Shipping in a regulated environment is a different skill
The output looks the same. A feature ships, customers use it, the metric moves. But the path there involves a different set of dependencies, a different risk calculus, and a different kind of stakeholder management.
The PMs who do it well are not the ones who complain least about the constraints. They are the ones who understand the environment well enough to find the room that exists inside it, and build the trust with legal, compliance, and risk teams that lets them move when the opportunity is there.
Regulation is not the problem. Not understanding it is.
By Curtis Blunden
15 February 2026