編按：
幾乎所有網路公司的產品經理都會說：當然是小步快跑，快速疊代！他們會舉微信的例子：微信1.0版本時連語音功能都沒有，但不妨礙先推出，搶占用戶，然後根據用戶反饋，不斷改進。如果必須第一天就把所有功能都想清楚、做出來，包括後來的朋友圈、公眾號、小程式……那微信永遠都推不出來了吧。
那小步快跑、快速疊代的產品策略就必然正確嗎？ 未必。（本文摘自《每個人的商學院・商業實戰（下）》，以下為摘文。）
疊代策略——小步快跑永遠正確嗎？
L不怎麼會做菜，但很想在社區門口開家餐館，怎麼辦呢？「小步快跑，快速疊代」的網路思維給了他極大信心，他相信，只要不斷改進，一定會做出顧客喜愛的飯菜。於是，他興奮地開店了。第一天，鄰居們都來祝賀試吃，門庭若市。第二天，就再也沒有人來了......這是為什麼呢？
其實，L的問題是做產品時總會遇到的經典的兩難選擇：到底是小步快跑、快速疊代，還是一次性把事做對？
幾乎所有網路公司的產品經理都會說：當然是小步快跑，快速疊代！他們會舉微信的例子：微信1.0版本時連語音功能都沒有，但不妨礙先推出，搶占用戶，然後根據用戶反饋，不斷改進。如果必須第一天就把所有功能都想清楚、做出來，包括後來的朋友圈、公眾號、小程式……那微信永遠都推不出來了吧。
那小步快跑、快速疊代的產品策略就必然正確嗎？ 未必。
有一次，我去中廣核集團給高層講「行動網路時代的商業本質」，看到牆上貼著一句話：一次性把事做對。我有點兒尷尬，但更多的是震撼。一座核電廠，確實要一次性把事做對。誰敢住在一個「小步快跑，快速疊代」的核電廠旁？
那「小步快跑，快速疊代」和「一次性把事做對」，到底哪個更正確或者更先進呢？ 答案是視情況而定。沒有唯一正確或者更加先進的產品策略，要根據實際情況來選擇。接下來，我們看看有哪些「情況」會左右產品的疊代策略。
第一點，目標的確定性。
滴滴出行、摩拜單車、「得到」App，它們最終會是什麼樣的？我估計它們的創始人也不知道。在目標不確定時，不斷調整方向和姿態的「小步快跑、快速疊代」是更有效的策略。
但如果做螺紋鋼呢？它的生產目標是：更好的品質，更低的價格。那跑什麼步，疊什麼代啊！每一批產品都要比上個版本質量更好，價格更低。目標極度確定時，需要一次性把事做對。
第二點，結果的忍受度。
按鈕位置太靠右了，按下去沒有抖動效果，按鈕顏色和其他部分不協調……這些地方都可以優化，但優化前用戶能「忍受」嗎？ 他們可能會抱怨兩句，但看在可以免費騎車、瀏覽新聞、比價購買的面子上，大多數人就忍了。
那如果是核電廠呢？ 第一次完全外洩，第二次減少15％的外洩，第三次再減少8％……可以嗎？ 絕對不可以。我們對核電廠外洩是零容忍的。
所以，結果忍受度高的可以考慮快速疊代；結果忍受度低的，要一次性把事做對。
第三點，疊代的頻繁度。
谷歌和百度的網站，理論上一天可以疊代幾百次；手機App，一周可以更新好幾次。這些疊代頻繁度高的，步子小，可以快速疊代。
那手機呢？就算用戶一年換一次手機，小米4不夠完善的地方，小米5改進；小米5不夠優秀的地方，小米6改進，邁的步子也不算大。
而冰箱、衣櫃等商品，用戶一旦購買，很長時間內都不會更新，就基本沒給商家疊代機會。（標楷）對這樣疊代頻繁度幾乎為零的產品，要一次性把事做對。
第四點，用戶的數量級。
一款產品到底面對多少用戶？ 滴滴出行面對的是幾億用戶，如果讓幾萬用戶失望了，還有更多用戶可以開發。而在開篇的案例中，L面對的用戶是幾百戶鄰居，讓他們陪跑，大家都因為難吃而不光顧了，L還有誰可以開發呢？
所以，面對大數量級的用戶群，更適合小步快跑；面對少量用戶，更適合一次性把事做對。
沒有什麼方法論是普世真理，它們都有適用的前提。拋開適用前提，神話任何經驗都是極度危險的。一款產品到底應該「小步快跑，快速疊代」，還是「一次性把事做對」，要根據目標的確定性、結果的忍受度、疊代的頻繁度、用戶的數量級來看情況而定。
