I often walk into a planning session knowing that a significant portion of my team’s capacity is already spoken for. Not by features. Not by tech debt. By compliance. And when I present a roadmap that reflects this reality, colleagues look at it and ask: “Why is Q2 so thin?” It isn’t thin. It’s honest. But most roadmaps in regulated industries aren’t.
The Third Stream
Most product managers carry two dimensions on their roadmap: features and technical foundations. That model works for an unregulated SaaS team. In product management for an eIDAS qualified trust service provider, it’s a planning fiction. Regulation doesn’t sit inside either category. It has its own resource demands, its own deadlines, and its own consequences for failure. Treating it as a first-class planning dimension changes how you resource, communicate, and defend your roadmap. Treating it as anything less is how you build a plan that won’t survive contact with Q2.
If you’ve read my earlier pieces on making invisible work visible, whether that’s tech debt or blockers, this is the same thesis applied to a higher-stakes domain. The pattern is consistent: what you don’t name on the roadmap controls the roadmap anyway. In regulated environments, the cost of that silence isn’t just a missed metric. It’s a certification issue. Certification issues end products.
Why Compliance Doesn’t Fit Inside the Other Two
The instinct most teams have is to absorb compliance work into existing categories. Audit preparation becomes an engineering task. Certification requirements get folded into infrastructure sprints. Regulatory documentation gets assigned to whoever has bandwidth.
This is how compliance becomes invisible. And invisible compliance still consumes resources, still blocks engineers, still delays releases, without anyone outside the team understanding why. It competes with technical priorities and loses. It competes with feature priorities and loses harder. In a qualified trust service, the result of losing those fights isn’t a delayed dashboard. It’s a finding in your next conformity assessment.
The Audit Reality
It’s not only the extensive yearly audits. What most people outside regulated product teams don’t see is everything between them. Every new feature has a compliance surface: a document trail, a control to validate, an evidence requirement tied to your certification scope. Every architecture decision carries regulatory implications that your auditor will ask about twelve months later. Every release has documentation requirements that aren’t optional and don’t wait for a convenient sprint.
Compliance isn’t an annual disruption. It’s a permanent operating condition. The PMs who treat it like a calendar event spend the other eleven months explaining delays they can’t name.
What Happens When You Hide It
There’s a predictable failure pattern in regulated environments. A team builds a roadmap that looks like one from an unregulated company. Leadership approves it. Commitments get made externally. Then midway through the quarter, engineers get pulled into documentation reviews, security assessments, and evidence collection.
The PM absorbs this silently. Adjusting scope. Renegotiating timelines. Apologizing for delays they didn’t cause and can’t fully explain without sounding like they’re making excuses.
Over time, it’s not just the quarter that erodes. It’s the PM’s standing. Each unexplained slip makes the next commitment harder to defend. Stakeholders stop asking what happened and start assuming the answer. The next planning cycle opens with pressure to catch up, which compresses compliance further, which produces the same slippage, which produces the same apology. It’s not a delivery problem. It’s a roadmap honesty problem.
Visibility as a Political Act
Putting compliance on the roadmap isn’t just organizational hygiene. It’s a political act.
You’re telling leadership something they often don’t want to hear: this team cannot move as fast as an unregulated team, and pretending otherwise produces worse outcomes, not better ones. That’s uncomfortable to say out loud. But the roadmap is exactly where that discomfort belongs. Not in a side document. Not in a footnote. Not in a mid-quarter apology. The artifact leadership uses to ask “what are we delivering” needs to show compliance as a named, resourced, time-bound stream of work. Anything else is a negotiation you’ll lose after the commitments are already made.
When compliance is visible on the roadmap, two things change:
Expectations become realistic. Leadership sees that available feature capacity is a portion of total capacity, not all of it. The gap between what they want and what’s possible stops being a surprise and starts being a planning input.
Trade-off conversations happen before commitments, not after. If leadership wants to accelerate a feature, they can see what it would displace. You negotiate scope in planning, where the PM has leverage, not mid-sprint, where they don’t.
What Three Streams Actually Look Like
In practice, my roadmap has three explicit streams, each with a named capacity allocation, agreed before the quarter starts. Not assembled from whatever features and tech debt left over.
Features: User-facing capabilities, integrations, experience improvements. What gets demoed, marketed, and sold.
Technical foundations: Infrastructure, performance, scalability, security hardening, debt reduction. What keeps the product viable over time.
Compliance: Audit preparation, regulatory documentation, certification maintenance, policy implementation, evidence collection, control validation. What keeps us allowed to operate.
The split isn’t fixed. A quarter anchored to certification renewal might allocate 35 to 40 percent of engineering capacity to compliance work alone. A steady-state quarter with no major audit milestones might run closer to 15 percent. But compliance never drops to zero, and it never competes silently with the other two streams. The negotiation happens in planning, not mid-sprint.
The Conversation You Need to Have
This is where most PMs stop: they agree with the framework but never say the words out loud. So here’s what the conversation actually sounds like.
Before the quarter starts, you sit down with your engineering lead, align on a capacity split across the three streams, and bring those numbers to leadership. You say something like: “Next quarter, roughly 30 percent of our engineering capacity goes to compliance. Here’s what’s driving it: [certification renewal, control validation for the new feature scope, evidence collection for the upcoming audit]. That leaves this much capacity for features. Here’s what fits. Here’s what doesn’t. If you want to change the feature list, we can talk about what moves, but the compliance allocation isn’t optional.”
The key is specificity. Not “compliance takes time,” but “compliance takes 30 percent next quarter because of these three obligations.” Not “we might slip,” but “here’s the capacity, here’s the plan, here’s what happens if we compress it.” You’re not asking permission. You’re presenting the operating reality and offering trade-offs within it.
The cost of not having this conversation is specific. Mid-quarter scope cuts. Timelines renegotiated without a credible explanation. Credibility that erodes sprint by sprint. Regulated PMs who absorb compliance silently don’t protect their teams. They absorb consequences that were never theirs to own.
Constraints that are named and planned for are just parameters. Constraints that are hidden and absorbed are the ones that break teams.
The Honest Roadmap
Being honest about where capacity goes is the most senior thing a regulated PM can do. It doesn’t feel strategic. It feels like admitting a limitation. But there’s only one version of that limitation that’s dangerous: the hidden one. A slow-moving crisis with your name on it.
If your roadmap only has two streams, you’re lying to someone. Maybe to leadership. Maybe to yourself. Name the third stream, resource it, defend it. Anything less is a description of a product organization that doesn’t exist.