Strategy and planning
Capacity allocation
Reserve capacity for growth, commitments, reliability and debt so incidents are not the only planning process.
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):
| Bucket | Share of capacity | Examples |
|---|---|---|
| New value / growth | 40–60% | Features, experiments, activation |
| Customer commitments | 10–20% | Contracted work, migrations |
| Reliability / security | 10–20% | SLOs, vuln remediation |
| Tech debt / platform | 10–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.
Related
Prioritization
RICE, ICE, Kano, cost of delay and opportunity cost: choosing what not to build.
Roadmaps and OKRs
Outcome-based roadmaps, now/next/later, and OKRs that guide rather than constrain. Start here for the map.
ICE, Kano and cost of delay
Faster scoring when reach is similar, categories of need, and how much waiting costs per week.