Someone forwards you a slide from the compliance town hall with a date on it, and by Thursday there is a ticket in your backlog called "regulatory uplift" with no acceptance criteria and no estimate. Nobody can tell you how big it is. Everybody agrees it is not optional. Six weeks later it has eaten the quarter you had planned for something else.
Regulatory change on a product backlog is work your team must deliver by an externally fixed date to remain compliant with a rule your firm did not choose. It behaves differently from every other item in the queue, because it arrives with a deadline attached and no value score. Most teams handle it by pretending it is a feature.
This is not an argument that compliance obstructs delivery. It is an argument that a specific class of work is being run through a ranking mechanism that cannot represent it, and that the resulting plans fail in predictable ways.
Why regulatory change breaks every prioritisation framework
Regulatory change breaks prioritisation frameworks because those frameworks rank items by value against effort, and a regulatory obligation has no value score. Its value is avoiding a consequence, which is unbounded and not comparable to revenue or retention. Feed it into a scoring model and the model returns whatever number the person entering it needed.
Watch it happen. A product manager opens the scoring sheet, reaches the Impact column for an obligation carrying supervisory consequences, and types the highest value available. The arithmetic then produces a rank that was decided before the sheet opened. The score is not a decision; it is a receipt for one, and treating it as evidence is how a team loses the ability to argue about sequencing at all.
The frameworks fail differently, which matters because the failure shapes what your team does next.
| Framework | What it does with a regulatory obligation | How it fails |
|---|---|---|
| RICE | Reach is the entire user base; Impact is set to maximum | Two of four inputs are typed rather than estimated. The score is precise, unfalsifiable, and identical for every obligation, so it cannot sequence three of them against each other. |
| Weighted Shortest Job First | Cost of Delay is genuinely enormous past the deadline | Cost of Delay approaches unbounded, so the ratio outranks everything permanently. Every regulatory item ties for first and ordering within the class disappears. |
| MoSCoW | Classified as Must | The Must column swells until it is the entire release. The label stops carrying information, and teams invent an informal second tier to restore the signal they just destroyed. |
| Value versus effort matrix | Plots in high effort, low measurable value | That quadrant reads "avoid", which is the one response unavailable. Somebody drags the dot rather than questioning the instrument. |
| Kano model | Basic or expected quality | The classification is correct and useless. It tells you customers will not thank you, which you knew, and says nothing about capacity or sequence. |
| Opportunity scoring | No unmet need to measure | Users never requested it and will not rate satisfaction on it. The instrument returns nothing, so the item bypasses discovery entirely and arrives at delivery unexamined. |
The common thread is that all six were built to compare optional work. An obligation is not optional, so the comparison is malformed before it starts. This is a sharper version of the general problem covered in where each prioritisation framework lies to you: the frameworks are not wrong, they are being asked a question outside their domain.
Some vocabulary, because these words get used loosely and the looseness is where schedules go missing.
- Obligation — the requirement as written in the rule text, which your firm cannot negotiate.
- Interpretation — your firm's chosen reading of how that requirement applies to your product, which is negotiable and frequently more expensive than the obligation itself.
- Evidence pack — the artefacts proving you did what you say you did: decision logs, test results, sign-off records, screenshots of the control operating.
- Second line — the risk and compliance function that reviews and challenges what the business builds, distinct from the business itself and from internal audit.
- Implementation window — the period between a rule entering force and its obligations applying, during which firms are expected to build.
- Scope assessment — the analysis determining which entities, products and processes a rule actually captures, usually the cheapest work available and usually done last.
The date on the regulation is not your deadline
The regulatory date is when you must be compliant, not when your team must finish. Your real deadline is that date minus the evidence pack, minus second-line review, minus remediation of whatever review finds, minus any change freeze. In most firms that sequence consumes eight to twelve weeks, which is why teams that plan to the published date deliver late having worked to schedule.
Work it backwards on a single line before you estimate anything. Regulatory date, then the freeze period around it, then the window your second line books for review, then a remediation cycle, then testing, then build. The number that falls out is usually a quarter earlier than the date on the slide.
The review window is the piece teams forget, because it is capacity belonging to someone who does not report to you and does not share your sprint calendar. Second-line reviewers work to their own queue, and the queue is fullest exactly when everyone else's regulatory deadline is also approaching. Book it early or inherit whatever slot is left.
The evidence pack is the other silent cost. Building a control takes a sprint; proving it operated correctly, repeatedly, with a decision log attached, takes longer and lands on people who thought they had finished. Write the control into acceptance criteria on the stories themselves rather than raising a separate compliance ticket — the same acceptance criteria discipline you use for functional work, applied to the audit trail.
[ASHISH: add a real example of a regulatory deadline where the effective internal date turned out to be materially earlier than the published one, and what got cut to absorb it]
What regulatory change actually costs a product team
Regulatory change costs a product team four things, and most estimates capture one. There is the build, the evidence pack, the review cycles, and the permanent operational change left behind after go-live. The fourth is the one that quietly reduces your team's capacity in every subsequent quarter, and it almost never appears in the original estimate.
Take a rule that requires a new field to be captured, checked and reported. The build is a fortnight. The evidence is another week. Review adds two cycles. Then, forever afterwards, an operations team fills that field, someone reconciles it monthly, exceptions come back to your team, and a report goes out quarterly that somebody has to own when it breaks.
That ongoing cost is a real, permanent subtraction from delivery capacity. Estimate it in days per month and say the number out loud during planning, because a commitment nobody sized is a commitment your team absorbs silently. Data-heavy obligations are worse: reporting requirements often demand history you never stored, and the retrospective build is frequently larger than the forward one. That is the same shape as the migration problem in collateral systems, where the agreements already loaded have no amendment history behind them.
Scope assessment is where the largest reduction sits, and it is cheap. Which entities are captured, which products, which jurisdictions, from which date. Plenty of scope is assumed rather than established, and an afternoon with whoever owns the legal reading can remove a third of a programme. Distinguishing the obligation from your firm's interpretation of it is the same instinct as asking which rule that actually is when someone says a thing cannot be done.
How to put a regulatory obligation on the backlog
Put a regulatory obligation on the backlog by removing it from the ranking contest and subtracting it from capacity instead. Establish the scope, work backwards from the date to find your real deadline, size all four costs, then reduce the team's available capacity by that amount before any prioritisation happens. What remains is what your team can genuinely choose between.
- Get the obligation in writing with its article or section reference. A summary slide is not a requirement; ask which rule and which paragraph, and read that paragraph yourself.
- Separate obligation from interpretation in two columns. The left column is fixed. The right column is your firm's choice, is usually where the cost lives, and can be challenged.
- Establish scope before estimating: entities, products, jurisdictions, effective date. Ask what is out of scope and get that written down too.
- Work backwards from the regulatory date through freeze, review, remediation and testing to find your real delivery date. Put both dates on the plan so nobody confuses them.
- Size all four costs — build, evidence, review cycles, and the permanent operational change — and state the fourth in days per month.
- Subtract the total from the team's capacity for the affected quarters before prioritisation starts. Do not enter the obligation into the ranking; it is not competing.
- Name an owner for the interpretation and a date to re-check it. Interpretations get revised and published dates move, and both changes arrive without anyone telling your team.
Step six is the whole argument, and it is the step that gets resisted, because subtracting capacity makes the cost visible to stakeholders who preferred it invisible. A roadmap showing four features and one regulatory item invites a debate about whether the regulatory item is really necessary. A roadmap showing four features against a capacity line already reduced by a stated number invites a debate about which of the four survives, which is the honest conversation.
[ASHISH: add a real example of a scope or interpretation question that materially changed the size of a regulatory programme once someone asked it]
The dates move, and planning to them is its own failure
Regulatory implementation dates move often enough that a plan anchored to a single published date is fragile by construction. Deadlines get deferred, phased, or split between entity types while the underlying obligation stays exactly as written. A team that built to the obligation adjusts its schedule. A team that built to the date has to reopen decisions it thought were closed.
The European Union's implementation calendar as of 2026 shows the pattern plainly. The Digital Operational Resilience Act has applied since January 2025 and moved from supervisory education into enforcement during 2026. The Digital Omnibus revisited the Artificial Intelligence Act's high-risk timetable, deferring some obligations to later dates while leaving prohibited practices, general-purpose model rules and transparency obligations on their original schedule.
Payment Services Directive 3 and the accompanying Payment Services Regulation followed political agreement in November 2025, with a long implementation window running after entry into force. Elsewhere, the Fundamental Review of the Trading Book was postponed to January 2027 by delegated act. Confirm every date yourself against the official text before it enters a plan, because secondary sources disagreed with each other throughout 2026.
The concentration is the real problem, not any single rule. The Institute of International Finance noted in its staff analysis of the European digital finance package that implementation deadlines cluster heavily across 2025 to 2027, creating simultaneous demands on the same teams. Its note on the horizontal effects is worth reading for the overlaps, particularly where operational resilience obligations sit on top of the procurement pipeline that other rules draw from.
[VERIFY: current status and applicable dates for each regulation named above, checked against the Official Journal or the relevant supervisor's published text at time of publishing]
When regulatory work is genuinely a product opportunity
Some regulatory obligations create product value, and telling which is a judgement your team can make deliberately rather than by accident. The test is whether the obligation forces you to build something a customer would notice or pay for. Access rules, data portability and reporting obligations sometimes do. Record-keeping and internal control requirements almost never do.
The failure mode here runs in both directions. Teams that treat every obligation as pure cost miss the cases where a mandated capability could be extended cheaply into something differentiating. Teams that treat obligations as opportunities gold-plate the minimum, ship late, and then defend a scope nobody asked for to a supervisor who only wanted the minimum.
Decide which one you are looking at before build starts, write the answer down, and separate the compliant minimum from the discretionary extension into different items. The minimum ships to the regulatory date. The extension competes for capacity with everything else, on the normal terms, where a scoring framework works exactly as intended.
The next problem is already visible if you look at your calendar. The second obligation arrives while the first is still in flight, drawing on the same second-line reviewers and the same three engineers who understand the reporting pipeline. At that point the question stops being how to sequence one regulatory item and becomes how much of your team's permanent capacity belongs to regulatory change as a standing line — and whoever funds your roadmap needs that number before they set next year's expectations.
Frequently asked questions
How do you prioritise regulatory work against feature work?
You do not. Scoring an obligation against optional work produces a number reflecting the decision already made. Instead, size the regulatory work fully, subtract it from the team's capacity for the affected period, and prioritise features against what remains. This makes the trade-off explicit to stakeholders rather than hiding it inside a ranking.
Should regulatory work go in the same backlog as feature work?
Yes, in the same backlog and the same sprints, because work outside the sprint backlog gets no capacity allocated to it. What should differ is how it enters: features arrive through prioritisation, obligations arrive as a capacity reduction agreed before prioritisation starts. Same queue, different entry route.
Who owns regulatory requirements, product or compliance?
Compliance owns the interpretation of the rule; product owns how it is built, sequenced and evidenced. The failure happens when neither owns the translation between them. Name one person accountable for turning the interpretation into acceptance criteria, and give them a date to re-check it, because interpretations are revised more often than teams expect.
How do you estimate regulatory work when the requirement is unclear?
Estimate the scope assessment first as a small, time-boxed piece of work, and refuse to estimate the build until it completes. An unclear requirement is not an estimation problem; it is an unanswered question about which entities, products and dates are captured. Answering it usually shrinks the programme.
What happens if a regulatory deadline is missed?
Consequences vary by regime and by how the firm behaves. Supervisors generally distinguish a firm that identified a gap, documented it, and presented a remediation plan from one that discovered it during an examination. That distinction is why the decision log and evidence pack matter as much as the build, and why a documented delay beats a silent one.
Is regulatory change different in fintech than in other regulated industries?
The mechanics are the same wherever an external body sets dates you cannot move. What differs in financial services is density: multiple regimes apply concurrently to the same product, deadlines cluster, and the same small group of reviewers and data engineers is required by all of them. Volume, rather than any individual rule, is what breaks the plan.