ClaudeTemplate, 4 blanks to fill

<role>You are a tough but fair product reviewer for an early-stage company. You do not rewrite the spec; you find the weak spots and say exactly how to fix them.</role> <spec> [PRODUCT SPEC] </spec> <context> - Company stage and team size: [STAGE] - Who will read this review: [AUDIENCE] - Deadline or launch date we are working towards: [DEADLINE] </context> <instructions> If something critical is missing, ask me up to four questions first. Otherwise continue and label your assumptions. Review the spec on these points: 1. The problem: is it specific, frequent and owned by someone who pays? 2. The user and the buyer: are they named clearly enough to say who this is not for? 3. The main jobs the product must do, ranked, with which belong in the first release. 4. Success measures: can they be checked within 30 and 90 days of launch? 5. Scope: what is explicitly left out, and where extra work is likely to creep in. 6. Risks: technical, market, legal and distribution, each with severity. 7. How the first users will actually arrive. 8. Dependencies that could stall the launch: data, partners, approvals. 9. Alternatives the user has today, including doing nothing. 10. Whether engineering could start tomorrow, and if not, which decisions block it. </instructions> <output> - Verdict: ready to build, ready after fixes, or rethink the problem. - A summary of three to five sentences. - A findings table with severity (blocker, high, medium, low), area, issue, why it matters and the fix. - A numbered list of the decisions to make before engineering starts. - Open questions, only for blockers. </output> <rules>Quote the weak lines from the spec. Do not invent research. Every blocker or high finding needs a concrete fix.</rules>

The words in brackets are the parts you replace with your own details.

Claude

Critique a product spec before engineering starts prompt

Paste your spec or one-pager before you hand it to engineers. Claude reads it like a demanding reviewer and checks the problem, the user, the scope, the success measures, the risks and how the first users will arrive. The answer starts with a verdict, then a table of findings ranked by severity, each with a concrete fix, and a short list of decisions that block the build. Teams use it to catch vague goals and hidden scope while changing them still costs a conversation rather than a sprint.

ClaudeOpen Claude

Replace [PRODUCT SPEC] and [STAGE] and [AUDIENCE] and [DEADLINE] with your own text before you send it.

Business

Adapted from a prompt by f on prompts.chat (CC0-1.0), rewritten as a template by us.

More inspiration

Open in Claude Write your own

What each part of the prompt does

Critic, not ghostwriter: The role says Claude should not rewrite the spec. A rewrite hides the problems under nicer prose; a critique points at them so the author can decide what to change.
Questions before review: Allowing up to four questions first stops the model from guessing about something central, like who the buyer is, and then building the whole review on that guess.
Severity table: Sorting findings into blocker, high, medium and low lets a busy founder fix the two things that matter today and leave the polish for later.
Quoted weak lines: Requiring quotes from the spec keeps the feedback tied to the document. "Success metrics are vague" is easy to ignore; quoting the exact vague line is not.

Variations to try

Same idea, one thing changed.

Feature spec in an existing product
<role>You are a tough but fair product reviewer. You do not rewrite the spec; you find the weak spots and say how to fix them.</role> <spec> [PRODUCT SPEC] </spec> <context> - Company stage and team size: [STAGE] - Who will read this review: [AUDIENCE] - Deadline: [DEADLINE] </context> <instructions>This is a new feature in a product that already has users. Check the problem evidence from current users, the effect on existing flows, migration or settings changes, how success will be measured against today's baseline, and the rollout plan. Output a verdict, a findings table with severity and fixes, and the decisions that block engineering.</instructions> <rules>Quote the weak lines. Do not invent research.</rules>
Five-minute review
<role>You are a tough but fair product reviewer.</role> <spec> [PRODUCT SPEC] </spec> <context> - Company stage: [STAGE] - Who will read this: [AUDIENCE] - Deadline: [DEADLINE] </context> <instructions>Give only the verdict, the three most serious problems with a quoted line and a fix for each, and the one decision that must be made before anyone writes code. Keep it under 250 words.</instructions>

If the result isn't right

Paste the spec as plain text. Tables and comments copied from a doc tool sometimes arrive scrambled, and the review then criticises formatting instead of content.
Run it once on your own and once with [AUDIENCE] set to your engineering lead. The second version tends to focus more on scope and dependencies.
Answer the open questions in the same chat and ask for an updated verdict, so the review tracks your fixes.
If every finding is low severity, ask "what would a skeptical investor push back on?" to make sure nothing was missed.