Guide

A healthy portfolio is not 100% new features. If reliability only gets staffed after SEVs, you are borrowing from future velocity. Put a capacity allocation in the roadmap so debt is a planned investment, not a guilt trip.

Rough rule of thumb many product eng leaders use (adjust for context):

BucketShare of capacityExamples
New value / growth40–60%Features, experiments, activation
Customer commitments10–20%Contracted work, migrations
Reliability / security10–20%SLOs, vuln remediation
Tech debt / platform10–20%Refactors that unlock speed

Growth bets often have low Confidence — that is fine if Effort is small. Prefer a cheap test (continuous discovery, MVP) over a fully scored fantasy.

Separate the backlog into classes of work before scoring across them blindly: keep-the-lights-on, customer commits, growth experiments, strategic bets. Scoring a SEV remediation against a growth idea on the same RICE sheet creates false precision — reliability work often belongs in a reserved capacity bucket with its own threshold (e.g. "any P0 security issue jumps the queue").

A low-scoring platform investment sometimes unlocks three high-scoring features. Score the platform work by the portfolio it enables, or carve a debt/platform bucket so enabling work is not permanently starved by flashy feature RICE.

Walking through a quarter

One quarter, 3 person-months of eng. If 100% goes to new features, the p95 dashboard that sits at 4 seconds never moves until it pages. Reserve ~15% (call it half a person-month) for reliability and another ~15% for platform. The remaining ~2 person-months still take the RICE winners. Now an incident is not the only way debt gets a hearing.

Common mistakes

  • Scoring SEVs vs growth on one RICE sheet. False precision. Give reliability its own bucket and threshold.
  • Starving platform work because its standalone RICE loses to shiny features. Score the portfolio it unlocks.
  • Waiting for an incident to staff reliability.

Check yourself

Should a P0 security issue compete with a growth experiment on RICE? No. It jumps the queue inside a reserved reliability bucket. Do not score it as optional.

A refactor unlocks three high-RICE features. How do you justify it? Score the portfolio it enables, or fund it from the debt/platform bucket so it is not starved.

Key takeaways

  • Allocate capacity across growth, commitments, reliability and debt. Do not wait for incidents.
  • Do not RICE keep-the-lights-on work against optional bets.
  • Platform investments often pay as a portfolio, not as a single feature score.

Further learning

Pair with roadmaps: Now should be mostly top-scored or explicitly overridden items. Next: cheaper versions.