When RICE Isn't Enough: Prioritizing Features Where Failure Trips the Grid

RICE fails safety-critical features because it scores expected value — reach times impact times confidence divided by effort — while treating a 1-in-10,000 catastrophic failure the same as a 1-in-10 minor one. Fix it by multiplying, or gating, each score with a failure-severity factor pulled from a lightweight failure-mode analysis, so tail cost, not just average payoff, drives rank.

Quick answer: Standard RICE hides tail risk inside an average. Add a failure-severity multiplier — drawn from FMEA or IEC 61508-style severity tiers — so a rare catastrophic outcome can outrank a high-reach convenience feature. True safety-of-life risks shouldn't be multiplied at all; they should be treated as a gate, not a score.

If you plan features for anything grid-connected — a DER inverter, a demand-response controller, a substation dashboard — you've felt this tension every planning cycle. The scheduling nicety with ten thousand weekly users always wins the spreadsheet. The interlock nobody notices until it's gone always loses it. That's not a bias in your judgment. It's a blind spot built into the formula.

Why Reach × Impact Hides the Failure That Actually Matters

RICE assumes failure cost scales linearly with how often something happens, so it averages a rare catastrophic outcome into a single expected-value number and effectively erases it. In grid-connected and safety-critical systems, cost isn't linear — a low-probability event can be too expensive to average away, no matter how rare it is.

Sean McBride's original RICE framework, published at Intercom in 2016, was built to compare consumer feature bets against each other, not to weigh a firmware patch against a lineman's safety. It multiplies Reach, Impact, and Confidence, then divides by Effort, producing one expected-value number. That's the right lens when outcomes are symmetric and repeatable — most software features are.

Grid-connected products aren't always symmetric. Sociologist Charles Perrow's Normal Accidents argues that tightly coupled, complex systems — the grid is a textbook example — produce failures that cascade faster than operators can intervene, which is precisely why a "rare" failure mode deserves more scrutiny, not less. Nassim Taleb's writing on ruin and ergodicity makes the sharper point: an outcome you can't survive isn't a cost to average into a portfolio, it's a threshold to avoid entirely, regardless of how favorable the odds look on paper.

Expected value assumes you get to play the hand enough times for the average to show up. A grid failure doesn't wait for the average.

RICE quietly assumes several things that don't hold once safety enters the picture:

• Every unit of impact is fungible — a point of impact on a convenience feature counts the same as a point of impact on a safety feature.
• Confidence describes uncertainty about adoption, not uncertainty about a failure mode's tail.
• Effort is the only cost competing with reach, not the downstream cost of getting it wrong.
• The scoring window is short enough that rare events wash out — a bad assumption when a feature ships once and runs in the field for a decade.

This isn't hypothetical for energy teams. The August 2003 Northeast blackout traced back to an alarm-processing software bug at a single utility, compounded by sagging lines and a slow human response, and it cascaded to an estimated 50 million people across the US and Canada with damage estimates in the billions of dollars, according to the joint U.S.–Canada task force that investigated it. No feature-level RICE score written that quarter would have flagged alarm software as the highest-reach item on the roadmap. It looked like a maintenance ticket until it became a continental event.

RICE's Reach and Impact numbers are themselves forecasts, and forecasts carry error bars of their own. Demand-forecasting failures show how far those estimates can drift once weather, distributed generation, or behind-the-meter storage move faster than a model assumes — the same estimation fragility our guide to megawatt-scale demand forecasting errors covers in depth applies just as much when you're scoring a backlog item's reach twelve months out. An 80% confidence score on a five-point impact scale hides exactly the kind of tail your safety case needs to see.

If you're building anything that touches generation, transmission, or distribution, it's worth grounding this discussion in the broader operating context first. Our complete guide to energy and climate product management covers how grid constraints reshape the entire PM toolkit, well before you get to scoring an individual backlog item.

The Failure-Severity Multiplier: Extending RICE with Tail Cost

Add a Severity factor to RICE so RICE-FS = (Reach × Impact × Confidence ÷ Effort) × Severity. Severity is scored from real engineering failure-severity tiers, not a marketing guess, and the highest tier bypasses scoring altogether and becomes a release gate rather than a multiplier.

Borrowing Severity from FMEA and IEC 61508

Borrow the Severity axis from FMEA — Failure Mode and Effects Analysis — a risk method formalized in standards like the AIAG-VDA FMEA Handbook used across automotive and aerospace engineering. Classic FMEA multiplies Severity, Occurrence, and Detection into a single Risk Priority Number.

RICE already encodes something like occurrence and detection inside Reach and Confidence. The piece you're actually missing is Severity: what happens in the worst case, independent of how often it happens.

Energy and industrial-control engineers already have a vocabulary for this. IEC 61508, the international functional-safety standard, defines Safety Integrity Levels by the target probability of a dangerous failure per hour — not by projected user reach.

The point isn't to get your product backlog IEC-certified. It's that safety engineering already treats "how bad if it fails" as a first-class axis, scored independently of frequency — exactly the axis RICE is missing.

Interlocks like this typically live in firmware or embedded controllers, shipping on a certification and hardware-release cadence entirely different from your web app's weekly deploys. That's the same mismatch our piece on the hardware-software two-clock problem walks through, and it means severity scoring also has to account for how slowly a fix can actually reach the field once something is wrong.

A Five-Tier Severity Model You Can Actually Run in an Afternoon

For a product backlog, you don't need SIL certification. You need a lightweight, five-tier version your team can apply during a normal grooming session.

Everything through S4 gets multiplied into the RICE-FS score. S5 doesn't get multiplied at all — it gets pulled out of the ranked backlog entirely, the same way a live security vulnerability skips the sprint-planning debate rather than competing for points.

Kano's Blind Spot: Why Must-Be Reliability Features Score Low Until They Break

Noriaki Kano's model calls reliability and safety features must-be attributes: users don't reward you for having them, but punish you severely and permanently for lacking them. Standard Kano surveys under-detect this because respondents rarely imagine, or want to imagine, the failure scenario, so must-be features chronically under-score against delighters.

Kano's 1984 framework sorts features into must-be, performance (one-dimensional), and attractive (delighter) categories, based on how satisfaction responds to presence versus absence. A performance feature produces a roughly linear satisfaction curve — more of it, more happiness. A must-be feature produces an asymptotic curve: presence buys you nothing beyond neutral, but absence craters satisfaction almost instantly.

Reliability, correct billing, and safety interlocks all sit in the must-be quadrant. Kano's classic survey method pairs a functional question ("how do you feel if this is present") with a dysfunctional one ("how do you feel if it's absent") — but for a genuinely catastrophic absent scenario, most product teams never ask the dysfunctional question with any seriousness, and the respondent pool rarely includes the field crew actually exposed to it.

A must-be feature's entire job is to never be noticed. The day it gets noticed is the day it already failed.

This is where a Jobs to Be Done lens helps more than a satisfaction survey. The job a safety interlock does is "let me trust this system enough to stop watching it" — a job that's invisible by design when it's succeeding, the same invisible-job pattern our complete guide to Jobs to Be Done unpacks for products generally.

Map it onto an emotion curve and the shape confirms it: a must-be reliability feature holds a flat, quietly positive line for months or years, then drops off a cliff in a single incident. That's a very different shape from the gradual satisfaction slope a performance feature produces — exactly the kind of pattern our guide to mapping the customer journey emotion curve is built to catch before it becomes a postmortem.

Signs a backlog item is a must-be safety feature masquerading as a low-priority ticket:

• It shows up in incident postmortems, never in feature-request lists.
• Users can't articulate wanting it — only articulate anger when it's gone.
• Its ideal customer experience is silence.
• Removing it doesn't lower satisfaction gradually; it removes trust in one step.

Worked Example: A Convenience Feature vs a Safety Interlock

Score both features on standard RICE first, then multiply each by its severity tier. A high-reach scheduling convenience feature can post a RICE score roughly 80 times higher than a low-reach islanding interlock — until the interlock's critical severity multiplier flips the ranking and it becomes the higher-priority build.

Consider two real-shaped backlog items competing for the same sprint. Smart Away-Mode Scheduling Suggestions nudges customers to shift usage to off-peak hours. Reverse-Power-Flow Islanding Interlock is a firmware feature ensuring a distributed-energy-resource inverter disconnects within its required trip time when the grid de-energizes, preventing it from back-feeding power onto lines a crew may be servicing.

On base RICE, the scheduling feature outscores the interlock by roughly 80 to 1 — the interlock barely clears the cutting line most roadmaps use to even keep an item on the board. Multiply by severity and the interlock edges ahead, not because the arithmetic is precise to the decimal, but because a critical-tier failure across 140 sites — equipment damage, a NERC-reportable event, potential harm to a lineman — isn't a cost a product organization can average away against ten thousand mildly inconvenienced thermostat users.

Treat the multiplier's range, not its exact value, as the real takeaway here. A cross-functional group — safety engineering, field operations, compliance — should set the tier and multiplier together, the same way a change-advisory board sets severity for a live production incident, rather than one PM guessing at "90x" alone on a Friday afternoon.

Operationalizing Tail-Risk-Aware Prioritization

Run standard RICE or Kano scoring first for a defensible, comparable baseline, then layer a severity pass on top as a second, explicit step — never bury it inside a single fudged number. Document the failure mode, the tier, and who signed off, so the reasoning survives the next reorg, audit, or incident review.

1. Score every backlog item with RICE (or run a Kano classification for anything user-facing) to get a defensible baseline everyone can audit and argue about on the same terms.
2. Name the failure mode in one sentence for each item: what breaks, who or what is exposed, and what happens immediately after.
3. Assign a severity tier (S1–S5) with input from whoever actually owns the consequence — safety engineering, field operations, or your utility and regulator liaison, a stakeholder group our guide to navigating utility and regulator stakeholders treats as core to the process rather than an afterthought.
4. Multiply — unless it lands in S5. If it does, stop multiplying, pull the item out of the ranked backlog, and treat it as a release gate instead of a score.
5. Re-rank and sanity-check any flipped items out loud with the team before committing. "Does this still feel right" is a legitimate check on a model that's inherently approximate.
6. Log the tier, the multiplier, and the reasoning next to the score so the decision is inspectable later — not just a mystery number in a spreadsheet six months from now.

Where a Prioritization Tool Fits

Key Takeaways

• RICE hides tail risk inside an average. Multiplying reach, impact, and confidence treats a rare catastrophic failure the same as a common, minor one.
• Add a Severity axis, borrowed from FMEA and standards like IEC 61508. Score the worst case independently of how often it happens.
• Catastrophic severity isn't a multiplier — it's a gate. Safety-of-life risks should bypass ranking entirely, the way a live security hole skips the backlog debate.
• Kano's must-be features are invisible until they fail. Reliability and safety work rarely shows up in a satisfaction survey until the day it becomes an incident postmortem.
• A low-reach safety interlock can legitimately outrank a high-reach convenience feature once severity is weighted — the worked example above closed an 80-to-1 base-RICE gap entirely.
• Set severity tiers cross-functionally, not by one PM's guess. Safety engineering, field operations, and regulatory stakeholders should weigh in before a multiplier goes into the model.
• Document the failure mode and tier next to the score so the reasoning is auditable later, not just a mystery multiplier in a spreadsheet.