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:
- Problem identification — Did you identify the right problem before jumping to solutions?
- Framework discipline — Did you apply a framework to remove bias and surface stakeholder perspectives?
- Bundle and journey awareness — Did you account for bundle effects and the full user journey?
- Pre-committed success / failure criteria — Did you define what success and failure look like upfront?
- 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
Read the artifact. Don't skim. The whole thing.
Score each criterion 1–5. Be specific. A "3" with reasoning is more useful than a "4 — looks good."
Identify the strongest section. What did the author do well? Be concrete — quote or reference the section.
Identify the weakest criterion. Where's the lowest score? Why specifically?
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."
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.
1---2name: pm-evaluator3description: 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.4---56# PM evaluator78Grades 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.910## When to use1112Use this when:13- The user shares a strategy memo, PRD, recommendation deck, or product analysis and asks for critique14- The user is about to send something up the chain and wants a pre-flight check15- The user wants to grade someone else's analysis (review of a peer's memo, evaluation of an interviewee's case response)1617Don't use this when:18- The user wants to be told their work is great. Push back honestly.19- The artifact is too short to evaluate (one paragraph). Ask for more first.2021## The rubric2223Five criteria, each scored 1–5, total 5–25:24251. **Problem identification** — Did you identify the right problem before jumping to solutions?262. **Framework discipline** — Did you apply a framework to remove bias and surface stakeholder perspectives?273. **Bundle and journey awareness** — Did you account for bundle effects and the full user journey?284. **Pre-committed success / failure criteria** — Did you define what success and failure look like upfront?295. **Validation before commitment** — Did you prototype or validate before committing real resources?3031Full criterion-by-criterion scoring guidance: `rubrics/pm-evaluation-rubric.md`.3233For strategy memos specifically: `rubrics/strategy-memo-rubric.md`.34For live product review participation: `rubrics/product-review-rubric.md`.3536## How to apply37381. **Read the artifact.** Don't skim. The whole thing.39402. **Score each criterion 1–5.** Be specific. A "3" with reasoning is more useful than a "4 — looks good."41423. **Identify the strongest section.** What did the author do well? Be concrete — quote or reference the section.43444. **Identify the weakest criterion.** Where's the lowest score? Why specifically?45465. **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."*47486. **Flag any of the common failure patterns** that appear:49 - Wikipedia summary mode (description without analysis)50 - Feature laundry list (no through-line)51 - Risk taxonomy without risk analysis52 - Generic success metrics53 - No tradeoffs / every alternative obviously inferior54 - No kill criterion55 - Convenient-segment validation56 - Hope-as-strategy57 - One-way-door blindness58 - Standalone-only metrics5960## Output structure6162```63## Overall: [score]/256465[One-paragraph honest assessment.]6667## Strongest section68[What the author did well, specifically.]6970## Scores by criterion711. Problem identification: [n]/5 — [why]722. Framework discipline: [n]/5 — [why]733. Bundle and journey awareness: [n]/5 — [why]744. Pre-committed success/failure: [n]/5 — [why]755. Validation before commitment: [n]/5 — [why]7677## Weakest criterion78[Identify it; explain specifically why it's weak.]7980## Specific re-work recommendations811. [Specific section, specific change, specific reason]822. ...8384## Failure patterns flagged (if any)85- [Pattern]: [where it shows up]86- ...8788## What an exec audience will press on89[The 1-2 questions the author will be asked that they're not yet ready for.]90```9192## What good looks like9394- **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.95- **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.96- **Cite the rubric file.** Every score should be groundable in the rubric criteria.97- **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.9899## Anti-patterns100101- Scoring everything 4 or 5 to avoid being harsh102- Generic feedback ("good analysis, could be tightened")103- Listing 15 minor issues instead of the 2–3 that matter most104- Failing to identify the *one* missing thing that would most improve the artifact105106## Chain with pm-red-team107108For artifacts heading into a real exec review, fundraise, or board meeting, run the output of this skill through [`pm-red-team`](../pm-red-team/SKILL.md) 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.