版本迭代规划是产品经理的一项基本工作，好的版本迭代规划方法应该是稳健的，综合的，可持续的并考虑到研发资源情况。作者目前在公司负责的是业务线H5版本的规划。刚开始做版本规划的产品经理常常会遇到以下问题：

我的需求从哪来？

版本应该由哪些需求构成？

哪些需求应该放到下个版本？

要解决这些问题，你首先应该知道，一个好的版本规划方法应该有以下几个特点：

一、稳健。稳健的产品规划方法意味着它不会太过激进，太过激进的产品迭代策略会导致整个公司的节奏波动较大，要么研发加班完成你的需求，要么研发周期研长，过长的研发周期会带来迭代慢、不可控因素增多等等问题。

稳健的产品规划也意味着不太过消极，不会因需求太少导致研发资源空闲浪费。

要做到这一点需要考虑到研发资源的现状，研发资源并不是一直稳定的，研发请婚假、离职了、抽调去支援其他项目了或者有比较大的技术需求需要做，都会导致给产品研发资源减少；最近研发招人了，其他项目的人员调过来了等则会导致研发资源增加。这些情况不止是项目经理需要考虑，进行版本规划的产品经理也需要提前考虑。

二、综合。综合是指，根据这个方法规划出来的版本的需求来源是多样的，不会因为某个需求来源的需求量下降，就导致下个版本变得干煸。

同时，版本的需求构成也是多样，有些需求可能是上线后可以预见肯定有效果的，有些需求可能则是实验性质的，结果不可控。

综合意味着我们能在一个版本里包含不同性质的需求，这有点像投资的方法论，投资专家建议投资者把30%（这个比例根据年龄有所不同）的收入放在有固定收益的定期存款或者理财产品，把30%的收入放在中风险的基金，把30%的收入投资高风险高收益的股票期货市场。如果某个版本规划70%的需求都是实验性质的，且需要投入大量研发资源，那对公司产品和产品经理个人风险就太大了。

三、可持续。好的产品规划方法一定是可持续的，即在这个版本规划方法的指导下，能够持续的输出产品迭代方案。可能有的产品经理能说出一个尽善尽美的产品规划方法，但那个方法在几个版本的迭代后，就不再适用了，我认为这也不是一个好的产品迭代方法。

那么具体的版本迭代方法是怎么样的呢？一个版本的需求应该由哪些部分构成？

一、已明确的需求版本规划（1-3个）

这类需求大家应该很熟悉，一般是版本里的P0或P1，它们是一些你做也得做，不做也得做的需求。它们可能来自你的老板，或者老板的老板的需求，或者行业的趋势，或者法律政策的变动；也可能是你已与相关负责人讨论过的下版本的核心功能点。

这类需求往往比较重要，是版本的核心，产品和研发都需要投入大量时间以保证质量，所以尽量一个版本不要太多。

二、预判有用的研究方向（0-2个）

很多需求是具有实验性质的，在写需求文档的时候，产品经理并没有把握这个需求能带来效果，同时，这些需求又往往是最能体现产品经理直觉。最让产品经理兴奋的。这类需求我建议是在每个版本穿插着做，或者在没有大需求的版本里作为核心需求做。

三、优秀厂商或产品的更优秀功能设计（1-2个）

相比于第二点，这类需求是最不需要产品经理思考，最没有风险的需求了。好处是写这类需求有时候连美术资源都不需要（手动滑稽），直接在友商的App里截图就行了。

但还是建议你在“借鉴”的时候，充分思考友商为什么要这么做，目的是什么，有没有更好的方案。

四、线上版本细节优化点（1-3个）

上个版本上线后，你一定还有不满意的地方；线上一定存在一些你一直不爽的交互、图标等细节需要优化。

这需要你平时多用自家的产品，遇到让你需要思考或觉得不舒服的地方，及时记录；

多观察你身边其他使用者（包括但不限于其他产品、运营、研发、测试）对你产品使用的体验。比如测试在测试我的功能，我会认真的看他的操作，是否连贯，是否有举棋不定的时候，有时候用户自己是说不出自己的不爽的，但他们的行为不会说谎，需要产品经理去捕捉。

多听用户的声音，客服群、产品公众号留言区、App内意见反馈区、社交平台都是你收集用户声音的好地方，当你在公司喝下午茶的时候，少刷点抖音新闻，去后台看看用户的留言吧。

————————————————

更多产品经理成长日记，时间管理心得，外文博客翻译，请关注我的公众号「原住民的自修室」