一談到“互聯網思維”，大家都會想到“快速迭代”。但我發現，很多人對於” 快速迭代”的理解是不夠全面的。
大部分人對“快速迭代”的理解是：一個產品，所有的功能不用一次做出來，做好一部分上線一部分，一些功能的完善可以等產品上線後，靠後續版本，慢慢改進。
有人基於上述的理解，會對“快速迭代”提出疑義：
1. 在總的工作量一定的情況下，分幾次開發和上線，要完成所有的功能，所花費的總時間往往會更長，“快速迭代”究竟是提高了效率，還是降低了效率
2. 爲了快速上線，“快速迭代”中第一個版本往往是不夠好的。這樣的版本是否會影響用戶體驗，導致口碑不好，不利於產品的後續推廣
之所以有上述的疑義，關鍵還是對於“快速迭代”的理解不夠深刻。
首先，“快速迭代”應該應用在探索型的產品設計上。探索型的產品，意味着大家對產品是否能很好滿足用戶需求，是否能成功並沒有把握，這時如果做一個完整的產品再推出，一旦發現不符合市場需求，就會造成很大研發成本浪費，因此需要“快速迭代”，用一個不完整的版本去驗證產品設計的合理性。探索型的產品的研發工作量是不定的，它會根據市場反饋增加功能或調整功能，因此採用“快速迭代”可以避免大的研發成本的浪費。如果是確定性的產品，的確可以儘可能完善後，才把產品推向市場。
其次，在應用“快速迭代”做產品設計時，一個不完整的版本，不等於一個粗糙的版本。不完整的版本，只是輔助功能有所缺失，但核心功能不會缺失，且在易用性，美觀性上也會達到一定的標準。因此並不會造成產品口碑的大幅下降。
在產品設計過程中，應用“快速迭代”思維，關鍵是要找出“需要驗證的市場假設”，用一個簡單的產品來驗證。下面是我過去工作中的一些例子：
1. 曾經我的團隊做一個新產品，原型出來後，內部討論時，大家覺得上線前，有20幾個地方需要改進。當時，我發現這些改進點都不影響用戶對核心功能的使用，所以我的決策就是一個都不用改，直接先給用戶試用。我給團隊的解釋是，有可能我們新產品最核心的功能打動不了用戶，我們會把產品整個推倒重來，如果是那樣的話，做這20幾個的改進點，就是一種資源的浪費。即使新產品打動了客戶，後續需要做進一步完善，我也傾向於與先聽聽真正的客戶覺得產品哪些地方最需要改進，有可能客戶提的和團隊討論出來的20幾個點是一致的，但更有可能客戶覺得優先需要改進的，是其他方面，或只是這20幾個點中的一小部分。後來，事實證明，新產品還是受到了用戶的好評，但團隊原來覺得要優先改進的點，大部分從用戶角度來說，並不是很重要。
2. 我曾經規劃過一個 SaaS 產品，當時新產品有3種可能的側重點，吃不準客戶會更接受哪一個。爲了決定究竟選擇哪個方面作爲產品的側重點，我們並沒有在內部做過多的討論，而是飛快的推出了第一個版本，這個版本是一個不完整的版本，網站上只有產品介紹，和“申請試用”按鈕，申請試用後的功能什麼也沒做。當用戶“申請試用”時，會彈出一個類似“謝謝你對我們的產品感興趣，我們會主動和你聯絡”的頁面。而產品介紹其實我們有三種，分別對應了一種產品設計的側重點，某個用戶在看產品介紹時，會隨機看到三種中的一種。根據一週內，用戶“申請試用”的轉換率，我們知道了大部分用戶更認可其中一種的產品方向。有了這個結論後，我們纔開始真正做下一步的產品設計。
當對一些重要的產品決策沒有把握時，在傳統的思維中，往往會通過內部討論，慎重地做一個決策，在決策基礎上做完整的方案設計。如果決策錯誤，就會導致產品的失敗，即使發現錯誤後再修正，也會造成大量時間和精力的浪費。而在“快速迭代”理念的指導下，我們會用儘可能少的資源，儘快推出原型產品，通過用戶反饋來驗證產品決策的正確性並決定下一步的方向。