人人都是产品经理-6
功能：细化与打包
6.1一个功能的DNA
俗话说，产品经理推动工程师实现功能的三宝：竞品已搞，老板想要，开发量小。如果不行，再上杀招，求求你了好不好。在本章中，主要展
开说三点：评估价值，成本评估和功能分类。
更进一步的说可以总结为两点：
>>价值由产品功能背后的用户需求（问题）决定
>>成本由产品功能（解决方案）决定
实现成本低，或者对应需求的价值高，这两个条件中的任一个，都不能单独作为决定趋势线一个功能的理由。必须结合这两个条件，综合考量
功能的性价比。理论上，性价比高的功能优先级也就高，必须先做。
性价比=价值/成本
不过实际操作中，还需要考虑功能的分类。
6.1.1功能的价值和判断
6.1.1功能的价值判断
先说说对某个功能进行价值判断的流程。
>>参照"产品原则。里"目标。部分的定义，明确当前产品最看重的指标是什么可以是数字化的KPI,比如注册用户数达到10万，也可以是某些关
健结果，比如。建立起线上自动化的专家入驻全流程。。如果有多个指标，则需要对这些指标加权合并2.
>>考察每个功能点实现后，对上述指标的帮助大不大。如果大，则这个功能的价值就大，因为每个产品不同时期的指标不同，所以评判各个功
能价笸的标准也各有差异。通常用半定量的方式来衡量、比如最简单的大、中、小，或者5.4.3.2.1等评分标准。
>>广度：潜在用户数*单用户价值
简中来讲，广度对应着潜在用户数，即一个产品将来可能覆盖的用户群体有多大。
不同产品、不同功能的定位，直接决定其可能覆盖的潜在用户数会有差异，有时苌至相系一个或多个量级。
同样是面向出行这一需求，如果是打车应用，覆盖的潜在用户数可能是几个亿，如果是代驾应用，因为要求用户有车且没法开，可能覆盖的潜
在用户数最多只有几百万，两者相差两个量级，同样是餐饮服务，日常快餐和只接婚宴，潜在用户数的差距也很大。
同等条件下，我们肯定愿意做潜在用户数多的产品功能。但是，潜在用户数不是唯一的因素，、有一些产品虽然潜在用户人数很少，但是也可
以做，因为它覆盖的这些用户，·单用户价值"非常高。典型的例子就是银行的VIP业务，从普卡、银卡、金卡、白金卜到钻石卡，以及再高级一点
的私人银行，用户数越来越少、但一个高级用户的资产少则几千万，多则几个亿，可以抵上几千几万个初级用户。
单用户价值这个词，在不同行业能找到不同的说法。比如，电商行业的，客单价，是指用户平均每次消费花多少钱；游戏行业和运营商的，
ARpU值。(av·rage revenue peruser)，是指平均每个用户在单位时间内给公司带来的收入；而对于社交应用，对应的说法也许是活跃度。
从广度的角度，“潜在用户数*单用户价值”可以用来判断产品对应的市场容量、也就是第3章提到的产品概念筛选里的天花板。当然，具体操
作时，经常先从某些细分用户切人，再逐步扩大到所有潜在用户。比如，2016年下半年火爆的ofo共享单车，就是先攻高校内部，再扩张到校园外。
>>频度：需求频次"单次复杂度
频度是指需求频次的高低，不同的需求，频次差异会非常大。
有些需求每天都会出现一次苌至多次，比如叫外卖；有的需求每周最多出现一次，比如看电影有的需求也许每个月只出现一次，比如交水电费
、还信用卡有的需求每年出现一、两次，比如车险，出境游等；有的需求葚至有可能一辈子只出现一次，比如结婚。
同等条件下，我们当然更喜欢做频次高的产品功能。我曾负责过天猫积分系统，当时有很多积分相关的消息要开发。在产品的早期版本里，我
做了一些简化买家每次购物产生的积分变动消息，需要先做；而用户每年年底积分过期的提醒，可以缓缓，如果碰到可以先手动解决。但是，有些
需求的频次不是那么高，我们也愿意做。这是因为这些单次需求的复杂度高，而且单价也高，有很大的价值空间可供挖掘。虽说外卖需求的频次比
较高，但每单通常只有20块左右。而婚礼，虽然一辈子只有一次，但背后的需求包含了很多点——拍婚纱照要几万，办酒席要几十万，蜜月旅行要
几万；还需要买一些周边产品，小到喜糖，大到车和房，后者又至少有几百万的潜在市场价值。
通常，频次很高的需求不太可能有太高的单次价值。理由很简单、类似每天一次、每次一万块这种需求，只能存在于极端小众的土豪市场，大
众菁遍没这么强的消费能力。
>>强度不可替代、紧急、持久
强度背后说的就是真实刚需。
个需求是不是真的，是不是刚性，有一个简单的判断原则，就是问自己这样个司题。当你没有做这个产品功能时，用户是不是在设法解决，基至已
经在川某种钡效的方式来解决这个问题?。如果答案是肯定的，那么说明需求真的很强烈。接下角
再给大家讲几个判断的角度。
>>可替代性
可替代性用来说明一个功能是不是很容易被其他功能替代。打个比方，假设你月了家早餐店，一开始技术不太熟练，所以每天早上只能供应包
子这一款单品。做了月个礼拜之后，技术水平提高了，发现早上时间还有富余，可以再做第一款单品。这则有两个选择，一个是馒头，一个是豆浆
，应该怎么选呢?我相信大家都会选择豆浆。
因为馒头和包子是可以互相替代的，豆浆是不可替代的。你会发现，买了包子的人多
常会四处张望，看看旁边有没有卖牛奶、豆浆或其他饮料的，因为包子太干，容易嗟
着。
>>紧急程度
需求紧急程度也可以作为衡量需求强度的判断原则。科学的时间管理建议我们庄该更有计划性，尽量避免紧急的事情发生，但现实中的确有
这样的需求，真的是受窑种客观情况所限，必须马上动手实施或调整计划。比如，极个别用户的负面评价、弓起了广泛的舆论风波，必须要在产品
上做出响应；营销方案已经开始推广、忽然发现支撑后台还有部分功能没有实现应战。竞争对手突然提高了补贴力度，必须马上决定是否应战。
>>持续时间
持续时间是指一个功能做好之后，用户有效使用的周期是多久。有一些需求上线后用户可能只用几天，另外一些需求上线后用户可以用几年
，产品经理当然愿意做后者。举个例子，中秋节的促销活动一般只持续3天。如果要开发一个特定的系统，那么产品经理通常会采取两种对策，或是
和营销人员沟通，询问能否借用已有功能来实现这一需求，或是争取把这个功能做成通用模块，以后可以经常复用。
>>不同阶段的产品看重什么
在产品的不同阶段，对上面提到的广度、频度、强度，会有不同的侧重点。产品早期的验证阶段，更重视"强度。。通常在产品上线前后，要
设法验证用户是否认可产品，愿意用且愿意反复用，即测验留存率高低。只有留存率够高，产品在将来才会有好的发展，而留存率高就要求产品背
后的需求足够强。所以，刚上线的产品就像大家在小学应用题里经常见到的那个游泳池，有一个进水口在进水(获取新用户)，有一个出水口在出水(
失去老用户)。如果产品经理在现实生活中遇到这样的事情，当然会先去堵上出水口，而不是急于灌水。这个阶段的产品，常见的版本号是0.8，0.9
和1.0，还在不断试错，寻找最能打动用户的切入点。
6.1.2 几个价值判断的案例
>>实用工具，如何突破
>>智能硬件，怎样送礼
>>上***，哪种靠谱
6.1.3 成本评估与性价比
>>成本评估
判断完了功能的价值，就要评估另外一个同等重要的因素-成本。
判断二个产品功能的成本，有很多方面的考量，比如人力、时间、金钱等，基至也可以把风险看作广义的成本，，日常评估时，没法面面俱到
，所以通常会先判断成本的瓶颈在哪里，然后用对成本瓶颈的评估来简化完整评估。互联网、IT行业的功能成本瓶颈一般在开发工程师的丁.作量上
，所以常常把"开发量"的高低视为成本的高低，
那么，具体谁来评估我认为有技术背景的产品经理，这时候自己上就可以了，因为这个阶段的评估是相对粗略的，可以称作成本的"初评，虽
然常用的计量单位还是。人天。(指一个人一天可以做的工作量)、人周、人月，但目的不是为了精确知道工作量，而是为了了解不同功能实现难度
的排序。
这个时候只做初评的原因，一方面是因为评估准确也需要很多投入资源，而这个功能做不做还不知道，所以没有必要精确评估；另一方面是因
为做不到，毕竟还没有确定功能细节，也不知道有谁来做这个功能。
>>确定性价比
经常有人问我产品经理要不要懂技术!我的观点是，产品经理懂技术肯定是优势，只要不滥用，比如，在初步评估成本时，自己能搞定就可以大
大提升效率。那如果不懂技术怎么办？你就必须和技术人员配合，提供两个常见的方法，Team Estimationame和Planning Poker，都是敏捷开发
过程中供团队一起评估成本的方法，非常简单也非常好用，有需要可以自行查找资料加以学习。
要牢记此时评估的目的确定功能的相对成本高低，从而确定性价比。功能A与功能B相比，哪个相对成本较大一点，哪个较小一点，只需要知道对比
关系就可以，比如“高中低”的评价或者54321的不同分值。然后，用半定量的价值和半定量的成本，就可以计算出半定量的性价比。
这个半定量的公式是:性价比=价值/成本
按理说应该先做那些性价比高的功能，但这太理想化了，实际操作中，还需要考虑功能的分类和其他的实际情况。
6.1.4功能分类：KANO模型
>>第一类，基础功能
当这类功能没有实现时，用户对产品是。极其不满的。但是，这个功能做得再好，用户也认为，理所应当。于是，把这种功能叫作基础功能敷
中的说法是Must Have。基础功能是必须要实现的功能点，但无法带来满意，只会消除不满。
>>第二类，亮点功能
当这个功能没有做时，用户并不会不满意或觉得有问题，因为已经习以为常。但是一旦有了这个功能，用户就会大为惊喜，甚至赞不绝口。
为什么会这样?主要因为这些功能通常是新的，用户事先想不到产品居然还能有此妙用。比如，若干年前，有谁会想到，手机能当手电筒用，浏览器
能通过记忆和联想自动补全你刚开始输入的网址，已发送出去的电子邮件还可以因内容不妥在几秒内撤回·这类功能有一个名字，叫作，亮点，对
应的英文说法是*** To Have.
亮点是忠诚度、口碑传播的基础。如今，一个没有亮点的产品，用户也许偶尔会用、但不会与产品建立正向情感连接，更不会主动帮我们传
播。想要低成本引流，让老用户带来新用户产品必须找到自己的亮点。那么应该做什么样的亮点呢?常见的亮点特性有。用户没见过。未经市场检验
。和"如果被认可就能获得巨大回报"这儿种。由其可知，选择亮点不能一概而论，大公司和小公司，已经很厉害的产品和新生的产品，都会做出截
然不同的判断
>>第三类，期望功能
之所以取“期望功能”这个名字，是因为这类功能都是用户的期望。比如，做一款创新的智能手环，去问用户有什么需求，用户的答案可能是
"最好操作简单些。要能自动记录我的运动情况，充电不用太频繁，希望充一次至少用一个礼拜、样子要酷一点······这种大多数用户能说得
出来的，就是期望功能。
产品具备了期望功能，用户当然会继续使用，但因为缺乏惊喜而不大可能主动传播。如果只是通过简单地和用户交流来采集需求，最终实现的
大多只能是期望功能，这再一次印证了第05章反复提到的Y模型中的一个原则：。用心听，但不要照着做。
KAN0模型从另外一个角度告诉我们，如果直接从1到3，照着用户说的做，这个产品的功能往往是不完整的。因为用户告诉你的，只会是期望
功能。用户不会提基础功能，因为他觉不能抄近道必须从1往下挖，挖到2后用领域知识来补全基础功能，再4、这时要通过对人性和价值观的理解来
提出亮点。从各种功能的来源看，期望功能对应的是1亮点对应的是4而基础功能对应的是2。
得你的产品肯定会有用户也不会说亮点功能，因为他想不到。
前三类功能的与时俱进
我们刚刚讲的前三类功能，还只是在一个时间切片上去分析。现在，再加入时间耄耋未理解KANO模型，先说结论，随着时间的推移，一个功
能的类型是会变化的，往往会经历y亮点功能到期望功能再到基础功能这样一个完整变迁。预测未来很难，但可以通过追溯过往来找到例子。2000年
左右，有少数手机已经可以闲来听歌，彻底颠覆丁单独使用MP3的用户习惯，所以可以听歌，明显是个亮点一两年后，越来越多的用户意识到手机能
听歌的好处，会在参与需求调研时提出。希望你们的下一款手机也可以听歌。这时可以听歌。又变成了典型的期望功能主过去几年，当所有手机都
能听歌了，用户就再也不会主动提这个功能，可以听歌变成了理所当然的基础功能。
>>第四类,无差别功能
IT系统作为狭义的产品，本来就是用于提高效率的。所以，先通过人肉跑流程来验证模式、使用量上来后再用IT系统来提升效率、实现规
模化效益，是常见的操作方式，一个流程在效率可接受时，不一定非要做一个产品出来。千万不要因为我们是产品经理、为刷存在感，就要把各种
东西都做成IT系统。产品只是一种解决方案、人工服务也是，这里面的核心考量是投人产出比。
>>第五类，反向功能
在评估反向功能时，要注意以下两种常见的用户属性。第一种是用户的多边性，指多边型的平台产品4里有完全不同类型的用户，他们之之
间可能存在的利益矛盾。比如同时有卖家、买家双方的交易类平台，往往卖家很喜欢的功能、对买家利益可能有损害，反之亦然。比如出行应用里
，司机希望能够主动挑乘客，不希望被平台派单，而乘客也希望能主动挑司机，不希望被动接受，这里面就有冲突，而广义的多边，是外部用户和
公司，他们之间的利益，也经常是有冲突的
第二种是用户的多样性。同一类用户中，有一些人喜欢这个功能，有一些人不喜欢这个功能，举个例子，豆瓣每次改版后总有一些用户会不
满意，然后产品经理被骂得受不了了，只好改回去。卫上，另外一些刚才没说话的用户站出来说.你怎么又改回去了，我们挺喜欢新版的。这体现的
就是用户的多样性。反向功能很考验产品经理，我们需要在多种用户利益之间寻找平南，而如何判断不同用户孰重孰轻,则又要回“价值判断”的章
节寻求答案。
6.2 功能打包，确定MVP
6.2.1尽可能多地放弃
产品界的主流价值观是。少做就是多做。、。完美不是无一分可增，而是无一分可减。，所以，这一步要确定。最小可行产品。，即MVp
(Minimum Viable Product)。
MVP是指的是满足。用户愿意用、最好愿意付费。、。用户易于使用。、一团队有能力实现。的最小功能集合，有些可以直接作为最终产品
使用，有些&至只能用来演示，它的煎点就是制作的成本费极低，但是却能展示最终产品的主要特色。当然，对MVP的解释也有争议，比如。可以人
l-跑通流程的业务模型。算不算MVP?但比起理解MVP的目的，这并不重要。
Mvp的功用就是让你拿着它接触客户，尽早根据客户的回馈来改进你的产品，用户需要的东西有时候并不难实现，但很容易被忽略。如果你
不是一开始就跟用户接触，就很难知道这些内幕。典型的错误就是窝在家里做没人要的东西，却自以为很有成就、和需求采集阶段尽可能多地采集
不同，这一步要。尽可能多地放弃，看似矛盾的理念，其实目的都是为了提供尽可能多的用户价值。可以通过表6-2以及图6-12来理解这个观点。
6.2.2案例：QQ的MVP
6.2.3MVP的限制因素
>>不同功能不同对策
先回顾理想模型，结合相关原则和限制，按照性价比的评估和KANO模型的功能分类，最终结论可总结为
基础功能必做，要留足资源。
>>在产品初创期，先实现个别低成本的亮点。
>>对期望功能，先做性价比高的。
>>无差别功能无须做，低成本验证出来即可。
>>对反向功能，权衡各方利益后再决定。
>>考虑功能依赖关系
功能的内外部依赖关系，如合作伙伴和各种前置条件等、都需要事先考察。例如，某个功能的实现有技术难点，在你的公司里只有某位技术大
牛才能解决，而他短期内在另外一个项目里出不来；或者，你的海淘业务想做一个互动、能不能成功，取决于某个关键商品是否能拿到更好的价格
，现在需要等待与供应商的谈判结果、功能的依赖关系，有点像产品概念筛选环节需要讨论的那些因素。只不过，这里需要考虑的因素更细节、更
具体，并且是针对每一个具体功能点的。
>>考虑功能相似性
功能相似才能保证我们做的是一个整体的项目，而不是一个小需求合集。本书提及的所有产品相关流程，更加适用于一个完整的可以实现用户价值
的产品，而日常小修小补的需求合集、则可以做适当简化。一般来说，1.0.2.0这种成熟的版本，基本上已经是一个完整的产品，而1.01.2.1.3这
样微小的版本升级，通常对应一个小需求的合集，
>>考虑非功能需求
最后，还要识别出一些。非功能需求。由于非功能需求也是有成本的，所以要在项目实施之前应当一并考虑进去。如。论坛需要支持1000人同时在
线，这是一个性能需求。系统功能升级，必须在发布2周以前完成对客服部门的培训、这是一个培训需求。如果硬件压力突增，应该有报警，具体细
节是······。
6.2.4MVP的表达，产品架构图
>>公交实时到站查询让用户了解是否需要一路小跑去公交站，还是可以先去旁边的便利店买一瓶水。将来计划对接公交公司的数据、BI
(Business
Intelligence，商业智能)系统，还会对接地图应用。
>>候车娱乐：如果车还有很久才来，或者已经上车还没到站的时候，用户可以通过候车娱乐玩游戏。其亮点在于，玩的过程中不用再紧张地随时
需要停下来抬头看看是否该上、下车了，系统里会有到站提醒。这一功能点将来可以用来承接广告，产生直接收人。
>>叫车功能如果实在等不及，还可以唤起第三方的打车应用。
>>到站提醒准备上车和准备下车的提醒，同样需要对接公交系统的数据。
>>个人中心iBus:建立用户数据库，让系统记录用户的家、公司等常去地点及乘车路线，将来也许可以做社交，比如。本月你和小红已经在这路
公交车上邂逅3次了，要不要打个招呼?。
6.2.5功能分分合合的本质
顺着产品架构的话题，再探讨一个产品形态的问题——不同的功能，到底应该做在起，还是分开。举个例子滴滴平台的顺风车，乘客和车主的功
能在同一个客户端里，而其出租车，乘客和司机的功能分布于两个客户端。其实这个问题背后的判断逻辑很简单，就是看不同用户角色背后的自然
人重合度高不高，如果高，则倾向于同一个端搞定，如果不高，则倾向于分离
6.3 把需求和功能管起来
6.3.1 空间维度：功能列表
6.3.2时间维度：需求流程
#产品#6.1一个功能的DNA
俗话说，产品经理推动工程师实现功能的三宝：竞品已搞，老板想要，开发量小。如果不行，再上杀招，求求你了好不好。在本章中，主要展
开说三点：评估价值，成本评估和功能分类。
更进一步的说可以总结为两点：
>>价值由产品功能背后的用户需求（问题）决定
>>成本由产品功能（解决方案）决定
实现成本低，或者对应需求的价值高，这两个条件中的任一个，都不能单独作为决定趋势线一个功能的理由。必须结合这两个条件，综合考量
功能的性价比。理论上，性价比高的功能优先级也就高，必须先做。
性价比=价值/成本
不过实际操作中，还需要考虑功能的分类。
6.1.1功能的价值和判断
6.1.1功能的价值判断
先说说对某个功能进行价值判断的流程。
>>参照"产品原则。里"目标。部分的定义，明确当前产品最看重的指标是什么可以是数字化的KPI,比如注册用户数达到10万，也可以是某些关
健结果，比如。建立起线上自动化的专家入驻全流程。。如果有多个指标，则需要对这些指标加权合并2.
>>考察每个功能点实现后，对上述指标的帮助大不大。如果大，则这个功能的价值就大，因为每个产品不同时期的指标不同，所以评判各个功
能价笸的标准也各有差异。通常用半定量的方式来衡量、比如最简单的大、中、小，或者5.4.3.2.1等评分标准。
>>广度：潜在用户数*单用户价值
简中来讲，广度对应着潜在用户数，即一个产品将来可能覆盖的用户群体有多大。
不同产品、不同功能的定位，直接决定其可能覆盖的潜在用户数会有差异，有时苌至相系一个或多个量级。
同样是面向出行这一需求，如果是打车应用，覆盖的潜在用户数可能是几个亿，如果是代驾应用，因为要求用户有车且没法开，可能覆盖的潜
在用户数最多只有几百万，两者相差两个量级，同样是餐饮服务，日常快餐和只接婚宴，潜在用户数的差距也很大。
同等条件下，我们肯定愿意做潜在用户数多的产品功能。但是，潜在用户数不是唯一的因素，、有一些产品虽然潜在用户人数很少，但是也可
以做，因为它覆盖的这些用户，·单用户价值"非常高。典型的例子就是银行的VIP业务，从普卡、银卡、金卡、白金卜到钻石卡，以及再高级一点
的私人银行，用户数越来越少、但一个高级用户的资产少则几千万，多则几个亿，可以抵上几千几万个初级用户。
单用户价值这个词，在不同行业能找到不同的说法。比如，电商行业的，客单价，是指用户平均每次消费花多少钱；游戏行业和运营商的，
ARpU值。(av·rage revenue peruser)，是指平均每个用户在单位时间内给公司带来的收入；而对于社交应用，对应的说法也许是活跃度。
从广度的角度，“潜在用户数*单用户价值”可以用来判断产品对应的市场容量、也就是第3章提到的产品概念筛选里的天花板。当然，具体操
作时，经常先从某些细分用户切人，再逐步扩大到所有潜在用户。比如，2016年下半年火爆的ofo共享单车，就是先攻高校内部，再扩张到校园外。
>>频度：需求频次"单次复杂度
频度是指需求频次的高低，不同的需求，频次差异会非常大。
有些需求每天都会出现一次苌至多次，比如叫外卖；有的需求每周最多出现一次，比如看电影有的需求也许每个月只出现一次，比如交水电费
、还信用卡有的需求每年出现一、两次，比如车险，出境游等；有的需求葚至有可能一辈子只出现一次，比如结婚。
同等条件下，我们当然更喜欢做频次高的产品功能。我曾负责过天猫积分系统，当时有很多积分相关的消息要开发。在产品的早期版本里，我
做了一些简化买家每次购物产生的积分变动消息，需要先做；而用户每年年底积分过期的提醒，可以缓缓，如果碰到可以先手动解决。但是，有些
需求的频次不是那么高，我们也愿意做。这是因为这些单次需求的复杂度高，而且单价也高，有很大的价值空间可供挖掘。虽说外卖需求的频次比
较高，但每单通常只有20块左右。而婚礼，虽然一辈子只有一次，但背后的需求包含了很多点——拍婚纱照要几万，办酒席要几十万，蜜月旅行要
几万；还需要买一些周边产品，小到喜糖，大到车和房，后者又至少有几百万的潜在市场价值。
通常，频次很高的需求不太可能有太高的单次价值。理由很简单、类似每天一次、每次一万块这种需求，只能存在于极端小众的土豪市场，大
众菁遍没这么强的消费能力。
>>强度不可替代、紧急、持久
强度背后说的就是真实刚需。
个需求是不是真的，是不是刚性，有一个简单的判断原则，就是问自己这样个司题。当你没有做这个产品功能时，用户是不是在设法解决，基至已
经在川某种钡效的方式来解决这个问题?。如果答案是肯定的，那么说明需求真的很强烈。接下角
再给大家讲几个判断的角度。
>>可替代性
可替代性用来说明一个功能是不是很容易被其他功能替代。打个比方，假设你月了家早餐店，一开始技术不太熟练，所以每天早上只能供应包
子这一款单品。做了月个礼拜之后，技术水平提高了，发现早上时间还有富余，可以再做第一款单品。这则有两个选择，一个是馒头，一个是豆浆
，应该怎么选呢?我相信大家都会选择豆浆。
因为馒头和包子是可以互相替代的，豆浆是不可替代的。你会发现，买了包子的人多
常会四处张望，看看旁边有没有卖牛奶、豆浆或其他饮料的，因为包子太干，容易嗟
着。
>>紧急程度
需求紧急程度也可以作为衡量需求强度的判断原则。科学的时间管理建议我们庄该更有计划性，尽量避免紧急的事情发生，但现实中的确有
这样的需求，真的是受窑种客观情况所限，必须马上动手实施或调整计划。比如，极个别用户的负面评价、弓起了广泛的舆论风波，必须要在产品
上做出响应；营销方案已经开始推广、忽然发现支撑后台还有部分功能没有实现应战。竞争对手突然提高了补贴力度，必须马上决定是否应战。
>>持续时间
持续时间是指一个功能做好之后，用户有效使用的周期是多久。有一些需求上线后用户可能只用几天，另外一些需求上线后用户可以用几年
，产品经理当然愿意做后者。举个例子，中秋节的促销活动一般只持续3天。如果要开发一个特定的系统，那么产品经理通常会采取两种对策，或是
和营销人员沟通，询问能否借用已有功能来实现这一需求，或是争取把这个功能做成通用模块，以后可以经常复用。
>>不同阶段的产品看重什么
在产品的不同阶段，对上面提到的广度、频度、强度，会有不同的侧重点。产品早期的验证阶段，更重视"强度。。通常在产品上线前后，要
设法验证用户是否认可产品，愿意用且愿意反复用，即测验留存率高低。只有留存率够高，产品在将来才会有好的发展，而留存率高就要求产品背
后的需求足够强。所以，刚上线的产品就像大家在小学应用题里经常见到的那个游泳池，有一个进水口在进水(获取新用户)，有一个出水口在出水(
失去老用户)。如果产品经理在现实生活中遇到这样的事情，当然会先去堵上出水口，而不是急于灌水。这个阶段的产品，常见的版本号是0.8，0.9
和1.0，还在不断试错，寻找最能打动用户的切入点。
6.1.2 几个价值判断的案例
>>实用工具，如何突破
>>智能硬件，怎样送礼
>>上***，哪种靠谱
6.1.3 成本评估与性价比
>>成本评估
判断完了功能的价值，就要评估另外一个同等重要的因素-成本。
判断二个产品功能的成本，有很多方面的考量，比如人力、时间、金钱等，基至也可以把风险看作广义的成本，，日常评估时，没法面面俱到
，所以通常会先判断成本的瓶颈在哪里，然后用对成本瓶颈的评估来简化完整评估。互联网、IT行业的功能成本瓶颈一般在开发工程师的丁.作量上
，所以常常把"开发量"的高低视为成本的高低，
那么，具体谁来评估我认为有技术背景的产品经理，这时候自己上就可以了，因为这个阶段的评估是相对粗略的，可以称作成本的"初评，虽
然常用的计量单位还是。人天。(指一个人一天可以做的工作量)、人周、人月，但目的不是为了精确知道工作量，而是为了了解不同功能实现难度
的排序。
这个时候只做初评的原因，一方面是因为评估准确也需要很多投入资源，而这个功能做不做还不知道，所以没有必要精确评估；另一方面是因
为做不到，毕竟还没有确定功能细节，也不知道有谁来做这个功能。
>>确定性价比
经常有人问我产品经理要不要懂技术!我的观点是，产品经理懂技术肯定是优势，只要不滥用，比如，在初步评估成本时，自己能搞定就可以大
大提升效率。那如果不懂技术怎么办？你就必须和技术人员配合，提供两个常见的方法，Team Estimationame和Planning Poker，都是敏捷开发
过程中供团队一起评估成本的方法，非常简单也非常好用，有需要可以自行查找资料加以学习。
要牢记此时评估的目的确定功能的相对成本高低，从而确定性价比。功能A与功能B相比，哪个相对成本较大一点，哪个较小一点，只需要知道对比
关系就可以，比如“高中低”的评价或者54321的不同分值。然后，用半定量的价值和半定量的成本，就可以计算出半定量的性价比。
这个半定量的公式是:性价比=价值/成本
按理说应该先做那些性价比高的功能，但这太理想化了，实际操作中，还需要考虑功能的分类和其他的实际情况。
6.1.4功能分类：KANO模型
>>第一类，基础功能
当这类功能没有实现时，用户对产品是。极其不满的。但是，这个功能做得再好，用户也认为，理所应当。于是，把这种功能叫作基础功能敷
中的说法是Must Have。基础功能是必须要实现的功能点，但无法带来满意，只会消除不满。
>>第二类，亮点功能
当这个功能没有做时，用户并不会不满意或觉得有问题，因为已经习以为常。但是一旦有了这个功能，用户就会大为惊喜，甚至赞不绝口。
为什么会这样?主要因为这些功能通常是新的，用户事先想不到产品居然还能有此妙用。比如，若干年前，有谁会想到，手机能当手电筒用，浏览器
能通过记忆和联想自动补全你刚开始输入的网址，已发送出去的电子邮件还可以因内容不妥在几秒内撤回·这类功能有一个名字，叫作，亮点，对
应的英文说法是*** To Have.
亮点是忠诚度、口碑传播的基础。如今，一个没有亮点的产品，用户也许偶尔会用、但不会与产品建立正向情感连接，更不会主动帮我们传
播。想要低成本引流，让老用户带来新用户产品必须找到自己的亮点。那么应该做什么样的亮点呢?常见的亮点特性有。用户没见过。未经市场检验
。和"如果被认可就能获得巨大回报"这儿种。由其可知，选择亮点不能一概而论，大公司和小公司，已经很厉害的产品和新生的产品，都会做出截
然不同的判断
>>第三类，期望功能
之所以取“期望功能”这个名字，是因为这类功能都是用户的期望。比如，做一款创新的智能手环，去问用户有什么需求，用户的答案可能是
"最好操作简单些。要能自动记录我的运动情况，充电不用太频繁，希望充一次至少用一个礼拜、样子要酷一点······这种大多数用户能说得
出来的，就是期望功能。
产品具备了期望功能，用户当然会继续使用，但因为缺乏惊喜而不大可能主动传播。如果只是通过简单地和用户交流来采集需求，最终实现的
大多只能是期望功能，这再一次印证了第05章反复提到的Y模型中的一个原则：。用心听，但不要照着做。
KAN0模型从另外一个角度告诉我们，如果直接从1到3，照着用户说的做，这个产品的功能往往是不完整的。因为用户告诉你的，只会是期望
功能。用户不会提基础功能，因为他觉不能抄近道必须从1往下挖，挖到2后用领域知识来补全基础功能，再4、这时要通过对人性和价值观的理解来
提出亮点。从各种功能的来源看，期望功能对应的是1亮点对应的是4而基础功能对应的是2。
得你的产品肯定会有用户也不会说亮点功能，因为他想不到。
前三类功能的与时俱进
我们刚刚讲的前三类功能，还只是在一个时间切片上去分析。现在，再加入时间耄耋未理解KANO模型，先说结论，随着时间的推移，一个功
能的类型是会变化的，往往会经历y亮点功能到期望功能再到基础功能这样一个完整变迁。预测未来很难，但可以通过追溯过往来找到例子。2000年
左右，有少数手机已经可以闲来听歌，彻底颠覆丁单独使用MP3的用户习惯，所以可以听歌，明显是个亮点一两年后，越来越多的用户意识到手机能
听歌的好处，会在参与需求调研时提出。希望你们的下一款手机也可以听歌。这时可以听歌。又变成了典型的期望功能主过去几年，当所有手机都
能听歌了，用户就再也不会主动提这个功能，可以听歌变成了理所当然的基础功能。
>>第四类,无差别功能
IT系统作为狭义的产品，本来就是用于提高效率的。所以，先通过人肉跑流程来验证模式、使用量上来后再用IT系统来提升效率、实现规
模化效益，是常见的操作方式，一个流程在效率可接受时，不一定非要做一个产品出来。千万不要因为我们是产品经理、为刷存在感，就要把各种
东西都做成IT系统。产品只是一种解决方案、人工服务也是，这里面的核心考量是投人产出比。
>>第五类，反向功能
在评估反向功能时，要注意以下两种常见的用户属性。第一种是用户的多边性，指多边型的平台产品4里有完全不同类型的用户，他们之之
间可能存在的利益矛盾。比如同时有卖家、买家双方的交易类平台，往往卖家很喜欢的功能、对买家利益可能有损害，反之亦然。比如出行应用里
，司机希望能够主动挑乘客，不希望被平台派单，而乘客也希望能主动挑司机，不希望被动接受，这里面就有冲突，而广义的多边，是外部用户和
公司，他们之间的利益，也经常是有冲突的
第二种是用户的多样性。同一类用户中，有一些人喜欢这个功能，有一些人不喜欢这个功能，举个例子，豆瓣每次改版后总有一些用户会不
满意，然后产品经理被骂得受不了了，只好改回去。卫上，另外一些刚才没说话的用户站出来说.你怎么又改回去了，我们挺喜欢新版的。这体现的
就是用户的多样性。反向功能很考验产品经理，我们需要在多种用户利益之间寻找平南，而如何判断不同用户孰重孰轻,则又要回“价值判断”的章
节寻求答案。
6.2 功能打包，确定MVP
6.2.1尽可能多地放弃
产品界的主流价值观是。少做就是多做。、。完美不是无一分可增，而是无一分可减。，所以，这一步要确定。最小可行产品。，即MVp
(Minimum Viable Product)。
MVP是指的是满足。用户愿意用、最好愿意付费。、。用户易于使用。、一团队有能力实现。的最小功能集合，有些可以直接作为最终产品
使用，有些&至只能用来演示，它的煎点就是制作的成本费极低，但是却能展示最终产品的主要特色。当然，对MVP的解释也有争议，比如。可以人
l-跑通流程的业务模型。算不算MVP?但比起理解MVP的目的，这并不重要。
Mvp的功用就是让你拿着它接触客户，尽早根据客户的回馈来改进你的产品，用户需要的东西有时候并不难实现，但很容易被忽略。如果你
不是一开始就跟用户接触，就很难知道这些内幕。典型的错误就是窝在家里做没人要的东西，却自以为很有成就、和需求采集阶段尽可能多地采集
不同，这一步要。尽可能多地放弃，看似矛盾的理念，其实目的都是为了提供尽可能多的用户价值。可以通过表6-2以及图6-12来理解这个观点。
6.2.2案例：QQ的MVP
6.2.3MVP的限制因素
>>不同功能不同对策
先回顾理想模型，结合相关原则和限制，按照性价比的评估和KANO模型的功能分类，最终结论可总结为
基础功能必做，要留足资源。
>>在产品初创期，先实现个别低成本的亮点。
>>对期望功能，先做性价比高的。
>>无差别功能无须做，低成本验证出来即可。
>>对反向功能，权衡各方利益后再决定。
>>考虑功能依赖关系
功能的内外部依赖关系，如合作伙伴和各种前置条件等、都需要事先考察。例如，某个功能的实现有技术难点，在你的公司里只有某位技术大
牛才能解决，而他短期内在另外一个项目里出不来；或者，你的海淘业务想做一个互动、能不能成功，取决于某个关键商品是否能拿到更好的价格
，现在需要等待与供应商的谈判结果、功能的依赖关系，有点像产品概念筛选环节需要讨论的那些因素。只不过，这里需要考虑的因素更细节、更
具体，并且是针对每一个具体功能点的。
>>考虑功能相似性
功能相似才能保证我们做的是一个整体的项目，而不是一个小需求合集。本书提及的所有产品相关流程，更加适用于一个完整的可以实现用户价值
的产品，而日常小修小补的需求合集、则可以做适当简化。一般来说，1.0.2.0这种成熟的版本，基本上已经是一个完整的产品，而1.01.2.1.3这
样微小的版本升级，通常对应一个小需求的合集，
>>考虑非功能需求
最后，还要识别出一些。非功能需求。由于非功能需求也是有成本的，所以要在项目实施之前应当一并考虑进去。如。论坛需要支持1000人同时在
线，这是一个性能需求。系统功能升级，必须在发布2周以前完成对客服部门的培训、这是一个培训需求。如果硬件压力突增，应该有报警，具体细
节是······。
6.2.4MVP的表达，产品架构图
>>公交实时到站查询让用户了解是否需要一路小跑去公交站，还是可以先去旁边的便利店买一瓶水。将来计划对接公交公司的数据、BI
(Business
Intelligence，商业智能)系统，还会对接地图应用。
>>候车娱乐：如果车还有很久才来，或者已经上车还没到站的时候，用户可以通过候车娱乐玩游戏。其亮点在于，玩的过程中不用再紧张地随时
需要停下来抬头看看是否该上、下车了，系统里会有到站提醒。这一功能点将来可以用来承接广告，产生直接收人。
>>叫车功能如果实在等不及，还可以唤起第三方的打车应用。
>>到站提醒准备上车和准备下车的提醒，同样需要对接公交系统的数据。
>>个人中心iBus:建立用户数据库，让系统记录用户的家、公司等常去地点及乘车路线，将来也许可以做社交，比如。本月你和小红已经在这路
公交车上邂逅3次了，要不要打个招呼?。
6.2.5功能分分合合的本质
顺着产品架构的话题，再探讨一个产品形态的问题——不同的功能，到底应该做在起，还是分开。举个例子滴滴平台的顺风车，乘客和车主的功
能在同一个客户端里，而其出租车，乘客和司机的功能分布于两个客户端。其实这个问题背后的判断逻辑很简单，就是看不同用户角色背后的自然
人重合度高不高，如果高，则倾向于同一个端搞定，如果不高，则倾向于分离
6.3 把需求和功能管起来
6.3.1 空间维度：功能列表
6.3.2时间维度：需求流程
