之前负责过一款上亿 DAU 的产品改版，其中有一些教训和收获分享一下：
提前思考，循序渐进
DAU 到达一定程度，如果改版是一蹴而就的，「变化」这件事一定会带来很大的反对声音。上亿用户的产品，0.1% 的负反馈也代表了 10 万的用户，80/20 原则在这种情况下完全不适用。也许长期来看，这是一个成功的改版，但是短期的反对声音会对公司内部造成极大的压力。
为了让改版更加落地的更加顺滑，建议是提前思考好长期产品改变的最终形态，并分步逐渐修改。就像进化论一样，从猿人进化到人，中间还有很多的过渡形态。换成你的改版，假设它包括了 10 个功能的优化，我们在后续的迭代中每个迭代升级一个，既能降低工作量，又不会对产品造成太大的用户习惯改动，而前面优化的功能还能随着后续的迭代逐步优化，经过了 10 个迭代之后，产品就悄然变成了早前计划的样子。
慎重做加法，没有回头路
对于用户量比较小的产品，做了一个新功能发现有问题可以在后续的迭代中告知用户并去掉。而对于用户量大的产品，上了一个有问题的功能，同样哪怕只有 0.1% 的用户使用，也是几万乃至几十万的人。
我在之前的产品做改版时，经常会在调整的时候遇到一些非常犄角旮旯的界面逻辑，为了调整这些部分，技术要额外花费很多的时间。但是如果我们直接不管，又不知道会对正在使用又为数不多的用户造成什么样的影响。
当然为了避免这样的问题，我们在上线前可以使用 AB 测试或者分步灰度的方式避免，可是很多功能在初期时好用的，慢慢因为没人维护或者不符合长期的方向，变成了只有少数人在用的功能。
所以，每一个加法，都需要我们非常谨慎的对待。
重视内部测试的反馈
很多时候，我们在新功能开发完成但还没完全优化好的时候，会先让内部的同事使用我们的功能。
我教训最深刻的一次是，改版在没有做任何引导的情况下，直接对阿里的同学强制更新新版本使用来吸取内部反馈。结果就是在内网收到了猛烈的反馈和投诉，我们不得不为了这些反馈做了很多的调整来表达我们重视的态度，为此增加了很多额外的工作量。
所以，内网的用户也是用户，内部用户反馈的力量甚至可以左右你的产品。想要获得最真实的内部反馈，我们就要给予真实的更新体验。如果想要简单一点，至少不能强制对方更新并使用，而是可以选择内部发帖号召大家主动测试的方式，进行更柔和或者更有神秘感的形式，来提升测试用户的积极性，把强迫变成吸引。
以上。