Move fast is a liability when it means creating commitments you cannot honor.
Product Management in Government and Traditional Industries - The Adapter's Guide
Product management in legacy and regulated industries is not a lesser form of the discipline - it is a harder constraint environment where most tactics that work at a startup will get you fired or audited. This guide maps the real constraints and shows how to adapt without abandoning judgment.
This article is for PMs who have strong product instincts built in consumer tech, early-stage startups, or digital-native companies - and who are now operating in, moving into, or advising organizations where regulation, procurement, and institutional process shape every decision. You should already understand discovery, prioritization, and stakeholder management at a working level. What you need here is the adaptation layer.
The Setup Nobody Tells You
Picture a PM three months into a role at a large public-sector bank. She has run discovery at two growth-stage fintechs. She knows how to move fast. Her first assignment is a digital onboarding initiative - theoretically straightforward.
She proposes two-week sprints. Her first sprint includes user interviews, a clickable prototype, and a recommendation on the onboarding flow. Her manager nods. The steering committee date arrives.
The committee tells her the onboarding flow touches a Know Your Customer process that is currently under review by the financial intelligence regulator. No changes to the flow can be committed until that review closes - in approximately nine months.
This is not a failure of process. It is not a failure of the committee. It is a PM who walked into a constraint environment she had not mapped, carrying a set of tools built for a different physics.
The Constraint Map
Regulated and legacy industries do not have one type of constraint. They have four, and they interact.
Regulatory Cycles
Regulators do not move on product timelines. In banking, telecommunications, healthcare, and government, regulators issue guidance, review commitments, and conduct audits on cycles measured in quarters or years - not sprints. A product change that touches a regulated process often requires filing, review, and approval before deployment, not after.
The practical consequence: a PM cannot commit to a regulator on a feature that is still in discovery. And a PM cannot discover freely on a feature that a regulator has already reviewed and approved. The two processes have to be sequenced, not run in parallel.
Procurement
Government and institutional procurement exists to prevent corruption and ensure fair vendor selection. That is a legitimate purpose. It also means that switching a vendor, adding a new tool, or expanding a contract can take six to eighteen months in a well-run public institution - and longer in a dysfunctional one.
A PM who discovers that a third-party payments provider would significantly improve the user experience has discovered something that is, at best, eighteen months away from being actionable. Discovery without procurement awareness produces backlogs full of things that cannot be built.
Change Advisory Boards
Change Advisory Boards - committees that review and approve changes to production systems - exist in most large banks, hospitals, government agencies, and telecoms. They review risk, coordinate deployment windows, and gate releases. A two-week sprint that ends in a production deployment is not possible if the change advisory board meets monthly and requires a two-week lead time for submissions.
This does not mean nothing can move. It means deployment cadence is a constraint to be designed around, not ignored.
Legacy Integration
Legacy systems are not a temporary problem that will be solved before you get to the interesting work. In most regulated industries, the core transactional system is decades old, runs on infrastructure the organization is contractually or operationally unable to replace quickly, and has integration patterns that predate modern application programming interfaces. Building new products on top of legacy infrastructure means negotiating the legacy's constraints into every design decision.
What Agile Actually Means Here
Everyone says regulated industries need to adopt agile. Most teams adopt the rituals and leave the constraints in place.
The honest version: agile in a regulated environment means making the smallest committable increment of progress that does not trigger a regulatory or procurement event you are not prepared for. It does not mean deploying every sprint. It does not mean continuous discovery on regulated processes.
The useful reframe is to separate the discovery-and-design loop from the regulatory-and-deployment loop. Discovery can move fast - user research, prototyping, internal testing - as long as it does not create external commitments. The regulatory loop moves on its own timeline. A PM's job is to feed the regulatory loop with decisions that are already validated so that when the regulatory window opens, the organization is ready to move through it.
DBS Bank's digital transformation is the most frequently cited example of agile in regulated banking, and it illustrates this exactly. DBS did not become a technology company by importing Silicon Valley methods unchanged. They spent approximately a decade building internal engineering and product capability, retraining staff, restructuring around customer journeys, and adapting agile practices to fit the bank's constraint environment. The result was a bank that could move significantly faster than its peers - not a bank that could move at startup speed. The distinction matters. Comparing DBS 2024 to a Series B fintech is a category error.
Startup PM vs. Regulated Industry PM
| Dimension | Consumer Startup | Regulated Industry |
|---|---|---|
| Deployment cadence | Continuous or weekly | Gated by change advisory board - often monthly |
| Discovery scope | Any user problem is in scope | Regulated processes require approval before changes |
| Stakeholder alignment | Fast consensus, ship and learn | Alignment must precede the formal meeting, not happen in it |
| Vendor / tooling changes | Low friction, card on file | Procurement process - months to over a year |
| Risk tolerance | Fail fast is a virtue | A public failure can trigger a regulatory audit |
| Definition of done | Live in production | Approved, documented, audited, and trained |
| Iteration speed | Days to weeks | Weeks to quarters on regulated features |
| Success signal | User metrics move | Metrics move within compliance parameters |
The column on the right is not a worse version of the column on the left. It is a different operating environment. A PM who treats the right column as a slower version of the left column will optimize for the wrong things.
How to Read a Regulated Environment Before Designing Your Process
The first ninety days in a regulated organization are an environment audit, not a product sprint. Three things to map before committing to any delivery process.
What triggers a regulatory event. Sit with the legal, compliance, and risk functions in the first month - not as a courtesy, but to understand the specific boundaries. Which product changes require regulator notification? Which require prior approval? Which are free to ship? Most PMs discover this map by accident, after crossing a boundary. That is an expensive way to learn it.
Where procurement controls the dependency graph. Every product has upstream dependencies. In a regulated institution, some of those dependencies are controlled by contracts that procurement owns. Map the critical path for your product area and identify every point where a vendor, tool, or service change would require a procurement event. Then design around it. If you cannot design around it, start the procurement event immediately and put a long timeline on that dependency.
How decisions actually get made. The org chart is rarely the authority map in a traditional institution. The steering committee matters, but the decision on whether something gets through the steering committee is usually made in a series of bilateral conversations before the meeting. A PM who tables a new proposal at a steering committee without pre-aligning with each key stakeholder is not being efficient - they are creating a situation where powerful people are surprised in a formal setting, which is one of the most reliable ways to kill a proposal in an institutional environment.
The Judgment Turn
Here is the position this article is taking, and it is not a comfortable one.
The PM who comes from a consumer startup into a bank and tries to run two-week discovery cycles on a core banking migration will spend their first year learning why that does not work. Not because the bank is broken. Not because the stakeholders are resistant to change. Because the constraint environment is real, and the tools built for a different environment do not transfer without adaptation.
The PMs who thrive in regulated industries share one observable pattern: they get alignment before the meeting, not during it. They treat the formal decision process as a confirmation step, not a discovery session. They do the political and relationship work that a fast-moving startup context lets you skip - because in a fast-moving startup context, you can recover from a surprise in the next sprint. In a regulated institution, a surprise in a steering committee can cost you a quarter.
Move fast is a liability when moving fast means creating commitments you cannot honor with a regulator, triggering a procurement event you are not funded for, or shipping a change that fails a change advisory board review and has to roll back. The discipline in regulated industries is not moving slowly. It is moving deliberately - which is harder than moving fast, not easier.
Key Takeaways
- Regulated industries have four interacting constraint types - regulatory cycles, procurement, change advisory boards, and legacy integration. Map all four before designing your delivery process.
- Agile in a regulated environment means separating the discovery loop from the regulatory loop and feeding validated decisions into the regulatory window when it opens - not compressing both into a sprint.
- DBS Bank's transformation took a decade and required adapting agile to the bank's constraints, not replacing the constraints with a startup model.
- Alignment in regulated institutions happens before the formal meeting, through bilateral conversations. A surprise in a steering committee is a political event with consequences measured in quarters.
- The PM who treats a regulated environment as a slower version of a startup will optimize for the wrong things. It is a different operating environment, not a lesser one.
Related Articles
A PM joins a regulated bank from a consumer startup and proposes two-week discovery sprints on a core banking migration. What is the most likely outcome?
Make the call in Reps and see how your reasoning holds up.
Make the call