prd-master

PRD Master

核心原则

• 持续演进的文档 — PRD 会在产品生命周期内持续演进
• 利益相关者协作 — 尽早参与可避免后期返工
• 目标可衡量 — 用可量化的目标取代模糊描述
• 聚焦且灵活 — 精简的结构有助于适应变化
• 问题优先 — 先定义问题，再着手寻找解决方案
• 以用户为中心 — 基于用户研究和数据做出决策

---

硬性规则（必须遵守）

这些规则是强制要求。违反规则意味着此技能未能正常工作。

不得使用模糊指标

所有指标和需求都必须可量化。禁止使用模糊描述。

❌ FORBIDDEN:
- "The app should be fast"
- "Support many users"
- "Good user experience"
- "The system should be reliable"
- "Easy to use interface"

✅ REQUIRED:
- "Page load time < 2s on 4G, < 500ms on WiFi (P95)"
- "Support 10,000 concurrent users with 99.9% uptime"
- "NPS > 50, Task completion rate > 85%"
- "99.9% availability, MTTR < 1 hour"
- "User can complete checkout in < 3 clicks"

先定义问题，再考虑解决方案

在清晰定义问题之前，绝不提出解决方案。

❌ FORBIDDEN:
"We should add a search bar to the navigation"

✅ REQUIRED:
"Problem: Users can't find products quickly (40% exit rate on catalog).
They need a way to filter 1000+ products by attributes.
Proposed solutions: search bar, smart filters, AI recommendations."

用户故事必须符合 INVEST 标准

所有用户故事都必须通过 INVEST 标准检查清单。

❌ FORBIDDEN:
- Dependent stories that can't be delivered independently
- Stories without acceptance criteria
- Stories too large to complete in one sprint
- Stories without clear user value

✅ REQUIRED:
- [ ] Independent — Can be delivered alone
- [ ] Negotiable — Details can be discussed
- [ ] Valuable — Clear user/business value
- [ ] Estimable — Team can estimate effort
- [ ] Small — Fits in one sprint
- [ ] Testable — Has acceptance criteria

---

快速参考

适用场景与方法

场景	方法	工具/框架
功能优先级排序	评分模型	RICE、ICE
发布规划	必须/应该/可以/不会	MoSCoW
客户满意度	满意度与基础需求	Kano 模型
Sprint 规划	用户故事 + BDD	Given-When-Then
复杂需求	传统 PRD	完整模板
敏捷迭代	精益需求	用户故事 + 验收标准

---

PRD 结构

必备组成部分

## 1. Executive Summary
- Problem statement (2-3 sentences)
- Proposed solution (1-2 sentences)
- Success metrics (3-5 key metrics)

## 2. Context & Background
- Why now? Market opportunity or user pain
- Strategic alignment with company goals
- What happens if we don't build this?

## 3. Goals & Success Metrics
- Business objectives (revenue, retention, growth)
- User objectives (satisfaction, engagement)
- Success criteria (quantifiable targets)

## 4. Target Users & Personas
- Primary users (who benefits most?)
- Secondary users (indirect beneficiaries)
- User needs, pain points, motivations
- Jobs to be done

## 5. User Stories & Use Cases
- Core user flows
- Edge cases and error scenarios
- Integration with existing features

## 6. Requirements
- Functional requirements (what it does)
- Non-functional requirements (performance, security)
- Acceptance criteria (how we verify)

## 7. Out of Scope
- What we're explicitly NOT building
- Future considerations for later phases

## 8. Design & UX
- Link to design files (Figma, etc.)
- Key design decisions
- Accessibility requirements (WCAG 2.2 AA)

## 9. Technical Considerations
- Architecture overview
- Dependencies and integrations
- Data model changes
- API contracts

## 10. Rollout & Launch Plan
- Phased rollout strategy
- Feature flags and A/B tests
- Monitoring and alerts
- Rollback plan

## 11. Open Questions & Risks
- Unknowns requiring research
- Technical risks and mitigations
- Dependencies on other teams

---

用户故事编写

标准格式

As a [persona/role],
I want to [action/goal],
So that [benefit/value].

三个 C

Card          — Brief description on index card
              → Captures essence, not details
              → Placeholder for conversation

Conversation  — Discussion between team members
              → Explore edge cases
              → Clarify assumptions
              → Uncover hidden requirements

Confirmation  — Acceptance criteria
              → Defines "done"
              → Testable conditions
              → Given-When-Then format

INVEST 标准

Independent   — Story stands alone, minimal dependencies
Negotiable    — Details emerge through conversation
Valuable      — Delivers value to users or business
Estimable     — Team can estimate effort
Small         — Completable within one sprint
Testable      — Clear acceptance criteria

示例

## Good User Stories

### Feature: Password Reset
As a user who forgot my password,
I want to reset it via email,
So that I can regain access to my account without contacting support.

**Acceptance Criteria:**
- Given I'm on the login page
- When I click "Forgot Password"
- Then I see a form requesting my email address

- Given I've entered my registered email
- When I submit the form
- Then I receive a password reset link within 2 minutes

- Given I click the reset link within 24 hours
- When I set a new password (min 8 chars, 1 number, 1 symbol)
- Then I'm logged in automatically

### Feature: Bulk Upload
As a content manager,
I want to upload multiple products via CSV,
So that I can save time compared to manual entry.

**Acceptance Criteria:**
- Given I'm on the products page
- When I click "Bulk Upload" and select a CSV file
- Then the system validates the file format (max 10MB, .csv only)

- Given the CSV has 1000 rows
- When I start the upload
- Then I see a progress bar showing completion percentage

- Given the upload completes
- When I view the results
- Then I see: success count, error count, downloadable error report

常见错误

❌ Too technical
"As a user, I want the API to return a 200 status code"
→ Focus on user benefit, not implementation

❌ Too vague
"As a user, I want the system to be fast"
→ Define measurable performance targets

❌ Missing the "so that"
"As a user, I want to filter products by price"
→ Add the value: "so that I can find items within my budget"

❌ Too large (Epic)
"As a user, I want a complete e-commerce checkout experience"
→ Break into smaller stories: cart, address, payment, confirmation

---

验收标准

Given-When-Then（BDD 格式）

Given [precondition/context]
When [action/trigger]
Then [expected outcome]

And [additional context/outcome]

最佳实践

✓ Keep scenarios focused (one behavior per scenario)
✓ Maintain clear separation of Given/When/Then
✓ Avoid UI-specific details (test behavior, not implementation)
✓ Make criteria testable and measurable
✓ Include both happy path and edge cases
✓ Use real user interactions, not hypothetical

示例

## E-commerce Checkout

Scenario: Successful payment with saved card
  Given I have items in my cart
  And I'm logged in with a saved payment method
  When I click "Place Order"
  Then I see an order confirmation page
  And I receive a confirmation email within 2 minutes
  And my cart is emptied

Scenario: Payment declined
  Given I'm at the payment step
  When I submit payment and the card is declined
  Then I see an error message: "Payment declined. Please try another card."
  And I remain on the payment page
  And my cart items are preserved

Scenario: Session timeout during checkout
  Given I've been idle for 30 minutes
  When I attempt to place an order
  Then I'm redirected to login
  And my cart items are preserved after re-authentication

## Search Feature

Scenario: Search with results
  Given I'm on the homepage
  When I search for "laptop"
  Then I see results within 500ms
  And results are ranked by relevance
  And I see result count: "Showing 1-20 of 156 results"

Scenario: Search with no results
  Given I'm on the search page
  When I search for "xyznonexistent"
  Then I see "No results found for 'xyznonexistent'"
  And I see search suggestions or alternative queries

备选格式：检查清单

For simpler features, use a checklist:

## File Upload Acceptance Criteria
- [ ] Supports formats: PDF, DOCX, XLSX (max 10MB each)
- [ ] Shows upload progress bar
- [ ] Displays file name and size after upload
- [ ] Allows removal of uploaded files
- [ ] Shows error message for unsupported formats
- [ ] Shows error message for files exceeding size limit
- [ ] Scans files for malware before processing
- [ ] Works on mobile (iOS Safari, Android Chrome)

---

优先级排序框架

RICE 评分

RICE Score = (Reach × Impact × Confidence) / Effort

Reach      — How many users affected per time period?
             (users/quarter, transactions/month)
Impact     — How much does it improve their experience?
             3 = Massive, 2 = High, 1 = Medium, 0.5 = Low, 0.25 = Minimal
Confidence — How certain are we?
             100% = High data, 80% = Medium, 50% = Low
Effort     — Person-months required
             (engineering + design + PM time)

示例：

功能	覆盖人数	影响	置信度	工作量	RICE 分数
密码重置	5000/月	3	100%	1	15,000
深色模式	10000/月	0.5	80%	2	2,000
导出为 PDF	500/月	2	50%	0.5	1,000

适用场景： 管理大量想法、需要进行量化比较、拥有用户数据时。

---

ICE 评分

ICE Score = (Impact + Confidence + Ease) / 3

Impact     — 1-10: How much business/user value?
Confidence — 1-10: How certain are we?
Ease       — 1-10: How easy to implement? (10 = very easy)

示例：

功能	影响	置信度	易实施度	ICE 分数
一键登录	9	8	6	7.7
AI 推荐	10	5	3	6.0
邮件通知	6	9	9	8.0

适用场景： 快速确定优先级、每周梳理、增长实验，以及重速度而非精确度时。

---

MoSCoW 方法

Must Have      — Critical for launch, non-negotiable
                 Without this, the product fails

Should Have    — Important but not vital
                 Painful to omit, but workarounds exist

Could Have     — Nice to have, "vitamins not painkillers"
                 Include if time/resources allow

Won't Have     — Explicitly out of scope
                 Defer to future releases

示例：MVP 电商网站

必须有	应该有	可以有	不会有
商品列表	商品评价	愿望清单	AR 试穿
购物车	相关商品	礼品包装	在线聊天
结账	订单跟踪	折扣码	忠诚度计划
支付（Stripe）	邮件收据	社交分享	移动应用
用户账户	访客结账	商品对比	订阅服务

适用场景： Sprint 规划、MVP 范围界定、发布边界确定、利益相关者协调。

---

Kano 模型

Basic Needs       — Must-haves, assumed by users
                    Absence = dissatisfaction, presence = neutral
                    Example: Website loads, checkout works

Performance       — More is better, linear satisfaction
                    Example: Faster page load, more payment options

Delighters        — Unexpected features that wow
                    Absence = neutral, presence = delight
                    Example: Free shipping, personalized recommendations

Indifferent       — Users don't care either way
                    Example: Animated logo, theme customization

适用场景： 以客户为导向的决策、平衡基础需求与创新、改进 UX 时。

流程：

1. 通过成对问题调查用户：
   • “如果我们有功能 X，你会有什么感受？”
   • “如果我们没有功能 X，你会有什么感受？”
2. 对回答进行分类：基本型、期望型、兴奋型、无差异型
3. 确定优先级：先满足基本需求，再满足期望需求，最后提供兴奋型功能

---

混合方法

Best practice: Combine frameworks

1. Use MoSCoW to define release scope
   → Separate must-haves from nice-to-haves

2. Use RICE to rank must-haves
   → Sequence within release based on impact

3. Use Kano to ensure balance
   → Don't over-invest in basics, under-invest in delight

Example:
- All "Must Have" items → Score with RICE → Build in RICE order
- Validate with Kano → Ensure we have delighters, not just basics

---

扩展参考

从 ## Agile Requirements Management 开始的详细内容已移至 reference/extended.md，以保持此技能内容简洁。如果任务需要已移出的示例、命令目录、检查清单、平台详情或实现模板，请加载该参考文档。