如何用写情书的思路写PRD？

在产研的世界里，情书（PRD）一定是写给RD的。

还是在五彩城工作的时候，一个炎热的下午，PM小潘来找我吐苦。大致就是PRD被研发喷了，上我这儿讨几颗“灵丹妙药”。

因为私下都很熟，我也就开门见山的问道：“你不是有女朋友吗？”。

“对啊，咋了？”，他一脸呆萌的望着我回道。

“跟我我聊聊，你追妹子的过程吧~”

此处省略一万字……

“你是说把RD当成女朋友？”

“准确的说，是用你写情书的思路和态度，去写PRD！只要把几个关键的问题想清楚了，写个好点的PRD也就不是啥难事儿。”

1. 情书到底是写给谁的

在产研的世界里，情书（PRD）一定是写给RD的。

一次和老板开方案沟通**，某个PM滔滔不绝的讲着自己的PRD交互如何友好，却被老板喷到“这次**议只讨论战略层和内容层面，表现层面的事情你们产品团队内部自己搞定！”，于是乎这位仁兄就弄了个烧鸡大窝脖，甚是尴尬。

还有一次，我手下的一个产品负责了一个非常复杂的项目，为了避免上线前业务反水就去和业务过方案。不可否认，该同学非常认真，连字段表结构设计都给业务讲了一遍，得到的是业务同学的一脸懵逼和不屑。

老板对方向和资源分配负责，员工对战略落地质量负责。方案质量应该通过产品内审**来搞定，老板**从结果追责，但不**过多介入过程。所以别再拿你的PRD给老板扣字了。他不**看的，也不应该看（ps.抽查监控除外）。

业务同学都是目标导向，老板定了目标，玩儿命的去冲锋。他们使用工具，但不**关心工具的产生原理。“你进屋开灯后，**思考灯光发亮的原理吗？”所以别再拿工程术语鄙视业务同学的智商了，那只能暴露你的情商。他不**看，也不应该看。

以上例子并未覆盖全部类型的同事，但要知道，众口难调，没有聚焦，无法取舍。如果我们不清楚到底是写给谁看，就没办法做出取舍。有的妹子喜欢幽默一点的表达方式、有的喜欢文艺点的、有的喜欢简单直接，有的喜欢委婉含蓄。

天知道，她到底好哪口儿？

所以必须承认一个事实，情书的接收对象只有RD（那个目标明确，ID唯一且清晰的姑娘）。

对老板、业务不友好是可以接受的，甚至是必然的。

2. 具体该怎么写

用你的情商设计模块，用你的智商撰写方案。

面试的时候经常**听到应聘者这样炫耀：

• 我交互方案质量非常好，高保真的。
• 我这个方案用的是xx大公司模板，非常严谨。
• 我跟研发沟通的时候，经常用术语，这样才证明我够专业，避免被他们小看了。

“我以为”“我觉得”是这个世界上比较可怕的思维，有点以个人为中心自负的味道。在家自嗨还行，在外追妹子就差点事儿。

残酷的现实如下，玻璃心请关闭此文。

高保真的方案既浪费你的时间，又浪费RD的时间，鬼才知道你这个页面还有那个地方可以跳转。

大公司的PRD成熟严谨是没错，可就一个敏捷需求你给我整一堆略，也是醉了，半天也找不到你到底要让我做啥。

专业术语体现自己牛逼这没错，但总是说**出研发认知范围外术语，就有点欺负人了（光理解MVP就够对方解释一阵子了）。

不要在为了做而做，还是回归初心，安静的听听人家姑娘的心声，也许她就想喝碗小米粥呢~

一般来讲，如果把RD这类妹子确实都比较简单，爱好不外乎如下：

（1）简单直接

但凡有点工作经验的都知道，研发的排期永远都是非常紧张的。虽然他们**评估工期的时候给自己留一些弹性时间，但那时留给意外情况的，不是给理解你方案的。

为此，请简单明了的描述你的需求。不要出现“可能”、“大概”、“我觉得”这类令人抓狂的字眼儿。

记住，老板、PM0和你催的那么紧，她没功夫看你写的废话。

（2）逻辑清晰

RD就像是翻译，将你的PRD语言翻译成工程语言。

为此在这个过程中，为此一个好的PM在撰写PRD的时候就应该是像在写代码。逻辑无非条件、顺序和循环。交代清楚事件的触发条件，降级方案和极端情况。

记住，你让她翻译的越轻松，她就越喜欢你。

（3）内容完整

他想要的你给了，他没想的你也给了，制造**预期的体验。

一般来讲完整的PRD需要包含的模块：

• 背景；
• 预期目标；
• 版本说明；
• 业务逻辑（流程图&storyboard）；
• 功能说明；
• 风控；
• 埋点；
• UI （此处不做展开说明）；
• 参考资料。

记住，你越体贴，她就越喜欢你~

（4）充分尊重

工程的不确定性与方案的复杂程度呈正相关，为此如果你很兴奋的启动一个这类重点工程的话，请早些和相关的RD进行沟通。

条件允许的情况下，可以融入他们的产品方案建议，利用参与感提升主动性。

想想看，如果准备开发的PRD中有她自己贡献的一部分智慧结晶，内心回事多么的骄傲。

人毕竟不是机器，都希望自己是在输出价值，而不是在做重复的劳动。

为此，方案里一定要体现对方投入时间后**给业务带来多么大的价值（当然前期沟通需求的时候，才是最好表达的时机。方案里体现是再一次强调当前工程的意义）。

记住，每个RD的声音都值得尊重，能在PRD中体现出来就尽量体现。

另外，每个人都不想浪费时间，当你的方案明显属于意淫的时候，对方**感觉自己可能在实现一坨垃圾，在浪费时间。

所以能在PRD参考资料模块中，体现自己的决策依据（有源设计）是一个不错的习惯，对双方的时间都是一种尊重。

（5）表达友好

一般PRD就三种模式，这个公司要是没有强制规定的话，就根据方案内容来选择。

storyboard模式：

这种用axure/sketch作图加标注的PRD,适合界面比较多，逻辑比较简单的方案。

优点是比较直观，有几个页面以及页面之间的关系通过连接线一目了然的就能够识别。

缺点，设计页面过多或逻辑较复杂的情况下，阅读体验和效率就**差一些，另外文档的检索效率也**差很多。（可以通过分类目录来解决）

xib模式：

用axure/sketch话storyboard（不展示业务逻辑规则），再用相截图加文字写到word或wiki里面，具体说明规则逻辑。

纯代码模式：

截图加说明在word/wiki按照一定逻辑层级展开，适用于逻辑比较复杂含有一定的前端交互（数量比较少）。用好标题导航工具，逻辑也能展示的很清楚。

（3）也许上面都是错的

我们必须承认，唯一不变的就是变化本身。

时代在变，世界也在变（学徒里的川普都当上总统了），我们赖以生存的互联网也在变，以上的内容都具有一定的局限性和时效性。

经验总是靠不住的，唯一不变的是真理。“以用户为中心做设计”为用户创造价值，才**获得相应的回馈，这就是真理。

所以忘记那些专家，忘记那些模板，回到你的“梦中情人”身边，静静的倾听她们的心声。写一篇“贴心的”清楚，必然**赢得RD们的一篇“芳心”。

本文由 @吴天 原创发布于人人都是产品经理。未经许可，禁止转载

题图来自Unsplash，基于CC0协议