22 | 产品经理的图文基本功（上）：产品文档
邱岳
该思维导图由 AI 生成，仅供参考
“没有内容的形式和没有形式的内容，都是不能存在的；即使存在的话，那么，前者有如奇形怪状的空洞的器皿，后者则是虽然大家都看得见、但却不认为是实体的空中楼阁。”
——（俄）别林斯基《论人民的诗第一篇》
产品经理的大部分工作是无形的，比如思考、分析、协调，在日常的工作中，我们能交出来的、唯一看得到摸得着的产出，就是各种各样的产品文档或产品原型，所以才会有人戏称产品经理就是写文档或做 PPT 的。
文档（包括原型和 PPT 等等）是产品经理重要的基本功，也是产品经理的脸面，很多时候会决定别人跟你合作的初始心态；而且从某种意义上来说，产品文档也是产品经理设计的一个“产品”，也是有用户（阅读者），目的（文档的目的）和特性设计（如何表述，用什么逻辑和工具等）的。
虽然现在越来越多的流派在提倡削减文档，用更敏捷和直接的方式驱动产品发展，我依然认为产品经理需要掌握做出漂亮文档的能力，这也是对产品设计过程的尊重。
接下来，我会分几篇文章，从产品经理日常工作需要用到的几种文档、模型和图示类型入手，分享怎样做出优雅、易读、清晰的产品文档。
平时说到产品文档，我们第一个想到的就是 PRD（Product Requirement Document），但其实在不同的场景下，基于不同的受众和目的，产品文档的种类很多，我们常用到的产品文档包括以下几类。
1. BRD/MRD
BRD 是商业需求文档（Business Requirement Document），MRD 是市场需求文档（Marketing Requirement Document），BRD 和 MRD 的出现机率并不高。通常在启动全新产品线的时候才需要用到 BRD。
顾名思义，BRD 描述的是商业级别的内容和判断，通常逻辑和内容会比较短小精悍，但背后要有广泛的调研和思考基础，而且 BRD 是站在公司和股东层面的，它回答的问题是我们要不要做，比如我们是否需要面向所有用户新增一种新的商业产品，或者我们是否需要将一次性收费模式变更为订阅模式。
我在过去的工作中，大部分要用到 BRD 的机会都伴随着重大的战略决策，需要比较长时间的周密推演和讨论，最终一般会是高层非常慎重的决策过程。
从另一个角度来说，我觉得大部分的项目是不需要 BRD 的，尤其是有些项目，都已经决定要做了，还要去准备 BRD 论证其合理性，就很形式化，没有太大价值。
MRD 一般会在既有的产品路线上启动比较大的项目或者新功能时用到，但我在过去的工作中却很少专门写 MRD，我自己的理解是： MRD 是 BRD 和 PRD 之间承上启下的一种形式，交代市场机会，竞争情况，产品和运营策略和计划等等，有点像是对 BRD 的拆解和细化，也有点像是高度概括、没有细节的 PRD；所以我会选择干脆把这样的内容拆到 PRD 或 BRD 里面去。
如果说 BRD 回答的是“我们要不要做”，那 MRD 回答的就应该是“我们怎么做”，它会比 BRD 多了很多细节，却又不涉及详细的功能逻辑和流程。在大部分项目中，我的习惯是把 MRD 的内容放到 PRD 中去，在不同的场合着重讲不同的部分。
比如在对业务和运营部门宣讲的时候，我会避开产品特性的细节逻辑，着重讲偏向 MRD 的部分，而在向工程师宣讲的时候，则会反过来，主要精力放在讲具体要实现些什么特性，只需要简明扼要地交代商业背景。
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
产品经理的工作主要体现在产品文档和原型的产出，本文从产品经理日常工作所需的文档、模型和图示类型入手，分享了如何制作优雅、易读、清晰的产品文档。文章首先介绍了BRD/MRD和PRD/UC/FSD两类产品文档，分别描述了它们的作用和使用场景。BRD和MRD主要用于商业需求和市场需求的描述，而PRD/UC/FSD则更侧重于产品需求和功能实现的描述。作者强调了文档的重要性，同时提出了简化文档类型的建议，认为对于大部分项目来说，BRD加PRD足够，中等项目或小需求可以直接写PRD或UC。此外，文章还提到了产品原型/交互稿的重要性，强调了做到刚刚好就够，避免过度追求完美。另外，产品原型需要明确的阅读线索，以便开发者能够准确理解。最后，文章指出了其他各种因需创建的文档形式，强调了文档在明确目的和保证沟通效率的前提下的重要性。总的来说，本文通过介绍产品文档的种类和使用方法，为产品经理提供了实用的指导，帮助他们更好地理解和应用产品文档的重要性和作用。
仅可试看部分内容，如需阅读全部内容，请付费购买文章所属专栏
《邱岳的产品手记》，新⼈⾸单¥59
《邱岳的产品手记》，新⼈⾸单¥59
立即购买
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
登录 后留言
全部留言(17)
- 最新
- 精选
听天由己感谢分享，今天的文章是产品经理的重要工作之一，很多时候我们会忘了将自己最重要的产品打磨好，交付给相关人员，这也是做事的态度。 我有两点想法： 一是用户用例，个人理解是将与用户交互的整个流程和逻辑全部理清楚，也就是偏向于在场景中解决问题，这一部分也是为了让我们更快速地测试与上线准备。 二是产品原型与交互稿上次经提醒，我现在正在用印象笔记拍照记录，特别方便，能够看到自己的努力转换为图片记录很有成就感，当然这里也需要我们明确地标出规则与说明，方便日后交流。作者回复: 学以致用，👍
2018-01-096
向茂遥一直写不出让开发同学满意的需求文档，可能就是自己太注重形式了。 二爷，文末的链接挂了呀…作者回复: http://heidixie.lofter.com/post/b8226_168d4b5 btw. Heidi 博客上的其他文章也值得一读
2018-01-095
Bonnie Mei不管是原型上面没写完善，产品写漏了；还是原型上面写了，开发做漏了。到了这种情况下去讨论谁的锅，真心觉得这感觉很不爽……作者回复: 嗯，就是最好不讨论，产品争取把锅背了就好
2018-01-143
拾叔我们公司产品经理分为金融产品经理和系统产品经理，一般金融产品经理负责业务方案的设计，也就是撰写MRD和BRD，而系统产品经理写PRD，并负责推进项目的上线，系统产品主要是面向后台系统，所以基本没有涉及到页面设计，文档核心在于后台系统的交互流程，系统交互都是通过接口交互，所以我觉得文档模板不能一味的套用，要看实际的项目，如果是toC前端业务，直接demo加说明文字甚至类似二爷说的线框图就可以搞定，而像我们公司的这个后台的，就不需要demo，直接流程加文字说明。作者回复: 后端业务通常都重流程中逻辑，页面和交互流程其实就不应该是文档中的核心部件
2018-01-103
aichideniuniu二爷，文中提到「如果项目是重交互，以用户场景驱动的话，我会推荐用 UC 来组织 PRD」，这意味着还有别的驱动方式？我一直以为都是以用户场景驱动的作者回复: 重逻辑和重系统规则的可能不会用 UC，有可能会写特性描述。
2019-05-051
晓小文章里分享的产品原型标注非常棒，一目了然。 这几类文档在很多文章中都介绍过，虽然网上搜索有大量模板，但感觉质量参差不齐。真正想找一份能够提供给团队参考学习的不容易。 信任二爷分享的文档质量，希望二爷能够分享一下本文中提到的MRD、BRD、PRD、UC、FSD文档的范例，理论看来终觉浅，欲取真经需范例。 先谢过了，盼复。作者回复: 系统性地去讲解和培训这些文档类型是挺难的事情，可能要有一个我们都在同一语境下的项目会好一些。不过更好的方式可能还是在实践中去迭代自己
2018-01-131
ure二爷，请教一下用例里面的主流程事件和分支流程事件是不是合在一起后就是一个完整的业务流程图？那如果是的话，主流程和分支流程是画图表达好一些还是直接文字按步骤描述？作者回复: 我一般是文字为主，图为辅助
2018-02-28
时间之树“完美主义倾向很多时候来源于对目标的不清晰和对真正产品价值思考的逃避”，非常赞同这句话，我之前就一直在追求事事完美，还自以为是产品经理必备的素质，其实在很多情况下，浪费了大量时间。现在越来越觉得，对目标的定义，对价值的思考，对投入产出比的把握，才是产品经理的核心价值。 对于各种文档也是，能做到有效沟通即可，当然除了内容，让别人看着顺畅和舒服也是需要考虑的。作为产品经理，要时刻提醒自己，不要为了形式而忘了目标。2018-01-1015
GeekAmI我们一般手画草稿加口述需求2018-01-1017
Milk喝了牛奶Heidi就是雨宏啊～ 她的各种文档，流程简直牛逼到爆炸2018-05-206
收起评论