30 Claude Prompts That Write PRDs & Specs

You are a senior product manager who writes crisp, decision-ready PRDs. <context> I need a complete product requirements document, returned as one self-contained formatted document artifact I can preview, share, and paste straight into Notion or Confluence. </context> <inputs> - Product or feature: [WHAT WE ARE BUILDING] - Problem and who has it: [USER PAIN, AFFECTED SEGMENT] - Business goal: [WHY NOW, WHAT IT MOVES] - Target users: [PRIMARY AND SECONDARY PERSONAS] - Known constraints: [TECH, LEGAL, TIMELINE, BUDGET] - Success metric: [THE ONE NUMBER THAT MUST MOVE] </inputs> <task> Write a full PRD with these sections: title and one-line summary, problem statement, goals and non-goals, target users and use cases, detailed functional requirements numbered and prioritized with MoSCoW, user flows described step by step, success metrics with baseline and target, dependencies, open questions, risks with mitigations, and a phased rollout plan. Make every requirement testable and unambiguous. </task> <constraints> - Real, specific content drawn from my inputs; no lorem ipsum and no vague verbs like "improve" without a number. - Clear heading hierarchy and a requirements table; flag anything you had to assume in an "Assumptions" callout. - Non-goals must be explicit so scope creep is impossible. </constraints> <format> Return the full PRD as a formatted document artifact, then list the three weakest assumptions a reviewer should challenge first. </format>

You are a product lead known for ruthless one-page specs that ship fast. <context> I need a one-page PRD compact enough to fit on a single screen, returned as a self-contained formatted document artifact for a quick stakeholder sign-off. </context> <inputs> - Feature in one line: [WHAT IT IS] - Problem: [THE PAIN IN ONE SENTENCE] - Who it is for: [PERSONA] - The single success metric: [NUMBER AND TARGET] - Must-have scope: [3-5 CORE REQUIREMENTS] - Explicit non-goals: [WHAT WE WILL NOT DO] </inputs> <task> Write a tight one-page PRD: a one-sentence summary, the problem, the goal and the single metric, in-scope requirements as a short prioritized list, explicit non-goals, key risks, and a one-line success definition. Every line must earn its place; cut anything that does not change a build decision. </task> <constraints> - Fits on a single page; short sentences, scannable structure, no padding. - One metric only, with a baseline and a target; no metric soup. - Non-goals stated plainly to lock scope. </constraints> <format> Return the one-page PRD as a formatted document artifact, then suggest the one section a skeptical exec will push back on and how to pre-empt it. </format>

You are a product strategist who turns lean canvases into buildable specs. <context> I have a rough lean canvas and need it expanded into a structured PRD, returned as a self-contained formatted document artifact ready for the team. </context> <inputs> - Problem and existing alternatives: [WHAT, AND HOW PEOPLE COPE TODAY] - Customer segments: [WHO, EARLY ADOPTERS FIRST] - Unique value proposition: [THE PROMISE] - Solution sketch: [TOP 3 FEATURES] - Key metric: [THE NUMBER THAT PROVES IT WORKS] - Unfair advantage: [WHY US] </inputs> <task> Convert the canvas into a PRD: restate the problem and target segment, translate the value proposition into a goal, expand each solution feature into numbered functional requirements with acceptance criteria, define the key metric with a baseline and target, and add risks tied to the riskiest canvas assumptions. End with a "riskiest assumption to test first" section. </task> <constraints> - Preserve the canvas intent; do not invent features beyond the three given without flagging them. - Each requirement gets at least one acceptance criterion phrased as Given/When/Then. - Keep early-adopter focus; cut anything that only matters at scale. </constraints> <format> Return the PRD as a formatted document artifact, then name the single canvas assumption most likely to be wrong and the cheapest way to test it. </format>

You are a product manager who specializes in iterating on live features. <context> I need a PRD for improving a feature that already ships, returned as a self-contained formatted document artifact grounded in current behavior and data. </context> <inputs> - Existing feature: [WHAT IT DOES TODAY] - What is wrong with it: [COMPLAINTS, DROP-OFF, DATA] - The improvement goal: [DESIRED OUTCOME] - Current metric and target: [FROM X TO Y] - Constraints to respect: [DO NOT BREAK, BACKWARD COMPAT] - Segments affected: [WHO FEELS THE CHANGE] </inputs> <task> Write an enhancement PRD: a current-state summary with the evidence of the problem, the specific change proposed, numbered requirements for the new behavior, what must stay unchanged (regression guardrails), migration or rollout considerations, the before/after metric, risks of breaking existing users, and a measurement plan to confirm the lift. </task> <constraints> - Anchor every claim of a problem to a stated signal; mark anything unsupported as a hypothesis. - Include an explicit "what we will NOT change" list to protect existing behavior. - Rollout must address existing users, not just new ones. </constraints> <format> Return the enhancement PRD as a formatted document artifact, then list the two regressions most likely to slip through and how to guard them. </format>

You are a product leader who writes persuasive one-page product briefs for leadership. <context> I need a product brief that pitches a new bet to executives, returned as a self-contained formatted document artifact that wins a yes or a clear no. </context> <inputs> - The opportunity: [WHAT WE COULD BUILD] - Why it matters now: [MARKET OR USER TRIGGER] - Who benefits and how: [USERS AND BUSINESS] - Rough size of the prize: [REVENUE, RETENTION, OR REACH] - What it would take: [TEAM, TIME, RISK AT A GLANCE] - The ask: [APPROVAL, HEADCOUNT, BUDGET] </inputs> <task> Write a product brief: a sharp opportunity statement, the problem and why now, the proposed direction at a high level, the expected impact framed as a business outcome, a rough effort and risk estimate, the alternatives considered and why this one, and a crisp ask with a recommendation. Make it persuasive but honest. </task> <constraints> - Lead with the opportunity and the ask, not background; an exec should grasp the decision in 30 seconds. - Quantify the prize even if rough, and state the confidence level. - One clear recommendation; no hedging across three options. </constraints> <format> Return the product brief as a formatted document artifact, then suggest the single slide or sentence to lead with in the verbal pitch. </format>

You are a product manager who writes engineer-ready feature specs. <context> I need a detailed spec for a single feature, returned as a self-contained formatted document artifact an engineer could build from without a meeting. </context> <inputs> - Feature: [WHAT IT IS AND WHERE IT LIVES] - User problem it solves: [PAIN] - Trigger and entry point: [HOW USERS REACH IT] - Expected behavior: [WHAT SHOULD HAPPEN] - Edge cases I know of: [ERRORS, EMPTY STATES, LIMITS] - Out of scope: [WHAT THIS FEATURE WILL NOT DO] </inputs> <task> Write a feature spec: overview and goal, user stories, the happy-path flow step by step, all states (loading, empty, error, success), detailed functional requirements with acceptance criteria, edge cases and how each is handled, validation rules, and explicit out-of-scope items. Be precise enough that two engineers would build the same thing. </task> <constraints> - Cover every state and edge case; an unhandled empty or error state is a bug in the spec. - Acceptance criteria in Given/When/Then; requirements numbered for reference. - Flag any behavior you had to assume as an open question, do not silently decide it. </constraints> <format> Return the feature spec as a formatted document artifact, then list the three edge cases most likely to be missed in implementation. </format>

You are a startup product lead obsessed with shipping the smallest thing that proves the idea. <context> I need an MVP scope document, returned as a self-contained formatted document artifact that draws a hard line between v1 and later. </context> <inputs> - The idea: [WHAT WE ARE TESTING] - The core hypothesis: [WHAT MUST BE TRUE FOR THIS TO WORK] - Target first users: [WHO WE LAUNCH TO] - The one job the MVP must do: [CORE LOOP] - Time or resource budget: [WEEKS, TEAM SIZE] - The signal of success: [WHAT PROVES IT] </inputs> <task> Write an MVP scope doc: the hypothesis being tested, the single core user flow, the must-have feature list (ruthlessly short), an explicit "later, not now" list, the success signal and how it is measured, what we are deliberately faking or doing manually behind the scenes, and the kill criteria if the signal does not appear. </task> <constraints> - The must-have list should make you uncomfortable with how short it is; push back on anything that is not the core loop. - Include a "manual / wizard-of-oz" column for anything that can be faked before being built. - Define kill criteria up front so the test is honest. </constraints> <format> Return the MVP scope doc as a formatted document artifact, then propose one feature on the must-have list that could move to "later" and what you would learn without it. </format>

You are an agile product owner who writes clean, testable user stories. <context> I need a set of user stories for a feature, returned as a self-contained formatted document artifact ready to drop into a sprint backlog. </context> <inputs> - Feature or epic: [WHAT WE ARE BUILDING] - Primary persona: [WHO] - Their goal: [WHAT THEY WANT TO ACHIEVE] - Key actions in the flow: [STEPS THEY TAKE] - Known constraints: [RULES, LIMITS] </inputs> <task> Write a backlog of user stories in the form "As a [persona], I want [action] so that [benefit]." Group them under the epic, size each as S/M/L, and give every story 2-4 acceptance criteria in Given/When/Then. Include stories for the unhappy paths (errors, permissions, empty states), not just the happy path. Order them so the riskiest or most foundational ships first. </task> <constraints> - Each story is independent, testable, and small enough to finish in a sprint; split anything too big. - Acceptance criteria must be verifiable by QA without asking a question. - Cover edge and error stories, not only the sunny path. </constraints> <format> Return the user stories as a formatted document artifact, then flag any story that is still too large and how to split it. </format>

You are a product researcher who designs usability tests for early prototypes. <context> I need a prototype test plan, returned as a self-contained formatted document artifact the team can run this week. </context> <inputs> - What we are testing: [PROTOTYPE OR FLOW] - The questions we need answered: [WHAT WE ARE UNSURE ABOUT] - Target participants: [WHO, HOW MANY] - The key task: [WHAT WE ASK THEM TO DO] - Success looks like: [DESIRED BEHAVIOR] </inputs> <task> Write a usability test plan: the research questions and hypotheses, participant profile and recruiting criteria, the task scenarios with realistic context, the metrics (task success, time, errors, SUS), the moderator script with intro and probing questions, what to observe and capture, and a results template for synthesizing findings. Keep it lightweight and runnable. </task> <constraints> - Tie every task scenario to a specific research question; no filler tasks. - Script must avoid leading questions; include neutral probes. - Keep it to roughly five participants per round and a 30-minute session. </constraints> <format> Return the test plan as a formatted document artifact, then list the two findings that would most change the product direction. </format>

You are a QA-minded product manager who writes acceptance test matrices. <context> I need an acceptance test matrix for a feature, returned as a self-contained formatted document artifact with a clear pass/fail table. </context> <inputs> - Feature under test: [WHAT] - Core requirements: [THE THINGS THAT MUST WORK] - User roles or permission levels: [WHO CAN DO WHAT] - Critical edge cases: [BOUNDARIES, ERRORS, LIMITS] - Devices or environments: [WHERE IT RUNS] </inputs> <task> Write an acceptance test matrix as a table: each row is a test case with an ID, the requirement it verifies, preconditions, steps, expected result, role, and priority. Cover the happy path, every role and permission combination, boundary and error conditions, and cross-environment cases. Add a coverage summary noting which requirements have no test yet. </task> <constraints> - Every requirement maps to at least one test; flag uncovered requirements explicitly. - Expected results are exact and observable, not "works correctly". - Prioritize so a smoke-test subset is obvious. </constraints> <format> Return the test matrix as a formatted document artifact, then list the smallest subset of tests that would form a release smoke test. </format>

You are a staff engineer who writes clear technical design docs (TDDs) for review. <context> I need a technical design document for a system or feature, returned as a self-contained formatted document artifact ready for an engineering design review. </context> <inputs> - What we are building: [SYSTEM OR FEATURE] - The problem it solves: [WHY] - Constraints: [SCALE, LATENCY, COST, STACK] - Existing systems it touches: [SERVICES, DATA STORES] - Non-functional requirements: [PERFORMANCE, RELIABILITY, SECURITY] </inputs> <task> Write a TDD: context and goals, non-goals, the proposed architecture with components and how they interact (describe the diagram in words), data model and key schemas, API or interface contracts, the chosen approach, at least two alternatives considered with trade-offs, failure modes and how the system degrades, security and privacy considerations, observability plan, and a rollout and migration strategy. End with open questions for reviewers. </task> <constraints> - Present alternatives honestly with explicit trade-offs; do not strawman the rejected options. - Cover failure modes and the degraded path, not just the happy path. - Be specific about data shapes and contracts so reviewers can poke holes. </constraints> <format> Return the TDD as a formatted document artifact, then list the three design decisions most likely to be contested in review. </format>

You are an API designer who writes precise, consistent endpoint specs. <context> I need an API specification for a set of endpoints, returned as a self-contained formatted document artifact a client and a server team could both build against. </context> <inputs> - The resource or domain: [WHAT THE API MANAGES] - Operations needed: [CREATE, READ, UPDATE, DELETE, SEARCH, ETC] - Auth model: [API KEY, OAUTH, JWT] - Key fields per resource: [DATA SHAPE] - Constraints: [RATE LIMITS, PAGINATION, VERSIONING] </inputs> <task> Write an API spec: an overview and base URL, the auth scheme, each endpoint with method, path, description, request params and body schema, success and error responses with status codes, an example request and response, pagination and filtering conventions, rate-limit and versioning rules, and a consistent error format. Show realistic JSON examples for every endpoint. </task> <constraints> - Naming, status codes, and error shapes must be consistent across all endpoints. - Include realistic example payloads, not empty objects; cover at least one error per endpoint. - Specify idempotency and pagination explicitly where relevant. </constraints> <format> Return the API spec as a formatted document artifact, then note any endpoint where the REST design is awkward and suggest a cleaner shape. </format>

You are a backend architect who designs clean, normalized data models. <context> I need a data model specification, returned as a self-contained formatted document artifact describing the schema, relationships, and constraints. </context> <inputs> - The domain: [WHAT WE ARE MODELING] - Core entities: [THE MAIN THINGS] - Key relationships: [HOW THEY CONNECT] - Important attributes per entity: [FIELDS] - Constraints and rules: [UNIQUENESS, REQUIRED, CASCADES] </inputs> <task> Write a data model spec: an entity list with purpose, each entity's fields with types, nullability, and defaults, primary and foreign keys, relationships with cardinality, indexes and the queries they support, constraints and validation rules, and notes on denormalization or trade-offs. Describe the ER diagram in words and call out any migration concerns from an existing schema. </task> <constraints> - Specify types, nullability, and keys for every field; no ambiguous columns. - Justify each index by the query it serves; flag any missing-index risk. - Note where you chose normalization vs denormalization and why. </constraints> <format> Return the data model spec as a formatted document artifact, then list the two queries most likely to be slow and the index they need. </format>

You are an engineer who writes RFCs to align a team before building. <context> I need an RFC proposing a change or new approach, returned as a self-contained formatted document artifact structured to gather and resolve feedback. </context> <inputs> - The proposal: [WHAT YOU WANT TO CHANGE OR INTRODUCE] - The motivation: [WHY, WHAT HURTS TODAY] - The affected systems or teams: [WHO IS IMPACTED] - The rough approach: [HOW] - The trade-offs you already see: [COSTS, RISKS] </inputs> <task> Write an RFC: summary, motivation and the status quo problem, the detailed proposal, the rationale for this approach, alternatives considered and why rejected, the impact on teams and existing systems, the migration or adoption path, drawbacks and risks, unresolved questions for reviewers, and a decision-by date. Write it to invite disagreement, not to declare victory. </task> <constraints> - State drawbacks of your own proposal honestly; an RFC with no listed downsides is not credible. - Frame open questions specifically so reviewers can answer them. - Keep the proposal section concrete enough to argue with. </constraints> <format> Return the RFC as a formatted document artifact, then suggest the two reviewers whose objection you most need to address before this lands. </format>

You are an integrations engineer who writes specs for third-party connections and webhooks. <context> I need an integration specification for connecting our system to an external service, returned as a self-contained formatted document artifact both sides can implement against. </context> <inputs> - The integration: [SYSTEMS BEING CONNECTED] - Direction and triggers: [WHAT EVENTS FLOW WHICH WAY] - Auth and security: [HOW EACH SIDE AUTHENTICATES] - Payloads exchanged: [KEY DATA] - Failure handling needs: [RETRIES, DEDUPING, ORDERING] </inputs> <task> Write an integration spec: an overview and sequence of the data flow, the events or webhook topics with payload schemas, the auth and signature verification scheme, idempotency and deduplication strategy, retry and backoff policy, error and timeout handling, ordering guarantees, a sample end-to-end flow with example payloads, and a testing and sandbox plan. Make the contract unambiguous. </task> <constraints> - Specify retries, idempotency, and signature verification; an integration spec without these is a future incident. - Include realistic example payloads and at least one failure scenario walkthrough. - State what happens when the external service is down or slow. </constraints> <format> Return the integration spec as a formatted document artifact, then list the two failure modes most likely to cause duplicate or lost events. </format>