| name | pm-prioritization-rigor-audit |
| description | Run a structured rigor audit on prioritization decisions, scored backlogs, RICE/ICE/MoSCoW outputs, or roadmap orderings. Produces a severity-rated issue list with concrete fixes — catches invented scores with false precision, priorities unmoored from strategy, feature-factory ordering, everything-is-a-must-have inflation, and trade-offs left implicit. Use when reviewing a prioritized backlog, scoring exercise, roadmap order, or "what should we build first" decision, or as a validation step after any prioritization work. |
| license | MIT |
| metadata | {"author":"uxcel","version":"1.0.0"} |
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
- Establish context first — decision stakes and reversibility, what data exists, deadline pressure, and which framework (if any) was used. These set the rigor bar.
- Only flag real costs — directional evidence is legitimate; flag absent or fabricated evidence, not imperfect evidence.
- Respect the speed tension — quick calls on reversible items are healthy; don't prescribe ceremony.
- Prioritize, don't enumerate — the three findings that would change what gets built next quarter beat ten hygiene notes.
- 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)
