“没有内容的形式和没有形式的内容，都是不能存在的；即使存在的话，那么，前者有如奇形怪状的空洞的器皿，后者则是虽然大家都看得见、但却不认为是实体的空中楼阁。”
——（俄）别林斯基《论人民的诗第一篇》
其实在不同的场景下，基于不同的受众和目的，产品文档的种类很多，我们常用到的产品文档包括以下几类。
1. BRD/MRD
顾名思义，BRD
描述的是商业级别的内容和判断，
通常逻辑和内容会比较短小精悍，
但背后要有广泛的调研和思考基础，
而且 BRD 是站在公司和股东层面的，
它回答的问题是我们要不要做，
比如我们是否需要面向所有用户新增一种新的商业产品，或者我们是否需要将一次性收费模式变更为订阅模式。
我在过去的工作中，
大部分要用到 BRD 的机会都伴随着重大的战略决策，
需要比较长时间的周密推演和讨论，
最终一般会是高层非常慎重的决策过程。
从另一个角度来说，我觉得大部分的项目是不需要 BRD 的，
尤其是有些项目，都已经决定要做了，还要去准备 BRD 论证其合理性，就很形式化，没有太大价值。
MRD
一般会在既有的产品路线上启动比较大的项目或者新功能时用到，
但我在过去的工作中却很少专门写 MRD，
我自己的理解是： MRD 是 BRD 和 PRD 之间承上启下的一种形式，
交代市场机会，竞争情况，产品和运营策略和计划等等，
有点像是对 BRD 的拆解和细化，
也有点像是高度概括、没有细节的 PRD；
所以我会选择干脆把这样的内容拆到 PRD 或 BRD 里面去。
如果说 BRD 回答的是“我们要不要做”，那 MRD 回答的就应该是“我们怎么做”，
它会比 BRD 多了很多细节，却又不涉及详细的功能逻辑和流程。
在大部分项目中，我的习惯是
把 MRD 的内容放到 PRD 中去，在不同的场合着重讲不同的部分。
比如在对业务和运营部门宣讲的时候，我会避开产品特性的细节逻辑，着重讲偏向 MRD 的部分，
而在向工程师宣讲的时候，则会反过来，主要精力放在讲具体要实现些什么特性，只需要简明扼要地交代商业背景。
2. PRD/UC/FSD
PRD
它一般是写具体的功能逻辑和细节，给工程师看的；
在操作过程中，产品经理还是应该在 PRD 中写一些包含商业、业务背景、市场机会等等内容；也就是交代清楚“为什么做”，而不是简单地描述流程和功能。
重操作的 To C 产品可能需要交互流程描述和线框图，而 To B 的产品可能注重的是概念模型和业务流程。
UC 是指用例文档，
通常是以用户角度的完整功能单位为粒度，描述用户跟系统的交互过程以及系统的输出逻辑。
如果项目是重交互，以用户场景驱动的话，我会推荐用 UC 来组织 PRD，
也就是 PRD 里面按照用例的方式来描述功能实现，这样做更容易向工程师交代产品价值。
用例文档的模板比较简单，网上一搜一大把，
最核心的部分是流程，通常会把主流程和分支流程分开描述，
再复杂的业务，主流程一般都简明扼要，所有的复杂度最好都放到分支流程里面去，
分支流程里面的一些限制和规则，可以整理一下，在业务规则的那个部分重写一份，便于工程师在开发过程中去查阅。
FSD 是
功能详细说明（Function Specifications Document），有时候我们也称作 FRD，我们经常说“写 Spec”，其实就是指它。
这时的文档就偏向实现了，交代具体的数据字典，概念模型结构，业务接口规范等等，
一般 FSD 会跟 PRD 合并，不会单独拆出来。
大部分项目中，如果你写了 PRD，就不大需要再写 FSD 了。除非项目的规模很大，涉及各种各样的子项目，可能整个项目组有一套 PRD，但每个具体的子项目会准备专门的 FSD。
在我看来，大部分项目其实不需要这么多类型的文档，我的建议是尽量简化，对于大项目，BRD 加 PRD 足够，中等项目或者小需求直接写 PRD 或者 UC 就可以。
3. 产品原型 / 交互稿
关于产品原型有两个提醒，
一是记得把事情做到刚刚好就够了，很多产品经理喜欢炫技，把原型做得极其逼真，细节、动效俱全。大家要想清楚做原型图的目的是什么，做到什么程度可以达成这个目的，有时候原型做到八十分，把逻辑和框架表达清楚就足够了，结果产品经理非要做到一百分甚至一百二十分，这样一来会耗费没有必要的精力（但这不是你做一个不及格原型的借口）。
一个产品所有的相关产出不一定要处于同样的质量水平
这种完美主义倾向很多时候来源于对目标的不清晰和对真正产品价值思考的逃避。专业的事情交给专业的人，让设计师去完美产品的样子就够了。
二.除非面对面讲解，否则产品原型需要一个明确的阅读线索。很多产品经理画完原型图就完了，往文档上一贴，不解释不说明。大部分人很难系统性地读完一张产品原型图，因为图不是一个线性信息，需要引导。在这里跟你分享一个方法，就是在产品原型图上齐整地加上标注：可以用数字标记，在下方注释，或是用细线引导在原型图边上加注释。
4. 其他各种因需创建的文档
总之，只要有明确的目的，而且在保证沟通效率的前提下，文档不是一个坏东西。但千万不要为了文档而文档，变成形式化的东西，禁锢了流程和创造力，就糟糕了。
“完美主义倾向很多时候来源于对目标的不清晰和对真正产品价值思考的逃避”，非常赞同这句话，我之前就一直在追求事事完美，还自以为是产品经理必备的素质，其实在很多情况下，浪费了大量时间。现在越来越觉得，对目标的定义，对价值的思考，对投入产出比的把握，才是产品经理的核心价值。
对于各种文档也是，能做到有效沟通即可，当然除了内容，让别人看着顺畅和舒服也是需要考虑的。作为产品经理，要时刻提醒自己，不要为了形式而忘了目标。
网友评论