Pm Prioritization Rigor Audit

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:

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

Copy code
## 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

Source lessons (Uxcel)

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