Prioritisation Frameworks

Prioritisation Frameworks

Every product team has more ideas than capacity. Prioritisation is the process of deciding what to build next — not by instinct or by whoever argues loudest, but by a systematic evaluation of impact, effort, and strategic fit.

The goal of prioritisation frameworks is not to make the decision automatic. It is to make the decision process explicit, auditable, and defensible — so that the PM can explain to stakeholders why specific work was chosen and why alternatives were deferred.

The Core Trade-off: Value vs Effort

All prioritisation frameworks are variations on value divided by effort. High value, low effort items should always come first. Low value, high effort items should almost never be done. The interesting decisions are high value, high effort (big bets) versus low value, low effort (quick wins).

A 2×2 matrix of value vs effort is the simplest prioritisation tool:

• Top right (high value, low effort): do immediately
• Top left (high value, high effort): plan and invest
• Bottom right (low value, low effort): do if capacity allows
• Bottom left (low value, high effort): never do unless strategically required

RICE Scoring

Intercom's RICE framework adds rigour:

RICE = (Reach × Impact × Confidence) / Effort

• Reach: how many users will this affect in a given period? (e.g., users per quarter)
• Impact: how much will it improve each user's experience? (scored 3/2/1/0.5/0.25 for massive/high/medium/low/minimal)
• Confidence: how confident are you in the estimates? (100%/80%/50% for high/medium/low)
• Effort: person-months of work across the full team

A feature reaching 500 users/quarter with medium impact (1), high confidence (100%), and 1 month effort scores 500. Another reaching 2,000 users with low impact (0.5), low confidence (50%), and 2 months effort scores 250. RICE makes these comparisons explicit.

Caveats: RICE numbers are only as good as the estimates feeding them. Teams new to the framework tend to overestimate reach and underestimate effort. Calibrating against historical data makes scores more reliable over time.

ICE Scoring

A simpler version: Impact × Confidence × Ease, each scored 1–10. Useful for quick comparative ranking in early-stage teams where rigorous estimation is not feasible. Less precise but faster and applicable with limited data.

MoSCoW Method

Used primarily for release scope management:

• Must Have: without this, the release is a failure
• Should Have: important, but the release works without it
• Could Have: nice to have if time allows
• Won't Have: explicitly excluded from this release (but not forever)

MoSCoW does not prioritise across all backlog items — it scopes a specific release. The discipline is being honest about "Must Have." Teams that put everything in Must Have have negated the tool.

Opportunity Scoring (Jobs To Be Done Prioritisation)

Tony Ulwick's method: for each important customer "job," survey users on:

1. Importance: how important is getting this job done? (1–10)
2. Current satisfaction: how satisfied are you with current solutions? (1–10)

Opportunity score = Importance + max(Importance – Satisfaction, 0)

High importance, low satisfaction = high opportunity. High importance, high satisfaction = over-served (low opportunity). Low importance regardless of satisfaction = low opportunity.

This surfaces the gaps where users care deeply but existing solutions (including yours) are failing them — the highest-leverage investment areas.

Balancing Technical Debt

Features generate user value. Technical debt is the maintenance cost of shortcuts taken in pursuit of speed. Left unmanaged, debt compounds — each feature becomes more expensive to build on an increasingly brittle codebase.

The PM's role in technical debt management:

• Include debt repayment in roadmap planning (many teams target 20-25% of engineering capacity for debt and infrastructure)
• Understand the business consequence of specific debt items (if this database query bottleneck isn't addressed, what does it cost?)
• Avoid using "technical debt" as a black box that excuses engineering time without PM visibility

The best argument for debt repayment: frame it in user and business terms. "If we fix this caching issue, page load times drop from 4s to 0.8s, which reduces checkout abandonment by approximately 15% based on our analytics."