人人都是产品经理2.0——8
第八章：成长：规划与迭代
8.1好产品步步为营
成功的产品都是相似的，因为每个环节、每一步都要做对，而失败的产品各有各的不同，因为任何一环出问题都会垮掉。
8.2规划：只看最短和最长
一个产品经理在做产品三五年之后，不可避免地要碰到写规划这件事，在快速变化的互联网行业里，规划到底该怎么做才有实际意义？、
规划通常会有业务规划和产品规划两种，字面意思看，产品规划只需要讲清楚产品要做什么，而业务规划要大于产品规划。
业务规划可以包含MRD里的所有内容，但他更加强调“未来几步怎么走”，就像一名优秀的棋手，会多算几步，更通俗的说：吃着嘴里的，看着碗里的，想着锅里的。
一句话的业务定位：如果一句话说不清楚，那就说明定位还不够准确，还需要反复想清楚。这句话通常也会表现为产品的Slogan，比如小红书的“全世界的好东西”，微信的“一个生活方式”，以及陌陌的“总有新奇在身边”。
一个业务模型：包括这个业务内容分为哪些模块，彼此之间有什么关系，与产业链中各个角色怎么配合，如何平衡各方的利益，自己如何赚钱等。
三五个业务关键点：接下来的一段时间，主攻的几个业务难点是什么。
8.2.1 从规划向上看战略
长期的规划即战略，他是一种从全局考虑，谋划实现全局目标的规划。一个战略就是设计用来发展核心竞争力、获取竞争优势的一系列综合的约定和行动。选择一种战略，公司即在不同的竞争方式中做出了选择，从这个意义上说，战略选择表明了这家公司打算做什么，以及不做什么。
8.2.2 通过提问把别人干翻
先说说抢资源时如何提问，这种事儿通常发生在规划PK会上，因为大公司人当事多、听以选择不做什么比决定做什么更重要，于是每隔一段时间，就会有一次产品和业务规划的PK会、这个会，和第o3章谈到的产品概念筛选及第07章谈到的立项前的评审、在实际***作中有可能合并，因为目的和参与者很类似。会上公司会决定接下来的资源投向，参与宣讲的就是每个产品和业务的负责人。
8.2.3 提升规划能力的实践
下面分享一个淘宝某些团队的简单实践。
>>让产品团队每个人做一份自己产品的规划，规划周期可以限定为3个月。重点是每个月要拿出1天时间，每个人轮流宣讲，听众是团队其他人。
>>每个人讲完以后，听众轮流说一点"好"与一点"可以更好"(其实就是不好的委婉说法)，不许重复。可以针对规划本身，也可以针对PPT制作、
演讲技巧等
>>主讲人自己在白板上记录大家的发言，等所有人发言完毕后统一进行回复和讨论，会后优化产品规划PPT以供下次讨论
一般半天时间(4小时计)可以讨论3个人的规划，假设是一个6个人的团队，一天时间正好全部讨论完。最终毎份规划可以得到5点好，与5点可以更好。全组就能得到30点好，与30点可以更好。相信3到6个月下来，每个人的产品规划PPT演不能力都会有显著的提升。
熟练之后，对现场点评的内容还可以进行约定和细分，比如从产品规划的Why.What.How几个层面分别给出评价。
还有一个小技巧如果团队成员比较温和，不愿意互相批评，可以用评选最优评论员与最差评论员并适当奖惩的措施来加以刺激。
这种在实战中互相学习的模式，可以推广到"如何写出--份好的PRD""如何做屯品分析。等诸多产品经理技能提高目标，成败不论，贵在坚持。
8.3 迭代：在理解敏捷
说完规划再说迭代。
提到迭代。一定绕不开敏捷这个词。敏捷是一个偏技术的概念，是指以用户的需求变化为核心，采用循序渐进的方法进行软件开发。敏捷最重要的不是那些具体方法论，反而是底层的价值观、***和原则。对此先说说自己的理解，然后再分享一些实践。
8.3.1 价值观、***与原则
>>沟通
团队中绝大多数的问题、问五次为什么之后，都会归结于人的问题，或沟通的问题，团队配合过程中，开始就约定好明确的。沟通计划和沟通原则是很有必要的，比如"工作日每天18点开站立会议.最新信息及时同步给相关人，不要藏着，掖着"等具体约定背后的目的，是要实现团队成员之间真正的互相信任、互相认可。
>>简单
简单强调一切按需，遵循的是Less is more(少做就是多做)原则，随着技术发展，各种基础设施越来越完善，有很多任务都可以由更小的团队来完成。小团队在做产品时，要努力做一个爆一个，不要堆砌功能。在团队管理、文档、流程等方面也要力求简单，切忌为了显得。正规。而增加一些不必要的规范。
>>反馈
及时获取反馈，用反馈来拥抱变化。阿里的价值观里面有一条。拥抱变化。，让所有人印象深刻。因为我们所在的这个行业实在变化太快，只有适应变化才能够生存下去，及时变化的前提是不断地收到各种反馈，所以信息透明、共享是整个团队必须做到的。Teambition公司的前台有一块很大的屏幕，实时展示整个公司的各种运营数据，供全公司同事基至外部参观者随时了解，这种信息公开的力度可不是每个企业都能做到的.
勇气
不怕犯错，勇于尝试。在一个新兴行业里，怕犯错就什么都做不了。
谦逊
承认自己的无知，也就是互联网行业很重要的一个特点，他来自“求援”思维。我们经常向专家求援，甚至向用户求援，力争把对方智慧、能力榨取出来，为产品做贡献。
8.3.2 敏捷项目管理的实践
Scrum关键概念的理解
>>团队角色
PO通常是产品经理，要对各种利益相关方负责。
SM充当教练的角色，一般由对流程、方法论比较熟悉的人来担当，不建议这个角色和PO重叠。
Team有核心成员组成，其中的某一个人是可以担任SM的。
>>关键产出物
ProduceBacklog指出较长期的产品任务表。
SprintBacklog在Scrum里指当前这个迭代里面的任务点。
Burndown Chart是燃尽图，用来监控任务是不是在按期推进。
>>重要的会议
首先是每个迭代的计划会，经常和需求评审会合并，主要目的是明确任务，以及评审这个迭代里需要做的功能。
每天的站立会议，是重要的信息同步手段。
功能评审会用来评估做出来的东西是不是想要的。
回顾会的目的是为了过程改进，因为Scrum和敏捷最核心的思想就是不断优化，以优化出一个最适当前团队的方法论。
>>日常管理工具
看板是一个非常重要的实用工具，很多公司的办公区里都会有，在硅谷创新公司里也被广泛应用。
>>
8.4 天下武功 唯快不破
每个产品都要通过不断的规划和迭代一步步成长，而互联网产品的特殊之处在于成长f导格外快几个月以内，就能亲历一个互联网产品"看他初乍到，看他起高楼、看他宴宾客，看他楼塌了的全过程，这可比以几十年一个变化周期的传统行业刺激多了
做产品，成功当然最好，但最差的不是失败，而是半死不活地一直拖着，其间的机会成本会大到很难负担得起。互联网产品追求快速，首先要强调研发周期的缩短和迭代频率的加快，因为迭代周期越短、同样时间段内获得的尝试次数越多，用来纠正和改进的机会也就越多。
8.4.1 互联网速度到底有多快
在产品早期的验证阶段，团队灵活，流程简单，还没有太多的用户，最能体现出勺.联网速度。有的产品从发现问题或机会，到讨论出方案，再到上线，大约可以做到两二个小时，甚至不到一个小时。
8.4.2 烧钱是为了抢时间
烧钱似乎是互联网行业很有特色的一个发展策略。能理解快的重要性，就不难理解烧钱的目的——抢时间。对创业团队来说，抢时间尤其重要。
一位创业的朋友在分享运营策略时，谈到"单用户成本"的算法计算一款产品的单用户成本时，要纳入整个公司的运营成本(含人员等成本)，而不是只计算该产品的推广费用。
8.4.3 省时间的低成本验证
单纯为了速度而横冲直撞，是不可取的，也是得不偿失的。那么，如何合理而科学地加快速度呢?答案就是低成本验证。低成本验证的理念，本质上和迭代的思路完全一致在一个快速变化的环境下，不断地用最少的时间、成本去获取市场反馈，不断修正前进方向。
8.5与用户一起成长
产品除了要通过规划和迭代，面对快速成长的问题，还需要在更大的时间尺度，比如5到10年上，考虑用户的成长。经过这么大的时间跨度，产品的用户往往已经不再是最初那批人，产品将面临这样一个选择是跟着原有用户走，还是服务一批新用户？
举一个校园社交产品的例子。随着最早的一批学生用户毕业，这款产品是应该转而服务职场人士，还是服务新一批的学生7一些同行观察到了类似的现象一个女性社区，随着用户从小姑娘变成***，几年间最活跃的版面也按照用户的自然成长规律，依次在服饰、装修、婚嫁、孕育之间切换。
事实上，产品往哪里走，并不是由产品经理决定的，而是由产品团队和用户共同决定的，产品与用户在几年时间内已经形成共生的关系，产品影响着用户，用户也影响着产品。
试图决定产品走向的产品经理，实在有些自不量力。
#产品#
8.1好产品步步为营
成功的产品都是相似的，因为每个环节、每一步都要做对，而失败的产品各有各的不同，因为任何一环出问题都会垮掉。
8.2规划：只看最短和最长
一个产品经理在做产品三五年之后，不可避免地要碰到写规划这件事，在快速变化的互联网行业里，规划到底该怎么做才有实际意义？、
规划通常会有业务规划和产品规划两种，字面意思看，产品规划只需要讲清楚产品要做什么，而业务规划要大于产品规划。
业务规划可以包含MRD里的所有内容，但他更加强调“未来几步怎么走”，就像一名优秀的棋手，会多算几步，更通俗的说：吃着嘴里的，看着碗里的，想着锅里的。
一句话的业务定位：如果一句话说不清楚，那就说明定位还不够准确，还需要反复想清楚。这句话通常也会表现为产品的Slogan，比如小红书的“全世界的好东西”，微信的“一个生活方式”，以及陌陌的“总有新奇在身边”。
一个业务模型：包括这个业务内容分为哪些模块，彼此之间有什么关系，与产业链中各个角色怎么配合，如何平衡各方的利益，自己如何赚钱等。
三五个业务关键点：接下来的一段时间，主攻的几个业务难点是什么。
8.2.1 从规划向上看战略
长期的规划即战略，他是一种从全局考虑，谋划实现全局目标的规划。一个战略就是设计用来发展核心竞争力、获取竞争优势的一系列综合的约定和行动。选择一种战略，公司即在不同的竞争方式中做出了选择，从这个意义上说，战略选择表明了这家公司打算做什么，以及不做什么。
8.2.2 通过提问把别人干翻
先说说抢资源时如何提问，这种事儿通常发生在规划PK会上，因为大公司人当事多、听以选择不做什么比决定做什么更重要，于是每隔一段时间，就会有一次产品和业务规划的PK会、这个会，和第o3章谈到的产品概念筛选及第07章谈到的立项前的评审、在实际***作中有可能合并，因为目的和参与者很类似。会上公司会决定接下来的资源投向，参与宣讲的就是每个产品和业务的负责人。
8.2.3 提升规划能力的实践
下面分享一个淘宝某些团队的简单实践。
>>让产品团队每个人做一份自己产品的规划，规划周期可以限定为3个月。重点是每个月要拿出1天时间，每个人轮流宣讲，听众是团队其他人。
>>每个人讲完以后，听众轮流说一点"好"与一点"可以更好"(其实就是不好的委婉说法)，不许重复。可以针对规划本身，也可以针对PPT制作、
演讲技巧等
>>主讲人自己在白板上记录大家的发言，等所有人发言完毕后统一进行回复和讨论，会后优化产品规划PPT以供下次讨论
一般半天时间(4小时计)可以讨论3个人的规划，假设是一个6个人的团队，一天时间正好全部讨论完。最终毎份规划可以得到5点好，与5点可以更好。全组就能得到30点好，与30点可以更好。相信3到6个月下来，每个人的产品规划PPT演不能力都会有显著的提升。
熟练之后，对现场点评的内容还可以进行约定和细分，比如从产品规划的Why.What.How几个层面分别给出评价。
还有一个小技巧如果团队成员比较温和，不愿意互相批评，可以用评选最优评论员与最差评论员并适当奖惩的措施来加以刺激。
这种在实战中互相学习的模式，可以推广到"如何写出--份好的PRD""如何做屯品分析。等诸多产品经理技能提高目标，成败不论，贵在坚持。
8.3 迭代：在理解敏捷
说完规划再说迭代。
提到迭代。一定绕不开敏捷这个词。敏捷是一个偏技术的概念，是指以用户的需求变化为核心，采用循序渐进的方法进行软件开发。敏捷最重要的不是那些具体方法论，反而是底层的价值观、***和原则。对此先说说自己的理解，然后再分享一些实践。
8.3.1 价值观、***与原则
>>沟通
团队中绝大多数的问题、问五次为什么之后，都会归结于人的问题，或沟通的问题，团队配合过程中，开始就约定好明确的。沟通计划和沟通原则是很有必要的，比如"工作日每天18点开站立会议.最新信息及时同步给相关人，不要藏着，掖着"等具体约定背后的目的，是要实现团队成员之间真正的互相信任、互相认可。
>>简单
简单强调一切按需，遵循的是Less is more(少做就是多做)原则，随着技术发展，各种基础设施越来越完善，有很多任务都可以由更小的团队来完成。小团队在做产品时，要努力做一个爆一个，不要堆砌功能。在团队管理、文档、流程等方面也要力求简单，切忌为了显得。正规。而增加一些不必要的规范。
>>反馈
及时获取反馈，用反馈来拥抱变化。阿里的价值观里面有一条。拥抱变化。，让所有人印象深刻。因为我们所在的这个行业实在变化太快，只有适应变化才能够生存下去，及时变化的前提是不断地收到各种反馈，所以信息透明、共享是整个团队必须做到的。Teambition公司的前台有一块很大的屏幕，实时展示整个公司的各种运营数据，供全公司同事基至外部参观者随时了解，这种信息公开的力度可不是每个企业都能做到的.
勇气
不怕犯错，勇于尝试。在一个新兴行业里，怕犯错就什么都做不了。
谦逊
承认自己的无知，也就是互联网行业很重要的一个特点，他来自“求援”思维。我们经常向专家求援，甚至向用户求援，力争把对方智慧、能力榨取出来，为产品做贡献。
8.3.2 敏捷项目管理的实践
Scrum关键概念的理解
>>团队角色
PO通常是产品经理，要对各种利益相关方负责。
SM充当教练的角色，一般由对流程、方法论比较熟悉的人来担当，不建议这个角色和PO重叠。
Team有核心成员组成，其中的某一个人是可以担任SM的。
>>关键产出物
ProduceBacklog指出较长期的产品任务表。
SprintBacklog在Scrum里指当前这个迭代里面的任务点。
Burndown Chart是燃尽图，用来监控任务是不是在按期推进。
>>重要的会议
首先是每个迭代的计划会，经常和需求评审会合并，主要目的是明确任务，以及评审这个迭代里需要做的功能。
每天的站立会议，是重要的信息同步手段。
功能评审会用来评估做出来的东西是不是想要的。
回顾会的目的是为了过程改进，因为Scrum和敏捷最核心的思想就是不断优化，以优化出一个最适当前团队的方法论。
>>日常管理工具
看板是一个非常重要的实用工具，很多公司的办公区里都会有，在硅谷创新公司里也被广泛应用。
>>
8.4 天下武功 唯快不破
每个产品都要通过不断的规划和迭代一步步成长，而互联网产品的特殊之处在于成长f导格外快几个月以内，就能亲历一个互联网产品"看他初乍到，看他起高楼、看他宴宾客，看他楼塌了的全过程，这可比以几十年一个变化周期的传统行业刺激多了
做产品，成功当然最好，但最差的不是失败，而是半死不活地一直拖着，其间的机会成本会大到很难负担得起。互联网产品追求快速，首先要强调研发周期的缩短和迭代频率的加快，因为迭代周期越短、同样时间段内获得的尝试次数越多，用来纠正和改进的机会也就越多。
8.4.1 互联网速度到底有多快
在产品早期的验证阶段，团队灵活，流程简单，还没有太多的用户，最能体现出勺.联网速度。有的产品从发现问题或机会，到讨论出方案，再到上线，大约可以做到两二个小时，甚至不到一个小时。
8.4.2 烧钱是为了抢时间
烧钱似乎是互联网行业很有特色的一个发展策略。能理解快的重要性，就不难理解烧钱的目的——抢时间。对创业团队来说，抢时间尤其重要。
一位创业的朋友在分享运营策略时，谈到"单用户成本"的算法计算一款产品的单用户成本时，要纳入整个公司的运营成本(含人员等成本)，而不是只计算该产品的推广费用。
8.4.3 省时间的低成本验证
单纯为了速度而横冲直撞，是不可取的，也是得不偿失的。那么，如何合理而科学地加快速度呢?答案就是低成本验证。低成本验证的理念，本质上和迭代的思路完全一致在一个快速变化的环境下，不断地用最少的时间、成本去获取市场反馈，不断修正前进方向。
8.5与用户一起成长
产品除了要通过规划和迭代，面对快速成长的问题，还需要在更大的时间尺度，比如5到10年上，考虑用户的成长。经过这么大的时间跨度，产品的用户往往已经不再是最初那批人，产品将面临这样一个选择是跟着原有用户走，还是服务一批新用户？
举一个校园社交产品的例子。随着最早的一批学生用户毕业，这款产品是应该转而服务职场人士，还是服务新一批的学生7一些同行观察到了类似的现象一个女性社区，随着用户从小姑娘变成***，几年间最活跃的版面也按照用户的自然成长规律，依次在服饰、装修、婚嫁、孕育之间切换。
事实上，产品往哪里走，并不是由产品经理决定的，而是由产品团队和用户共同决定的，产品与用户在几年时间内已经形成共生的关系，产品影响着用户，用户也影响着产品。
试图决定产品走向的产品经理，实在有些自不量力。
#产品#
