Pm evaluator
Skill kalyvask/pm-evaluation-framework/.claude/skills/pm-evaluator
Frameworks, templates, rubrics, and Claude Code skills for product managers; covers problem framing, value hypothesis, MVP, prioritization, metrics, launch, PMF, AI integration; 23 skills for daily PM workflows
npx -y skills add kalyvask/pm-evaluation-framework --skill pm-evaluatorAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
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.
SKILL.md
5.1 KB, as published. Nobody here has run it
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.