PRD的模板长什么样

PRD是产品经理的开家本领之一，你需要靠PRD输出你的产品方案，并跟各个团队沟通交互，最终落地上线。

PRD一方面能证明产品经理的实力，所谓的逻辑能力、表达能力、分析能力等，另一方面则是各团队配合的契约证明，大家按你的PRD去推进项目，拿到对应的结果。

一份标准的PRD有哪些模块，什么点是产品经理比较关注但大家可能容易忽略的事项，这里同步介绍下相关内容。

PRD大体有以下核心部分，分别是：产品背景、核心流程、需求列表、需求详述、交互设计稿、外部依赖、埋点需求、上/下线需求等，但不一定每个模块都需要。

比如外部依赖、上下线需求则可以作为可选状态，如果该项目并未涉及到外部协作，以及上线发版问题，则可以不做说明。

再比如你做的产品如果针对底层改造，不涉及到界面调整，则可以没有交互设计稿，具体的模块根据你的产品适当调整。

1、产品背景

产品背景是描述该产品希望解决的问题，以及量化的具体目标。

问题需要描述清楚，即该产品希望解决什么问题，该问题产生的原因是什么，有无数据佐证问题的严重性等。

举例来说，你打算对电商“全部品类”的页面做改版，问题是当前该页面点击率低，比如仅有40%，低于竞对的水平，且用户反馈比较一般，每周大约有20+用户反馈找不到对应的类目。

量化的具体目标则是该产品上线后预期带来的价值，最好用数据量化结果。

比如上面提到的页面改版，量化指标即提升页面点击率，从40%提升到50%+，且问题反馈从20+降低到10（减少50%）。

有预期之后，产品上线后才可以看到是否符合当时预定的目标，是产品方案有偏差，还是当时预定的目标不合理等。

你只有通过这些比较，才能复盘整个链路的发展情况，给自己多增加点产品经验，也给团队做些新的输入。

2、需求列表

需求列表是该产品涉及的功能模块，相当于做一次需求的概览，让研发等知道具体要做哪些功能模块。

需求列表一般用表格来体现，有需求功能、简单说明、优先级等字段，如果功能比较简单，则可以用文字简单说明做哪些需求即可。

以上面的项目为例：

3、需求详述

需求详述是PRD比较核心的内容，是整个PRD的重点。

需求详述如果有涉及到页面改动，则可以配合页面做说明，说明每个改动的具体内容，务必让各个团队知道该页面的具体逻辑，以及具体的规则等。

衡量该模块是否符合要求，有以下几个维度：

1）逻辑完整

逻辑完整是有考虑到产品的整个状态，知道每个流程的流转方向，以及有异常场景下的处理方式。

如果你做交易方面的产品，自然涉及到订单的流转状态，假设你做新的模式比如预售，则预售的正向环节需要有详细说明，逆向环节，比如到期自动退、用户主动取消等也需要同步考虑。

再比如你考虑到异常场景下的处理方式，比如用户高峰时间段如果都想抢购该预售商品，是排队机制类似于双11的方式来做处理，还是有其他更好的方式来并发订单的处理。

2）表达清晰

表达清晰是要能准确描述业务逻辑，让人一眼知道你想要说明的内容是什么，简简单单但又能说清楚。

以类目改版为例，你可以从类目排序顺序、展现样式等去说明具体产品方案。

展现样式可说明为”图+文“的方式，图片来自于运营配置的内容，大小为100*100，文本做字符限制，最多5个字符（含英文、标点符号等）。

另外少用些专业术语，尽量用通俗易懂的方式去描述，因为你的PRD可能不仅仅面向你组内的同事，有时需要对外协作的部门。

如果涉及到专业词汇，可以用“名词解释”来说明，比如前面提到的预售，解释为新的交易方式，用户提前支付定金，等预售结束后再有效期内支付尾款的方式，类似于购商品房的方式。

解释是让大家都能知道你想表达的意思，这样理解一致，后续能减少彼此的沟通成本，确保大家在一个频道上去说明。

3）模板样式

需求详述并无标准的固定模板，大家可以根据自己的产品及喜欢的方式说明需求，只要能清晰表达你想说的产品方案即可。

不过如果有涉及到页面改动，则可以推荐“左中右”表格的方式，举例来说：

功能模块说明具体改动的页面，页面稿则是该页面的交互或设计稿，具体说明是针对该页面的详细说明，这样左中右的陈列方式方便各个人员阅读，即实现所见即所得的效果。

4、交互设计稿

交互设计稿最好是评审是有完整的样式图，能清晰地告知到研发等上线后页面具体长什么样，会有什么样的效果，一般放设计稿图或者蓝湖等链接。

交互稿参考性不如视觉稿，尤其对于前端开发的同学来说，真正工作量需要根据视觉稿来评估。

如果你能提前沟通好UED资源，建议评审时以设计稿为准，后续返工的概率比较低。

设计稿的方式先要有主流程，即主页面的逻辑，让大家知道大体流程是什么样，至于异常逻辑，确保设计稿的交互态要有，别等前端过来催促说哪个状态没有视觉稿。

5、外部依赖

外部依赖是指你的产品跟其他团队协作的支持，看对方是否已经明确支持，并且有排期。

比如你的预售方式涉及到平台、C端等，这时你需要看下这些耦合方是否已经准备好，具体时间点大概是什么时候。

6、埋点需求

埋点需求是往往被忽略的环节，属于重要但看起来没那么紧急的事情。

埋点务必要一起做，否则上线后跟踪不到数据，你得再回来重新埋点再上线，来来回回时间反而被拉长。

具体的埋点方式每个公司都不一样，可以跟公司的数据分析师沟通，看具体的埋点信息要有哪些，怎么按照对应的格式做埋点。

7、上/下线需求

上下线需求一般针对有特殊需求的产品，比如要做A/B测试、分版本切流量上线、回滚机制等。

A/B测试是常用监控产品效果的最优手段之一，如果你产品需要做A/B测试，PRD说明下测试的具体方案。

即如何圈选流量，用用户手机号作为固定测试，或者有具体标签可选取部分用户，以及测试的具体目标，看什么的指标来判断数据效果。

分版本切流量即你的上线节奏计划是什么，如果担心全量上线有问题，你是否可以按城市或品类逐步上线，观察两三天后没有问题再逐步放量。

回滚机制则是下线方案，如果你的产品出问题，要有备选方案，比如回到原来的版本，保证线上的体验不受影响。

以上就是产品PRD需要的模块，最为重点的是“产品背景、功能详述、埋点需求”，其余模块根据需要适当填充即可。

PRD模板只是让大家能充分考虑有哪些维度，避免遗漏，但最为关键是对产品的理解，看为何做产品，以及做产品后的价值度量。

PRD只是表达形式，背后透露的是你对产品的思考，以及后续上线后的复盘。