邱岳的产品手记
邱岳
无码科技产品经理,公众号二爷鉴书作者
立即订阅
9922 人已学习
课程目录
已完结 48 讲
0/4登录后,你可以任选4讲全文学习。
开篇词 | 产品经理的世界没有对错
免费
01 | 验证码是个好设计吗?
02 | 产品经理工具指南
03 | 产品案例分析·Trigraphy的设计哲学
04 | 如何当好AI时代的产品经理?(学习篇)
05 | 如何当好AI时代的产品经理?(实践篇)
06 | 产品案例分析 · The Guardian的文本之美
07 | 关于需求变更(上):需求背后的需求
08 | 关于需求变更(下) : 化变更于无形
09 | 产品案例分析:Hopper的“人工智能”
10 | 产品被抄袭了,怎么办?
11 | 如何借鉴灵感?
12 | 产品案例分析:LabRdr的设计实验
13 | 无用却必要:产品规划(上)
14 | 留白与节奏:产品规划(下)
15 | 产品案例分析:Mimo与Learn Python的导学之趣
16 | 在内部产品中找到产品经理的价值
17 | 产品经理如何获得非权力性的影响力?
18 | 产品案例分析:WWF Together的情怀设计
19 | 产品经理如何与开发打交道(上):打破思维的边界
20 | 产品经理如何与开发打交道(下):合作与共赢
21 | 产品案例分析:Fabulous的精致养成
22 | 产品经理的图文基本功(上):产品文档
23 | 产品经理的图文基本功(下):产品图例
24 | 产品案例分析:PathSource的混乱与直观
25 | 产品世界的暗黑模式:操纵的诱惑
26 | 写好产品文档的诀窍
27 | 产品案例分析:Quartz&Hooked的对话式交互
28 | 产品分析的套路(上):谁是利益相关者?
29 | 产品分析的套路(中):解决什么问题?
30 | 产品案例分析:Primer的扑克牌交互
31 | 产品分析的套路(下):如何出解决方案?
32 | 从受众规模、需求频率和强度出发:排定需求优先级的方法(上)
33 | 产品案例分析:Arts & Culture 的架构之美
34 | 价值曲线分析:排定需求优先级的方法(下)
35 | 答疑时间:关于产品经理的12个问题
36 | 产品案例分析:解读知识星球
37 | 如何做好需求评审(上):需求评审不只是一次会议
38 | 如何做好需求评审(下):在评审中控住全场
39 | 产品案例分析:SeatGeek的订票设计
40 | 新年给产品经理的几碗鸡汤
41 | 产品经理的项目管理心得
42 | 产品案例分析:Unread的阅读体验
43 | “玩”的力量:从游戏设计中学习产品设计(上)
44 | “玩”的启示:从游戏设计中学习产品设计(下)
45 | 产品案例分析:Chartistic的“复杂”图表
尾声:你的快乐是哪一种
【第二季回归】二爷归来,再次扬帆起航
邱岳的产品手记
登录|注册

22 | 产品经理的图文基本功(上):产品文档

邱岳 2018-01-09
“没有内容的形式和没有形式的内容,都是不能存在的;即使存在的话,那么,前者有如奇形怪状的空洞的器皿,后者则是虽然大家都看得见、但却不认为是实体的空中楼阁。”
——(俄)别林斯基《论人民的诗第一篇》
产品经理的大部分工作是无形的,比如思考、分析、协调,在日常的工作中,我们能交出来的、唯一看得到摸得着的产出,就是各种各样的产品文档或产品原型,所以才会有人戏称产品经理就是写文档或做 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/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《邱岳的产品手记》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(14)

  • 时间之树
    “完美主义倾向很多时候来源于对目标的不清晰和对真正产品价值思考的逃避”,非常赞同这句话,我之前就一直在追求事事完美,还自以为是产品经理必备的素质,其实在很多情况下,浪费了大量时间。现在越来越觉得,对目标的定义,对价值的思考,对投入产出比的把握,才是产品经理的核心价值。
    对于各种文档也是,能做到有效沟通即可,当然除了内容,让别人看着顺畅和舒服也是需要考虑的。作为产品经理,要时刻提醒自己,不要为了形式而忘了目标。
    2018-01-10
    9
  • 刘祯
    感谢分享,今天的文章是产品经理的重要工作之一,很多时候我们会忘了将自己最重要的产品打磨好,交付给相关人员,这也是做事的态度。

    我有两点想法:

    一是用户用例,个人理解是将与用户交互的整个流程和逻辑全部理清楚,也就是偏向于在场景中解决问题,这一部分也是为了让我们更快速地测试与上线准备。

    二是产品原型与交互稿上次经提醒,我现在正在用印象笔记拍照记录,特别方便,能够看到自己的努力转换为图片记录很有成就感,当然这里也需要我们明确地标出规则与说明,方便日后交流。

    作者回复: 学以致用,👍

    2018-01-09
    5
  • 向茂遥
    一直写不出让开发同学满意的需求文档,可能就是自己太注重形式了。
    二爷,文末的链接挂了呀…

    作者回复: http://heidixie.lofter.com/post/b8226_168d4b5

    btw. Heidi 博客上的其他文章也值得一读

    2018-01-09
    4
  • Milk喝了牛奶
    Heidi就是雨宏啊~ 她的各种文档,流程简直牛逼到爆炸
    2018-05-20
    3
  • GeekAmI
    我们一般手画草稿加口述需求
    2018-01-10
    3
  • 拾叔
    我们公司产品经理分为金融产品经理和系统产品经理,一般金融产品经理负责业务方案的设计,也就是撰写MRD和BRD,而系统产品经理写PRD,并负责推进项目的上线,系统产品主要是面向后台系统,所以基本没有涉及到页面设计,文档核心在于后台系统的交互流程,系统交互都是通过接口交互,所以我觉得文档模板不能一味的套用,要看实际的项目,如果是toC前端业务,直接demo加说明文字甚至类似二爷说的线框图就可以搞定,而像我们公司的这个后台的,就不需要demo,直接流程加文字说明。

    作者回复: 后端业务通常都重流程中逻辑,页面和交互流程其实就不应该是文档中的核心部件

    2018-01-10
    2
  • 疯子
    目前我从事的项目主要都是B端的工具类产品,感受非常深刻的的是,每次写需求文档我都是单个功能来些写,特别是一些体量大的需求,不可能整体写完prd,再来出原型,本身周期长很多东西会漏掉,所以我都是单个功能出uc后,出响应界面的原型,然后再反过来看uc有没有没考虑到的情况,
    prd大概包括
    1,交代使用该功能的背景,包括介绍用户是谁以及正常场景下的用户心理和期望目标
    2,操作步骤闭环流程,其中包括前置条件和后置结果
    3,异常情况的考虑
    2018-04-23
    1
  • Bonnie Mei
    不管是原型上面没写完善,产品写漏了;还是原型上面写了,开发做漏了。到了这种情况下去讨论谁的锅,真心觉得这感觉很不爽……

    作者回复: 嗯,就是最好不讨论,产品争取把锅背了就好

    2018-01-14
    1
  • 晓小
    文章里分享的产品原型标注非常棒,一目了然。
    这几类文档在很多文章中都介绍过,虽然网上搜索有大量模板,但感觉质量参差不齐。真正想找一份能够提供给团队参考学习的不容易。
    信任二爷分享的文档质量,希望二爷能够分享一下本文中提到的MRD、BRD、PRD、UC、FSD文档的范例,理论看来终觉浅,欲取真经需范例。
    先谢过了,盼复。

    作者回复: 系统性地去讲解和培训这些文档类型是挺难的事情,可能要有一个我们都在同一语境下的项目会好一些。不过更好的方式可能还是在实践中去迭代自己

    2018-01-13
    1
  • 辣酱
    邱老师感觉很累啊,注意休息啊……
    2018-01-12
    1
  • aichideniuniu
    二爷,文中提到「如果项目是重交互,以用户场景驱动的话,我会推荐用 UC 来组织 PRD」,这意味着还有别的驱动方式?我一直以为都是以用户场景驱动的

    作者回复: 重逻辑和重系统规则的可能不会用 UC,有可能会写特性描述。

    2019-05-05
  • Dylan
    你表达清楚,说明其逻辑为直接目的,同时我今天也学习了一些文档种类,感谢分享
    2018-06-30
  • winehouse_1989
    比如重操作的 To C 产品可能需要交互流程描述和线框图,而 To B 的产品可能注重的是概念模型和业务流程。
    2018-03-28
  • ure
    二爷,请教一下用例里面的主流程事件和分支流程事件是不是合在一起后就是一个完整的业务流程图?那如果是的话,主流程和分支流程是画图表达好一些还是直接文字按步骤描述?

    作者回复: 我一般是文字为主,图为辅助

    2018-02-28
收起评论
14
返回
顶部