从0开始做增长
刘津
前宜人贷用户增长团队负责人,《破茧成蝶》系列图书作者,UGDlab创始人
立即订阅
5495 人已学习
课程目录
已完结 43 讲
0/4登录后,你可以任选4讲全文学习。
课前必读 (5讲)
开篇词 | 人人都是增长官
免费
01 预习 | 增长小白如何“弯道超车”?
02 预习 | 如何理解“增长”?
03 预习 | 不同职能如何做好增长?
04 预习 | 做增长如何处理职能间的矛盾?
模块一 | 找对目标,增长路上不迷失 (3讲)
05 | 正确目标找不对,天天加班也枉然
06 | 活学活用北极星指标
07 | OKR如何助力增长?
模块二 | 学会洞察,菜鸟也能做好增长 (11讲)
08 | 不懂用户调研?那就对了!
09 | 调研目标:在差异性洞察中找到爆破点
10 | 数据分析:在“花式对比”中发现玄机
11 | 用户分类:围绕北极星指标细分人群
12 | 用户访谈:像侦探一样寻找破案线索(上)
13 | 用户访谈:像侦探一样寻找破案线索(下)
14 | 提炼用户差异,发现增长契机
15 | 挖掘产品优势,打破增长瓶颈
16 | 定位营销差异,抢占用户心智
17 | 一级方向:找到增长爆破点
18 | B端产品如何调研?
模块三 | 发现“四两拨千斤”的增长机会 (8讲)
19 | 全局规划增长机会
20 | 统筹全局的用户增长地图
21 | 案例解析:定义关键增长指标
22 | 正负双向洞察,找准切入点
23 | 二级机会:制定增长策略
24 | 为一家濒临破产的公司制定增长策略(上)
25 | 为一家濒临破产的公司制定增长策略(中)
26 | 为一家濒临破产的公司制定增长策略(下)
模块四 | 打造百发百中的增长闭环 (8讲)
27 | 为什么指标数据怎么优化都不提升?
28 | 案例解析:打造增长闭环(上)
29 | 案例解析:打造增长闭环(下)
30 | 案例解析:唤醒沉睡用户(上)
31 | 案例解析:唤醒沉睡用户(下)
32 | 没有分解,就无缘增长
33 | 四个要点颠覆传统需求文档
34 | 三级落地:无限场景应用
模块五 | 小小实验让增长稳稳落地 (2讲)
35 | 手把手教你设计一次成功的实验(上)
36 | 手把手教你设计一次成功的实验(下)
模块六 | 巧妙复制让增长遍地开花 (2讲)
37 | 积少可成多,别针换别墅
38 | 四级延续:增长组件库案例
模块七 | 增长总结 (1讲)
39 | 以用户为中心增长
增长加餐 (2讲)
预习答疑 | 你需要一张思维导图吗?
增长导航图 | 增长专栏的知识架构是怎样的?
尾声 (1讲)
尾声 | 结束意味着新的开始
从0开始做增长
登录|注册

33 | 四个要点颠覆传统需求文档

刘津 2019-06-26
你好,我是刘津。
前面我们学习了精益闭环的思路,也讲解了不少案例。其实精益闭环的思路可以应用在各种事项上,今天我们就来讲解一个有意思的延伸应用的场景——需求文档。
“写需求文档”这件事,如果用精益闭环的思路来做,会有怎样的效果呢?现在你可能还想不明白,不过没关系,我想先从一个问题引入。
在工作中,你可能经常要接触“需求文档”,可你喜欢写、喜欢看需求文档吗?我想你的答案是否定的。
为什么会这样呢?这是因为常规的需求文档就像一本厚厚的遥控器使用手册,看起来很专业,但是你宁可自己去试着摆弄、探索各种功能按钮,也不会愿意一页一页地读下去。除非实在是遇到了搞不定的问题,你才会从使用手册里有针对性地寻找相关内容。
同样的,在实际工作中,很多研发人员也会更愿意看图文并茂的原型说明(原型图是需求文档的部分表现形式,不能代表需求文档),而不是一堆干巴巴的文字。

我们为什么需要需求文档?

但是,需求文档又十分的重要。
如果需求文档写不清楚,产品经理就无法向设计师和研发人员传达具体的要求,也就是说这会让设计师和研发人员不知道该做些什么。需求文档其实可以看作是产品经理与设计师、开发人员之间的一种“协议”,或者说是“契约”,可以约束双方。而且,后面在进行上线前的测试时,需求文档也会被用做产品质量验收的衡量标准之一。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《从0开始做增长》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(5)

  • 言知
    打卡
    2019-07-11
    2
  • Dimple
    第一次用听的方式来看增长课,全称让我不敢分心去做笔记,因为一分心就错过重点。

    需求文档这部分,我真的很深刻,最近在做一个功能,光是需求文档,我就看了差不多大半天,还没看出个大概来。哦,对了,我是一名开发,是需要看需求文档的人。

    我拿到的需求文档,真的就如文中说的,只有上游的朋友才能看懂,下游的像我这样的,能看懂,但是一到落地的时候,就一头雾水。以致于现在的我,做需求都是左右代码,右手文档,做一块对一块;遇到需要交互的,还得经常拉人讨论,很多时候功能写完了,发现还不符合要求,真的是很扎心。

    看了这节课,需要好好自己先探讨一番,然后和同事好好聊聊,感谢老师

    作者回复: 谢谢你的心得,我开始以为写好需求文档是为了帮助上游人员想清楚,不提无意义的需求。看了你的心得我才想到对于下游的工程师来说,如果不了解前因后果很容易产生理解上的歧义,辛苦半天还达不到要求。确实扎心了。感谢你的分享也帮助我想的更多🤝

    2019-07-06
    2
  • JohnnyB0Y
    看到需求文档,我要先把里面的点一个一个拆分出来,然后把有疑问不合理的地方拿去问产品经理。🤪

    作者回复: 把知识化为行动,很赞👍

    2019-07-21
    1
  • Derrick
    1.不是每个需求都需要拆解验证的吧,是否有必要?并且埋点太多,还有可能影响性能?
    2.有些改动某个环节,同时会使得很多指标同事变化。

    作者回复: 不是每个需求都要拆解,视情况而定。也不需要太多埋点,看主要数据即可。

    2019-11-25
  • 阿兰ALan
    人人都是产品经理 门槛太低 真正愿意做好的不多见
    2019-11-12
收起评论
5
返回
顶部