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

<! 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 , 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 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: 1. 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." 2. 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." 3. 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.) 4. 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?" 5. 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?" 6. 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 )." If neither skill is available in the environment, do not leave the pointer bare: name the research in plain language instead, which is asking, per feature, how the user would feel if it were present and how they would feel if it were absent. Be honest about what a small run buys rather than naming a number that implies more than it delivers. The tier is set by how you collect (see the evidence tiers below), and what you may claim is set separately by how many people answered; a small formal instrument is still a surveyed run and still not measurement. Report the tier and the claim strength as two separate statements. 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 capacity weeks. Higher = lower score. Scale the unit to the executing team's real weekly capacity and state the conversion in the output. A notional 40 hour engineering week is the right unit for a staffed team and the wrong one for a solo maintainer with five hours a week: at that capacity every small item rounds to "under one week" and the Effort dimension stops discriminating between items entirely. Size in whatever a week actually buys that team, name the unit once, and keep it consistent across all items. 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

define-prioritization-framework