How to Prioritize Data Infra Work That Has No Obvious User Story

Infrastructure work loses roadmap fights because it's scored on the same axis as features — visible benefit — when its real value is reach across downstream teams, risk avoided, and velocity unlocked. Reframe it as a RICE variant scored for reliability and enablement, not just delight.

Quick answer: Score infra work with reach defined as downstream teams and pipelines that depend on it, impact defined as risk reduction plus velocity unlocked, and pair the score with a cost-of-inaction estimate — the bill tech debt is quietly running up. That gives infrastructure a number that competes with features instead of losing to them by default.

Why Infrastructure Loses the Roadmap Fight By Default

Infra work loses because roadmaps reward what's easy to see: a shipped feature with a demo, a screenshot, a user quote in a release note. A pipeline refactor has no interface and usually no metric until it breaks — so it reads as lower priority even when it carries more risk.

This isn't a communication failure you can fix with a better slide. It's a structural mismatch between how most prioritization frameworks are built and what infrastructure actually produces.

• Features produce a story. A user hits a wall, a feature removes it, someone can point at the before/after.
• Infrastructure produces an absence. A pipeline that doesn't break, a dataset that's trustworthy by default, a migration nobody notices — the entire point is that nothing happens.
• Stakeholders reward the visible. A roadmap review is a room full of people who can picture a feature and can't picture a schema.

Noriaki Kano's quality model has a name for this asymmetry: must-be quality. Reliability, correctness, and uptime are attributes users don't notice when present and punish severely when absent — the opposite of a "delighter" feature that earns credit for existing. Infra work almost always lives in Kano's must-be quadrant, which means it structurally cannot win a side-by-side comparison against a delighter unless you change what's being compared.

The complete guide to the data PM role covers this tension in more depth — a data platform PM is judged on reliability metrics that are invisible until they fail, while feature PMs are judged on metrics that are visible the moment they ship. That's the gap this article closes.

The Cost of Staying Invisible

DORA's long-running State of DevOps research (Forsgren, Humble, and Kim's Accelerate) found that elite-performing engineering organizations — the ones investing consistently in pipelines, testing, and platform reliability — run change failure rates in the single digits, while low performers cluster well above 40%. That gap doesn't show up as a line item; it shows up as every other roadmap item moving slower, breaking more, and costing more to fix.

Give Infrastructure a User: The Downstream-Team Reframe

Infra work gets a real user story the moment you stop asking "who clicks this" and start asking "who is blocked, slowed, or put at risk if this doesn't exist." Every downstream engineer, analyst, and automated system that consumes a dataset or pipeline is a user of that infrastructure, with real jobs and real pain when it fails.

This is the same mental shift behind treating data products as having users, not just consumers: a schema, a pipeline, or an API is a product with a customer, even if that customer sits inside the company.

Once you accept downstream teams as users, the exercise becomes concrete:

1. List every consumer of the pipeline, table, or service — other teams, other services, scheduled jobs, dashboards, ML models.
2. Name their job-to-be-done with this data — what decision or system depends on it being correct and on time.
3. Log every incident where lateness, drift, or an outage blocked one of those jobs, and who had to intervene.
4. Estimate the blast radius if the current fragility continues unaddressed for two more quarters.

That list is your reach number, and it's usually bigger than any single feature's. A shared identity-resolution pipeline feeding six product teams, three dashboards, and a fraud model has a reach of nine dependents before a single external user is counted.

A platform team's "user" isn't a persona on a slide — it's the on-call engineer from another team who gets paged at 2 a.m. because your table didn't land.

A RICE Variant Built for Risk and Enablement

Standard RICE — reach, impact, confidence, effort — was built at Intercom to compare user-facing features on one scale, and it still works for infra if you redefine each input around dependency and downside instead of adoption and delight. The math doesn't change; what feeds it does.

The table below maps the standard inputs to their infrastructure equivalents.

Two adjustments make the variant honest rather than a rebranding exercise:

• Weight impact by severity tier, not enthusiasm. A failure that causes a wrong number in an internal dashboard is not the same impact tier as one that causes a compliance breach or a customer-facing outage — score them on a documented severity ladder, not a gut feel of "pretty important."
• Treat confidence as evidence-backed, not optimism. Confidence in a feature bet is often a guess; confidence in an infra bet can be grounded in actual incident logs, page counts, and SLA-breach history — use that data instead of a vibe score.

This is close to the logic behind WSJF (Weighted Shortest Job First), the prioritization method from the Scaled Agile Framework built on Don Reinertsen's cost-of-delay economics: sequence work by the cost of not doing it soon, divided by how long it takes. Infra work often wins under WSJF for the same reason it should win under an honestly-scored RICE variant — the cost of delay compounds while the job duration doesn't grow with it.

A trustworthy metrics layer is what makes this scoring defensible in the room — if leadership can't see incident counts, SLA breaches, or dependency graphs in a shared source, your reach and impact numbers are assertions, not evidence.

Quantify the Cost of Inaction: Tech Debt Has a Bill, Not Just a Vibe

"We should really fix this someday" loses to every funded feature because it has no number attached. Cost of inaction gives tech debt a number by pricing what continued neglect costs across incidents, rework, and slowed delivery — the same currency features are funded in.

Google's Site Reliability Engineering discipline formalizes a version of this with the error budget: reliability is treated as a finite resource with its own budget, and once it's spent, feature work pauses in favor of reliability work by policy, not persuasion. You don't need Google's scale to borrow the principle — you need a documented threshold that triggers infra investment automatically instead of relying on someone winning an argument every quarter.

McKinsey's technology-debt research has estimated that accumulated tech debt can represent 20–40% of the value of an enterprise's entire technology estate before depreciation — a number CIOs increasingly track the same way finance tracks depreciating assets. Translating that into a roadmap conversation means naming the categories where inaction is compounding.

Treating data quality as a feature rather than a background chore is the mindset shift that makes this table legible to non-technical stakeholders — quality isn't overhead, it's the thing every other feature is quietly built on top of.

Turning the Table Into a Pitch

Don't present the table as a spreadsheet. Present it as a forecast:

• "At the current incident rate, we'll spend roughly X engineer-hours a quarter on firefighting instead of new work."
• "Our SLA-breach rate has climbed from Y% to Z% over two quarters — here's what happens if that trend continues unaddressed."
• "This lineage gap is the same one flagged in last year's audit; the cost of fixing it now is a fraction of the cost of fixing it during a live audit finding."

Cost of inaction reframes the ask from "trust me, this matters" to "here's the bill we're already paying, itemized."

Sequencing: When to Bundle Infra With a Feature vs. Pitch It Alone

Bundle infra work with a feature launch when the feature is genuinely blocked by it — that's the fastest funding path because the feature's urgency inherits into the infra work. Pitch infra as a standalone initiative when its risk spans multiple future features, because bundling it into just one buries the true reach.

Two situations, two different pitches:

1. Blocking bundle. The new feature literally cannot ship without the schema change or pipeline fix. Here, don't separate the ask — the feature's roadmap slot is the infra work's funding, and splitting them just adds review overhead.
2. Standalone platform initiative. The risk or slowdown touches every team building on the platform, not one feature. Bundling this into a single feature's scope understates its reach and sets a precedent that infra only gets funded when a feature happens to need it.

Mapping this against the actual jobs to be done of your downstream teams clarifies which bucket you're in. If the "job" is "ship this one feature," bundle. If the job is "build anything on this platform reliably, indefinitely," it's standalone — and Bob Moesta and Clayton Christensen's Forces of Progress model (push, pull, anxiety, habit) is a useful lens for why teams keep tolerating a broken platform instead of demanding the fix: the anxiety of a big migration often outweighs the push of daily pain, until someone quantifies both.

It also helps to map the downstream team's own customer journey against the platform — where do they hit friction with your data, when does trust break down, and where does a fragile pipeline turn into a support ticket for them instead of you. A journey map built for engineers-as-customers surfaces infra priorities a feature backlog never will.

Making the Invisible Explicit: Scoring Platform Work Alongside Features

The point isn't that a tool magically wins the argument for you — it's that reliability investments stop being an assumed-lower-priority afterthought the moment they're expressed in the same units everyone else is scored in. Making that reach and impact explicit, instead of implicit and easy to deprioritize, is most of the battle.

Key Takeaways

• Infra loses by default because it's invisible, not because it's low-value — Kano's must-be quality attributes are punished when absent and unnoticed when present, which structurally disadvantages them against feature "delighters."
• Redefine reach as downstream dependents, not end users — every team, pipeline, dashboard, and model that consumes your data is a user with a real job-to-be-done.
• A RICE variant works if you re-anchor the inputs: reach as dependent teams, impact as risk avoided plus velocity unlocked, confidence grounded in incident history rather than optimism.
• Cost of inaction turns "someday" into a number — price incidents, SLA breaches, compliance gaps, and the velocity tax every dependent team pays for platform fragility.
• Bundle infra with a blocking feature; pitch it standalone when the risk spans multiple future features — bundling understates reach when the real audience is the whole platform.
• Borrow the error-budget principle: a documented reliability threshold that auto-triggers infra investment beats re-litigating priority every planning cycle.
• Score infra and features on one shared scale so reliability work stops losing to visibility by default — that's what a tool like Prodinja's RICE/Kano Prioritization is designed to make explicit.