Back to Details

pm-prd

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Product Requirements Document (Pragmatic Framework: Planning)

产品需求文档（Pragmatic 框架：规划）

A PRD here is a market requirements document — it specifies the WHAT (the market problems, personas, and prioritized requirements). The HOW (design, flows, UI, prototypes, error conditions) belongs to the team. Lead with the problem, cite evidence, and write problems in the persona's first-person voice. See 
../pm-copilot/references/framework.md
for the primitives used below.
Requirement form: [persona] has [problem, described in a use scenario] with [frequency]. Priority = Market Evidence × Impact (advanced: × (B + U + C + V) — Buying, Using, Vision, Competitive).
这里的 PRD 是一份市场需求文档——用于明确做什么（市场问题、Persona 以及按优先级排序的需求）。如何实现（设计、流程、UI、原型和错误处理场景）由团队负责。内容应以问题开篇，引用证据，并使用 Persona 的第一人称语气描述问题。下文所用的基本要素见 
../pm-copilot/references/framework.md
。
需求表述格式： [Persona] 存在[以使用场景描述的问题]，发生频率为[频率]。 优先级 = 市场证据 × 影响（进阶公式：× (B + U + C + V)——购买、使用、愿景、竞争）。

Reuse what already exists

复用已有内容

Before gathering inputs, find or resume the feature dossier as described in 
../pm-copilot/references/artifact-output.md
("Find or resume the feature dossier" and "Reuse prior artifacts"): look for the feature folder (or 
NN-*.md
files, or artifacts earlier in this conversation) and reuse their personas, problems, positioning statement, and prioritized requirements — don't duplicate work, and carry their open caveats forward. If nothing exists yet, gather inline (or offer to run 
pm-personas
, 
pm-market-problems
, 
pm-requirements
, 
pm-use-scenarios
first).
在收集输入之前，按照 
../pm-copilot/references/artifact-output.md
中“查找或恢复功能档案”和“复用先前工件”的说明，查找或恢复功能档案：寻找功能文件夹（或 
NN-*.md
文件，或本次对话中较早生成的工件），并复用其中的 Persona、问题、定位陈述和已排序需求——不要重复工作，同时延续其中尚未解决的注意事项。如果尚不存在任何内容，则在当前对话中收集（或提出先运行 
pm-personas
、
pm-market-problems
、
pm-requirements
、
pm-use-scenarios
）。

Interview the user (batch questions)

向用户提问（批量提问）

  1. Product & release — name, version, and the goal of this release.
  2. Market forces — what's driving this now? Is it content-driven (ship when the problems are solved) or target-date-driven (a fixed market window)?
  3. Personas — who is the buyer, who is the user? (summarize or link)
  4. Top market problems — in the persona's first person, each with evidence (interview count, % of customers, win/loss, support tickets, usage data).
  5. Success metrics — how will you know it worked? (Value / Quality / Progress / Satisfaction)
  6. Out of scope, dependencies, risks.
  1. 产品与发布——名称、版本以及本次发布的目标。
  2. 市场驱动力——当前是什么在推动这一工作？它主要由内容驱动（问题解决后即可发布），还是由目标日期驱动（固定的市场窗口期）？
  3. Persona——谁是购买者，谁是使用者？（概述或提供链接）
  4. 主要市场问题——用 Persona 的第一人称描述每个问题，并附上证据（访谈次数、客户占比、赢单/丢单情况、支持工单、使用数据）。
  5. 成功指标——如何判断工作是否成功？（价值 / 质量 / 进度 / 满意度）
  6. 范围外事项、依赖项与风险。

Artifact template

工件模板

markdown
undefined
markdown
undefined

Product Requirements Document — <Product> <Version>

产品需求文档 — <产品> <版本>

Confidential and subject to change. For internal use only. No external commitments can be made based on this document since it is in early planning stages. Content and timing are very likely to change.
Company: <company> · Feature / Product: <feature / product name> Author: <author> · Contact: <email> · Date created: <date> · Version: 1.0
机密且可能发生变化。仅供内部使用。由于本文档仍处于早期规划阶段，任何内容与时间安排都很可能发生变化，因此不得据此作出对外承诺。
公司： <公司> · 功能 / 产品： <功能 / 产品名称> 作者： <作者> · 联系人： <电子邮件> · 创建日期： <日期> · 版本： 1.0

1. Overview of the target release

1. 目标版本概述

Goal of this release: <one paragraph>. Market forces driving it: <evidence-backed forces>. Driven primarily by: <content | target date>. Target window: <date/quarter>. Related artifacts: <positioning doc, roadmap, canvas, links>.
本次发布目标：<一段话>。 驱动本次发布的市场力量：<有证据支持的力量>。 主要驱动方式：<内容 | 目标日期>。目标窗口：<日期/季度>。 相关工件：<定位文档、路线图、画布、链接>。

2. Personas

2. Persona

Buyer persona — <name>

购买者 Persona — <姓名>

<motivations, buying process, barriers>
<动机、购买流程、障碍>

User persona — <name>

用户 Persona — <姓名>

<goals, behaviors, problems>
<目标、行为、问题>

3. Market problems (persona's first person, with evidence)

3. 市场问题（使用 Persona 的第一人称，并附证据）

  • "<I can't …>" — evidence: <n interviews / % customers / win-loss>
  • "<It takes too long to …>" — evidence: <…>
  • “<我无法……>”——证据：<访谈次数 / 客户占比 / 赢单与丢单情况>
  • “<完成……耗时太长>”——证据：<……>

4. Requirements (grouped, prioritized)

4. 需求（分组并排序）

GROUP 1 — <group name>

第 1 组 — <组名>

  1. <Requirement> — <Persona> has <problem, in a use scenario> with <frequency>. Priority: <evidence> (inputs) × <impact> (impact) = <priority>.
  2. <Requirement> — … Priority: … = <priority>.
  1. <需求> — <Persona> 存在<以使用场景描述的问题>，发生频率为<频率>。 优先级：<证据>（输入因素）× <影响>（影响程度）= <优先级>。
  2. <需求> — …… 优先级：…… = <优先级>。

GROUP 2 — <group name>

第 2 组 — <组名>

  1. …
  1. ……

5. Use scenarios (day-in-the-life)

5. 使用场景（日常使用流程）

<Scenario name> — <Persona> is trying to <goal>. Today, <what happens, the pain, the current workaround>. This happens <frequency>. <Why it matters.>
<场景名称> — <Persona> 希望<目标>。目前，<发生的事情、痛点和当前变通方案>。这种情况的发生频率为<频率>。<为何重要>。

6. Requirements summary

6. 需求汇总

RequirementPersonaMarket EvidenceImpactPriorityGroupGroup Order
<name><persona>254100<group>1
需求Persona市场证据影响优先级分组组内顺序
<名称><Persona>254100<分组>1

7. Out of scope / non-goals

7. 范围外事项 / 非目标

  • <explicitly not doing …>
  • <明确不做……>

8. Success metrics

8. 成功指标

Metric categoryMetricCurrentGoal
Value<LTV / revenue>
Quality<defects / coverage>
Progress<cycle time>
Satisfaction<NPS / CSAT / renewal>
指标类别指标当前值目标值
价值<LTV / 收入>
质量<缺陷数 / 覆盖率>
进度<周期时间>
满意度<NPS / CSAT / 续约率>

9. Dependencies & risks

9. 依赖项与风险

  • <dependency / risk> — <mitigation>
  • <依赖项 / 风险> — <缓解措施>

10. Approvals

10. 审批

NameTitleDateSignature
Product Manager
Systems Architect
Development Manager
Interaction Designer
QA Lead
姓名职务日期签名
产品经理
系统架构师
开发经理
交互设计师
QA 负责人

11. Change tracking

11. 变更跟踪

VersionDateChangesReason
1.0<date>Initial draft
版本日期变更原因
1.0<日期>初始草稿

Open questions / evidence to gather

待收集的开放问题 / 证据

  • TODO: <unproven claim or missing evidence>
undefined
  • TODO: <未经证实的主张或缺失证据>
undefined

Deliver the artifact

交付工件

Follow 
../pm-copilot/references/artifact-output.md
: confirm inputs (fill gaps with clearly-marked assumptions rather than inventing evidence), ask Markdown or .docx, write the 
.md
, convert to 
.docx
on request via your environment's native document-creation capability. Then offer the next stage: turn the prioritized requirements into a committed 
pm-release-plan
, and set up 
pm-stakeholder-communication
 to keep everyone aligned.
按照 
../pm-copilot/references/artifact-output.md
：确认输入（对于缺失项，应使用明确标注的假设进行补充，而不是凭空编造证据），询问用户需要 Markdown 还是 .docx，编写 
.md
文件，并应用户要求通过当前环境原生的文档创建能力转换为 
.docx
。 随后提供下一阶段选项：将按优先级排序的需求转化为确定版的 
pm-release-plan
，并设置 
pm-stakeholder-communication
，确保所有相关人员保持一致。