移动产品经理必须要知道的11件事

因为有许多混淆因素，会导致剖析用户行为时受到干扰。如果没有真正理解每个模块之间是怎样相互影响和驱动用户行为的，那么做出完整功能的版本也是无意义的。

如果在MVP上做一个小改动配合A/B测试，就能够很直接的发现这个改动与用户行为之间的直接关系。这样就可以通过用户的正向或消极的反馈来验证产品的想法，避免只靠假设做判断。

6、为什么版本迭代要使用列车时刻表模式

就像列车的时刻表一样，无论你现在是否已经上车，列车都会按照时刻表准时离开。版本迭代周期需要常规化，提前设置好迭代间隔（比如1周），到达时间节点无论功能是否完成，都按照计划上线。迭代的版本可能只是修复了一些bug，亦或者是全面优化。

对比功能迭代的模式，列车时刻表模式减轻了许多压力和不确定性。团队知道每个版本的迭代时间点，尽管这个功能没有100%的完成，也不会影响版本的迭代，只需要放到下个版本上线。这样就会避免为了赶在时间节点上完成功能而粗糙编写代码，对于用户体验如此重要的今天，这种模式带来的优势显得如此重要。

7、应用商店的约束

阻碍App成功的一些因素与应用商店有关，因为当团队想要更新版本时，必须通过提交一个新的版本到应用商店进行审核和上线，从而引起以下三个问题：

应用商店的审核周期平均是一周

一次性让所有用户都更新

不能回滚到上一个版本

为了应对这些问题，许多团队会选择每隔一两个月更新一个大版本，而不是使用上述提到的小版本每周迭代。

这种大版本更新的模式就像回到了盒装软件的时期，不再是通过小版本迭代验证产品想法而是投入很多人力去猜测用户需要的是什么。

因为不能回滚版本，所以当出现了一些严重Bug或者影响用户体验的问题时，就只能够重新提交一个版本，而漫长的审核周期会使得处理这些问题的反馈变得很慢，也削减了整个团队的信心。

8、Feature Flag功能发布控制

Feature Flag是一种允许控制线上功能开启或者关闭的方式，通常会采取配置文件的方式来控制。