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. 聊天记录管理器
1704233284
1704233285
8. 语音
1704233286
1704233287
9. 视频
1704233288
1704233289
10. 看谁在线上
1704233290