这个问题源自人人都是产品经理的讨论群，其实是个挺大的话题，在此仅以我的个人理解为大家分享一二
我理解这个问题，是要思考一款产品如何通过不断打磨其核心模块，让产品更有竞争力。那么迭代好这样的功能模块，可以从：需求收集、价值评估、逻辑梳理、迭代计划、可扩展性评估几个角度来思考和判断。
1、需求收集。
这里的需求收集，包括从内部收集需求、用户收集需求、市场收集需求、竞品收集需求几个角度。
内部需求。指公司领导对这个功能的预期，运营人员在推广这个功能时的想法，开发人员在开发这个功能时的建议等等，目标是让公司内部对功能的发展达成一致。
用户需求。指通过反馈系统、用户群、一对一沟通收集到的用户对这个功能的体验感受，从用户角度来评估需求是否受到认可，及有何提升的空间。
市场需求。指市场对这类功能模块的认可度，这决定了这个功能是否有继续开发下去的价值。市场需求可通过看各类市场分析报告作出初步判断。
竞品需求。就是同类产品是如何优化这个功能的，是否有可以参考的点，以及是否结合我们功能的特色有更优方案等等。
2、价值评估。
收到了需求后，就要思考需求的价值，也就是解释清楚为什么我们要实现这个功能模块的某个需求。换句话说，不是所有的需求都有实现价值的，要从实现成本，后期运营维护成本、功能可复用性、功能实现带来的收益（流量收益+物质收益）几个角度进行重要度评估；从短期不实现需求带来的损失，实现需求后长期带来的好处等角度进行紧急度评估。优先考虑实现这个功能块重要度高、紧急度高的需求。
3、逻辑梳理。
决定做哪些需求后，就要思考怎么把这个需求的业务前因后果说清楚，可以借助流程图、结构树的方式梳理框架，再将不同场景下不同角色的人会遇到的不同业务逻辑描述到位，目的是给需求实现部门（通常是开发）讲清楚实现需求的步骤，尽量将所有可能的分支都考虑清楚。
4、迭代计划。
准备工作做完后，就要思考如何实现了。对于比较完整的功能模块，比如用户激励体系，需求可以用“无穷无尽”来形容，那具体什么时候，先实现哪些功能？后实现哪些功能，就要考虑产品经理的产品规划能力了。判断标准可以参考“2、需求评估”中的方法，但前提是每迭代需求要实现的是一套完整逻辑。因此“3、逻辑梳理”工作也要提前做好才能进入迭代计划。
5、可扩展性评估。
按照迭代排期开发后，产品经理还要随时关注上线后的功能表现，用户是否认可我们实现的需求？是否有新需求可以复用这个已实现的需求，以及这个已实现的需求是否可以衍生出新的场景、新的需求，如果可以，那可以重新进入到“1、需求收集”阶段，再开始新的打磨过程。
以上就是我的功能迭代方法论，实际工作中也是在这么做的，你也可以试试看~希望对你有帮助，有问题欢迎随时留言哦~
