一谈到“互联网思维”，大家都会想到“快速迭代”。但我发现，很多人对于” 快速迭代”的理解是不够全面的。
大部分人对“快速迭代”的理解是：一个产品，所有的功能不用一次做出来，做好一部分上线一部分，一些功能的完善可以等产品上线后，靠后续版本，慢慢改进。
有人基于上述的理解，会对“快速迭代”提出疑义：
1. 在总的工作量一定的情况下，分几次开发和上线，要完成所有的功能，所花费的总时间往往会更长，“快速迭代”究竟是提高了效率，还是降低了效率
2. 为了快速上线，“快速迭代”中第一个版本往往是不够好的。这样的版本是否会影响用户体验，导致口碑不好，不利于产品的后续推广
之所以有上述的疑义，关键还是对于“快速迭代”的理解不够深刻。
首先，“快速迭代”应该应用在探索型的产品设计上。探索型的产品，意味着大家对产品是否能很好满足用户需求，是否能成功并没有把握，这时如果做一个完整的产品再推出，一旦发现不符合市场需求，就会造成很大研发成本浪费，因此需要“快速迭代”，用一个不完整的版本去验证产品设计的合理性。探索型的产品的研发工作量是不定的，它会根据市场反馈增加功能或调整功能，因此采用“快速迭代”可以避免大的研发成本的浪费。如果是确定性的产品，的确可以尽可能完善后，才把产品推向市场。
其次，在应用“快速迭代”做产品设计时，一个不完整的版本，不等于一个粗糙的版本。不完整的版本，只是辅助功能有所缺失，但核心功能不会缺失，且在易用性，美观性上也会达到一定的标准。因此并不会造成产品口碑的大幅下降。
在产品设计过程中，应用“快速迭代”思维，关键是要找出“需要验证的市场假设”，用一个简单的产品来验证。下面是我过去工作中的一些例子：
1. 曾经我的团队做一个新产品，原型出来后，内部讨论时，大家觉得上线前，有20几个地方需要改进。当时，我发现这些改进点都不影响用户对核心功能的使用，所以我的决策就是一个都不用改，直接先给用户试用。我给团队的解释是，有可能我们新产品最核心的功能打动不了用户，我们会把产品整个推倒重来，如果是那样的话，做这20几个的改进点，就是一种资源的浪费。即使新产品打动了客户，后续需要做进一步完善，我也倾向于与先听听真正的客户觉得产品哪些地方最需要改进，有可能客户提的和团队讨论出来的20几个点是一致的，但更有可能客户觉得优先需要改进的，是其他方面，或只是这20几个点中的一小部分。后来，事实证明，新产品还是受到了用户的好评，但团队原来觉得要优先改进的点，大部分从用户角度来说，并不是很重要。
2. 我曾经规划过一个 SaaS 产品，当时新产品有3种可能的侧重点，吃不准客户会更接受哪一个。为了决定究竟选择哪个方面作为产品的侧重点，我们并没有在内部做过多的讨论，而是飞快的推出了第一个版本，这个版本是一个不完整的版本，网站上只有产品介绍，和“申请试用”按钮，申请试用后的功能什么也没做。当用户“申请试用”时，会弹出一个类似“谢谢你对我们的产品感兴趣，我们会主动和你联络”的页面。而产品介绍其实我们有三种，分别对应了一种产品设计的侧重点，某个用户在看产品介绍时，会随机看到三种中的一种。根据一周内，用户“申请试用”的转换率，我们知道了大部分用户更认可其中一种的产品方向。有了这个结论后，我们才开始真正做下一步的产品设计。
当对一些重要的产品决策没有把握时，在传统的思维中，往往会通过内部讨论，慎重地做一个决策，在决策基础上做完整的方案设计。如果决策错误，就会导致产品的失败，即使发现错误后再修正，也会造成大量时间和精力的浪费。而在“快速迭代”理念的指导下，我们会用尽可能少的资源，尽快推出原型产品，通过用户反馈来验证产品决策的正确性并决定下一步的方向。
本文出自 “千里之行，始于足下” 博客，转载请与作者联系！
原文地址：http://daniellu.blog.51cto.com/4173745/1961043
