经常有人说“产品就是自己的孩子”，作为产品经理，我们确实要把产品当成自己的孩子，不仅要负责孩子的“出生”，更要负责孩子的“成长”。对于一个产品来讲，迭代是产品成长的必经之路。接下来，笔者分享一下自己的经验，希望对大家有帮助，感谢支持！
为什么要迭代？（1.0版本–2.0版本）
解决遗留问题（1.0版本）
产品经理不是万能的，产品首次上线（即1.0版本）不可能是完美的，譬如功能缺失、前后端不能很好的衔接等问题，但往往受时间、KPI等因素影响，产品又必须上线。一般而言，产品1.0版本的上线会留下诸多问题（未修复的bug、未满足的需求、未开发完成的版块等），这些问题要通过小版本迭代来解决。
新增需求或功能点（1.1–1.N版本）
因为每个公司的架构不同，在这里我针对我们自己公司的实际情况为大家举例说明。产品1.0上线后除了解决遗留问题，其他相关部门的需求会“接踵而至”，运营会提运营需求、业务会提业务需求、财务会提财务需求，这些需求需要通过迭代来实现。
产品本身迭代（2.0版本）
在1.0版本到2.0版本的过程中，产品要配合运营、业务等其他部门做很多工作，譬如用户调研、需求调研、市场调研等。在做完这些工作之后，产品要把整个环节中遇到的问题解决掉，迭代。而在整个产品的发展周期中，市场在变化、思维在变化、理念在变化，我们要保证产品与时俱进的同时，大胆创新。
如何迭代？
流程：各部门提出需求→产品汇总需求→发起需求评审会→确定需求，判断优先级（签订需求评审单）→产品设计原型→原型评审→UI评审→开发
在整个产品发展过程中，做好迭代其实并不难，关键是迭代流程一定要规范，作为产品经理需要“挖–判–定”
挖：挖掘用户对产品的真实评价及建议，挖掘让用户“爽”的爆点等。
我们在产品1.0发布后做过一次问卷调研，虽然很多用户冲着奖品完成了问卷，但是收效甚微，很多用户敷衍了事，最终只收到了一堆毫无用处的建议。后来我们就采取线下一对一的沟通，先从线上（QQ群、微信群）选择了一批较为活跃的用户，然后一对一的面谈，了解用户的真实体验及感受，针对产品分析问题，然后解决。
除了用户，还要做好与其他部门的沟通，找到各个渠道反馈的问题，共同商讨解决方案。
判：判断所有需求的可行性、明确性。
很多用户会提出一些“奇葩的需求”，而这些需求我们无法满足或者很多需求是不合理的，在这个过程中，我们要学会过滤。在得到需求后进行需求可行性判断，明确此需求确实有必要并对产品发展有建设性作用。
定：确定需求，评审会。
在整个1.0–2.0的过程中，我们经历最多的会议是“需求评审会”，这个会议需要公司相关部门的领导及核心人员参与。各部门提出需求，由产品经理汇总需求、发起会议，共同评审。需求评审的目的在于不同部门、不同人对同一需求的看法和见解不同，站的角度也不同。如果一个需求提出后，各个部门一致通过，那么这个需求就是可行的。
在我得个人经历中，关于产品迭代有很多经验与大家分享：
- 做好用户沟通，多种方式、多渠道了解现存问题，筛选有价值需求。
- 做好迭代规划，根据时间节点，确定需求优先级，跟进研发排期及上线。
- 做好需求评审，确定需求后签订需求确认单，最大限度避免需求变更，降低开发成本。
- 做好原型评审，确定原型设计与需求相符，符合需求方要求。
- 做好上线验收，确保功能的准确完善，无bug、无遗漏，符合上线要求。
整个大流程已经分享完，在产品迭代的过程中，产品经理应该始终站在全局的角度对待问题，产品的完善需要迭代，一个成功的产品背后必定有一个敢于探索、善于学习、勇于创新的主导者、先行者、开拓者，这个人就是你。
