如果把prd看成一件产品，那它的核心用户必然是研发。要写好产品文档，首先要学会的就是站在研发的角度看问题。技术经常强调要面向对象编程，那么产品经理就应该学会面向研发写PRD。
面向研发写PRD，首先要知道的是，研发对产品文档最直观的感受不是需求价值、用户体验，而是文档的严谨性。
研发们喜欢逻辑严谨、细节考虑周全的产品文档。一方面是这样可以大大减少沟通成本，减少研发在实现功能时中断去问产品细节的时间，另一方面是大部分研发是内向型人格，能用文字说清楚的尽量不要说话。
对产品经理而言，把需求细节考虑周全，一是让你在工程评审时更有底气，减少被怼；
二是节省开发过程中的沟通成本。我见过有的产品经理喜欢把文档写得很粗糙，到了开发阶段频繁来往研发工位讨论细节，这种方式让他看起来每天都很充实，存在感很强，实际上是一种低效的表现；
三是增加你在研发中好感度和专业认可度。想象一下当研发遇到所有他想到的和没想到的细节，都在你的文档中找到答案，他肯定会由衷地佩服你的缜密。
以下归纳了几种PRD里常见易忽视的细节：
一、数据保存时限
”你可以接受记录保存最短的时间是多少？“
这是在开发过程中我经常听到研发对产品的提问。长期保存作用不大的记录对服务器存储是一种浪费，所以大多数记录需要产品经理提供一个最长数据保存时间。以蚂蚁森林的动态为例，如果保存12亿人从注册起的收集能量记录，将是一笔高昂且意义不大的开销（不考虑用户数据价值）。
蚂蚁森林记录
二、极限值
任何涉及到可变长度的文本、数值，都需要考虑到极限值的情况，文本框超过最大可编辑文字长度时如何显示？用户余额超过最大可显示位数时如何显示？
三、显示格式
时间显示”08:00“还是”8:00“？是否显示前置0？类似的问题请在文档里写清楚，而不是扔一个”16:23“的美术图，然后让研发去猜8点的实现方式。
类似的还有取整的问题，时间/倒计时的显示，是向上取整还是向下取整，都需要注明。
四、是否允许误差
在App实现过程中，由于前后端数据传输等问题，误差常常是不可避免的，但是善良朴实的研发还是经常会向产品经理确认是否允许误差，并苦口婆心地解释产生误差的原因。
例如许多电商活动的前端倒计时，倒计时时间一般是前端从服务器一次性取到后，开始在本地倒计时，所以倒计时的时间难免与服务器时间存在一定误差。产品经理可以在PRD撰写阶段就把这种可能存在的误差考虑进去，并写明自己可接受的误差范围，会大大减少之后的沟通成本。
拼多多倒计时
五、前后端实现
有些功能前端或后端实现是不言自明的，但有些功能则不然，且不同端实现的达到效果是不一样的，这时候前后端研发往往需要产品根据需求拍板决定。
继续举例子，某产品做了一个新的H5活动，要求引导弹窗仅在用户每天第一次进入活动时显示，这时候就需要记录用户是否是当天首次参与活动，问题就来了，前端记还是后端记？
分析一下，前端记录的话这个记录会记在本地存储上，优点是不需要读取服务器，缺点是如果用户删除App或者清空缓存，就可能出现一天两次弹窗的情况；后端记录则不存在这个问题，但是需要在接口里提供这个信息。在这个具体的问题上（引导弹窗），记在本地是没有问题的，极少数一天出现两次弹窗的情况是可以接受的，也不存在什么风险。
但是有些情况，例如发放优惠券或者奖励，则是必须由服务器记录。所以，对于一些前后端实现模棱两可的需求，产品经理可以在文档里标明自己倾向的实现方式，或是在评审时告诉研发们自己定。
六、配置切换时的表现
有的公司产品配置是可视化后台实现的，比较节省成本公司可能会用JSON配置。无论哪种方式，一个新功能上线，都需要考虑好配置切换时的情况。
以趣头条的任务中心为例，趣头条的任务中心有「每日重置」类型的任务，若上线「倒计时重置」类型（领取完任务后倒计时x秒重置为未完成状态）功能，产品经理需要考虑任务配置时是否允许「每日重置」和「倒计时重置」任务互相切换，如果允许，切换时会有什么表现？对用户的进度和领取状态是否会有影响？进度是否需要继承？
趣头条任务中心
七、异常情况处理
网络异常时页面的展示、用户输入手机号位数过长时的处理方式、用户短时间内高频率刷新界面处理方式，诸如此类的异常情况都是产品经理应该考虑到的。
有的产品会觉得这些属于技术范畴，完全交给技术处理。现实情况是，如果产品经理在文档里不提及解决方案，放任研发自由发挥，最后的结果大概率是会不符合产品预期的。你可能会看到非常硬核的内容，例如”错误码axc1353“的Toast。
