| name | pm-prioritization |
| description | Decide what to build first, or critique a prioritization. Derives criteria from strategy, picks the right framework for the context (RICE/ICE/MoSCoW/Kano/Impact-Effort), scores to expose trade-offs rather than manufacture false precision, sequences for flow, and says no with strategic context. Applies the always-true core and gates context-dependent decisions (which framework, scoring rigor, roadmap horizon, appetite vs. estimate, bets vs. tactical) with trade-offs. Trigger when asked to prioritize features/backlog, rank or sequence work, choose a prioritization framework, decide what to build first or what to cut, run a RICE/ICE/MoSCoW/Kano exercise, or defend a prioritization decision. |
| license | MIT |
| metadata | {"author":"uxcel","version":"1.0.0"} |
Prioritization Skill
How this skill behaves (read first)
This is a generative skill, and prioritization is where good intentions turn into a feature factory. Claude's defaults are the failure modes: reach for RICE for everything (the wrong tool for a brand-new product, where reach scores near zero), produce scores that look objective but rest on guesses, rank without tracing to strategy (so the loudest stakeholder wins), treat the backlog as a dump, and pretend you can optimize time, scope, and quality at once. Strong prioritization is the opposite: criteria derived from strategy, the right framework for the situation, scoring used to surface trade-offs rather than fake precision, sequencing that protects flow, and a defensible "no." So this skill gates:
- Establish the strategy, the stage/constraints, and the decision's reversibility — these determine the criteria, the framework, and how much rigor is warranted.
- Apply the always-true core — derive criteria from strategy, treat the backlog as a funnel, score to expose trade-offs, balance value × business × feasibility, make trade-offs explicit, sequence don't just rank, say no with context.
- Surface the context-dependent decisions (which framework, scoring rigor, roadmap horizon, appetite vs. estimate, bets vs. tactical) with trade-offs.
Then it hands off to pm-prioritization-rigor-audit (its primary pairing), plus pm-okr-metric-validity-audit, pm-assumption-rigor-audit, and — for high-stakes irreversible calls — pm-decision-quality-audit.
Scope: this skill owns the prioritization decision and its sequencing. It defers the roadmap artifact and its communication to pm-roadmap, the strategy itself to pm-vision-strategy, finding/validating the problems to pm-discovery and pm-problem-statement, and the spec to pm-product-spec.
Step 0 — Establish context before prioritizing
Ask if not known; state the assumption if proceeding without an answer:
- What's the strategy and the desired outcomes? Prioritization criteria are your strategy made explicit. Without named outcomes (retention, enterprise expansion, activation), you're ranking blind and will drift into a feature factory. Establish the vision → strategy → outcomes → opportunities hierarchy first.
- What stage and constraints are you in? A brand-new product has no reach to estimate (RICE misfires); a fixed launch date makes scope the only variable; a satisfaction-driven bet calls for Kano. Name capacity, deadlines, dependencies, and technical risk up front.
- How reversible is the decision? Rigor scales to stakes: a reversible, cheap call deserves a quick ICE pass; a costly, hard-to-undo bet earns heavier scoring and evidence. Over-analyzing a two-way door wastes the cycle.
The always-apply core (true for any prioritization)
- Derive criteria from strategy; trace every item back. Translate strategic choices into 3–5 weighted, scoreable criteria (enterprise strategy → deal-size impact, security, admin depth). A feature that solves a real user problem is still wrong if it doesn't advance the current strategy. If you can't trace an item to a strategic goal, question whether it belongs. This is the defense against the feature factory.
- Treat the backlog as a funnel, not a storage bin. Keep it selective — the next sprint plus a small second tier of near-term priorities; everything else moves to separate longer-term lists. Bucket items (bugs / tech debt / customer requests / strategic initiatives) so urgent noise doesn't bury high-impact work. An everything-list is a black hole that hides what matters.
- Score to expose trade-offs, not to manufacture precision. A framework's value is transparency — it forces assumptions into the open and creates a shared language — not the number it produces. Watch for scores that look more reliable than the guesses underneath them; the discussion a score triggers ("why is confidence low here?") matters more than the digits.
- Balance the three forces. Weigh user value × business outcomes × feasibility together. Overweight user asks → many small wins that don't advance goals; overweight revenue → drift from real needs; overweight feasibility → you ship only what's easy. Don't let any single voice dominate.
- Make trade-offs explicit; you can't optimize all three of time, scope, and quality (the Iron Triangle). Fix any two and the third flexes. A fixed date + fixed budget silently means cut quality — name it before work starts, not after the bugs ship. Saying "yes" to A is saying "not now" to B; say so.
- Sequence, don't just rank. A scored list is not a plan. Group work by theme so users feel a coherent change (three checkout improvements together beat three unrelated items), order by dependency so upstream decisions settle first, and define "done" beyond code deployed — analytics firing, support/sales trained, release notes written. Planning the sequence without the enablement work ships code that generates no measurable value.
- Say "no" with strategic context. A flat refusal frustrates; "that doesn't align with our current strategy of targeting mid-market" reframes it from opinion to criteria. Keep a parking-lot backlog for misaligned-but-promising ideas. Every yes to a non-strategic feature is a no to something that matters more.
- Communicate the decision. Share the framework and the rationale, tailor it to the audience (execs want strategic alignment; engineers want context; sales/support want customer-impact), and show a roadmap grouped by strategic theme. Surprise about priorities usually means communication, not the decision, failed.
The context-dependent decisions (surface, don't auto-apply)
Present each with its trade-off and a recommendation tied to Step 0; let the user choose. Defaulting to one framework for every decision is the failure mode — match the tool to the question.
| Decision | Apply when | Avoid / adapt when | Default recommendation |
|---|
| Which framework | RICE: comparing features in an existing product with estimable reach and higher stakes. ICE: quick, early, time-pressed calls. MoSCoW: negotiating scope under a fixed deadline (Must ≤ ~60% capacity). Kano: satisfaction-driven bets you can survey. Impact×Effort: fast early alignment. Eisenhower: filtering stakeholder noise, not a backlog tool | RICE on a brand-new product (reach → 0 punishes good ideas); using one framework everywhere; MoSCoW where everything becomes a "Must" | Match to context: ICE / Impact×Effort for speed, RICE when stakes and data justify the effort, MoSCoW under deadlines, Kano for satisfaction; then commit to it consistently |
| Scoring rigor | Heavier, data-backed scoring for high-stakes, irreversible bets | Manufacturing precise scores for a small reversible call | Scale rigor to reversibility; keep the number a conversation-starter, not a verdict |
| Confidence vs. projected value | When uncertainty is high, rank by confidence it'll work and validate first, not just projected value | Committing big resources to a high-value / low-confidence idea | Low confidence on a big bet → run a cheap experiment before it jumps the queue |
| Roadmap horizon format | Now-Next-Later to communicate certainty instead of dates for normal work | Date-committed roadmaps that create false certainty and erode trust when they slip | Now-Next-Later by default; fixed-date, variable-scope (Pareto/MVP cut line) only when the deadline is genuinely immovable |
| Appetite vs. estimate | Appetite (set the time, shape the solution to fit) to control investment | Open-ended estimates that default to extending the deadline when work runs long | Set an appetite; when it runs over, cut scope rather than extend time |
| Strategic bets vs. tactical needs (and segments) | Allocate capacity explicitly (e.g. 70/20/10) by product maturity; weight segments by strategic importance | Letting tactical firefighting or one big client crowd out strategic work | Set a target allocation, review it quarterly; escalate cross-segment conflicts to strategy rather than ad-hoc trades |
Validate the result (orchestration)
Hand-offs name each lens by its installable skill name. Invoke one only if that skill is installed; if it isn't, this skill's own core already carries these rules — proceed without it rather than blocking.
After producing or revising, hand it to the audit lenses rather than declaring it done. These are candidate lenses — posture per docs/orchestration-policy.md, or route the whole artifact through pm-product-review. Here assumption-rigor is the always-relevant lens (auto-runs); the others are offered, tied to what the artifact actually contains. If the user invoked this skill for one specific thing, respect that scope.
pm-assumption-rigor-audit (auto-runs) — the reach/impact/confidence estimates are assumptions; is "confidence" grounded in evidence (a pattern, a test) or just optimism?pm-prioritization-rigor-audit (offer — if it sets priorities) — its primary pairing: false precision (scores dressed up as certainty), strategy-linkage (does each ranked item trace to a goal?), the feature-factory trap, must-have inflation, and rigor scaled to reversibility.pm-okr-metric-validity-audit (offer — if it relies on an impact/value metric) — the "impact/value" criterion the scoring rests on: is it a real outcome, not a vanity or gameable number?pm-decision-quality-audit (offer — if it makes a high-stakes, hard-to-reverse call) — process over outcome, reversibility-matched deliberation, sunk-cost and bias guards, documented reasoning and trade-offs.
Composition (per docs/orchestration-policy.md §9): the roadmap that communicates this (pm-roadmap) is downstream (offer to produce next, don't auto-generate). If the audits surface a conflict (e.g., the highest-scoring item doesn't actually advance the strategy, or "confidence" is unfounded), resolve toward the purpose: prioritization exists to point limited resources at the work that most advances the strategy — keep it traceable, honest about uncertainty, and explicit about what you're saying no to. For a full idea-to-plan build, pm-idea-to-plan is the compositional front door that sequences this step with the rest of the ladder and enforces evidence before the spec.
Common do/don't patterns
| ❌ Don't | ✅ Do |
|---|
| Reach for RICE (or any one tool) for everything | Match the framework to the context; RICE fails on new products with no reach |
| Rank by gut, then let the loudest stakeholder win | Derive weighted criteria from strategy; trace every item back |
| Treat scores as objective truth | Use them to expose assumptions and trigger discussion, not to fake precision |
| Pile everything into one backlog | Funnel it: next sprint + small second tier; bucket and park the rest |
| Promise fixed date and full scope and quality | Name the Iron Triangle; fix two, flex the third explicitly |
| Hand engineering a deadline and ask for an estimate | Set an appetite; cut scope, not time, when it runs over |
| Ship a scored list as a plan | Sequence by theme and dependency; define "done" past code-deployed |
| Date-stamped roadmap that slips and erodes trust | Now-Next-Later that communicates certainty; fixed-date only when real |
| Flat "no" that frustrates stakeholders | "Doesn't fit our strategy of X" + a parking lot for later |
| Ship the prioritization unchecked | Hand off to prioritization-rigor (+ okr-metric-validity, assumption-rigor, decision-quality) |
Source lessons (Uxcel)
