分使用者習慣新版本後，再將新版本設為預設版本。同時將舊版本保留一段時間，公示為舊版本提供支援的最後期限，以便沒來得及習慣新版本的使用者在這段時間內能照常使用產品。對於使用者數量龐大的服務和產品，這個過疲可能需要幾個月的時間。 產品經理還要準備好承擔來自開發團隊和運維團隊的壓力，畢竟支援並行版本不是件容易的事。 另一種平滑部署的方式是區域性逐步部署，首先在某個區域內部署新版本，然後逐步擴大範圍。還有一種方式是增量部署，將更新項分割成幾個較小的部分逐步釋出。無論採用哪種處理方式，關鍵要全面考慮更新可能帶來的“副作用”，為用戶提供便利，方便他們在空閒時適應變化，同時儘可能降低新版本帶來的負面影響。 優秀的產品和服務可以贏得使用者的好感，這是寶貴的信任， 應該小心保護。不要輕易試探使用者的耐心，讓好感變成反感。
第25章快速響應階段 Rapid Response 產品出爐後場莫虎頭蛇尾我反覆強調發布產品不等於大獲全勝，交付產品後依然需要保持高度警惕。本章詳細介紹產品交付後的收尾工作。 產品釋出後，多數公司會迅速撤走為研發產品和釋出產品整合的資源，急於投入下一個專案，殊不知此時正是收集反饋資訊、改進產品的最佳時機。急於“撤軍”是專案管理和產品開發流程中的大忌，只要稍微延長專案週期，觀察使用者對產品的反應，效果就會有天壤之別。這樣做投資之小、回報之高會令你瞠目結舌，絕非其他專案階段可比。 我向來堅持產品釋出後的幾天至一週內，所有專案成員應該留出時間作為快速響應階段。這個階段的主要工作是快速響應、處理產品釋出後的使用者反饋意見。