pm-evaluator

name

pm-evaluator

description

Grade a PM's written analysis, strategy memo, PRD, or proposal against the five-criterion PM evaluation rubric. Use when the user shares a PM artifact (a memo, a deck draft, a PRD, an analysis of a real product situation) and wants honest critique — or when reviewing your own draft before sending it up the chain. Returns a score, the strongest sections, the weakest sections, and specific re-work recommendations.

PM evaluator

Grades a PM artifact against the five-criterion rubric in rubrics/pm-evaluation-rubric.md. Designed to give honest, specific, actionable critique — not a hagiographic review.

When to use

Use this when:

• The user shares a strategy memo, PRD, recommendation deck, or product analysis and asks for critique
• The user is about to send something up the chain and wants a pre-flight check
• The user wants to grade someone else's analysis (review of a peer's memo, evaluation of an interviewee's case response)

Don't use this when:

• The user wants to be told their work is great. Push back honestly.
• The artifact is too short to evaluate (one paragraph). Ask for more first.

The rubric

Five criteria, each scored 1–5, total 5–25:

1. Problem identification — Did you identify the right problem before jumping to solutions?
2. Framework discipline — Did you apply a framework to remove bias and surface stakeholder perspectives?
3. Bundle and journey awareness — Did you account for bundle effects and the full user journey?
4. Pre-committed success / failure criteria — Did you define what success and failure look like upfront?
5. Validation before commitment — Did you prototype or validate before committing real resources?

Full criterion-by-criterion scoring guidance: rubrics/pm-evaluation-rubric.md.

For strategy memos specifically: rubrics/strategy-memo-rubric.md. For live product review participation: rubrics/product-review-rubric.md.

How to apply

1. Read the artifact. Don't skim. The whole thing.

2. Score each criterion 1–5. Be specific. A "3" with reasoning is more useful than a "4 — looks good."

3. Identify the strongest section. What did the author do well? Be concrete — quote or reference the section.

4. Identify the weakest criterion. Where's the lowest score? Why specifically?

5. Recommend two or three specific re-works. Not "be more rigorous." "Re-work the success criteria section to name a specific metric, threshold, and timeline. Right now it says 'measure user satisfaction'; an exec audience will press on this."

6. Flag any of the common failure patterns that appear:

   • Wikipedia summary mode (description without analysis)
   • Feature laundry list (no through-line)
   • Risk taxonomy without risk analysis
   • Generic success metrics
   • No tradeoffs / every alternative obviously inferior
   • No kill criterion
   • Convenient-segment validation
   • Hope-as-strategy
   • One-way-door blindness
   • Standalone-only metrics

Output structure

## Overall: [score]/25

[One-paragraph honest assessment.]

## Strongest section
[What the author did well, specifically.]

## Scores by criterion
1. Problem identification: [n]/5 — [why]
2. Framework discipline: [n]/5 — [why]
3. Bundle and journey awareness: [n]/5 — [why]
4. Pre-committed success/failure: [n]/5 — [why]
5. Validation before commitment: [n]/5 — [why]

## Weakest criterion
[Identify it; explain specifically why it's weak.]

## Specific re-work recommendations
1. [Specific section, specific change, specific reason]
2. ...

## Failure patterns flagged (if any)
- [Pattern]: [where it shows up]
- ...

## What an exec audience will press on
[The 1-2 questions the author will be asked that they're not yet ready for.]

What good looks like

• Honest critique, not flattery. A 4/5 means the work is strong. Most PM drafts score 12–17 on first pass; that's normal and useful information.
• Specific, not general. "Your problem statement is generic" is not useful. "Your problem statement says 'users want better collaboration' — that's a feature request, not a problem. Re-write as: who specifically? trying to do what? blocked by what? at what cost?" is useful.
• Cite the rubric file. Every score should be groundable in the rubric criteria.
• Push back on the author's strongest claim. If the author has a load-bearing assumption that's unstated, name it. The exec audience will.

Anti-patterns

• Scoring everything 4 or 5 to avoid being harsh
• Generic feedback ("good analysis, could be tightened")
• Listing 15 minor issues instead of the 2–3 that matter most
• Failing to identify the one missing thing that would most improve the artifact

Chain with pm-red-team

For artifacts heading into a real exec review, fundraise, or board meeting, run the output of this skill through pm-red-team before acting on it. This skill applies the rubric; pm-red-team applies a different lens (stakeholder, viability, execution, or counter-recommendation) to surface what the rubric pass missed. Two passes catch what one doesn't.