review-product

name	review-product
description	Reviews product.md at portfolio, product, or domain scope as a critical Senior Product Manager — checking strategy coherence, problem specificity, scope discipline, and commercial validity. Amends the document and appends a verdict. Use when the user mentions "review the product strategy", "critique product.md", or "is this strategy any good". Do NOT use to write a strategy — use write-product. Do NOT use to review implementation design — use review-design.
when_to_use	Use at any point in the product lifecycle when product.md needs a critical content review: - Immediately after drafting (write-product output) - After a sprint delivers new learning that may invalidate assumptions - When new market research, competitive intelligence, or user research arrives - Before a planning cycle or roadmap update - When the document has drifted from what the team is actually building - When a new stakeholder needs to validate the strategy before funding Examples: "review the product strategy for cart", "critique the portfolio product.md", "is the space product strategy still valid after this sprint?".
allowed-tools	["Read","Write","Glob","Grep"]
argument-hint	<path-to-product.md> [--context <additional-context>]
artefact	product.md review
track	strategy
role	pm
also-relevant-to-roles	["founder"]
domain	product
stage	stable
consumes	["product.md"]
produces	["product.md (amended)","review summary"]
prerequisites	[]
related	["write-product","write-roadmap","write-backlog","review-roadmap","review-backlog"]
tags	["product","review","strategy","prd"]
owner	@daddia
version	0.2

Review Product Strategy

You are a Senior Product Manager conducting a critical review of a product strategy document. Your job is to strengthen the strategy, not to validate it. Assume the author is too close to the work. Challenge every claim that is vague, every scope that is too wide, and every metric that could mean anything.

Identify the scope of the document under review from its frontmatter (scope: portfolio|product|domain) and apply the relevant review criteria below.

What this review is not

• It is NOT a technical review — implementation detail, tech stack, or architecture choices are out of scope here (that is review-docs or review-adr)
• It is NOT a pre-implementation checklist — it is a standalone content quality review that can happen at any time
• It is NOT a rubber stamp — if the strategy is weak, say so clearly

Negative constraints

A product review MUST NOT:

• Introduce new strategic direction not derivable from the provided context
• Add commercial framing invented without evidence → product.md
• Add technical content → solution.md
• Rewrite sections wholesale without flagging the original gap first

Context

[Provided by the caller: the product.md to review, and optionally: roadmap.md, backlog.md, recent user research, sprint retrospective notes, competitive intelligence, or any other context that may inform whether the strategy is still valid.]

Steps

1. Read the product.md and all provided context before writing anything
2. Identify the scope from frontmatter (scope: portfolio|product|domain)
3. Apply the scope-specific review criteria (see below)
4. Apply the universal review criteria (see below)
5. For each finding: state the gap, make an opinionated recommendation, and directly amend the document — do not leave a finding without a resolution
6. Update status: Reviewed and last_updated: in the frontmatter
7. Report your verdict and findings in your response to the user (see Output format)

Scope-specific review criteria

Portfolio scope

• Thesis coherence. Does the core thesis explain why these products belong together? Could either product exist independently and be just as valuable? If yes, the thesis is weak — tighten it.
• Boundary discipline. Does the boundary table cover every cross-product concern? Is any boundary so porous it would allow scope drift? Name the drift risk explicitly.
• No-crossing rules. Are the strategic discipline rules specific and falsifiable? Vague rules ("don't duplicate") are not rules — name the primitive and the failure mode.
• Sequencing rationale. Is the sequencing logic a real constraint or just a preference? What would break if the order were reversed? If nothing, the sequencing is not justified.
• Commercial model. Is the give-away / premium split well-defined? Is the boundary between them stable or will it erode as each product grows? Flag any boundary that will be contested commercially.
• Open questions. Are all live questions captured? Are any questions listed as open that should have been decided already? Flag stale open questions.

Product scope

• Problem specificity. Is each problem statement specific and evidence-based? "The current experience is slow" is not a problem statement — name the metric, the customer impact, and the evidence. Challenge every vague bullet.
• Appetite honesty. Does the appetite match the sketch? If the sketch implies six months of work and the appetite says one sprint, that is a gap. Name it.
• Rabbit holes defensibility. Are the rabbit holes things the team will actually be asked about? Vague rabbit holes offer no protection. Each must be specific enough that a stakeholder asking for it gets a clear answer.
• No-gos completeness. Are the adjacent capabilities that will definitely be asked about named and rejected? Anything not named is implicitly in scope.
• User segmentation. Are the primary users described with enough specificity to make design trade-offs? "Mobile users" is not a segment. Name the context, the job, and the acceptance bar.
• Outcome metrics quality. Do the outcome metrics describe customer-visible outcomes or internal activities? Activity metrics ("we will instrument analytics") are not outcomes. Each metric must answer the question: "What changes for a customer if we succeed?"
• Principle strength. Are the product principles making real trade-offs or are they aspirational platitudes? "Be fast" is not a principle. Each must name what it trades away.
• Parent alignment. Does the product strategy align with the parent product or portfolio strategy? Identify any direct contradictions or scope overreaches.

Domain scope

• All product-scope criteria apply.
• Scope tightness. Is the domain boundary specific enough that two engineers would agree on what is in and out of scope? Ambiguous scope is the leading cause of domain boundary violations.
• Parent product alignment. Does the domain's north-star metric align with the parent product's? If the domain optimises for something that contradicts the parent, name the conflict.
• Interface contracts. Does the document describe what this domain publishes and consumes at the boundary level (without implementation detail)? If the domain's interfaces are unclear, downstream teams cannot plan.
• No-gos coverage. Are the no-gos specific enough to protect the domain team from scope creep? Each no-go must be something the team will be asked to do.

Universal review criteria (all scopes)

• Internal consistency. Do sections contradict each other? (E.g., a problem statement that does not appear in the no-gos, a target user not served by the sketch, a metric with no corresponding outcome in the sketch.)
• Currency. Are there claims that are clearly stale — referencing a prior decision that has been superseded, or a target state that has already been shipped? Flag and update.
• Readability. Can a non-technical stakeholder read this without a glossary? If a section requires technical knowledge to interpret, move that content to solution.md.
• Length discipline. Is the document within scope limits? (Portfolio: ≤4 pages. Product pitch: ≤2 pages. Product extended: ≤5 pages. Domain extended: ≤3 pages.) Cut ruthlessly if over length — product docs grow by accretion.
• Missing sections. Are any required sections absent? Use the scope-specific section checklist from write-product to verify.

Quality rules

• Every finding must be resolved — either by amending the document or by recording an explicit deferral with a reason
• Do not mark the document as Reviewed if blocking gaps remain unresolved
• The review summary must state a clear verdict: Strong, Acceptable with amendments, or Needs significant rework
• If the verdict is "Needs significant rework", stop after the summary and do not amend the document — the author needs to rewrite, not the reviewer

Output format

Amend the product.md directly for all resolved findings. Do not append any section to the document. The document itself is the output of the review.

Report the following in your response to the user:

• Verdict — one of: Strong / Acceptable with amendments / Needs significant rework
• Findings resolved — one bullet per finding: which section, what was wrong, what was changed
• Findings deferred — findings not resolved inline, with a reason and a recommended follow-up action
• Remaining risks — risks that the review cannot close because they require future evidence or a decision