prd-writing

概述

PRD 编写是运用“逆向工作法”将战略愿景转化为可执行工程需求的过程。它要求先撰写面向客户的叙述（新闻稿）并进行全面的风险审查（FAQ），再敲定任何技术规格，以此确保内容清晰明确。

铁律

NO PRD WITHOUT A CUSTOMER-FACING PRESS RELEASE DRAFT FIRST

在阐明客户收益之前编写需求，会导致“功能膨胀”、工程工作方向错位，以及产品解决的是技术问题而非客户问题。

状态机

digraph prd_writing_flow {
    "Strategy/Vision" [shape=doublecircle];
    "Step 1: Press Release (PR)" [shape=box];
    "Step 2: FAQ (Internal/External)" [shape=box];
    "Step 3: Narrative PRD" [shape=box];
    "Gate: Alignment Review" [shape=diamond];
    "Technical Spec Ready" [shape=doublecircle];

    "Strategy/Vision" -> "Step 1: Press Release (PR)";
    "Step 1: Press Release (PR)" -> "Step 2: FAQ (Internal/External)";
    "Step 2: FAQ (Internal/External)" -> "Step 3: Narrative PRD";
    "Step 3: Narrative PRD" -> "Gate: Alignment Review";
    "Gate: Alignment Review" -> "Step 1: Press Release (PR)" [label="benefits unclear"];
    "Gate: Alignment Review" -> "Step 2: FAQ (Internal/External)" [label="risks missing"];
    "Gate: Alignment Review" -> "Technical Spec Ready" [label="approved"];
}

何时使用此技能

• 开始开发新产品或重大功能时。
• 现有需求零散或不明确时。
• 需要跨职能团队（工程、设计、营销）就唯一事实来源达成一致时。
• 准备参加产品资金或资源分配会议时。

何时不使用此技能

• 用于简单的 Bug 修复或维护任务。
• 用于探索性研发，其目标是学习而非交付。
• 问题尚未定义时（请改用 problem-framing）。

核心流程

第 1 步：先写新闻稿（PR）

• 仅限一页： 将产品价值提炼为一页面向客户的文案。（来源：Bryar，《逆向工作法》）
• 必要组成部分：
  • 标题： 为产品命名，确保客户能够理解。
  • 副标题： 指明目标客户和一项主要收益。
  • 摘要： 用 1-2 句话概述产品及其收益。
  • 问题： 详细描述客户面临的问题（例如：“很难做到……”）。
  • 解决方案： 简明说明产品如何解决该问题。
  • 领导者引言： 引用你或某位领导者的话，说明这为何是优先事项。
  • 客户引言： 假设一段引言，描述产品对客户生活或工作的具体影响。
  • 行动号召： 说明客户如何开始使用。（来源：Bryar，《逆向工作法》）

第 2 步：起草 FAQ

• 外部 FAQ： 预判并回答客户最常提出的 5-10 个问题（价格、可用性、兼容性）。（来源：Bryar，《逆向工作法》）
• 内部 FAQ： 回答利益相关者提出的“棘手”问题：技术可行性、依赖项、ROI 和风险。（来源：Bryar，《逆向工作法》）

第 3 步：将金字塔原理应用于 PRD

• 自上而下的逻辑： 从“先说结论”（BLUF）开始。结论或建议必须放在最前面。（来源：Minto，《金字塔原理》）
• MECE 结构： 确保需求分组相互独立且完全穷尽。不重叠、不遗漏。（来源：Minto，《金字塔原理》）
• 归纳推理： 将支持性数据和事实归入主要需求之下，让叙述更易于理解。（来源：Minto，《金字塔原理》）

第 4 步：确定“限制步骤”

• 逆向规划： 找出“限制步骤”（构建过程中耗时最长、最敏感或成本最高的部分）。从该步骤的日期倒推，制定交付节奏。（来源：Grove，《高产出管理》）
• 以产出为导向： PRD 应聚焦于产出（交付的价值），而不只是活动（功能）。（来源：Grove，《高产出管理》）

跨技能调用

必需的子技能：buyer-persona —— 确保“客户引言”贴合现实。 推荐的子技能：stakeholder-review —— 在最终确定 PR/FAQ 前进行压力测试。 推荐的子技能：memo-stress-tester —— 确保最终 PRD 叙述的结构完整性。

理性分析表

想法	现实
“项目太小，不适合写 PR/FAQ。”	小项目也容易出现功能蔓延。PR/FAQ 是保持范围纪律的唯一方法。
“工程团队已经知道要构建什么。”	工程团队知道如何构建；PR/FAQ 能让他们就为何构建达成共识。
“写 PR 是在浪费时间，不如开始编码。”	重写代码的成本比重写一页叙述高出 10 倍。
“我们会在发布时写新闻稿。”	发布当天的 PR 是营销；项目启动日的 PR 是战略工具。跳过这一步必然会导致方向不一致。

警示信号

出现以下想法时就该停下来——你正打算走捷径：

• “PR 有三页长。” → 你还没有提炼出核心价值。
• “我先从技术规格入手，之后再补 PR。” → 你是从技术出发，而不是从客户需求倒推。
• “FAQ 里没有什么‘棘手’问题。” → 你在回避将来可能使项目脱轨的技术和组织风险。

诊断清单

• 是否有一份面向客户的一页新闻稿？
• PR 是否包含一条描述具体成果的客户引述？
• 内部 FAQ 是否涵盖技术债务和依赖项？
• PRD 是否采用金字塔原理，自上而下地组织内容？
• 是否已确定实施中的“限制步骤”？

来源

• Bryar 和 Carr，《Working Backwards》，第 5 章——PR/FAQ 方法论。
• Barbara Minto，《The Pyramid Principle》——MECE 和自上而下的结构化方法。
• Andrew Grove，《High Output Management》，第 1 章和第 3 章——限制步骤和管理杠杆。
• Amazon PR/FAQ 方法论相关文章。