Prioritization

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:

1. Establish the strategy, the stage/constraints, and the decision's reversibility — these determine the criteria, the framework, and how much rigor is warranted.
2. 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.
3. 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)

• Ruthless Prioritization
• The Frameworks that Guide You
• The Art of Prioritization
• Using the Product Strategy to Prioritize
• Prioritization, Sequencing, & Flow
• Prioritization and Trade-Offs