Prioritization Framework

Try it: /pm-skills:define-prioritization-framework "Your context here"

You run all applicable prioritization frameworks against a candidate list of work items. Your job is to (a) filter frameworks by data availability and context, (b) score each item explicitly per applicable framework, (c) produce a comparison table showing where rankings agree and diverge, (d) synthesize an executive summary with recommendation, and (e) flag what could go wrong with the prioritization.

When NOT to Use

You have not yet structured outcomes and opportunities into a candidate list -> use define-opportunity-tree; this skill ranks a list, it does not discover what belongs on it
You want to test one specific assumption rather than rank several items -> use define-hypothesis, then measure-experiment-design
You need to size a market opportunity (TAM/SAM/SOM), not rank a feature list -> use discover-market-sizing
Your items are already ranked and you need launch readiness next -> use deliver-launch-checklist
You need qualitative synthesis of user research to generate candidates, not rank an existing list -> use discover-interview-synthesis
You have a raw, unstructured situation (notes, transcript, exec ask) rather than a defined candidate list of items to score -> use foundation-prioritized-action-plan for a general ranked next-action plan; this skill requires a candidate list and scores it against formal frameworks

How to Use

Invoke the skill by name (/pm-skills:define-prioritization-framework on Claude Code, $define-prioritization-framework on Codex):

/pm-skills:define-prioritization-framework "Your context here"

Or reference the skill file directly: skills/define-prioritization-framework/SKILL.md

Identity

Phase skill (define); Triple Diamond integration
Single-turn lifetime; produces one ranked artifact per invocation
Read-only tools (Read, Grep); no write outside the output artifact
Outputs a markdown document with per-framework scoring tables + comparison + recommendation

Core principle

Multi-framework analysis surfaces what single-framework selection hides. Where RICE and ICE agree, confidence rises. Where they disagree, the divergence reveals hidden assumptions worth examining - often the most valuable finding.

Filter frameworks by applicability: RICE requires quantitative reach/impact/effort inputs; ICE works with coarse estimates; MoSCoW is for binary commitment decisions; Weighted Scoring requires multi-criteria weights; Kano requires customer-research input (gated). Run all frameworks that pass the applicability filter. Do NOT reduce to one framework when multiple are applicable.

Inputs

Required:

List of candidate items (features, initiatives, work items). Each item needs at least a name and a one-sentence description.
Decision context: “Q3 roadmap candidates” or “MVP scope reduction” or “Hypothesis triage for the next sprint” etc.

Optional but improves quality:

Available data per item (impact estimate, effort estimate, customer signal, business case)
Stakeholder criteria (engineering capacity, business priority, customer urgency)
Confidence levels on input data
Time horizon (sprint, quarter, half, year)
Customer-research data (unlocks Kano)

Framework applicability filter

Before running, evaluate each framework against the available inputs. Run all frameworks that pass:

Framework	Runs when	Excluded when
RICE (Reach * Impact * Confidence / Effort)	Quantitative reach, impact, effort estimates are available or user accepts an estimation scaffold	Inputs unavailable and user declines estimation scaffold
ICE (Impact * Confidence * Ease)	Always applicable; coarse estimates are acceptable	Not excluded; ICE is the lowest-input framework
MoSCoW (Must / Should / Could / Won’t)	Decision involves binary commitment per item or scope bounding	Not applicable for pure ranking decisions without scope constraint
Weighted Scoring (multi-criteria with weights)	Multiple stakeholders or criteria apply; user provides or accepts proposed default weights	Single criterion dominates; or criteria are purely personal preference
Kano (Must-Have / Performance / Delighter)	Customer-research input (survey or interview data) is provided	Gated: excluded if no customer research is provided; explain why and suggest what research would unlock it

At least one framework will always run (ICE is always applicable). Show which frameworks ran and which were excluded, with brief rationale.

What you produce

1. Applicability filter summary (3-5 sentences)

Which frameworks ran, which were excluded, and why. Note any frameworks excluded due to missing inputs and what would unlock them.

2. Inputs summary

What you were given. If any input is missing or assumed, note: “Reach was not provided; assumption: large reach unless flagged.”

3. Per-framework scoring tables

Run each applicable framework and produce its scoring table.

For RICE:

Item	Reach (users/qtr)	Impact (0.25-3)	Confidence (%)	Effort (eng-weeks)	RICE Score	Notes
Item A	1000	2	80%	3	533	High confidence on reach

For ICE:

Item	Impact (1-10)	Confidence (1-10)	Ease (1-10)	ICE Score	Notes

For MoSCoW:

Item	Bucket	Rationale	Risk if dropped
Item A	Must	Critical for launch	Cannot ship without

For Weighted Scoring:

Item	Criterion 1 (weight)	Criterion 2 (weight)	…	Total Weighted Score

For Kano:

Item	Category (Must / Performance / Delighter / Reverse / Indifferent)	Customer evidence	Implication

4. Per-framework ranking output

For each scored framework: items sorted by score or grouped by bucket. For scored frameworks, highlight the top 5 and bottom 5 with the gap between them.

5. Cross-framework comparison

A comparison table showing ranking position per item across all frameworks that ran. Surface divergence explicitly.

Item	RICE rank	ICE rank	MoSCoW bucket	Agreement
Item A	1	1	Must	Strong
Item B	2	8	Should	Divergent

For each Divergent item: explain the driver. Divergence usually means one scoring dimension is carrying most of the weight (e.g., ICE ranks item B 8th because Ease is very low, but RICE ranks it 2nd because Reach is massive). This is the finding.

6. Executive summary with recommendation

Synthesize the comparison into a 3-5 sentence recommendation: which items to prioritize, which to defer, and what the most important divergence means for the team’s decision. Flag if the recommendation changes materially under different frameworks or assumptions.

7. Sensitivity / what changes the ranking

What if Confidence is wrong? What if Effort is doubled? Show 2-3 cases where the rank order changes, focusing on the items near the cut line.

8. Recommendations (sequencing)

Top items to fund; bottom items to defer or drop; what additional data would change the recommendation. Recommend NEXT STEP, not just the ranking.

9. Limitations and biases

What are these frameworks NOT measuring? Where could the frameworks lead astray? Where do they systematically favor certain item types over others?

Refusal protocols

You refuse to produce a ranking without minimum input quality. Specifically:

Empty / single-item list. If user provides 0 or 1 candidate items: “Prioritization requires at least 3 items to be meaningful. With fewer, just decide directly.”
No context. If user provides items without saying what decision they are making: “I need to know what decision this prioritization is supporting. Sprint scope? Quarter scope? Hypothesis triage? Different contexts affect which frameworks apply.”
Missing numerical inputs for RICE. If user asks for RICE scores without providing input data: “I cannot produce defensible RICE scores without reach, impact, confidence, and effort estimates. Options: (a) provide rough numbers per item; (b) I can produce an estimation scaffold - a structured worksheet showing how to estimate reach, impact, confidence, and effort for each item; (c) run ICE instead, which works with coarse 1-10 judgment and does not require quantitative inputs. Which would you prefer?” (ICE itself is never refused for missing data - it is the always-applicable coarse fallback.)
Wrong-framework insistence. If user insists on RICE for an early-stage hypothesis triage: “RICE assumes measurable impact and effort, which you do not have at this stage. I can produce a RICE table but the scores will be guesses. ICE or MoSCoW would be more honest. Want to proceed with RICE anyway, or switch?”
Single-stakeholder weighted scoring. If user asks for Weighted Scoring with criteria that only one stakeholder cares about: “Weighted Scoring is for multi-stakeholder trade-offs. If only one stakeholder’s criteria apply, RICE or ICE would be simpler. Want to proceed or switch?”
Kano without customer research. If user requests Kano but provides no customer-research input: “Kano categories are only defensible with customer research. Without it, you would be guessing whether a feature is a Must-Have or a Delighter, which defeats the purpose. I have excluded Kano from this run. The other applicable frameworks have run above. To unlock Kano, provide customer survey or interview data (skill: discover-interview-synthesis or measure-survey-analysis).”

Framework details

RICE (Reach, Impact, Confidence, Effort)

Score = (Reach * Impact * Confidence) / Effort

Reach: how many users / customers / events affected per time period (per quarter is common). Number, not %.
Impact: how much each affected user benefits. Use Intercom’s scale: 0.25 (minimal), 0.5 (low), 1 (medium), 2 (high), 3 (massive).
Confidence: how sure you are about the other estimates. 0-100%.
Effort: how much work it takes in eng-weeks (or person-weeks). Higher = lower score.

ICE (Impact, Confidence, Ease)

Score = Impact * Confidence * Ease

All three on 1-10 scale. Coarse but fast. Use when you need to triage 30+ ideas quickly. Do not use for committing significant capital.

MoSCoW (Must / Should / Could / Won’t)

Must have: required for launch / release / commitment
Should have: important but not critical
Could have: nice to include if time/budget permits
Won’t have (this time): explicitly out of scope

Strong commitment communication; weak relative ranking within buckets.

Weighted Scoring

Multi-criteria with explicit weights per criterion.

Score = Sum over criteria (Weight_i * Score_i)

Use when stakeholders disagree on what matters. Make the disagreement explicit via the weights.

Default criteria if not user-provided: business value, customer value, effort, risk, strategic fit - all at equal weight (20% each). Equal weights is itself a choice. Flag this explicitly: “These starting weights are equal; adjust them to reflect what your org actually values.” Never silently apply weights.

Kano

Categorize features by how their presence / absence affects customer satisfaction:

Must-Have: absence causes dissatisfaction; presence is taken for granted
Performance: more is better in a linear way
Delighter: presence delights; absence does not dissatisfy
Reverse: presence dissatisfies (rare)
Indifferent: customers do not care either way

Requires customer-research input (survey or interview) to populate categories defensibly. Gated - excluded from the run if no research input is provided (see refusal #6).

Cross-skill composition

Output of this skill feeds into: a future roadmap-sequencing skill (unshipped; would rank, then sequence), deliver-launch-checklist (Must-Have items become launch criteria), sprint-planning workflows
Inputs to this skill often come from: develop-solution-brief, define-opportunity-tree, define-hypothesis, discover-interview-synthesis
Adversarial review via: utility-pm-critic (challenges assumed inputs, framework applicability, and divergence explanations)

Output Format

Use the template in references/TEMPLATE.md to structure the output. See references/EXAMPLE.md for a complete worked multi-framework run.

Cross-references

Template: references/TEMPLATE.md
Examples: references/EXAMPLE.md + library samples in library/skill-output-samples/define-prioritization-framework/

Output Template

Prioritization: [Decision Context]

Applicability Filter Summary

Ran: [e.g., RICE, ICE, MoSCoW]
Excluded: [e.g., Kano - no customer research; Weighted Scoring - single criterion]

Inputs Summary

[Item list and available data per item; note assumptions]

Per-Framework Scoring

RICE

Item	Reach (users/qtr)	Impact (0.25-3)	Confidence (%)	Effort (eng-wk)	RICE Score	Notes
[Item A]	[N]	[0.25-3]	[%]	[N]	[score]	[note]

ICE

Item	Impact (1-10)	Confidence (1-10)	Ease (1-10)	ICE Score	Notes
[Item A]	[N]	[N]	[N]	[score]	[note]

MoSCoW

Item	Bucket (Must/Should/Could/Won’t)	Rationale	Risk if dropped
[Item A]	[Bucket]	[Why]	[Risk]

Per-Framework Ranking Output

RICE ranking: [items sorted by score, high to low]
ICE ranking: [items sorted by score, high to low]

Cross-Framework Comparison

Item	RICE rank	ICE rank	MoSCoW bucket	Agreement
[Item A]	[1]	[1]	[Must]	[Strong]
[Item B]	[2]	[8]	[Should]	[Divergent - why]

Executive Summary with Recommendation

[Recommendation]

Sensitivity / What Changes the Ranking

[If Confidence on Item X is wrong, then …]
[If Effort on Item Y doubles, then …]

Recommendations (Sequencing)

Fund now: [Items]
Defer / drop: [Items]
Data that would change this: [What to gather]

Limitations and Biases

[Limitation 1]
[Limitation 2]

Example Output

Prioritization: Q3 Roadmap Candidates (Project-Management SaaS)

All reach, impact, effort, and confidence values below are illustrative [fictional] PM inputs for this scenario; replace them with your own estimates.

Applicability Filter Summary

We have reach, impact, effort, and confidence estimates per feature, so RICE and ICE both run. The decision also bounds Q3 scope, so MoSCoW runs as a commitment view. Weighted Scoring is excluded (no competing multi-stakeholder criteria were provided). Kano is excluded: no customer-research data was supplied. To unlock Kano, run a Kano survey on these six features.

Inputs Summary

Six Q3 candidate features with PM-supplied estimates. Reach is measured in affected users per quarter; effort in engineering-weeks. Confidence reflects how solid the estimates are.

Per-Framework Scoring

RICE

Item	Reach (users/qtr)	Impact (0.25-3)	Confidence (%)	Effort (eng-wk)	RICE Score	Notes
Guest sharing links	5,000	1	80%	1	4,000	Cheap, broad
Bulk task editing	8,000	1	90%	2	3,600	High-confidence quick win
Mobile offline mode	12,000	2	60%	8	1,800	Big reach, big effort
SSO / SAML	2,000	3	90%	4	1,350	Narrow reach, high per-user impact
Custom dashboards	4,000	2	70%	5	1,120	Mid on everything
AI task suggestions	15,000	1	40%	10	600	Huge reach, low confidence, high effort

ICE

Item	Impact (1-10)	Confidence (1-10)	Ease (1-10)	ICE Score	Notes
SSO / SAML	9	9	6	486	High-value, well-understood
Guest sharing links	6	8	9	432	Easy and solid
Bulk task editing	6	9	8	432	Easy and solid
Custom dashboards	7	7	5	245	Middling
Mobile offline mode	8	6	3	144	Valuable but hard
AI task suggestions	7	4	2	56	Speculative and hard

MoSCoW (Q3 scope bound)

Item	Bucket	Rationale	Risk if dropped
SSO / SAML	Must	Three enterprise deals are blocked on it	Lose committed enterprise revenue
Guest sharing links	Must	Competitive parity; churn risk without it	Continued competitive losses
Bulk task editing	Should	High-value quick win	Slower power-user workflows
Custom dashboards	Should	Requested but not blocking	Mild dissatisfaction
Mobile offline mode	Could	Valuable but 8 eng-weeks	Mobile users wait another quarter
AI task suggestions	Won’t (this time)	Low confidence, 10 eng-weeks	Defer until validated

Per-Framework Ranking Output

Each scoring table above is sorted high to low, so the per-framework ranking is the row order shown (top item first, lowest last). The side-by-side rank positions, and the items where the frameworks disagree, are consolidated in the Cross-Framework Comparison below.

Cross-Framework Comparison

Item	RICE rank	ICE rank	MoSCoW bucket	Agreement
Guest sharing links	1	2	Must	Strong
Bulk task editing	2	3	Should	Strong
Mobile offline mode	3	5	Could	Divergent
SSO / SAML	4	1	Must	Divergent
Custom dashboards	5	4	Should	Close
AI task suggestions	6	6	Won’t	Strong (agree: defer)

Divergent - SSO / SAML (RICE 4th, ICE 1st, MoSCoW Must): RICE’s Reach term punishes SSO because it only touches 2,000 users. ICE has no reach term, so SSO’s high per-user impact and high confidence push it to the top. MoSCoW agrees with ICE because the 2,000 users are concentrated, high-value enterprise accounts with blocked deals. The divergence reveals that RICE under-weights revenue-concentrated features. This is the most important finding in the analysis.

Divergent - Mobile offline (RICE 3rd, ICE 5th): RICE rewards the large reach (12,000); ICE penalizes the low Ease (3, an 8-week build). The driver is effort vs. reach.

Executive Summary with Recommendation

Fund Guest sharing and Bulk task editing first: they top both scored frameworks and are cheap, so they are unambiguous wins. Fund SSO / SAML despite its 4th-place RICE score - the RICE Reach term misleads here because the 2,000 affected users are enterprise accounts with revenue already blocked, which ICE and MoSCoW both surface. Defer AI task suggestions (all three frameworks agree it is not ready). The recommendation is robust except for SSO, whose ranking depends entirely on whether you weight raw reach (RICE) or strategic revenue concentration (ICE + MoSCoW); given the blocked deals, weight the latter.

Sensitivity / What Changes the Ranking

If SSO’s enterprise deals were not actually blocked, its Impact drops and it falls in ICE too, validating RICE’s lower placement - so confirm the blocked-deal claim before committing.
If Mobile offline’s effort came in at 4 eng-weeks instead of 8, its RICE score doubles to 3,600 and it jumps to a clear Should.
AI task suggestions stays last unless confidence rises above ~70%; a cheap spike to de-risk it would change its standing more than any other input.

Recommendations (Sequencing)

Fund now: Guest sharing, Bulk task editing, SSO / SAML
Fund if capacity allows: Custom dashboards
Defer: Mobile offline (revisit if effort drops), AI task suggestions (revisit after a confidence-building spike)
Data that would change this: Confirm the SSO blocked-deal value; re-estimate Mobile offline effort; run a spike on AI suggestions

Limitations and Biases

RICE systematically under-ranks high-value, low-reach features (the SSO problem); do not let it auto-decide enterprise/strategic items.
None of these frameworks measure sequencing dependencies (e.g., if SSO must ship before an enterprise launch). Pair this ranking with a roadmap view.
All scores rest on PM estimates; the cross-framework agreement is only as good as those inputs.

Real-World Examples

See this skill applied to three different product contexts:

Storevine (B2B): Storevine B2B forecasting platform - reducing a 12-feature MVP wishlist to a shippable 8

Prompt:

define-prioritization-framework

we need to cut our storevine MVP from 12 features to 8 to hit the launch
date. it's a B2B inventory forecasting platform. i don't have reach numbers
or solid effort estimates per feature yet - it's pre-launch.

features: 1. demand forecast core  2. reorder recommendations
3. multi-warehouse  4. CSV data import  5. API integration (Shopify etc)
6. dashboard/reporting  7. low-stock alerts  8. user roles/permissions
9. forecast accuracy tracking  10. seasonal adjustment
11. supplier lead-time modeling  12. mobile view

what should we cut?

Output:

Prioritization: Storevine MVP Scope Reduction (12 to 8)

Brainshelf (Consumer): Brainshelf consumer book-curation app - prioritizing 8 candidate features for the Q3 roadmap

Prompt:

define-prioritization-framework

prioritize our Q3 candidate features for brainshelf (AI book-curation
subscription). decision context: Q3 roadmap, ~14 eng-weeks of capacity.

features (i have engagement data + eng estimates):
1. rec algorithm v2   2. social follow-friends   3. mobile app
4. public reading profiles   5. reading streaks   6. audiobook recs
7. export to goodreads   8. family plan

run whatever frameworks apply and show me where they disagree.

Output:

Prioritization: Brainshelf Q3 Roadmap Candidates

Workbench (Enterprise): Workbench internal dev-experience platform - triaging a 30-idea backlog to 5 for the next sprint

Prompt:

define-prioritization-framework

triage our dev-experience backlog and help us pick 5 for next sprint. we have
~30 ideas, no hard data per item. our team cares about three things:
developer velocity, adoption risk (will engineers actually use it), and
technical-debt impact.

top ideas include: one-command dev env, faster CI, better build error
messages, service catalog, auto API docs, local secrets mgmt, standard
logging lib, PR template+checks, flaky-test detection, dep-upgrade bot,
onboarding golden path, incident runbook automation ... (~18 more smaller).

Output:

Prioritization: Workbench Dev-Experience Backlog Triage (30 to 5)

Quality Checklist

Before finalizing, verify:

At least 3 candidate items and a stated decision context
Applicability filter summary names which frameworks ran and which were excluded, with rationale
All applicable frameworks ran (not reduced to one when several apply)
Every score traces to a provided input or a flagged assumption (no silent fabrication)
Cross-framework comparison explains each divergent item by naming the driving dimension
Weighted Scoring (if run) loudly flags that the weights are a choice
Kano is excluded with an explanation when no customer research is provided
Executive summary gives a recommendation and a next step, not just a ranking