Product Requirements Documents

What You’ll Learn

• How to use Claude to rapidly draft complete, structured PRDs from a rough feature idea
• How to write user stories with proper acceptance criteria that engineers can build against
• How to define success metrics and edge cases that prevent scope creep and ambiguity

The Use Case

A Product Requirements Document (PRD) is the contract between product managers and engineering teams. When it’s vague or incomplete, engineers build the wrong thing, QA misses critical cases, and launches get delayed for clarification cycles. When it’s thorough and precise, teams can move fast with confidence.

The challenge is that writing a good PRD takes significant time — researching the problem space, interviewing stakeholders, thinking through edge cases, and translating product thinking into engineering-ready specifications. Most PMs are doing this while simultaneously managing roadmaps, stakeholder meetings, and sprint ceremonies.

Claude dramatically accelerates this process. You bring the product thinking — the user insight, the business rationale, the priorities. Claude brings the structural rigor — the complete user story format, the acceptance criteria checklist, the technical questions you need to answer, and the success metrics framework. The result is a first draft that would take a senior PM 4-6 hours in about 30 minutes.

This applies to new feature PRDs, redesign specs, API documentation for external developers, and internal tooling requirements.

Step-by-Step Guide

Step 1: Start with the problem, not the solution

The most common PRD mistake is starting with the solution (“we want to build X”) before clearly articulating the problem. Ask Claude to help you write the problem statement first, which anchors the entire document.

Prompt:

“I want to write a PRD for a new feature. The problem we’re solving is: [describe the user problem in 2-3 sentences]. The users affected are [describe persona — job title, what they’re trying to accomplish, current workaround]. Help me write a crisp problem statement that captures the ‘who, what, and why’ in 1-2 paragraphs.”

This also serves as a valuable alignment tool — if the problem statement doesn’t resonate with your engineering lead or design partner, you should resolve that disagreement before writing a single requirement.

Step 2: Generate user stories with acceptance criteria

Once the problem is clear, Claude can help you translate it into properly structured user stories. The standard format is: “As a [persona], I want to [action] so that [benefit].” But the real value is in the acceptance criteria — the specific conditions that must be true for the story to be considered done.

Prompt:

“Based on this problem statement, write 5-7 user stories for this feature. For each story:

• Use the ‘As a / I want / So that’ format
• Write 3-5 acceptance criteria using Gherkin format (Given / When / Then)
• Tag each story as must-have, should-have, or nice-to-have (MoSCoW prioritization)
• Flag any stories that are too large and should be broken into sub-stories”

Claude will return stories at the right level of granularity and flag epics that need to be decomposed — a skill that takes junior PMs years to develop intuitively.

Step 3: Define functional and non-functional requirements

Beyond user stories, a complete PRD captures functional requirements (what the system must do) and non-functional requirements (how well it must do it — performance, security, accessibility, scalability).

Prompt:

“Based on these user stories, generate:

1. A numbered list of functional requirements (system behaviors that must exist)
2. A list of non-functional requirements — include performance benchmarks (e.g., page load under X seconds), accessibility standards (WCAG 2.1 AA), security requirements (authentication, data handling), and scalability expectations
3. Any API or integration requirements if this feature touches external systems
4. Data requirements — what data needs to be stored, for how long, and with what access controls”

This section is often the most neglected and the most likely to cause problems in implementation. Claude will surface requirements you didn’t think to specify.

Step 4: Define success metrics and measurement plan

A requirement without a success metric is a hope, not a goal. For every feature you build, you should know how you’ll measure whether it solved the problem.

Prompt:

“Help me define success metrics for this feature. The business goal is [increase retention / reduce churn / increase engagement / reduce support volume / etc.]. What are the primary, secondary, and guardrail metrics I should track? How will I measure adoption? What does success look like at 30 days, 90 days, and 6 months post-launch? Format as a measurement framework table.”

Claude will suggest a layered metric structure — primary metrics (did this move the needle on the business goal), secondary metrics (leading indicators of success), and guardrail metrics (things that shouldn’t get worse when you ship this).

Step 5: Surface edge cases and open questions

One of Claude’s most valuable uses in PRD writing is systematically surfacing edge cases and open questions that you need to resolve before engineering starts.

Prompt:

“Review this PRD draft and identify:

1. Edge cases and error states that aren’t covered by the acceptance criteria
2. Open questions that need stakeholder input before development begins
3. Dependencies on other teams or systems (data, platform, design, legal, security)
4. Assumptions I’m making that could be wrong and would change the requirements List them in priority order by how likely they are to cause problems if left unresolved.”

This is the equivalent of a senior engineer’s “have you thought about what happens when…” conversation — but it happens before the sprint starts, not in the middle of it.

Prompt Template

I need to write a PRD for the following feature/product:

Feature name: [Name]
Problem statement: [What user problem does this solve? Who experiences it? What's their current workaround?]
Business goal: [What outcome does this drive? Retention, revenue, efficiency, etc.?]
Target users: [Describe the primary persona(s)]
Scope: [What is explicitly in scope? What is explicitly out of scope?]
Known constraints: [Technical limitations, timeline, budget, platform, compliance requirements]
Dependencies: [Other teams, systems, or external factors this relies on]

Please create a complete PRD that includes:
1. Problem statement (2 paragraphs)
2. Goals and non-goals
3. 5-8 user stories in As a / I want / So that format, each with:
   - 3-5 acceptance criteria in Given / When / Then format
   - MoSCoW prioritization tag
4. Functional requirements (numbered list)
5. Non-functional requirements (performance, accessibility, security, scalability)
6. Success metrics table (primary, secondary, guardrail) with measurement timeline
7. Open questions and dependencies
8. Edge cases that need to be defined before development begins

Format as a structured markdown document I can paste into Notion or Confluence.

Tips & Best Practices

1. Use Claude to write PRDs for features you’re saying no to — When you reject a feature request, write a one-page “anti-PRD” with Claude that explains why — the problem it solves, why now isn’t the right time, and what evidence would change the decision. This saves you from having the same conversation six months later.

2. Ask Claude to write the “definition of done” for each story — Beyond acceptance criteria, ask Claude to draft a checklist of conditions that must be verified before a story closes: unit tests written, documentation updated, analytics events instrumented, design QA completed. This becomes your sprint quality gate.

3. Generate test cases from acceptance criteria — After writing acceptance criteria, share them with Claude and ask: “Convert these acceptance criteria into QA test cases, including happy path, negative tests, and edge case tests.” Your QA team will love you for it.

4. Use Claude to catch scope creep in real-time — When someone proposes adding to a feature mid-sprint, paste the PRD and the new request into Claude and ask: “Does this new request fit within the current scope? If it does, which acceptance criteria does it fall under? If it doesn’t, draft a one-paragraph note I can use to defer it to the backlog.”

5. Run a “what could go wrong” session — After the PRD is complete, ask Claude: “If this feature ships and fails to solve the problem, what are the 3 most likely reasons? What can we add to the PRD now to reduce those risks?” This adversarial review catches issues before they become post-mortems.

Try It Yourself

Take a feature you’re currently working on or planning — it can be something small, like improving a form or adding a filter. Write a one-paragraph description of the user problem it solves. Then give that to Claude using the prompt template above and ask for a full PRD. When you get the draft, look at the “open questions” section specifically. How many of those questions have you already resolved? How many represent real ambiguity that could cause problems in development? The ratio will tell you how ready you actually are to start building.