Applicable Scenarios
After completing requirement penetration and research analysis, a complete Product Requirements Document (PRD) needs to be produced for designers, developers, and testers to use.
Standard PRD Structure
1. Overview
- Feature Name: [Clear and concise name]
- Version：1.0
- Date: [Current date]
- Author：PM Agent
Summary
Downstream Agents should read this section first; consult the full document when details are needed.
- Core Objective: [Describe in one sentence]
- Target Users: [Primary user groups]
- Key Features: [The 3-5 most core features]
- Technical Constraints: [Important constraints or preferences]
- Priority: [MVP scope description]
2. Requirement Penetration Analysis (Core Chapter)
See pm/requirement-penetration skill output requirements.
3. Competitive Research
3.1 Competitor Analysis
Use WebSearch to search for relevant competitors:
| Competitor | Core Features | User Experience Highlights | User Pain Points | Our Opportunity |
|---|---|---|---|---|
| [Competitor 1] | [Features] | [Highlights] | [Pain Points] | [Opportunity] |
| [Competitor 2] | [Features] | [Highlights] | [Pain Points] | [Opportunity] |
| [Competitor 3] | [Features] | [Highlights] | [Pain Points] | [Opportunity] |
3.2 Differentiation Strategy
| Dimension | Competitor Approach | Our Approach | Differentiation Value |
|---|---|---|---|
| [Dimension 1] | [Approach] | [Approach] | [Value] |
| [Dimension 2] | [Approach] | [Approach] | [Value] |
4. Target Users
User Persona 1: [Name]
- Basic Characteristics: [Age, occupation, income, etc.]
- Behavioral Characteristics: [Usage habits, preferences, etc.]
- Core Needs: [The problem they most want to solve]
- Pain Point Scenarios: [Description of specific painful scenarios]
- Expected Experience: [What the ideal experience looks like]
User Journey Map
journey
title 用户完成核心任务的旅程
section 发现阶段
了解产品: 3: 用户
产生兴趣: 4: 用户
section 使用阶段
首次使用: 3: 用户
完成任务: 5: 用户
section 留存阶段
持续使用: 4: 用户
推荐他人: 5: 用户
5. Functional Requirements
FR-001: [Requirement Title]
- Requirement Description: [Clear requirement description]
- User Value: [What value this feature brings to users]
- Priority：P0/P1/P2
- Requirement Source: Explicit/Implicit/Potential/Delight
- Acceptance Criteria：
- AC-1: [Testable criterion 1]
- AC-2: [Testable criterion 2]
- Edge cases：
- [Edge case 1 and handling approach]
- [Edge case 2 and handling approach]
FR-002: [Requirement title]
- Requirement description: [description]
- User value: [value]
- Priority：P1
- Requirement source: [source]
- Acceptance criteria：
- AC-1: [criterion]
6. Non-functional requirements
NFR-001: Performance requirements
- Page load: first screen load < 2s, full load < 3s
- Interaction response: user operation response < 100ms
- API response: interface response < 200ms
NFR-002: Experience requirements
- Usability: new users can complete core tasks without a tutorial
- Consistency: interaction patterns and visual style remain consistent
- Fault tolerance: operations can be undone, errors can be recovered
NFR-003: Security requirements
- Data security: sensitive data is encrypted in storage and transmission
- Privacy protection: complies with relevant privacy regulations
7. User stories
US-001: [Story title]
- As a [user type]
- I want [target behavior]
- so that [expected value]
- Acceptance criteria：
- [criterion 1]
- [criterion 2]
- Priority：P0
US-002: [Story title]
- As a [user type]
- I want [target behavior]
- so that [expected value]
- Acceptance criteria：
- [criterion]
- Priority：P1
8. Success metrics
| Metric type | Metric | Target value | Measurement method |
|---|---|---|---|
| Core metric | [metric] | [target] | [method] |
| Experience metric | [metric] | [target] | [method] |
| Business metric | [metric] | [target] | [method] |
9. Scope definition
In Scope
- [feature 1]
- [feature 2]
Out of Scope
- [excluded item 1]: [reason for exclusion]
- [excluded item 2]: [reason for exclusion]
10. Risks and dependencies
Risk register
| Risk | Likelihood | Impact | Mitigation measure |
|---|---|---|---|
| [risk] | High/Medium/Low | High/Medium/Low | [measure] |
Dependencies
| Dependency | Type | Status | Owner |
|---|---|---|---|
| [Dependency] | Technical/Business/External | Ready/Pending | [Owner] |
11. Milestones
| Milestone | Content | Target Date |
|---|---|---|
| MVP | [Core Features] | - |
| V1.0 | [Complete Features] | - |
| V1.1 | [Optimization Iteration] | - |
Writing Principles
Clarity
- Use simple and direct language
- Avoid vague words ("possibly", "probably", "try to")
- Every requirement has clear acceptance criteria
Completeness
- Cover all necessary sections
- Consider both functional and non-functional requirements
- Explain boundary cases and exception handling
Executability
- Designers can design interfaces based on the PRD
- Developers can write code based on the PRD
- Testers can write test cases based on the PRD
User-oriented
- Explain the user value of every feature
- Describe requirements from the user's perspective
- Focus on user experience details
Output Requirements
- File Naming：
prd-{功能名称}-{日期}.md - File Location: Project root directory or
docs/directory - Format: Markdown format, using a standard section structure
- Length: Depending on feature complexity, usually 5-20 pages
Quality Checklist
Before outputting the PRD, check the following items:
- Is the summary section clear enough for readers to quickly understand the core content
- Is the requirement penetration analysis complete (explicit, implicit, potential, surprise four layers)
- Does every functional requirement have clear acceptance criteria
- Are non-functional requirements considered (performance, experience, security)
- Do user stories conform to the "As a - I want - so that" format
- Is the scope definition clear (In Scope and Out of Scope)
- Are risks and dependencies identified
- Is the document format standardized and easy to read
Remember: A good PRD is not a pile of features, but precise insight into user needs and elegant satisfaction.