阶段2：黏性
最小可行化产品的黏性
不只是用户深度参与的表征，还要有证据表明你的产品正逐步成为用户生活中必不可少且难以替代的一部分。
如果你今天不能使100名用户留下来，那么将来也不太可能留下100万名用户。
第一要务是打造一组核心功能，以保证用户的频繁使用与功能的成功应用。
在步入病毒性阶段以前，需要证明两件事：
- 人们是否在如你所料地使用着产品？如果没有，你可以做什么？
- 人们是否从你的产品中得到了足够多的价值？他们也许会喜欢你的产品，但如果他们不愿为此付费、点击广告或邀请好友，你可能还是没有生意可做。
先别想着导流量，除非你有信心把新的流量转化为参与度。在得知用户开始反复使用你的产品后，才可以着手发展用户基数。
迭代最小可行化产品
迭代是渐变式的，转型是突变式的。
在迭代中，你的目标是提高跟踪中的核心指标。如果新功能无法显著提高第一关键指标，则应删除该功能。
过早追求病毒性
除非用户具有一定的参与度和黏性，否则即便拥有很多用户也不等于产品具有吸引力。
最终目标是留存率
“我是否相信这项功能（或改动）会增加产品的黏性？”
开发功能前七问
- 这个功能有什么帮助？为什么这样做会更好？
- 你能衡量这一功能的效果吗？
- 围绕功能展开的试验要求对功能的影响做出衡量，同时这种影响必须是可量化的。不经量化验证就将功能添加到产品上，会导致产品走上范围蠕变和功能膨胀的不归路。
- 如无法量化新功能的影响，就不能对其价值做出评估，也无法随时间的推移而真正了解其作用。
- 功能开发要多久？
- 这一功能是否会使产品变得太过复杂？
- 这一新功能会带来多大的风险？
- 这项新功能有多创新？
- 用户说他们想要什么？
如果提前做好规划，并真正了解背后的缘由，功能开发会变得十分简单。把高层次的愿景和长期的目标落实到具体的功能层面，这一点十分重要。如不能将二者很好地联系在一起，就无异于冒险去开发一些无法得到有效测试且不能推动公司发展的功能。
如何处理用户反馈
- 提前计划好测试，并在测试前理清自己究竟想要知道些什么。
- 选择特定的交谈对象。
- 在收集数据的同时快速评审结果。
最小可行愿景（minimum viable vision）
拥有最小可行愿景的信号：
- 在打造一个平台
- 有重复性收费的能力
- 形成了自然的阶梯定价
- 与一场颠覆性的革命息息相关
- 用户自发成为拥护者
- 能引发一场价格战
- 正处于一场环境变革中
- 拥有一种可持续的压倒性优势
- 边际成本逐步降为零（区分收益递减规律）
- 公司模式中有固有的网络效应
- 有多种赚钱方式
- 因客户的盈利而盈利
- 你的周围会形成一个生态系统
- 必须大胆创新
问题-解决方案画布
以学习为目的（复盘）
| 当前状态 | 上周的启示（与成就） | 首要问题 |
|---|---|---|
| 列出所跟踪的关键指标及其当前水平，并与前几周做对比 发展的趋势如何 |
你上周学到了什么 完成了什么 一切是否在计划之中 |
列举并描述首要问题 划分优先级 |
问题清单（最多3个）
| 假想的解决方案 | 指标/证据+目标 |
|---|---|
| 列举你下周会采用的几个可行方案，为其排序 你为什么相信这些方案可以帮助你解决或彻底解决当前问题 |
列举用于衡量解决方案是否奏效的指标（即能否解决问题） 列举你会用到的（定性）证据 确定指标的目标 |
永远不要低估将所有人的意见放在同一页面的力量。把一致的信息写在一张纸上，可以迫使所有利益相关者言简意赅地表明意见，并就此达成共识，这对问题的理清与定义很有帮助。
总结
- 你的目标是证明自己采用一种吸引回头客的方式解决了问题
- 本阶段的关键是参与度，以用户与你的交互时间以及回访率等作为衡量标准
- 即便你开发的是一款最小可行化产品，但仍应以感染客户、员工以及投资人为目标，而且需要通过一种可靠的方式，实现从当前验证到未来愿景的转变
- 在证明人们确实会如你所愿使用产品以前，先别加快开发速度。否则，你就是在费时旨财地开发一款毫无用户回头率的产品
- 在优化产品黏性的同时，利用同期群分析来衡量每次产品改动所带来的影响
问题清单
- 人们是否如预期般使用你的产品
- 对活跃用户进行定义，占比
- 围绕功能开发前提出的七大问题，审视自己的功能规划草图
- 对用户投诉进行评估，这些投诉如何影响下一步的功能开发