prd-writing

PRD 撰写

适用场景

当创始人或产品经理需要将产品构想、功能需求或战略计划转化为结构化的产品需求文档时启用。适用于用户提出“撰写 PRD”“详细规划此功能”“定义 X 的需求”或“我需要记录我们正在构建的内容”等请求。

所需背景信息

• **来自 startup-context：**公司阶段、目标客户群体、当前产品状态、团队规模、技术限制。
• **来自用户：**需要详细规划的功能或计划、要解决的已知用户问题、已有研究或客户反馈、期望时间线，以及范围偏好（轻量版还是完整 PRD）。

工作流

1. 明确范围级别 -- 询问用户需要轻量版 PRD（早期探索，2-3 页）还是完整 PRD（已确定的计划，5-8 页）。如果公司尚未实现产品与市场匹配，默认采用轻量版。
2. 收集输入 -- 收集问题陈述、目标用户、已有研究、成功标准和已知限制。确定关键联系人及其职责。
3. 撰写包含 8 个部分的 PRD -- 使用下方模板依次撰写每个部分。采用通俗易懂的语言，适合工程、设计和领导层等广泛受众阅读。
4. 标注假设 -- 明确列出支撑各部分的关键假设。对每项假设，说明有哪些证据支持，以及哪些情况会推翻它。
5. 审阅并完善 -- 展示草稿，征求反馈，并针对具体部分进行迭代。注明 PRD 版本和最后更新日期。

输出格式

一份包含 8 个部分的结构化 PRD 文档：

部分模板

1. 摘要 -- 用 2-3 句话概述要构建的内容及其重要性。面向广泛受众撰写。
2. 联系人 -- 列出关键利益相关者及其职责，并说明其参与的相关背景。
3. 背景 -- 介绍问题领域的背景：为什么是现在、发生了什么变化，以及哪些条件使此计划成为可能。说明竞争背景，即其他人如何应对同一问题。
4. 目标 -- 说明目标、业务和客户收益，以及战略契合度。定义与 OKR 挂钩的 SMART 成功指标。使用以下格式：“帮助[用户群体]实现[某项操作]，从而达成[可衡量的结果]。”
5. 市场细分 -- 根据问题和需求（而非人口统计特征）定义目标用户。描述主要和次要细分群体，并估算其规模。
6. 价值主张 -- 对应说明解决的客户任务、提供的收益和消除的痛点。使用价值曲线分析等框架展示竞争差异化。
7. 解决方案 -- 在适用时，说明功能、UX/原型、线框图、用户流程和技术细节。明确列出范围之外的事项。记录假设。至少列出 5 种边缘情况。
8. 发布 -- 使用相对时间范围（而非确切日期）制定分阶段推出计划。定义 MVP 与后续迭代、功能标志、回滚标准和评审检查点。

对于轻量版 PRD，第 2、3 和 8 部分可各精简为 2-3 句话。

框架与最佳实践

• 先讲问题，再讲解决方案。 在涉及第 7 节（“是什么”）之前，先用文档 40% 的篇幅介绍第 1–5 节（“为什么”）。跳过问题直接讲解决方案的 PRD 是规格说明，而不是 PRD。
• 一个目标，而非五个。 有多个目标的 PRD 实际上是多个 PRD。应将它们拆分。每个 PRD 都应只推动一个主要指标。
• 根据需求定义市场细分。 根据用户面临的问题，以及他们希望产品帮忙完成的任务来描述目标用户，而不要只根据人口统计特征或公司特征来定义。
• 明确价值主张。 针对每个细分群体，明确说明满足的客户任务、提供的收益和消除的痛点。使用价值曲线展示你与竞争对手的差异。
• 以数据为依据，明确具体。 用具体数字替换模糊表述。“提高留存率”不是指标；“在上线后 8 周内将 D7 留存率从 25% 提高到 35%”才是。
• 防止范围蔓延。 明确列出不在范围内的事项。利益相关者提出新增内容时，重新审视范围外清单。
• 使用相对时间范围，而非具体日期。 使用阶段和相对时间窗口，而不是确切的日历日期。这样可以避免虚假的精确性，并保留灵活性。
• 跟踪假设。 列出 PRD 所依据的前 3 个假设。针对每项假设，说明支持证据以及什么情况会推翻它。
• 考虑受众。 工程师需要技术约束和边缘情况；设计师需要用户流程和用户画像；高管需要摘要和指标。在同一份文档中满足这三类受众的需求。
• 持续更新文档。 标明 PRD 版本和最后更新日期。从不变更的 PRD，说明从未有人读过。
• 轻量级 PRD 的适用场景： PMF 前期探索、黑客马拉松项目、内部工具、周期少于 2 周的实验。
• 完整 PRD 的适用场景： 跨团队计划、具有外部依赖项的功能，以及任何涉及支付或合规的事项。

相关技能

• roadmap-planning -- 编写 PRD 后使用，以便将计划纳入更广泛的路线图，并明确依赖关系和时间安排。
• mvp-scoping -- 编写 PRD 前使用，以确定 v1 包含哪些内容，以及哪些内容留待后续版本。
• user-research-synthesis -- 编写 PRD 前使用，以真实的客户数据为“背景”和“市场细分”章节提供依据。

示例

示例 1：轻量级 PRD 提示词

用户：“我们需要一份 PRD，为我们的项目管理工具添加 Slack 通知。”

优质输出节选：

摘要： 添加可配置的 Slack 通知，让使用 ProjectFlow 的团队无需离开主要沟通工具，即可收到任务更新、提及和截止日期变更提醒。这解决了我们 Q3 客户调查中排名第 1 的功能请求（38% 的受访者提出）。

目标： 让付费套餐的团队负责人能够在 Slack 中实时接收项目更新，并在上线后 6 周内将任务分配的平均响应时间缩短 20%。

市场细分： 跨工具协作的 10 人以上团队，其主要痛点是在项目管理平台和沟通平台之间频繁切换。

范围外： Microsoft Teams 集成、自定义通知模板、Slack 机器人命令。

示例 2：完整 PRD 提示词

用户：“为我们的全新自助入门流程编写一份完整的 PRD。我们有 60% 的注册用户未完成设置就流失了。”

优质输出摘录：

**背景：**当前入门流程需要 7 个步骤，平均耗时 12 分钟。Hotjar 录屏显示，45% 的用户会在“连接数据源”这一步放弃。竞争对手 X 在 Q2 将入门流程缩减至 3 个步骤，并报告称激活率提升了 2 倍。我们的支持团队每周要处理 30 多个入门相关工单，每月成本约为 4,500 美元。

**价值主张：**通过提供示例数据集，让用户在接入数据之前就能体验核心价值，从而消除“连接数据源”这一步带来的阻碍。与仍要求立即连接数据的竞争对手 X 相比，这一方案更具差异化。

发布计划：

• 阶段 1：与团队内部试用（2 周）
• 阶段 2：通过功能标志向 10% 的新注册用户开放
• 阶段 3：如果激活率 > 45%，则扩大至 50%
• 阶段 4：如果没有 P0 错误且支持工单量有所下降，则正式发布
• 回滚触发条件：激活率降至当前 40% 基准线以下