几年前在知乎看到一个故事：
从前有个产品经理，一个比较大的项目只写了三页模糊不清的PRD就交给开发，开发当着所有人的面把PRD撕了。
这个梗我一直记得。
PRD本质上用来沟通。PM和自己沟通，PM和PM沟通，PM和开发沟通，PM和boss沟通。
总有人觉得，只要我们有一颗热忱的、愿意随时沟通的心，一切关于沟通的问题就会迎刃而解。
PRD写个大概，一切胸有成竹，细节都在脑子里，遇到模棱两可的问题当面讨论就是了。N个产品经理都这样想的。甚至有想不开的开发也这样想。
但问题是：
1 缺乏系统思考
模糊的问题当面讨论，每次当面讨论的解决方法都是针对这个局部问题的。尽管可能每次会稍微考虑一下全局，但还是不能从根本上全盘思考。
这样写PRD提前规划的意义就没有了，PM的价值也大大减弱。做出来的产品也可能缺乏统一性。
2 效率低下
沟通即成本。
引用一个产品讲的故事：
产品找研发，说一个人开发需要10天，那么两个人5天就搞定了。研发回复说，一个女人怀胎十个月生孩子，10个女人就只需要一个月。
开发之间的沟通有成本，开发和产品之间的沟通成本更大。
开发做了一半进行不下去，把产品找来问逻辑细节，产品说了一套，结果之前做的有部分要重新做。逻辑的细微不同都可能导致整个架构不同。
来来回回多少时间和精力被浪费了，这些时间本可以优化性能、学习新东西。
我尝试了一下，一份清晰的交互文档能让开发效率提高3倍，原本需要6天的东西2天就完成了。过程中还很愉快，因为你不会担心那些未知的不确定性。还有机会从架构层面思考问题，而不是陷进业务中。这份交互文档本身花费的时间是半天。也就是一共节省了原来一半多的时间。
3 反复修改
最可怕的是什么？
为什么会有模糊不清没有落地的PRD，最可能的原因是，产品经理自己都没有想清楚逻辑。
结果在开发过程中在关键地方摇摆不定，反复修改，开发者被折磨的死去活来。
这样一个反复修改的PRD会严重影响整个项目，包括设计、开发、测试流程。
问题怎么解决呢？
答案是一份高质量的PRD和一份高质量的交互文档。
有人会说，我们最关键的是要提高效率完成任务。一份事无巨细的PRD和包含无数图的交互文档本身就会花费大量时间。
或这个项目人不多，随时沟通效率更高。
但请相信我，可能是你不会写PRD和交互文档。有的人煞有其事地写PRD和交互文档，自己陷进无数逻辑出不来，写出的东西既不能理清逻辑，别人也不愿意看。这样当然是浪费时间。
交互文档是理清逻辑的必要途径，所以，可以说交互文档首先是PM给自己的产出，交互文档的第一个客户就是PM自己。一份逻辑清晰的交互文档能抵御所有人的盘问，能抵御来自开发和测试的伤害，是你最好的铠甲。
另外，交互文档不一定是PM或UED部门产出，任何一个对此不满的人都可以产出。
延伸话题：
如何写好交互文档
为什么应该随时拓展能力边界
下次再聊吧。