Prioritization rigor

Prioritization Rigor Audit Skill

What this skill changes vs. default behavior

By default, Claude performs prioritization confidently — it fills RICE tables with invented numbers, ranks features by plausible-sounding impact, and presents the result with unearned precision. Reviewing someone else's prioritization, it tends to accept scores at face value. This audit forces four things: every score is traced to its evidence (or flagged as decoration), every ranking is traced to a strategic outcome (or flagged as unmoored), every "must-have" is challenged, and every decision is checked for an explicit, stress-tested trade-off. Findings come severity-rated with concrete fixes.

This is an evaluative skill: it auto-runs whenever a prioritized list, scoring table, backlog order, or build-next decision appears in work being reviewed or generated.

Scope discipline. When invoked directly (the user named this audit), review only this concern — don't pull in sibling audits. It runs alongside other lenses only when the pm-product-review orchestrator or a generative skill calls it under docs/orchestration-policy.md, where it sits in an artifact-specific lens — offered (when work is prioritized or roadmapped). Explicit scope always wins.

---

The framework — what to check and what a violation looks like

1. Evidence behind scores (the false-precision check)

A RICE/ICE score is only as good as its inputs. Reach should come from real usage data, impact from a hypothesis someone can defend, confidence from the quality of evidence — not from optimism. Scores invented to two decimal places are intuition wearing a lab coat.

Flag when: scores appear without sources; confidence is uniformly high; effort estimates lack engineering input; the precision of the output (e.g., "RICE 847.5") exceeds the precision of any input; scoring was applied after the decision to justify it.

• ❌ "Reach: 9, Impact: 8, Confidence: 90% — RICE says build it" (no data named anywhere)
• ✅ "Reach: ~5,000 new users/mo (signup analytics); Impact: medium (2) — activation, not revenue; Confidence: 80% (interview evidence for the problem, none yet for the solution)"

2. Strategy linkage (the unmoored-priorities check)

Every ranking implies criteria, and the criteria must come from the product strategy — explicit, weighted, and written down. A priority list that can't name what strategic outcome each top item advances is ordered by loudness, recency, or stakeholder power.

Flag when: no stated criteria; criteria that don't trace to strategic goals; top items that serve a single deal or the loudest voice; a "weighted scoring" exercise whose weights nobody chose deliberately; priorities unchanged after a stated strategy change.

• ❌ Top of backlog: custom reporting dashboard for one enterprise prospect, rationale "sales needs it"
• ✅ "Criteria from strategy (mid-market expansion): deal-size impact 40%, security coverage 30%, admin depth 30% — scored 1–5, weights sum to 100%"

3. Outcome orientation (the feature-factory check)

Prioritization that ranks outputs produces a feature factory: many releases, no progress. Items should be framed as problems/outcomes with the user count and pain severity known, and each should map back to the hypothesis it serves.

Flag when: the list is pure feature names with no problem statements; nothing states how many users are affected or how severely; items can't be traced to an original hypothesis ("we believe [segment] will [behavior] because [reason]"); success of the ranked work is defined as "shipped."

• ❌ "1. AI assistant 2. Dark mode 3. New dashboard" — no problems, no outcomes
• ✅ "1. Activation drop-off at step 3 (affects 60% of signups, blocks the north-star driver) — candidate solutions listed beneath"

4. Honest categories (the must-have-inflation check)

MoSCoW and quick-win/major-project portfolios only work when categories have teeth. When everything is a must-have, nothing is; when "Won't have" is empty, scope creep is pre-approved.

Flag when: >~60% of items sit in Must Have; "Won't have" is empty or missing; no quick wins anywhere (momentum starves) or only quick wins (transformation never happens); Kano logic inverted — delighters prioritized while basics are broken.

• ❌ 14 of 18 items "Must Have," Won't-have list absent
• ✅ Musts = product fails without them; explicit Won't-haves with reasons; a balanced quick-win/major-project mix

5. Explicit trade-offs (the silent-cost check)

Every yes is a no to something. Rigor means the rejected alternatives, the costs of the chosen path, and the reasoning are visible — and would survive a stakeholder's "why this, why now?"

Flag when: no record of what was deprioritized or why; decisions jump from problem to choice with the tension smoothed over; the user-value vs. business-viability conflict is presented as naturally aligned; no answer to "what evidence would change this decision?"

• ❌ "We prioritized onboarding improvements." (and silence)
• ✅ "Onboarding over advanced reporting: activation lifts the whole base; reporting serves 8% of accounts — revisit if enterprise pipeline doubles. Cost: reporting customers wait a quarter."

6. Framework fit and consistency

Frameworks are tools with known failure modes: RICE needs data and time; MoSCoW ignores effort; Kano needs real survey input (not guessed "delighters"). And a framework applied selectively — abandoned whenever results are inconvenient — is worse than none.

Flag when: a framework mismatched to the situation (RICE with zero data; Kano categories assigned by gut); framework-hopping between decisions; scores overridden by intuition without documenting why; constraints (time/scope/complexity triangle) ignored in effort estimates.

• ❌ Kano "delighter" labels assigned in a meeting, no user survey behind them
• ✅ "MoSCoW for this release (fixed deadline, low data); RICE deferred until analytics mature"

Tension note: rigor vs. speed — not every decision deserves a full scoring exercise; a reversible, low-stakes choice made quickly is good prioritization. Flag missing rigor where the decision is expensive to reverse, not everywhere. And strategic bets legitimately override scores — the requirement is that the override is explicit and reasoned, not that math always wins.

---

Severity rating

Rate each finding by decision damage — what the prioritization, left as-is, would cause the team to build or skip:

Severity	Meaning
Critical	The ordering would steer the team wrong (priorities serving one deal over strategy, invented scores driving an expensive irreversible bet, feature-factory list with no outcomes)
Major	The reasoning can't be defended or audited (no criteria, no evidence trail, silent trade-offs, must-have inflation)
Minor	Process hygiene (framework mismatch on low-stakes items, missing Won't-have list, stale priorities after strategy shifts)
Cosmetic	Formatting/labeling polish; don't pad the report with these

Overlaps: whether the metrics used as criteria are themselves valid belongs to pm-okr-metric-validity-audit — this audit assumes the criteria and checks the ranking discipline. Broader decision-process quality (bias, reversibility, process-vs-outcome) belongs to pm-decision-quality-audit.

---

Output format

## Prioritization Rigor Audit — [Target]
Context: [team/product · decision stakes · framework used · data available, if known]

### Critical
- [Issue] — what's wrong → concrete fix. (Principle)
### Major
- …
### Minor
- …
### Working well ✓
- …

**Top 3 priorities:** the highest decision-damage fixes, each with the specific question the team must answer.

Always end with the prioritized top issues — a flat list helps no one act.

---

How to run a good audit

1. Establish context first — decision stakes and reversibility, what data exists, deadline pressure, and which framework (if any) was used. These set the rigor bar.
2. Only flag real costs — directional evidence is legitimate; flag absent or fabricated evidence, not imperfect evidence.
3. Respect the speed tension — quick calls on reversible items are healthy; don't prescribe ceremony.
4. Prioritize, don't enumerate — the three findings that would change what gets built next quarter beat ten hygiene notes.
5. Be specific in fixes — name the missing data source, propose the criteria weights, draft the Won't-have entry. Never just "add more rigor."

---

Common do/don't patterns

❌ Don't	✅ Do
Accept a RICE table at face value	Trace each score to its evidence; flag decoration
Fill in plausible scores when auditing a gap	Name the gap: "Reach is unmeasured — pull signup analytics"
Treat a ranked feature list as prioritization	Demand problems/outcomes with affected-user counts
Let "everything is critical" stand	Force Must-have teeth and an explicit Won't-have list
Praise the framework choice and move on	Check the framework fits the data and the stakes
Demand full scoring for every small call	Scale rigor to reversibility and cost
Re-audit the metrics' validity	Defer metric quality to pm-okr-metric-validity-audit
Deliver an unranked issue dump	Severity by decision damage + top-3 with the questions to answer

---

Source lessons (Uxcel)

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