Prioritisation frameworks

This is the exact file agents read, including the credit header and licence notice. Save it as prioritisation-frameworks/SKILL.md.

---
name: prioritisation-frameworks
description: Choose and correctly apply a product prioritisation framework: RICE, ICE, WSJF, Kano, weighted scoring, opportunity scoring, MoSCoW and value-versus-effort. Carries the real formulas and scales (RICE Impact 3/2/1/0.5/0.25 and Confidence 100/80/50%; WSJF cost of delay over job size on a modified Fibonacci scale; the Kano functional and dysfunctional questionnaire; MoSCoW Must at most about 60% of effort), the thresholds that catch a gamed or false-precision score, a protected lane for compliance and keep-the-lights-on work, and a sensitivity check before any order is published. Use it when someone says prioritise the backlog, RICE these, score with WSJF, run a Kano survey, MoSCoW this release, rank these features, which framework should I use, or why this and not that. Do NOT use it to set product strategy or decide whether a problem is worth solving at all, and do NOT use it to sequence work over time or communicate a plan to stakeholders (see product-roadmapping).
---

# Prioritisation frameworks

A prioritisation framework exists to force a hidden assumption into the open, not to produce a number that decides for you. The score is the by-product. The value is the argument you have to make to defend each input. This skill makes an AI agent run RICE, ICE, WSJF, Kano, weighted scoring, opportunity scoring, MoSCoW and value-versus-effort properly: the right framework for the situation, the real scales and formulas, the thresholds that catch a gamed score, and a protected lane for work that must happen regardless of its score.

## When to use this skill, and when not to

Use it when someone has more candidate work than capacity and needs a defensible order: a backlog of features, a set of bets for a quarter, a list of fixes competing for one engineer, or a stakeholder asking "why this and not that". Use it when someone names a framework ("let us RICE the backlog", "score these with WSJF", "run a Kano survey", "MoSCoW this release"), when they ask which framework fits, or when a score looks wrong and they want it checked.

Do not use it to decide *whether* a problem is worth solving at all: a framework ranks options that already passed a strategy filter, it does not supply the strategy. If the candidates have not been checked against the product strategy, say so and prioritise the strategy conversation first. Do not use it to sequence work over time or to communicate a plan to stakeholders; that is roadmapping, and it is covered by the product-roadmapping skill. Do not use it as a political shield: "the framework said so" is never a reason on its own, because every input was a judgement someone can question.

## What the agent must have before starting

Ask for whatever of these is missing, and do not invent any of it:

1. The list of candidate items, each described as a problem or outcome, not only a feature name.
2. The product strategy or the current goal the work should serve, so items that do not serve it can be flagged.
3. For each item, whatever evidence exists for reach and impact: real product metrics, support-ticket counts, revenue figures, research. Where there is no evidence, the agent marks the input a guess rather than filling a number.
4. The team or people doing the work and roughly how much capacity exists, so the shortlist can be cut to fit.
5. Who signs off on effort estimates. Effort is the denominator in most frameworks and the input most often wrong; an engineer should set it.

If the person asks for a score without any of this, give them the framework and the blank scoring sheet, and name what is still needed to fill it honestly. A framework run on four guesses returns a confident number built on nothing.

## The workflow

### Step 1: Mark every input as evidence or guess

Before any scoring, tag each number you are about to use as [evidence] (a metric, a count, a research finding with a source) or [guess] (someone's estimate). Keep the tag next to the number. This single habit is what separates a ranking from noise, and it makes the later sensitivity check possible. If more than half the inputs on an item are guesses, the output is a hypothesis to test, not a decision to act on; say that in the result.

### Step 2: Pull must-do work into a protected lane

Some work does not belong in a value formula at all: legal and compliance obligations, security fixes, keep-the-lights-on maintenance, contractual commitments. Scoring these against features is a category error, because they will usually score low on reach and lose, then reappear as an incident. Put them in a separate lane above the scored list, size them, and subtract their capacity before you rank anything else. Only discretionary work gets scored.

### Step 3: Choose the framework from the situation, not habit

Pick by what the decision actually is:

- Mixed backlog, need a defensible relative order, some evidence available: **RICE**.
- Early, low-rigour, need speed over precision: **ICE**.
- Engineering-led work where urgency and job size vary a lot, or a scaled/SAFe setting: **WSJF**.
- You need to communicate what is in and what is cut for one release: **MoSCoW**.
- The question is "which of these would users actually love, and which are merely expected": **Kano**.
- Several criteria matter and their weights differ (value, strategic fit, risk, cost): **weighted scoring matrix**.
- You want to find under-served needs, not rank solutions: **opportunity scoring**.
- Quick visual triage of a long list: **value versus effort** 2x2 as a first pass, never as the final cut.

If the person asked for one framework but the situation fits another, say so and offer the better fit, then use whichever they confirm.

### Step 4: Apply the chosen framework with its real scale

**RICE** (Intercom, who created it): score = (Reach × Impact × Confidence) ÷ Effort, read as impact per unit of work.
- Reach: number of people or events in a fixed time window, from a real metric (customers per quarter, transactions per month). Fix one window for the whole round; 5,000 per quarter and 5,000 per year are not the same number.
- Impact: a multiple-choice weight, not a free number. Massive = 3, High = 2, Medium = 1, Low = 0.5, Minimal = 0.25.
- Confidence: a percentage. High = 100%, Medium = 80%, Low = 50%. Below 50% is a moonshot: do not score it, run a discovery spike instead and score it next round.
- Effort: person-months (product, design and engineering combined), whole numbers or 0.5 for sub-month work, set by someone who will do the work.

**ICE**: Impact × Confidence × Ease, each scored 1 to 10. Faster than RICE and cruder; use it to triage, not to defend a cut to a stakeholder, because three 1-to-10 guesses multiplied together carry no real precision.

**WSJF** (SAFe): score = Cost of Delay ÷ Job Size, highest first. Cost of Delay is the sum of three scored components: user-and-business value, time criticality, and risk reduction or opportunity enablement. SAFe scores each on a modified Fibonacci scale (1, 2, 3, 5, 8, 13, 20); the honest way to use it is to set the smallest item in each column to 1 and score the others relative to it, rather than scoring in a vacuum. Job Size is a relative estimate of effort on the same kind of scale. Because small jobs raise the score, WSJF naturally surfaces cheap, urgent, high-value work first. It ignores sunk cost by design.

**Kano**: classify each feature by how its presence and absence affect satisfaction. Categories: Must-be (basic; absence angers, presence is invisible), Performance (one-dimensional; more is linearly better), Attractive (delighter; unexpected, creates delight, absence is not missed), Indifferent (no effect), Reverse (users prefer the opposite), Questionable (contradictory answer, usually a survey error). Classify with a paired question per feature: a functional question ("how do you feel if you have this?") and a dysfunctional one ("how do you feel if you do not have this?"), each answered on the five-point scale: I like it, I expect it, I am neutral, I can tolerate it, I dislike it. Map the answer pair to a category with the Kano evaluation table (for example: like-it-if-present and dislike-it-if-absent = Performance; like-it-if-present and neutral-or-expect-if-absent = Attractive; neutral-or-expect-if-present and dislike-it-if-absent = Must-be). For a group, either take the most common category per feature (discrete method; break ties in the order Must-be, then Performance, then Attractive, then Indifferent) or average on a continuous scale (functional answers scored dislike -2, tolerate -1, neutral 0, expect 2, like 4) and plot. The build order Kano implies: every Must-be first, then as much Performance as capacity allows, then a few Attractive. Treat Kano categories as unordered labels, not a total ranking.

**Weighted scoring matrix**: list the criteria that matter, assign each a weight that sums to 100%, score each item on each criterion on a fixed scale (say 1 to 5), and sum weight × score. Write the weights down before scoring any item, or the weights will be reverse-engineered to justify a favourite.

**Opportunity scoring** (Ulwick): for an outcome, ask customers how important it is and how satisfied they are, each on a 1-to-10 scale. Opportunity = importance + max(importance − satisfaction, 0). High importance with low satisfaction is an under-served need worth pursuing; high importance with high satisfaction is already handled.

**MoSCoW**: sort into Must have, Should have, Could have, Won't have this time. Must means the release fails without it (test: would you cancel the release if this slipped?). Keep Must at no more than about 60% of total effort; if it is higher, the scope is a strategy problem, not a prioritisation one. Hold roughly 20% as Could-have contingency. The Won't column is the most valuable one, because it records what you agreed to drop.

### Step 5: Run the sensitivity check before publishing an order

Take the two or three items near each decision boundary. Move each soft ([guess]) input within its plausible range, up to about double or half. If the order flips, you have noise, not a ranking: do not present a firm order, present the cluster as a tie and name the input that would settle it. As a standing rule, treat any two scores within about 15% of each other as tied and break the tie on strategy, dependency or learning value, not on the decimal.

### Step 6: Read the top of the list against strategy

Before handing over, read the top five as a group and ask whether they add up to the strategy. A list where everything optimises one dimension (usually reach) has a blind spot: foundational work, technical debt and strategic bets score low on reach and get cut every quarter unless they sit in a protected lane (Step 2) or are scored within their own group. If the top of the list is all quick wins and no bets, say so.

## Worked example

Input: four candidates for next quarter, team of three, roughly 9 person-months of discretionary capacity, goal is to raise activation.

1. Guided onboarding checklist. Reach 8,000 new users/quarter [evidence, product analytics]. Impact 2 (High) [guess]. Confidence 80% [evidence, a prior similar change lifted activation]. Effort 3 person-months [engineer sign-off]. RICE = (8000 × 2 × 0.8) ÷ 3 = 4,267.
2. Dashboard redesign. Reach 3,000/quarter [evidence]. Impact 3 (Massive) [guess]. Confidence 50% [guess]. Effort 4 [guess]. RICE = (3000 × 3 × 0.5) ÷ 4 = 1,125.
3. CSV export. Reach 10,000/quarter [guess, "everyone asks for it"]. Impact 1 (Medium). Confidence 100%. Effort 1. RICE = (10000 × 1 × 1) ÷ 1 = 10,000.
4. SSO for enterprise. Contractual, needed to close two signed deals.

First, Step 2 pulls SSO into the must-do lane: it is contractual, so it is scheduled and its effort is subtracted, not scored. Of the rest, CSV export tops RICE at 10,000, but Step 1 flags its reach as a guess and its justification as "everyone asks", which is table-stakes reasoning. Step 5: drop CSV reach to a defensible 4,000 (the share who use exports) and its score falls to 4,000, below onboarding. The sensitivity check has reordered the list, so the honest output is: SSO is committed; onboarding is the strongest activation bet with real evidence; CSV and the dashboard are a tie pending a reach number for CSV and a confidence spike for the dashboard. That is a more useful answer than "CSV wins, score 10,000".

## Templates you can use verbatim

RICE scoring row:
`Item | Problem it solves | Reach (/period, source) | Impact (3/2/1/0.5/0.25) | Confidence (100/80/50%, source) | Effort (person-months, by) | Score | evidence or guess`

Framework-choice prompt for the agent:
"Before scoring, tell me: what is the decision, what evidence exists for reach and impact, who sets effort, and what strategy should the top of the list serve. Then recommend the framework that fits and show the blank sheet."

Kano question pair, per feature:
"If [feature] were present, how do you feel? / If [feature] were absent, how do you feel?" Answers: I like it, I expect it, I am neutral, I can tolerate it, I dislike it.

## Failure modes and anti-patterns

1. **False precision.** A score of 42.7 built from three guesses reads as if it were measured. Spot it: inputs tagged [guess] but the score quoted to the decimal. Instead: score in ranges or buckets, treat within-15% scores as ties, and never let the arithmetic carry a decision the inputs cannot support.
2. **Gaming the inputs.** Inflate Impact, shrink Effort, claim 100% reach for a feature 2% of users want. Spot it: more than 30% of items holding the top Impact score, or Confidence at 100% across the board. Instead: cap the share of top-Impact items, require a written source for any Confidence above 50%, and have an engineer sign off every Effort.
3. **Reach dominance.** Because RICE multiplies by reach linearly, a broad shallow feature beats a narrow deep one every time. Spot it: the top of the list is all high-reach, low-impact items. Instead: compare impact within reach bands, or switch to WSJF or a weighted matrix when strategic value matters more than headcount.
4. **Scoring the wrong altitude.** A feature can score a perfect number and still solve a problem no customer has. Spot it: items scored before any opportunity or problem was validated. Instead: run opportunity scoring or a Kano pass first to confirm the need, then rank solutions.
5. **Score and forget.** Estimates two months old are wrong; attractive features decay into expected ones. Spot it: no re-scoring cadence, last quarter's order still driving work. Instead: re-score the top five each quarter against what actually shipped and what it moved, and re-run Kano periodically because categories drift.

## Quality bar

Before handing over a prioritised list, confirm: every input is tagged evidence or guess; must-do work sits in a protected lane, not the scored list; the framework matches the decision; the formula and scale used are the real ones, not improvised; a sensitivity check has been run on the boundary items and genuine ties are shown as ties; the top five have been read against the strategy; and every number a stakeholder could challenge has a source or an honest "guess" label. The deliverable is a ranking a person can defend input by input, plus a short note of what evidence would change it. Prioritisation is decision support; a human owns the decision, and any commitment to a date or a customer is made by a person, not by the score.

## Tool appendix

- **Jira / Linear / Productboard / Aha!**: RICE and value/effort fields exist natively or as custom fields; enter the scored inputs, not just the final score, so the source survives. None of these validate your inputs; the checks in this skill are yours to run.
- **Spreadsheets**: for RICE, keep Reach, Impact, Confidence and Effort in separate columns with a source column beside each, so a reader can audit a score without rebuilding it. Sort on the computed score, never type the score by hand.
- **Kano surveys**: any form tool runs the paired questions; the work is the evaluation table, not the survey. Keep the raw answer pairs so a feature can be re-classified later as expectations shift.
- No framework needs an API or paid tool; all of this runs in a sheet. If a scoring plugin asks for live product data, treat reach figures as the only ones worth wiring up, and keep the rest as reviewed estimates.

## Sources

- Intercom, "RICE: Simple prioritization for product managers" (the framework's origin), intercom.com/blog/rice. Last verified 10 November 2026.
- ProductPlan glossary, "Weighted Shortest Job First (WSJF)", productplan.com. Last verified 10 November 2026.
- Scaled Agile, "WSJF", framework.scaledagile.com/wsjf (modified-Fibonacci scoring is standard SAFe practice; verify against your SAFe version). Last verified 10 November 2026.
- Folding Burritos, "The Complete Guide to the Kano Model" (Daniel Zacarias), foldingburritos.com/blog/kano-model. Last verified 10 November 2026.
- Agile Business Consortium, "What is MoSCoW Prioritisation?" (DSDM), agilebusiness.org. Last verified 10 November 2026.
- Rock, "RICE Scoring Explained (and When Its Math Lies)", rock.so/blog/rice-scoring. Last verified 10 November 2026.
- Peter Hilton, "Product arithmetic", hilton.org.uk/blog/product-arithmetic. Last verified 10 November 2026.
- Tony Ulwick / Strategyn, Outcome-Driven Innovation opportunity algorithm (importance and satisfaction). Last verified 10 November 2026.

---
1.0.0, 10 November 2026: first release. Use, adapt and share this skill under CC BY 4.0: credit Afeez Adebayo, link afeezadebayo.com and the skill's download page. This is decision-support guidance, not a substitute for your own product judgement.