要诀：为什么+挖判定
一、为什么要迭代？（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评审→开发
在整个产品发展过程中，做好迭代其实并不难，关键是迭代流程一定要规范，作为产品经理需要“挖–判–定”
挖：挖掘用户对产品的真实评价及建议，挖掘让用户“爽”的爆点等。
采取线下一对一的沟通，先从线上（QQ群、微信群）选择了一批较为活跃的用户，然后一对一的面谈，了解用户的真实体验及感受，针对产品分析问题，然后解决。除了用户，还要做好与其他部门的沟通，找到各个渠道反馈的问题，共同商讨解决方案。
判：判断所有需求的可行性、明确性。
很多用户会提出一些“奇葩的需求”，而这些需求我们无法满足或者很多需求是不合理的，在这个过程中，我们要学会过滤。在得到需求后进行需求可行性判断，明确此需求确实有必要并对产品发展有建设性作用。
定：确定需求，评审会。
在整个1.0–2.0的过程中，经历最多的会议是“需求评审会”，这个会议需要公司相关部门的领导及核心人员参与。各部门提出需求，由产品经理汇总需求、发起会议，共同评审。需求评审的目的在于不同部门、不同人对同一需求的看法和见解不同，站的角度也不同。如果一个需求提出后，各个部门一致通过，那么这个需求就是可行的。
学习某课程内容，摘抄记录（有增改）。
