Feature Comparison
Produce a feature-by-feature comparison plan, eval design, and execution method, in three sequential phases with one explicit user confirmation gate.
Difference vs pmstack-competitive
- Competitive = market positioning (audience, value prop, where to wedge in)
- Compare = feature parity, scored, evidence-based, reproducible
Three phases (always sequential, never collapsed)
Phase 1 — Explore
Goal: gather raw material so dimensions emerge from products, not from your priors.
- Parse the user's product list. Each product needs at minimum a name. URL is helpful but optional.
- If two products share a name (e.g., "Notion" company vs "Notion" open-source tool), STOP and ask which one.
- For each product, gather: official feature list (from docs / pricing if URL given), pricing model, deployment options, target customer.
- Note explicitly what you could not find. Do not fill gaps with guesses.
Output: a brief raw-data summary. Do not write the comparison yet.
Phase 2 — Define
Goal: derive comparison dimensions from Phase 1, then propose a measurement plan.
- From the raw data, propose 5–10 dimensions specific to this product category. Do not import a generic SaaS template.
- For each dimension, define how you'll judge it (objective fact, scored 1–5, qualitative).
- Design an eval suite (use the eval template structure) with ≥6 test cases hitting the dimensions.
- Choose execution mode:
- Mode (a) Live: products have public docs / free tier / open API → Claude probes directly
- Mode (b) Plan-only: products require auth / payment / credentials → emit eval YAML +
/run-eval command for the user to run themselves
- Write the plan (raw summary + dimensions + eval design + chosen mode + risk note) to
outputs/compare-<products-slug>-<YYYY-MM-DD>-plan.md.
- STOP and ask the user for one y/n on the whole plan.
Phase 3 — Execute
Only after confirmation:
- Write eval YAML to
outputs/eval-compare-<products-slug>-<YYYY-MM-DD>.yaml.
- Mode (a): invoke
/run-eval and write findings to outputs/compare-<products-slug>-<YYYY-MM-DD>-findings.md.
- Mode (b): print the exact
/run-eval command + env vars the user needs to set first.
Hard rules
- Three phases, in order. No shortcuts.
- Confirmation gate between Phase 2 and Phase 3 is non-negotiable.
- Dimensions are derived from products, not imposed.
- No invented features. "Not documented" ≠ "doesn't have it".
- Do not silently switch modes mid-execution. If Mode (a) fails, stop and tell the user what's needed for Mode (b).
Where to write
- With filesystem: paths above
- Inline (web/mobile): emit each artifact as a code block with the filename header
Tone
Analytical, direct. Lead with what's surprising. Hedge appropriately on facts you couldn't fully verify.
1---2name: pmstack-compare3description: Feature-by-feature comparison of two or more products with built-in eval design and runnable execution. Use when the PM wants to compare specific features across products (e.g., "compare GitHub Copilot vs Cursor", "how does our pricing stack up against X and Y", "evaluate these two AI coding tools head-to-head"). Use pmstack-competitive instead for market-positioning analysis (audience, value prop, white space).4---56# Feature Comparison78Produce a feature-by-feature comparison plan, eval design, and execution method, in three sequential phases with one explicit user confirmation gate.910## Difference vs pmstack-competitive11- **Competitive** = market positioning (audience, value prop, where to wedge in)12- **Compare** = feature parity, scored, evidence-based, reproducible1314## Three phases (always sequential, never collapsed)1516### Phase 1 — Explore17Goal: gather raw material so dimensions emerge from products, not from your priors.18191. Parse the user's product list. Each product needs at minimum a name. URL is helpful but optional.202. **If two products share a name** (e.g., "Notion" company vs "Notion" open-source tool), STOP and ask which one.213. For each product, gather: official feature list (from docs / pricing if URL given), pricing model, deployment options, target customer.224. Note explicitly what you could not find. Do not fill gaps with guesses.2324Output: a brief raw-data summary. Do not write the comparison yet.2526### Phase 2 — Define27Goal: derive comparison dimensions from Phase 1, then propose a measurement plan.28291. From the raw data, propose 5–10 dimensions specific to *this product category*. Do not import a generic SaaS template.302. For each dimension, define how you'll judge it (objective fact, scored 1–5, qualitative).313. Design an eval suite (use the eval template structure) with ≥6 test cases hitting the dimensions.324. Choose execution mode:33 - **Mode (a) Live**: products have public docs / free tier / open API → Claude probes directly34 - **Mode (b) Plan-only**: products require auth / payment / credentials → emit eval YAML + `/run-eval` command for the user to run themselves355. Write the **plan** (raw summary + dimensions + eval design + chosen mode + risk note) to `outputs/compare-<products-slug>-<YYYY-MM-DD>-plan.md`.366. **STOP and ask the user for one y/n on the whole plan.**3738### Phase 3 — Execute39Only after confirmation:40411. Write eval YAML to `outputs/eval-compare-<products-slug>-<YYYY-MM-DD>.yaml`.422. Mode (a): invoke `/run-eval` and write findings to `outputs/compare-<products-slug>-<YYYY-MM-DD>-findings.md`.433. Mode (b): print the exact `/run-eval` command + env vars the user needs to set first.4445## Hard rules4647- Three phases, in order. No shortcuts.48- Confirmation gate between Phase 2 and Phase 3 is non-negotiable.49- Dimensions are derived from products, not imposed.50- No invented features. "Not documented" ≠ "doesn't have it".51- Do not silently switch modes mid-execution. If Mode (a) fails, stop and tell the user what's needed for Mode (b).5253## Where to write54- With filesystem: paths above55- Inline (web/mobile): emit each artifact as a code block with the filename header5657## Tone58Analytical, direct. Lead with what's surprising. Hedge appropriately on facts you couldn't fully verify.
RyanAlberts