前言 #
七月份，我正式开始做产品经理了。说实话，刚入行的时候，连 PRD 是什么都只有模糊的概念。
以前看别人写的文档，觉得也就那样，不就是画个原型写写功能吗？等自己真正上手才发现，问题远比想象中复杂。设计出来的功能漏这漏那，跟开发评审的时候被问得哑口无言，上线之后才发现埋点没做好、数据取不到。
痛定思痛，我开始认真研究 PRD 到底应该怎么写。今天这篇文章，就是我对 PRD 写作方法的一次总结，也是给刚入行的自己一个交代。
PRD 的三种形态 #
在开始讲怎么写之前，先说一个很多新人容易犯的错：不是所有需求都要写 PRD。
随着现在开发节奏越来越快，有些简单的改动根本没必要创建专门的文档。比如只是改几个文字、调一下按钮颜色，这种直接在任务管理系统里备注清楚就行了。我把这种方式叫做 in-task design，就是在任务卡片里把需求说清楚。
但还有一种情况恰恰相反，当你面对一个复杂的产品从零开始，比如做一个电商 App、做一个社区产品，这时候单个 PRD 根本装不下所有的设计细节，可能需要多个产品经理协作，共同完成一整套 产品家族（Product Suite）。这种情况下，就需要有一个更顶层的 PRD 来做总纲，各个模块再拆分成独立的 PRD。
我们日常最常写的，其实是中间这一层：面向单个用户故事（User Story）的 PRD。本文主要讲的就是这种。
PRD 的标准结构 #
一份合格的 PRD，在我看来应该包含以下六个部分：
- 版本说明
- 背景与目标
- 故事介绍
- 概要设计
- 详细设计
- 交付设计
下面逐一展开。
版本说明 #
这个最好理解，就是记录你每次更新的内容。但要注意一点：版本说明不是每次改一点就写一次，而是跟着评审（Review）走的。每一次 Review 之后发生了哪些变化，你需要记录下来。这样下次参与评审的同学就能快速了解：这个 PRD 跟上一次相比，有什么调整。
背景与目标 #
这部分也很基础，但在很多公司的实际流程中，可能已经有业务团队写的 MRD（Market Requirements Document）来交代背景了。
背景要回答的问题是：为什么需要这个功能？它在业务上能带来什么？
这里不需要讲太多细节，关键是说明做这件事的必要性。比如是拓展用户群、提升某项业务指标、还是解决用户反馈强烈的问题。把核心原因说清楚就行。
目标则是：功能上线后，你期望达成什么样的效果？
可以是量化的指标，也可以是定性的预期。比如「日活提升 X%」「用户投诉率降低」或者「支撑某类新场景」。目标的价值在于，它让所有阅读 PRD 的人都能理解：这个功能最终要创造什么样的价值。当然，目标怎么达成不用在这里展开，那是后面要做的事。
故事介绍 #
这是很多产品新人容易遗漏的部分。
很多人设计功能的时候，打开原型工具就开始画页面。这其实是不对的。作为产品经理，你更需要解释的是：这个功能的意义是什么，它能解决什么问题。
故事介绍的核心是场景拆解。具体做法很简单：把你想到的用户会做的事，一件一件列出来，一行一条。不用写得很细，关键是把用户旅程的关键节点梳理出来。
为什么要这么做？因为当你把这些场景列完之后，读者脑子里已经有了「画面感」，他们会联想到自己用过的类似产品，会在脑海里形成对这个功能的初步印象。这种画面感非常重要，接下来的所有设计都是在填充和完善这个画面。
有了场景之后，还需要做价值分析。简单说就是讲清楚：这个功能上线后，会在哪个环节产生什么正向影响。
价值分析的颗粒度可以根据实际需要来：有些团队有专门的 MRD 来说这些，产品经理可以简化这部分；有些团队没有，那就需要产品经理自己补上这块逻辑。
概要设计 #
概要设计对应的是产品设计五张图中的三张：模块图、功能清单图和页面结构图。
功能清单是核心中的核心。很多人觉得原型最重要，其实不对。一个清晰的功能清单（Feature List） 才是整个 PRD 的目录索引。
功能清单怎么列？可以按模块来分层组织。比如用 M 开头标记模块（Module），用 F 开头标记功能（Feature）。每个模块下面有哪些功能，全部穷举出来。
为什么要穷举？因为这能让团队快速了解全貌。开发团队有十几二十号人，每人每个迭代只能做三四个功能，首先得让他们知道整体在做什么。同时，Tech Leader 可以根据功能清单分配任务，测试团队也能据此准备测试用例。功能清单就像一本书的目录，保证任务不遗漏。
页面结构则是对功能清单的视觉化索引。每个页面对应哪些功能，如果发现页面里承载的功能在清单里找不到，或者清单里有但页面没有，那就要回头检查是不是哪里漏了。这是一种自洽的验证机制。
详细设计 #
详细设计其实是最不容易出错的部分，因为大家都会做：把每个页面的交互逻辑、字段说明一一写清楚。
但有一个点必须强调：详细设计里的每一个细节，都要能跟前面的功能清单和页面结构对应上。如果发现写了某个功能但前面没列，就要回头补上；反之亦然。
几次自洽检查下来，设计会非常完整，也不容易漏逻辑。跟团队的信任感就是这么建立的。
交付设计 #
这是另一个容易被遗漏的部分。
交付设计里，我认为最关键的两块是：数据埋点设计 和 上线前提条件。
数据埋点：很多产品经理等到功能上线了才想起来要分析数据，结果发现埋点没做、数据取不到，只能等下一个版本。这是非常糟糕的情况。
好的做法是，在 PRD 设计阶段、进入研发之前就想清楚：你需要看什么数据？现在的埋点方案能否满足你的分析需求？如果不能，就要提前改方案。
数据分析师也是 PRD 的「用户」之一。在测试阶段，他们要验证埋点是否正确、能否生成你需要的报表。如果不能，测试就不算通过。这是一个双保险。
上线前提条件：这个功能是否依赖其他系统先上线？是否会影响历史数据？需不需要提前备份？这些作为产品经理都要考虑清楚。
产品上线后 #
我的一个习惯是：功能上线一两周、数据稳定之后，更新 PRD，告诉团队当时设定的目标和实际达成的数据。
如果设计 10 个 PRD，这 10 个功能上线后的数据都跟预测接近，那你绝对是专家了。刚开始预测不准很正常，不要怕。大胆走出第一步，你就已经超过很多人了。
评审效率 #
最后说一个提高效率的技巧：PRD 评审会之前，把文档提前一到两天发给开发。
很多新人因为担心被老程序员吐槽，总是藏着掖着，评审会上才拿出文档让大家现场发挥。这是非常不可取的做法。
正确的做法是大胆地提前分享，让大家带着问题来开会，很多问题在线下就解决了，效率高得多。
结语 #
产品经理是一个非常依靠实践的岗位。只有真正动手写、动手做，才能把别人的经验转化为自己的能力。
共勉。