从0开始做增长
刘津
前宜人贷用户增长团队负责人，《破茧成蝶》系列图书作者，UGDlab创始人
立即订阅
5513 人已学习
课程目录
已完结 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)
Yeon打卡2019-07-11 2
Dimple第一次用听的方式来看增长课，全称让我不敢分心去做笔记，因为一分心就错过重点。
需求文档这部分，我真的很深刻，最近在做一个功能，光是需求文档，我就看了差不多大半天，还没看出个大概来。哦，对了，我是一名开发，是需要看需求文档的人。
我拿到的需求文档，真的就如文中说的，只有上游的朋友才能看懂，下游的像我这样的，能看懂，但是一到落地的时候，就一头雾水。以致于现在的我，做需求都是左右代码，右手文档，做一块对一块；遇到需要交互的，还得经常拉人讨论，很多时候功能写完了，发现还不符合要求，真的是很扎心。
看了这节课，需要好好自己先探讨一番，然后和同事好好聊聊，感谢老师作者回复: 谢谢你的心得，我开始以为写好需求文档是为了帮助上游人员想清楚，不提无意义的需求。看了你的心得我才想到对于下游的工程师来说，如果不了解前因后果很容易产生理解上的歧义，辛苦半天还达不到要求。确实扎心了。感谢你的分享也帮助我想的更多🤝
2019-07-06 2
JohnnyB0Y看到需求文档，我要先把里面的点一个一个拆分出来，然后把有疑问不合理的地方拿去问产品经理。🤪作者回复: 把知识化为行动，很赞👍
2019-07-21 1- Derrick1.不是每个需求都需要拆解验证的吧，是否有必要？并且埋点太多，还有可能影响性能？
2.有些改动某个环节，同时会使得很多指标同事变化。作者回复: 不是每个需求都要拆解，视情况而定。也不需要太多埋点，看主要数据即可。
2019-11-25 - 阿兰ALan人人都是产品经理 门槛太低 真正愿意做好的不多见2019-11-12
收起评论