人人都是产品经理02-06章摘要

6.1一个功能的DNA

在本章中，主要展开说三点：价值评估（表中的“商业价值”）、成本评估（表中的“开发量”）和功能分类（表中的“分类”）。
更进一步可以总结出以下两点：
►价值由产品功能背后的用户需求（问题）决定。
►成本由产品功能（解决方案）决定。

实现成本低，或者对应需求的价值高，这两个条件中的任一个，都 不能单独作为决定去实现一个功能的理由。必须结合这两个条件，综合考量功能的性价比。理论上，性价比高的功能优先级也就高，应该先做。
性价比 = 价值/成本

6.1.1功能的价值判断

1.广度：潜在用户数 *单用户价值
同等条件下，我们肯定愿意做潜在用户数多的产品功能。但是，潜在用户数不是唯一的因素。有一些产品虽然潜在用户人数很少，但是也可以做，因为它覆盖的这些用户，“单用户价值”非常高。典型的例子就是银行的VIP业务，从普卡、银卡、金卡、白金卡到钻石卡，以及再高级一点的私人银行，用户数越来越少，但一个高级用户的资产少则几千 万，多则几个亿，可以抵上几千几万个初级用户。

2.频度：需求频次 *单次复杂度

通过图6-2很容易就能得出结论，高频高单价的需求极少，低频低单价的需求不值得做。
对于另外两个象限的需求，常见的策略是：先利用高频低单价的需求抓用户，因为高频场景和用户互动的机会多，而低单价的轻决策场景可以降低用户进入门槛，容易引流；再用低频高单价 的需求做利润，因为单价高了，可以切分的蛋糕才大。
之所以采取这样的先后次序，是因为必须有海量用户做基础，低频需求的总量才足够大。比如汽车后市场（指买车以后产生的各种消费）就很典型，用高频 低单价的洗车增加客流量，甚至通过补贴来抓牢用户，然后用低频高单 价的保险、保养、修车来赚取利润。

3.强度：不可替代、紧急、持久
强度背后说的就是真实刚需。
一个需求是不是真的，是不是刚性，有一个简单的判断原则，就是问自己这样一个问题：“当你没有做这个产品功能时，用户是不是在设法解决，甚至已经在用某种低效的方式来解决这个问题？”如果答案是肯定的，那么说明需求真的很强烈。接下来再给大家讲几个判断的角度。

①可替代性
可替代性用来说明一个功能是不是很容易被其他功能替代

②紧急程度
需求紧急程度也可以作为衡量需求强度的判断原则

③持续时间
持续时间是指一个功能做好之后，用户有效使用的周期是多久

6.1.4功能分类：KANO模型

基础功能 亮点功能 期望功能 无差别功能 反向功能

Y模型里面的“1”，既是用户需求的表象，也是用户的期望。KANO模型从另外一个角度告诉我们，如果直接从“1”到“3”，照着用户说的做，这个产品的功能往往是不完整的。因为用户告诉你的，只会是期望功能。用户不会提基础功能，因为他觉得你的产品肯定会有；用户也不会说亮点功能，因为他想不到。可见，不能抄近道，必须从“1”往下 挖，挖到“2”后用领域知识来补全基础功能，再挖到“4”，这时要通过对人性和价值观的理解来提出亮点。从各种功能的来源上看，期望功能对 应的是“1”，亮点对应的是“4”，而基础功能对应的是“2”。

6.2功能打包，确定MVP

6.2.1尽可能多放弃

产品界的主流价值观是“少做就是多做”、“完美不是无一分可增， 而是无一分可减”。所以，这一步要确定“最小可行产品”，即 MVP（Minimum Viable Product）。
MVP是指的是满足“用户愿意用、最好愿意付费”、“用户易于使用”、“团队有能力实现”的最小功能集合，有些可以直接作为最终产品使用，有些甚至只能用来演示。它的重点就是制作的成本要极低，但是却能展示最终产品的主要特色。当然，对MVP的解释也有争议，比 如“可以人工跑通流程的业务模型”算不算MVP？但比起理解MVP的目的，这并不重要 MVP 的功用就是让你拿着它接触客户，尽早根据客户的回馈来改进你的产品。用户需要的东西有时候并不难实现，但很容易被忽略。如果你不是一开始就跟用户接触，就很难知道这些内幕。典型的错误就是窝在家里做没人要的东西，却自以为很有成就。
我们经常听到迭代、敏捷、试错、小步快跑、持续交付等这些说法，其实它们都表达了相似的价值观——尽可能早地改正错误。一年有 52周，如果4周迭代一次，则有13次改正的机会，如果2周迭代一次，就有26次改正的机会。迭代的话题属于研发生产环节，后面的章节还会细聊。

MVP的限制因素

现在，试着完整地回答如何打包功能和确定MVP这个问题。

1.不同功能不同对策
先回顾理想模型，结合相关原则和限制，按照性价比的评估和 KANO模型的功能分类，最终结论可总结为：
►基础功能必做，要留足资源。
►在产品初创期，先实现个别低成本的亮点。
►对期望功能，先做性价比高的。
►无差别功能无须做，低成本验证出来即可。
►对反向功能，权衡各方利益后再决定。

2.考虑功能依赖关系
功能的内外部依赖关系，如合作伙伴和各种前置条件等，都需要事先考察。
例如，某个功能的实现有技术难点，在你的公司里只有某位技术大牛才能解决，而他短期内在另外一个项目里出不来。

3.考虑功能相似性
功能相似才能保证我们做的是一个整体的项目，而不是一个小需求合集。本书提及的所有产品相关流程，更加适用于一个完整的可以实现用户价值的产品，而日常小修小补的需求合集，则可以做适当简化。一 般来说，1.0 2.0这种成熟的版本，基本上已经是一个完整的产品，而 1.01 2.1.3这样微小的版本升级，通常对应一个小需求的合集。

4.考虑非功能需求
最后，还要识别出一些“非功能需求”。由于非功能需求也是有成本的，所以要在项目实施之前应当一并考虑进去。如“论坛需要支持1000 人同时在线”，这是一个性能需求；“系统功能升级，必须在发布2周以前完成对客服部门的培训”，这是一个培训需求；“如果硬件压力突增， 应该有报警，具体细节是……”，这是一个运维部门的维护需求；“在用 户数增加10倍的情况下，硬件投入必须小于2倍”，这是一个可扩展需求；“此功能的用户操作日志需要记录”，这是一个内部数据分析的需求。

6.2.4MVP的表达，产品构架图