1704233234
1704233235
1704233236
1704233237
1704233238
图6-12 尽可能多的放弃，反而能提供更多价值
1704233239
1704233240
这是一个理想化的模型，假设功能列表里待开发的功能模块有A、B、C三个，价值和成本如表6-2以及图6-12所示。来对比以下两种做法。
1704233241
1704233242
第一种是传统做法，先做A和B，到第20天，可以发布一个用户价值为5.3.8 的产品。
1704233243
1704233244
第二种是新做法，先做A，再做B。这样，到第10天，就可以发布一个用户价值为5的产品，第20天依然可以发布一个用户价值为8的产品。
1704233245
1704233246
如果简单地把曲线下的面积理解成产品持续提供给用户的价值，那么可以从图中得出明显的结论：只要条件允许，“尽可能多地放弃”反而能提供更多的用户价值。这里的放弃不是要把更多功能丢掉，而是不要集中完成，分批次地迭代实现。
1704233247
1704233248
这样做的另一个好处是，可以提前10天开始获取用户和市场的反馈，而这就足以让我们能提前几天制定出更合理的产品策略。比如，在开始做C之前，发现价值为4的D模块，就可以改为先做D。
1704233249
1704233250
真实场景中可能会出现以下情况，需要加以留意。
1704233251
1704233252
►发布的频次，并非越频繁越好。因为发布本身也需要占用时间和支付成本，如果发布次数太多，正式版的最终发布时间会不断延迟，最终严重影响产品整体的市场节奏。
1704233253
1704233254
►越轻量级的产品，越容易打包出一个尽量小的MVP。能独立发布的前提条件是要有一个MVP，但并不是每个产品都能很容易地打包出一个MVP，这取决于产品形态。从大实体到软硬结合、CS结构、BS结构，越重的产品打包MVP的难度越大。
1704233255
1704233256
►不完美的产品先让种子用户去用。提前发布的产品，直接推给全体用户时一定要慎重。最好能和“种子用户”的概念结合起来，让他们来完成试用。
1704233257
1704233258
我们经常听到迭代、敏捷、试错、小步快跑、持续交付等这些说法，其实它们都表达了相似的价值观——尽可能早地改正错误。一年有52周，如果4周迭代一次，则有13次改正的机会，如果2周迭代一次，就有26次改正的机会。迭代的话题属于研发生产环节，后面的章节还会细聊。
1704233259
1704233260
6.2.2 案例：QQ的MVP
1704233261
1704233262
看一个真实的功能打包案例：QQ，当时还叫OICQ，1988年开始产品规划，1999年2月推出图6-13所示的Beta1，这是QQ的第一个公开版本。因为各种考虑和限制因素，只能优先实现三个特性，应该怎么选？
1704233263
1704233264
1704233265
1704233266
1704233267
图6-13 QQ早期版本的注册界面
1704233268
1704233269
这是一道腾讯的面试题，网上有很多版本的答案，我按照自己的理解梳理了一遍。我们不去回答在下面的12个特性里到底选哪3个，而把分析焦点放在每一个选项到底应该先做，还是缓缓。
1704233270
1704233271
1. 卡通头像
1704233272
1704233273
2. 不可窃听的安全通讯
1704233274
1704233275
3. 聊天室
1704233276
1704233277
4. 很小的.exe文件
1704233278
1704233279
5. 皮肤Skin
1704233280
1704233281
6. 速度超快0.5秒反应
1704233282
1704233283
7. 聊天记录管理器