版本迭代规划是产品经理的一项基本工作，好的版本迭代规划方法应该是稳健的，综合的，可持续的。本文通过4个方面讲述了产品经理如何进行版本迭代，与大家分享！

版本迭代规划是产品经理的一项基本工作，好的版本迭代规划方法应该是稳健的，综合的，可持续的。

考虑到研发资源情况。作者目前在公司负责的是业务线H5版本的规划。

一、好的版本规划有哪些特点

刚开始做版本规划的产品经理常常会遇到以下问题：

• 我的需求从哪来？
• 版本应该由哪些需求构成？
• 哪些需求应该放到下个版本？

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

1. 稳健

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

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

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

2. 综合

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

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

综合意味着：我们能在一个版本里包含不同性质的需求，这有点像投资的方法论，投资专家建议投资者把30%（这个比例根据年龄有所不同）的收入放在有固定收益的定期存款或者理财产品；把30%的收入放在中风险的基金；把30%的收入投资高风险高收益的股票期货市场。

如果某个版本规划70%的需求都是实验性质的，且需要投入大量研发资源，那对公司产品和产品经理个人风险就太大了。

3. 可持续

好的产品规划方法一定是可持续的，即在这个版本规划方法的指导下，能够持续的输出产品迭代方案。

可能有的产品经理能说出一个尽善尽美的产品规划方法，但那个方法在几个版本的迭代后，就不再适用了，我认为这也不是一个好的产品迭代方法。

二、一个好的产品迭代方法

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

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

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

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

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

很多需求是具有实验性质的，在写需求文档的时候，产品经理并没有把握这个需求能带来效果。同时，这些需求又往往是最能体现产品经理直觉。

最让产品经理兴奋的这类需求我建议是在每个版本穿插着做，或者在没有大需求的版本里作为核心需求做。

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

相比于第二点，这类需求是最不需要产品经理思考，最没有风险的需求了。

好处是写这类需求有时候连美术资源都不需要（手动滑稽），直接在友商的App里截图就行了。

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

4. 线上版本细节优化点（1-3个）

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

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

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

多听用户的声音——客服群、产品公众号留言区、App内意见反馈区、社交平台都是你收集用户声音的好地方。

当你在公司喝下午茶的时候，少刷点抖音新闻，去后台看看用户的留言吧！

作者：原住民，微信公众号：原住民的自修室

本文由 @原住民 原创发布于人人都是产品经理，未经许可，禁止转载

题图来自Unsplash，基于CC0协议