Designing Highly-Regulated Product Organizations for Speed and Safety

On today’s episode of Mythbusters, I’m debunking the myth of speed vs safety in product-led organizations. You know, that underlying tension that hinges on the belief that moving toward speed means moving away from safety. And if you skip to the end, I’m offering a few 15-minute sessions where you throw your gnarliest compliance challenges at me and I help talk you through it (but now you have to read through to the end to take me up on that offer).

This tension shows up in everyday work as hesitation, avoidance, undermining side conversations, and last-minute escalations.

Over time, it becomes one of the biggest forces slowing down otherwise well-intentioned transformations.

But it isn’t because compliance is “the enemy.” And it’s not because product teams are reckless.

It’s because most organizations are trying to run a modern Product Operating Model inside a system that was never designed to support both speed and safety simultaneously.

So, let’s talk about how to move beyond the false tradeoff between speed and safety, and design a Product Operating Model that integrates compliance into the work so you can scale delivery without stalling innovation.

The Speed vs Safety Myth 

In many of the legacy organizations I’ve worked with over the past decade, I’ve observed a common attitude toward the compliance team: they’re the Final Boss. The rule-holding function responsible for enforcement, sign-off, risk mitigation and, usually, the people who say “no.”

When leaders talk about moving toward product-centricity, agility, and faster customer feedback loops, that enforcement role can start to feel like an oppositional force. This mindset looks like:

• Speed vs safety

• Innovation vs control

• Product vs compliance

This framing is incredibly common. It’s also incredibly limiting.

For some organizations, it becomes the justification for not transforming at all.

For others, it creates an “us vs. them” dynamic that quietly corrodes trust over time.

And for transformation leaders caught in the middle, it becomes a daily tax on momentum.

How This Tension Shows Up in Real Life

If you’re leading transformation work day to day, you might observe some of these symptoms:

• Avoidance behaviors: “Let’s do the work first and bring compliance in later. If we involve them now, they’ll just tell us what we can’t do.”

• Decisions based on old assumptions: “Last time we asked, they said no.”
  (Was that last week… or six months ago?)

• Finger-pointing between functions: Product and tech feel blocked. Compliance feels blindsided or ignored.

• 11th-hour crackdowns: Compliance is pulled in right before release, identifies risk, and suddenly everything grinds to a halt.

None of this is malicious, but when teams make decisions based on outdated experiences or incomplete information, they don’t reduce risk…they create it.

Why Product-Compliance Relations Can Break During Transformation

If there’s one thing I want you to remember about this friction, it’s this:

Transformations don’t fail because compliance exists. They fail because compliance participation isn’t redesigned.

In a traditional project model, compliance has clear moments to get involved, such as:

• Requirements review

• Stage gates

• Pre-launch sign-off

The checkpoints are visible. The rhythm is predictable.

But when organizations move from project to product, those clear gates disappear.

Value is released continuously. Roadmaps evolve. Delivery becomes fluid.

If leaders don’t explicitly redesign how compliance contributes in this new model, it doesn’t “just work itself out.” Compliance will usually:

• Show up late and clamp down, or

• Get worked around entirely

Neither outcome builds trust. Neither supports scale. Both contribute to drag.

Reframing the Product Model as Risk Reduction

Done well, product management is one of the strongest de-risking mechanisms an organization can have. It creates:

• Smaller bets

• Faster feedback

• Clear hypotheses

• Tighter loops between intent and impact

That’s not chaos. That’s control, just exercised differently.

But for compliance teams to participate meaningfully, they need:

• Context, not just artifacts

• Early signal, not last-minute documentation

• A role designed for collaboration, not enforcement from the outside

When compliance is only invited in at the end, they behave exactly as they’re incentivized to behave: defensively.

The Real Work: Designing for Speed and Safety

This is not about choosing sides.

You can’t build a car that goes 200 mph and then bolt the seatbelts on at the end. Safety has to be designed into the system from the start.

The same is true for product operating models.

The work is not:

• “How do we move faster despite compliance?”

The work is:

• “How do we design an operating model where compliance increases speed by reducing uncertainty and rework?”

That requires intentional design.

What Actually Helps Transformation Leaders Move Forward

Here’s what’s required to design an operating model that supports a positive partnership with compliance (think “in a relationship" vs” it’s complicated”). 

1. Relationship Repair (Not Performative Alignment)

The most effective compliance partners don’t say “no.” They say, “If this, then that.”

Find compliance professionals who want to understand the problem space, not just enforce rules.

This isn’t about kumbaya. It’s about shared outcomes and the feeling that you're on the same team.

2. Pilot New Ways of Working, On Purpose

In most legacy organizations, product and technology teams vastly outnumber compliance. Expecting compliance to immediately “keep up” with a new product operating model isn’t realistic or fair.

This is where intentional pilots matter.

Rather than changing everything at once, choose a contained product area, platform, or value stream and design a new way of engaging compliance from the start. Bring them into discovery. Make expectations explicit. Test what continuous involvement actually looks like in practice.

Pilots create safety on both sides. Product teams learn how to move faster with guardrails. Compliance teams gain context without being overwhelmed. Most importantly, you create a concrete example the organization can learn from. Something real, not theoretical, that can be refined and expanded.

3. Treat Compliance Capacity as a Scaling Constraint

Pilots alone won’t carry you very far if the underlying system doesn’t change.

If a small compliance team is expected to support dozens of product teams without new structures, roles, or tooling, tension is inevitable. 

The key is to treat compliance capacity the same way you treat platform capacity, team capacity, or architectural constraints. If it’s underpowered, everything downstream slows, or breaks.

This is the work of Operating Model Design: clarifying how compliance participates at scale, where decision rights live, and how safety is embedded without becoming a bottleneck.

Final Thoughts + Your Homework

Speed vs safety is a false choice. But designing for both takes discipline, empathy, and structural change.

If your transformation feels stalled, it may not be because you’re pushing too fast, it may be because the system was never built to support the kind of movement you’re asking for.

And that’s not a personal failure. It’s an operating model problem.

So, here’s what I want you to ask yourself:

• Where is compliance brought in by design vs by emergency?

• What assumptions are we making based on outdated interactions?

• Are we designing for flow or defaulting to old gates inside new language?

• Who inside compliance wants a different way of working, and how visible are they?

My final action item for you is a dare: I dare you to come at me with your biggest compliance challenge. I’m offering a few 15-minute sessions to anyone who wants to take me up on the offer (first come, first served!). Book here to reserve time with me.