邱岳的产品手记
邱岳
无码科技产品经理,公众号二爷鉴书作者
立即订阅
9950 人已学习
课程目录
已完结 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的“复杂”图表
尾声:你的快乐是哪一种
【第二季回归】二爷归来,再次扬帆起航
邱岳的产品手记
登录|注册

26 | 写好产品文档的诀窍

邱岳 2018-01-18
“产品文档是产品经理交出的第一个产品。” —— 邱岳
我们之前的两次分享,聊到了产品文档以及图例的类型和作用,当时我说文档也是产品经理设计出来的一种“产品”,所以做好产品文档的诀窍其实跟做好产品的诀窍一脉相承,也讲究用户、场景、目的和体验。接下来我就结合自己的经验,跟你分享写好一份产品文档的诀窍。

1. 明确受众、目的和形式

第一次写产品文档的时候,我拿来文档模板就开始照葫芦画瓢,模板上有什么就写什么,好像只要把模板中所有的空位填满就能写出好文档了。
其实不然,好的产品文档应该有非常强的针对性。就像做产品要先明确用户一样,写产品文档的第一步就是要明确文章的目标受众是谁。知道谁是文档的主要受众或者读者,结合他们的思考维度,才能知道该用什么样的语言、逻辑和形式。
之后,我们是要清楚每个文档的目的,而不是把写文档本身当做目的。去设想一个文档的读者在读之前的状态和读完之后的状态,你希望他能获得什么信息,做出什么决定,以及有些什么后续的动作。
弄清楚受众和目的之后,你就可以判断用什么形式来呈现文档,是静态的产品原型,动态的 Demo,一张流程图,幻灯片还是一篇 PDF 或一封邮件,大概是什么长度等等。
比如 BRD 通常面向管理层和业务部门,目的一般是要获得支持和授权,申请到足够的资源,那就应该避免说产品实现细节,不要用技术的语言,而是从潜在的市场机会和风险解释要做什么,文档的形式可能是幻灯片。
幻灯片也分阅读型和演讲型的,阅读型要把逻辑写下来,演讲型则写提纲或放图,通常要准备两份,因为很多时候是既要做演讲,也有时候是发邮件的。
而 PRD 通常是面向工程师,让他们知道要做什么,以及为什么做,进而驱动他们设计和实现具体功能。PRD 通常是写成文档,PDF 或者写在 Wiki 上(建议不要用 Word,很多工程师如果不用 Windows 系统,排版会失控),工程师不喜欢长篇大论,最好能图文并茂,如果有机会能给现场给他们讲解一下,就更好了。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《邱岳的产品手记》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(15)

  • 靡小泡
    二爷已经第三次提到媳妇了,这说明做产品,有一个媳妇是多么重要🤔
    2018-03-08
    24
  • 张伟
    对二爷写过的文档好奇,二爷可否附件一版与大家共享。

    作者回复: 写文章的时候找来着,但因为都涉及到各种公司信息,很难脱敏。

    2018-01-18
    11
  • 牧羊犬
    待了几家创业小公司,好像产品经理都没有写文档(单独的需求文档)的习惯,而只是将所有需要注意的内容都备注在原型上,一般开发也就直接根据原型图来开发,大公司的需求文档都是单独写的吗?不太清楚其他公司的一些项目流程
    2018-01-18
    7
  • 刘祯
    现在都在强调产品能力,把每一件事情都要当作产品去思考与运作,这种思维方式本质上还是共情能力,我们有时很难跳出自己的框架去交流沟通,习惯于站在批判者的角度去讨论其他产品利弊,却忽略了自己的呈现方式。

    入行至今也十几万字的产品文档,现在其实还是不够细致,在评审会议后,梳理与统一容易遗漏。就像自己的工作那样,如果不注意总结或是改进,我们很难有真正的进步。
    2018-01-18
    7
  • 张星彩
    可以分享一个需求文档么,如果设计公司敏感信息,可以删减掉,超想看下
    2018-01-18
    5
  • Dylan
    总结了一下文章要点:
    1. 先明确受众与需求,定展现形式
        1. 去设想一个文档的读者在读之前的状态和读完之后的状态,你希望他能获得什么信息,做出什么决定,以及有些什么后续的动作
    2. 多交代“为什么”
    3. 不断拆解流程和异常情况
        1. 细致的用例+异常情况
    4. 先写厚,再写薄
    5. 冷静期发酵
    2018-07-05
    4
  • 嵩松
    这和律师写复杂一点的协议有很多共通之处,我也很希望留一个晚上发酵一下,但很多时候时间不允许,上个厕所再回来也有效果。写这种协议是成长最快的时候。

    作者回复: 专业!

    2018-01-20
    2
  • 陈康(三林)
    创业小公司业务调整快,人员也少。文档没有成文,需求的表现是sketch和思维导图
    2018-01-20
    2
  • Henglu
    二爷什么时候开始分享一下,数据对产品设计的影响。
    2018-01-25
    1
  • GeekAmI
    我已经看到二爷文档的样子
    2018-01-18
    1
  • 魔幻的季节
    学习了二爷三篇如何写好文档,现实中我有这样的困惑。FSD是需要怎样的颗粒度,如果需要做到数据库设计和接口定义,我在新团队做一些功能优化升级时往往需要大量阅读之前的系统设计,在文档不全的队伍中甚至需要找IT负责人才可以解决,否则往往写了也是无法被执行。但整个过程效率是非常低的。请问这种情况下,有更好的解决方案吗。
    2019-12-05
  • 李沛欣
    很多时候写东西,一心只想快点写完,不忍回首发酵修正,这样对文档写作能力的提升有害无益。
    2019-02-13
  • javaadu
    这个做事习惯非常棒,赶早不赶晚,如果拖延到deadline再交付结果,就少了中间的发酵期和二次加工
    2018-08-26
  • 空空
    二爷为什么不举个模板例子呢,这样会好理解很多。通偏光这样两,其实很不形象。比如atm机那个例子,用个脑图也好啊。有个您之前做个的产品文档模板就更好了,敏感信息可以删掉或者打马赛克。希望可以得到反馈,谢谢二爷。
    2018-07-31
  • 阿兰不是图灵
    PRD用什么工具写呢
    2018-07-25
收起评论
15
返回
顶部