版本迭代規劃是產品經理的一項基本工作，好的版本迭代規劃方法應該是穩健的，綜合的，可持續的並考慮到研發資源情況。作者目前在公司負責的是業務線H5版本的規劃。剛開始做版本規劃的產品經理常常會遇到以下問題：
我的需求從哪來？
版本應該由哪些需求構成？
哪些需求應該放到下個版本？
要解決這些問題，你首先應該知道，一個好的版本規劃方法應該有以下幾個特點：
一、穩健。穩健的產品規劃方法意味着它不會太過激進，太過激進的產品迭代策略會導致整個公司的節奏波動較大，要麼研發加班完成你的需求，要麼研發週期研長，過長的研發週期會帶來迭代慢、不可控因素增多等等問題。
穩健的產品規劃也意味着不太過消極，不會因需求太少導致研發資源空閒浪費。
要做到這一點需要考慮到研發資源的現狀，研發資源並不是一直穩定的，研發請婚假、離職了、抽調去支援其他項目了或者有比較大的技術需求需要做，都會導致給產品研發資源減少；最近研發招人了，其他項目的人員調過來了等則會導致研發資源增加。這些情況不止是項目經理需要考慮，進行版本規劃的產品經理也需要提前考慮。
二、綜合。綜合是指，根據這個方法規劃出來的版本的需求來源是多樣的，不會因爲某個需求來源的需求量下降，就導致下個版本變得乾煸。
同時，版本的需求構成也是多樣，有些需求可能是上線後可以預見肯定有效果的，有些需求可能則是實驗性質的，結果不可控。
綜合意味着我們能在一個版本里包含不同性質的需求，這有點像投資的方法論，投資專家建議投資者把30%（這個比例根據年齡有所不同）的收入放在有固定收益的定期存款或者理財產品，把30%的收入放在中風險的基金，把30%的收入投資高風險高收益的股票期貨市場。如果某個版本規劃70%的需求都是實驗性質的，且需要投入大量研發資源，那對公司產品和產品經理個人風險就太大了。
三、可持續。好的產品規劃方法一定是可持續的，即在這個版本規劃方法的指導下，能夠持續的輸出產品迭代方案。可能有的產品經理能說出一個盡善盡美的產品規劃方法，但那個方法在幾個版本的迭代後，就不再適用了，我認爲這也不是一個好的產品迭代方法。
那麼具體的版本迭代方法是怎麼樣的呢？一個版本的需求應該由哪些部分構成？
一、已明確的需求版本規劃（1-3個）
這類需求大家應該很熟悉，一般是版本里的P0或P1，它們是一些你做也得做，不做也得做的需求。它們可能來自你的老闆，或者老闆的老闆的需求，或者行業的趨勢，或者法律政策的變動；也可能是你已與相關負責人討論過的下版本的核心功能點。
這類需求往往比較重要，是版本的核心，產品和研發都需要投入大量時間以保證質量，所以儘量一個版本不要太多。
二、預判有用的研究方向（0-2）
很多需求是具有實驗性質的，在寫需求文檔的時候，產品經理並沒有把握這個需求能帶來效果，同時，這些需求又往往是最能體現產品經理直覺。最讓產品經理興奮的。這類需求我建議是在每個版本穿插着做，或者在沒有大需求的版本里作爲核心需求做。
三、優秀廠商或產品的更優秀功能設計（1-2）
相比於第二點，這類需求是最不需要產品經理思考，最沒有風險的需求了。好處是寫這類需求有時候連美術資源都不需要（手動滑稽），直接在友商的App裏截圖就行了。
但還是建議你在“借鑑”的時候，充分思考友商爲什麼要這麼做，目的是什麼，有沒有更好的方案。
四、線上版本細節優化點（1-3）
上個版本上線後，你一定還有不滿意的地方；線上一定存在一些你一直不爽的交互、圖標等細節需要優化。
這需要你平時多用自家的產品，遇到讓你需要思考或覺得不舒服的地方，及時記錄；
多觀察你身邊其他使用者（包括但不限於其他產品、運營、研發、測試）對你產品使用的體驗。比如測試在測試我的功能，我會認真的看他的操作，是否連貫，是否有舉棋不定的時候，有時候用戶自己是說不出自己的不爽的，但他們的行爲不會說謊，需要產品經理去捕捉。
多聽用戶的聲音，客服羣、產品公衆號留言區、App內意見反饋區、社交平臺都是你收集用戶聲音的好地方，當你在公司喝下午茶的時候，少刷點抖音新聞，去後臺看看用戶的留言吧。