Define Prioritization Framework
Run applicable prioritization frameworks (RICE, ICE, MoSCoW, Weighted Scoring, Kano) against a list of features or initiatives. Produces a comparison table showing where rankings agree and diverge across frameworks, and an executive summary with recommendation. Framework applicability is filtered by data availability; Kano requires customer research. Refuses to fabricate scores; produces an estimation scaffold when input data is missing.
- Skill ID
- product-on-purpose/pm-skills/define-prioritization-framework
- Publisher
- product-on-purpose
- Repository
- pm-skills
- Installs
- 0
- Files
- 5
- License
- Apache-2.0
- Synced
- Sep 23, 2026
Open any RiverX project, open the Skills panel in the chat, and search for this identifier. The files are fetched from the source repository at install time.
product-on-purpose/pm-skills/define-prioritization-frameworkInstalls these files- HISTORY.md
- SKILL.md
- evals/trigger-fixtures.json
- references/EXAMPLE.md
- references/TEMPLATE.md
What this skill tells the agent
<!-- PM-Skills | https://github.com/product-on-purpose/pm-skills | Apache 2.0 -->
Prioritization Framework
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.
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.
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, thenmeasure-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-planfor a general ranked next-action plan; this skill requires a candidate list and scores it against formal frameworks
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 is provided, at either evidence tier below | Gated: excluded only if no customer research at all is provided; explain why and suggest what research would unlock it. Run at the tier the evidence supports and label the tier in the output |
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 (capacity-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 / Ambiguous) | Response distribution (surveyed runs; not available (inferred) otherwise) | Evidence tier and claim strength | 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. When the backlog has 10 or fewer items, a top 5 and a bottom 5 overlap or exhaust the list, so the rule cannot be followed as written: show every item in rank order instead and describe the gap between the clear tiers rather than forcing a five-and-five split.
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."
More from product-on-purpose
Use this skill in a project
Open any RiverX project, search the Skills panel for product-on-purpose/pm-skills/define-prioritization-framework, and install it in one click.
