create-prd

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

PRD Scaffolding Expert

PRD框架生成专家

Overview

概述

Structured product requirements document creation using a proven 8-section framework. This skill produces clear, jargon-free PRDs that communicate what to build, why it matters, and how success is measured. Every PRD generated follows a consistent structure that keeps engineering, design, and business stakeholders aligned.

采用经过验证的8部分框架创建结构化产品需求文档。该技能可生成清晰、无专业术语的PRD，明确说明要构建的内容、其重要性以及如何衡量成功。生成的每份PRD都遵循统一结构，确保工程、设计和业务利益相关方保持对齐。

When to Use

使用场景

New Product Initiative -- Starting a product from scratch and need a comprehensive spec before development begins.
Feature Expansion -- Adding significant functionality to an existing product that requires cross-team alignment.
Stakeholder Alignment -- Need a single document that answers "what are we building and why?" for everyone involved.

新产品立项——从零开始开发产品，需要在开发前制定全面的规格说明。
功能扩展——为现有产品添加重要功能，需要跨团队对齐。
利益相关方对齐——需要一份统一文档，向所有相关人员说明“我们要构建什么以及为什么构建”。

Pre-PRD Techniques

PRD撰写前的方法

Before writing the PRD, use one or both of these techniques to sharpen the problem definition and align the team on value.

在撰写PRD之前，可使用以下一种或两种方法来明确问题定义，确保团队在价值认知上保持一致。

Technique A: Problem Framing Canvas

方法A：问题框架画布

Frame the problem from the user's perspective before jumping to solutions. This canvas produces the narrative that feeds directly into PRD Sections 3 (Background) and 5 (Market Segments).

markdown

undefined

在直接跳到解决方案之前，先从用户视角梳理问题。该画布产出的内容可直接用于PRD的第3部分（背景）和第5部分（市场细分）。

markdown

undefined

Problem Framing Canvas

Problem Framing Narrative

I am: [Describe the key persona experiencing the problem]

[Key characteristic 1]
[Key characteristic 2]
[Key characteristic 3]

Trying to: [A single sentence listing the desired outcomes]

But:

[Barrier preventing outcomes 1]
[Barrier 2]
[Barrier 3]

Because: [Root cause explanation in empathetic language]

Which makes me feel: [Emotional impact from persona perspective]

I am: [Describe the key persona experiencing the problem]

[Key characteristic 1]
[Key characteristic 2]
[Key characteristic 3]

Trying to: [A single sentence listing the desired outcomes]

But:

[Barrier preventing outcomes 1]
[Barrier 2]
[Barrier 3]

Because: [Root cause explanation in empathetic language]

Which makes me feel: [Emotional impact from persona perspective]

Context & Constraints

[Geographic, technological, time-based, organizational constraints]

[Geographic, technological, time-based, organizational constraints]

Final Problem Statement

[Single concise, empathetic summary for stakeholder alignment]

[Single concise, empathetic summary for stakeholder alignment]

Assumptions to Validate

[Assumption 1]
[Assumption 2]


**Next steps:** Generate testable solution hypotheses, convert into a workshop facilitation guide, or create stakeholder-specific variants (Exec, Eng, Design).

[Assumption 1]
[Assumption 2]


**后续步骤：** 生成可测试的解决方案假设，转化为研讨会引导指南，或创建针对不同利益相关方的版本（高管、工程师、设计师）。

Technique B: Working Backwards Press Release

方法B：逆向工作法新闻稿

Write an Amazon-style "future press release" announcing the product as if it already shipped. This forces you to articulate customer value before implementation.

markdown

undefined

撰写亚马逊风格的“未来新闻稿”，假设产品已发布并进行宣传。这会促使你在考虑实施之前先明确客户价值。

markdown

undefined

Working Backwards Press Release

"[Product Name] by [Company] Aims to [Main Purpose/Goal]"

"[City], [Date] --"

"Today, [Company], a [type of organization], announced [product/feature], a [brief description]. This [product] is set to [main benefit], addressing [key issue or need]."

"[Product] will [what it does/solves]. [Quote from key person]: '[customer-outcome-focused quote].' This initiative reflects [Company]'s commitment to [core value]."

"In addition to [mentioned features], [product] also [additional benefits]. According to [source], [relevant data supporting the news]."

Media Contact: [Name, Title, Email]


**Writing rules:**
- Focus on customer outcomes, not feature lists.
- Avoid hype; favor credible claims and concrete benefits.
- If you can't write a compelling PR, the product concept needs more work.

**Next steps:** Generate an FAQ, create stakeholder-specific variants, generate objection-handling talking points, or define launch success metrics.

---

"[Product Name] by [Company] Aims to [Main Purpose/Goal]"

"[City], [Date] --"

"Today, [Company], a [type of organization], announced [product/feature], a [brief description]. This [product] is set to [main benefit], addressing [key issue or need]."

"[Product] will [what it does/solves]. [Quote from key person]: '[customer-outcome-focused quote].' This initiative reflects [Company]'s commitment to [core value]."

"In addition to [mentioned features], [product] also [additional benefits]. According to [source], [relevant data supporting the news]."

Media Contact: [Name, Title, Email]


**撰写规则：**
- 聚焦客户成果，而非功能列表。
- 避免夸大，优先使用可信声明和具体收益。
- 如果无法写出有吸引力的新闻稿，说明产品概念需要进一步完善。

**后续步骤：** 生成常见问题解答（FAQ），创建针对不同利益相关方的版本，生成异议处理话术，或定义发布成功指标。

---

PRD Framework (8 Sections)

PRD框架（8部分）

Section 1: Summary

第1部分：摘要

Write 2-3 sentences that a busy executive can read in 10 seconds and understand the full scope. Answer three questions: What is this? Who is it for? Why are we doing it now?

Do not use marketing language. State the product, the user, and the expected outcome plainly.

撰写2-3句话，让忙碌的高管在10秒内读完就能理解全部范围。回答三个问题：这是什么？面向谁？为什么现在做？

请勿使用营销话术。清晰说明产品、用户和预期成果。

Section 2: Contacts

第2部分：联系人

A table of people involved in the decision:

Name	Role	Responsibility
...	Product Manager	Final decision on scope
...	Engineering Lead	Technical feasibility
...	Design Lead	UX direction
...	Stakeholder	Business approval

Keep this short. Only list people who will actively contribute or approve.

列出参与决策的人员表格：

姓名	角色	职责
...	产品经理	最终确定范围
...	工程负责人	技术可行性评估
...	设计负责人	UX方向把控
...	利益相关方	业务审批

保持简洁。仅列出会积极贡献或参与审批的人员。

Section 3: Background

第3部分：背景

Answer three questions:

Context -- What is the current state? What exists today?
Why now? -- What changed in the market, technology, or business that makes this urgent?
What recently became possible? -- New capabilities, partnerships, data, or insights that enable this initiative.

This section sets the stage. A reader who skips every other section should still understand the motivation after reading Background.

回答三个问题：

背景环境——当前状态是什么？现有哪些内容？
为什么是现在？——市场、技术或业务发生了什么变化，让这件事变得紧迫？
最近出现了哪些可能性？——新的能力、合作关系、数据或洞察，使该计划得以推进。

本部分为整个文档奠定基础。即使跳过其他所有部分，读者读完本部分也应能理解项目动机。

Section 4: Objective

第4部分：目标

State the business benefit and the customer benefit separately:

Business benefit: How does this move a business metric? (revenue, retention, cost reduction, market share)
Customer benefit: How does this improve the user's life? (time saved, friction removed, new capability)

Then define 2-4 SMART Key Results in OKR format:

Objective: [qualitative, inspirational statement]
KR1: [metric] from [current] to [target] by [date]
KR2: [metric] from [current] to [target] by [date]
KR3: [metric] from [current] to [target] by [date]

分别说明业务收益和客户收益：

业务收益：这将如何推动业务指标？（收入、留存率、成本降低、市场份额）
客户收益：这将如何改善用户生活？（节省时间、减少摩擦、新增能力）

然后以OKR格式定义2-4个SMART关键结果：

目标：[定性、鼓舞人心的陈述]
关键结果1：[指标]从[当前值]提升至[目标值]，截止日期[日期]
关键结果2：[指标]从[当前值]提升至[目标值]，截止日期[日期]
关键结果3：[指标]从[当前值]提升至[目标值]，截止日期[日期]

Section 5: Market Segment(s)

第5部分：市场细分

Define segments by the problems they face or jobs they need done -- not by demographics. A segment is a group of people who share a common struggle or desired outcome.

Format: "[Segment name]: People who need to [job/problem] because [context]."

Bad: "Millennials aged 25-35 in urban areas" Good: "Time-constrained professionals who need to coordinate schedules across 3+ tools because their organization lacks a unified calendar system"

根据用户面临的问题或需要完成的工作来定义细分群体——而非根据人口统计数据。一个细分群体是指有着共同困扰或预期成果的人群。

格式："[细分群体名称]：需要[工作/解决问题]的人群，因为[背景环境]。"

错误示例："25-35岁城市千禧一代" 正确示例："时间紧张的职场人士，需要在3个以上工具间协调日程，因为他们的组织缺乏统一的日历系统"

Section 6: Value Proposition(s)

第6部分：价值主张

For each market segment, define:

Jobs addressed -- What tasks or goals does this product help accomplish?
Gains created -- What positive outcomes does the user experience?
Pains relieved -- What frustrations, risks, or obstacles are removed?
Competitive advantage -- Why is our approach better than existing alternatives?

Use the Value Curve framework to visualize where you compete, where you exceed, and where you deliberately underinvest relative to alternatives.

针对每个市场细分群体，定义：

解决的工作任务——该产品帮助完成哪些任务或目标？
创造的收益——用户将获得哪些积极成果？
缓解的痛点——消除了哪些挫折、风险或障碍？
竞争优势——我们的方法比现有替代方案好在哪里？

使用价值曲线框架，可视化我们在哪些领域参与竞争、哪些领域超越对手、哪些领域有意减少投入。

Section 7: Solution

第7部分：解决方案

Break into subsections:

UX / Prototypes -- Key screens, flows, or interaction patterns. Link to design files.
Key Features -- Numbered list of features with one-sentence descriptions. Mark each as P0 (must-have), P1 (important), or P2 (nice-to-have).
Technology (optional) -- Architecture decisions, integrations, or infrastructure requirements that constrain the solution.
Assumptions -- Explicit list of things you believe to be true but have not validated. Each assumption should have a plan to validate it.

分为以下子部分：

UX / 原型——关键界面、流程或交互模式。链接至设计文件。
核心功能——带一句话描述的编号功能列表。标记每个功能为P0（必备）、P1（重要）或P2（锦上添花）。
技术选型（可选）——架构决策、集成需求或对解决方案构成约束的基础设施要求。
假设条件——明确列出你认为正确但尚未验证的内容。每个假设都应有验证计划。

Section 8: Release

第8部分：发布计划

Relative timeline -- Use T-shirt sizes (S/M/L/XL) or Now/Next/Later rather than specific dates, unless dates are firm.
v1 scope -- What ships in the first version? Draw a clear line.
Future versions -- What is explicitly deferred? List it so stakeholders know it was considered but intentionally excluded.
Success criteria -- When do we know v1 succeeded? Reference the Key Results from Section 4.

相对时间线——使用T恤尺码（S/M/L/XL）或Now/Next/Later（当下/近期/远期）而非具体日期，除非日期已确定。
v1范围——第一个版本将发布哪些内容？明确划清界限。
后续版本——明确推迟的内容有哪些？列出来让利益相关方知道这些内容已被考虑但有意排除。
成功标准——我们如何判断v1成功？参考第4部分的关键结果。

Writing Principles

撰写原则

Plain language -- No jargon, no acronyms without definition, no buzzwords.
One idea per sentence -- If a sentence has "and" connecting two distinct ideas, split it.
Specificity over abstraction -- "Reduce onboarding from 12 steps to 4" beats "Simplify onboarding."
Saved as:
```
PRD-[product-name].md
```

通俗易懂——无专业术语，无未定义的缩写，无流行语。
一句一观点——如果一个句子用“和”连接两个不同观点，拆分它。
具体而非抽象——“将注册流程从12步减少到4步”比“简化注册流程”更好。
保存格式：
```
PRD-[product-name].md
```

Workflow

工作流程

Gather context: product name, target segment, core problem.
Run
```
scripts/prd_scaffolder.py
```
to generate the skeleton.
Fill in each section using the guidance above and
```
references/prd-writing-guide.md
```
.
Review against the checklist in
```
references/prd-writing-guide.md
```
.
Share with stakeholders for feedback.

收集背景信息：产品名称、目标细分群体、核心问题。
运行
```
scripts/prd_scaffolder.py
```
生成框架。
使用上述指南和
```
references/prd-writing-guide.md
```
填充每个部分。
根据
```
references/prd-writing-guide.md
```
中的检查表进行审核。
分享给利益相关方获取反馈。

Tools

工具

Tool	Purpose	Command
`prd_scaffolder.py`	Generate PRD skeleton	`python scripts/prd_scaffolder.py --product-name "MyProduct" --objective "Short description" --segments "Segment A, Segment B"`

工具	用途	命令
`prd_scaffolder.py`	生成PRD框架	`python scripts/prd_scaffolder.py --product-name "MyProduct" --objective "Short description" --segments "Segment A, Segment B"`

Troubleshooting

常见问题排查

Symptom	Likely Cause	Resolution
PRD scaffolder output is too generic	Only product name provided; objective and segments need specificity	Write a 1-2 sentence objective that states the outcome, not just the product category; define segments by jobs-to-be-done, not demographics
Stakeholders skip reading the PRD	Document too long, too jargon-heavy, or lacks a clear Summary section	Ensure Section 1 (Summary) answers What/Who/Why in 3 sentences; cut any section beyond 1 page that is not Section 7
Engineering team builds the wrong thing	PRD focuses on solution before establishing problem context	Strengthen Section 3 (Background) and Section 5 (Market Segments); ensure problem definition precedes solution
PRD assumptions never validated	Assumptions listed in Section 7 but no validation plan assigned	Add a validation plan column to the Assumptions table; link each assumption to `identify-assumptions/` or `brainstorm-experiments/`
Scope creep after PRD approval	Section 8 (Release) does not clearly separate v1 from future versions	Be explicit about "Explicitly Deferred" items; ensure every stakeholder has seen and acknowledged the deferred list
PRD becomes stale during development	Treated as a static document rather than a living reference	Update after implementation decisions change; archive final state and link to retrospective notes
`--segments` flag parsing fails	Segments not properly comma-separated or contain special characters	Wrap the segments argument in quotes: `--segments "Segment A, Segment B"`

症状	可能原因	解决方法
PRD框架输出过于通用	仅提供了产品名称；目标和细分群体需要更具体	撰写1-2句话的目标，说明成果而非仅产品类别；以“待完成工作”而非人口统计数据定义细分群体
利益相关方跳过PRD阅读	文档过长、专业术语过多或缺乏清晰的摘要部分	确保第1部分（摘要）用3句话回答“是什么/面向谁/为什么”；删除第7部分以外超过1页的内容
工程团队构建内容不符合预期	PRD在明确问题背景前就聚焦解决方案	强化第3部分（背景）和第5部分（市场细分）；确保问题定义先于解决方案
PRD中的假设从未验证	第7部分列出了假设但未分配验证计划	在假设表格中添加验证计划列；将每个假设链接至 `identify-assumptions/` 或 `brainstorm-experiments/`
PRD获批后范围蔓延	第8部分（发布计划）未明确区分v1和后续版本	明确列出“已推迟内容”；确保所有利益相关方已查看并确认该列表
开发过程中PRD过时	被视为静态文档而非动态参考	当实施决策变更时进行更新；归档最终版本并链接至回顾笔记
`--segments` 参数解析失败	细分群体未正确用逗号分隔或包含特殊字符	将segments参数用引号包裹： `--segments "Segment A, Segment B"`

Success Criteria

成功标准

PRD passes the "10-second executive test" -- a busy executive understands scope from Section 1 alone
All 8 sections are complete before development begins (no placeholder sections remain)
Market segments defined by jobs-to-be-done, not demographics
Key Results in Section 4 are measurable with baselines, targets, and deadlines
Every assumption in Section 7 has a validation plan and owner
PRD reviewed by PM, Engineering Lead, Design Lead, and at least one stakeholder before commitment
v1 scope in Section 8 draws a clear line between what ships and what is explicitly deferred

PRD通过“10秒高管测试”——忙碌的高管仅通过第1部分就能理解范围
开发开始前所有8部分均已完成（无占位符内容）
市场细分以“待完成工作”而非人口统计数据定义
第4部分的关键结果可衡量，包含基线、目标和截止日期
第7部分的每个假设都有验证计划和负责人
PRD在确定前已由产品经理、工程负责人、设计负责人及至少一名利益相关方审核
第8部分的v1范围明确划分了发布内容和已推迟内容

Scope & Limitations

范围与局限性

In Scope:

8-section PRD skeleton generation with guided placeholders
Section-by-section writing guidance following plain-language, specificity-over-abstraction principles
Market segment definition using jobs-to-be-done framework
Value proposition mapping with Value Curve competitive analysis
Release planning with Now/Next/Later and explicit deferral documentation

Out of Scope:

Technical architecture or system design documents (see
```
engineering/
```
skills)
User story writing and backlog creation (see
```
execution/job-stories/
```
and
```
execution/wwas/
```
)
Detailed UX research or usability testing plans (see
```
product-team/
```
skills)
Financial business case modeling (see
```
finance/
```
domain skills)

Important Caveats:

A PRD is a communication tool, not a contract. Treat it as a living document that evolves with implementation learning.
The 8-section framework is a proven structure, but lightweight agile teams may need only sections 1, 3, 4, 7, and 8. Heavyweight compliance contexts (medical devices, regulated industries) may need additional sections.
A 2025 Carnegie Mellon SEI study found that effective requirements management eliminates 50-80% of project defects. The investment in a clear PRD pays for itself in reduced rework.

包含范围：

生成带引导性占位符的8部分PRD框架
遵循“通俗易懂、具体优先”原则的逐部分撰写指南
采用“待完成工作”框架定义市场细分
结合价值曲线竞争分析的价值主张映射
包含Now/Next/Later和明确推迟内容记录的发布规划

不包含范围：

技术架构或系统设计文档（参见
```
engineering/
```
技能）
用户故事撰写和待办事项创建（参见
```
execution/job-stories/
```
和
```
execution/wwas/
```
）
详细的UX研究或可用性测试计划（参见
```
product-team/
```
技能）
财务业务案例建模（参见
```
finance/
```
领域技能）

重要提示：

PRD是沟通工具，而非合同。将其视为随实施学习不断演进的动态文档。
8部分框架是经过验证的结构，但轻量敏捷团队可能仅需第1、3、4、7、8部分。高合规性场景（医疗设备、受监管行业）可能需要额外部分。
卡内基梅隆大学SEI 2025年的研究发现，有效的需求管理可消除50-80%的项目缺陷。投入精力撰写清晰的PRD可通过减少返工获得回报。

Integration Points

集成点

Integration	Direction	Description
`discovery/identify-assumptions/`	Receives from	Validated and "Test Now" assumptions populate PRD Section 7 with evidence
`discovery/brainstorm-experiments/`	Receives from	Experiment results validate or invalidate PRD assumptions
`discovery/pre-mortem/`	Receives from	Tiger mitigations become PRD risk sections
`execution/brainstorm-okrs/`	Feeds into	PRD Key Results (Section 4) align with quarterly OKR targets
`execution/outcome-roadmap/`	Feeds into	PRD release plan (Section 8) maps to roadmap Now/Next/Later horizons
`execution/prioritization-frameworks/`	Receives from	Feature priority (P0/P1/P2) in Section 7 informed by RICE/ICE scoring
`senior-pm/`	Feeds into	PRD stakeholder context feeds stakeholder mapper engagement plans

集成项	方向	描述
`discovery/identify-assumptions/`	接收	已验证和“需立即测试”的假设将带着证据填充至PRD第7部分
`discovery/brainstorm-experiments/`	接收	实验结果验证或推翻PRD中的假设
`discovery/pre-mortem/`	接收	风险缓解措施成为PRD的风险部分
`execution/brainstorm-okrs/`	输出	PRD第4部分的关键结果与季度OKR目标对齐
`execution/outcome-roadmap/`	输出	PRD第8部分的发布计划映射至路线图的Now/Next/Later阶段
`execution/prioritization-frameworks/`	接收	第7部分的功能优先级（P0/P1/P2）由RICE/ICE评分提供依据
`senior-pm/`	输出	PRD中的利益相关方背景为利益相关方映射工具提供参与计划信息

Tool Reference

工具参考

prd_scaffolder.py

Generates a complete 8-section PRD markdown skeleton with guided placeholders, market segment sections, and value proposition templates.

Flag	Type	Default	Description
`--product-name`	string	(required)	Name of the product (used in title and headers)
`--objective`	string	(required)	Short description of the product objective (1-2 sentences)
`--segments`	string	(required)	Comma-separated list of market segments
`--output`	string	stdout	Output file path; if omitted, prints to stdout

生成完整的8部分PRD markdown框架，包含引导性占位符、市场细分部分和价值主张模板。

参数	类型	默认值	描述
`--product-name`	字符串	必填	产品名称（用于标题和页眉）
`--objective`	字符串	必填	产品目标的简短描述（1-2句话）
`--segments`	字符串	必填	逗号分隔的市场细分列表
`--output`	字符串	stdout	输出文件路径；若省略则打印至标准输出

References

参考资料

```
references/prd-writing-guide.md
```
-- Section-by-section writing guide and review checklist
```
assets/prd_template.md
```
-- Complete PRD template ready to fill in

```
references/prd-writing-guide.md
```
——逐部分撰写指南和审核检查表
```
assets/prd_template.md
```
——可直接填充的完整PRD模板