确定迭代节奏
如果产品已经进入维护阶段，即无论搞什么都不会造成利润大幅变动，那大家可以轻松点，每个需求都不限时，做完为止。在前中期，为了配合快速迭代或敏捷开发，则需要限时。一般会把迭代周期定成两周或一月。固定节奏有助于提高团队凝聚力和协调度。
请注意，是迭代周期决定周期内做多少需求，而不是需求数量决定迭代周期。这会要求需求的总工作量贴近迭代周期，否则就得进行拆分（下节细述）。
实际的迭代计划可以微调多一两天，比如：需求真的无法拆或不想拆到两周计划内，那可以做三周计划，或者对此需求安排并行开发。但如果要四周，最好还是拆成2个两周。
如果排不满，那也不用把技术部门的资源用尽。空档期可以让他们组织重构、分享知识等。对不同的技术部门，安排会有差别：
app每月发布两个版本：一个版本是大版本，一个版本是修补的小版本。
前端项目：
web app、hybrid app、微信小程序的迭代应该和app一致；网站项目，一般除了第一版和大改版都不会有大需求，所以做完一个需求就上线一个；h5活动页，无论多小的改动都立刻改好并上线。后端项目：
配合前端或app的项目，跟随即可；中间件型业务，可以按app的节奏迭代；给内部人员用的系统，由使用者决定需求优先级，可在闲时更新。如果某些部分是紧急需要的，可以拆出来先做。
需求规划
做好规划要有需求池的帮助。需求池最基本的作用是防遗忘，就像个记事本。在它的基础上做好梳理，就可以得出版本规划。如果需求池用excel来管理，可以有这些列：
（1）简述：最好只有一句话；
（2）优先级（下节细述）：可以不要这列，直接在排序上反映；
（3）状态：未定，正在写，正在开发（哪个版本），已发布。可以不要这列，通过改变行的背景色来反映，例如已发布的是灰色，正在开发的是绿色。已发布的需求也可以删除或放到别的地方；
（4）关联：依赖哪个需求得先做完。
（5）备注：
可以写上来源。比如是谁提的需求，真要做了可以再找他讨论细节；可以用来写更详细的描述，免得遗忘；预估的开发时长。请注意，需求不一定只来自产品经理或运营的idea。技术需求、bug修复、运维事项等都可以放进需求池。不会直接影响营业额或者可随时修补的东西，可以交给开发自己规划，穿插在日常中实现。
在做整理之前，要对开发的战斗力心中有数，也就是自己能预计开发说这个需求要做多久。不管是否限时完成，都要对资源占用时长有个预期。如果有需要，可以找开发主管做个简单讨论。
整理的结果就是让需求安排符合迭代节奏，可以对需求做合并、拆分、删除（不做），其中最多的操作应该是把超过2周工作量的大需求拆成小件，拆分的思路只有一个——不影响核心功能的就可以拆。
比如：
评论需求：在评论中穿插表情可以拆，点赞可以拆；某业务的推送通知、分享功能；额外的动画交互效果。确定在下个版本要做的需求，应另外列出带时间表的开发计划。
更大规模的整理，会得出多个月的迭代路线图，总结出主题，甚至倒推出产品战略。清晰的目标能让团队更有凝聚力。
优先级
优先级可以分4级：
核心：必做，先做，不能砍，不做完就不发布新版本，可单独形成一轮提测；高：必做。条件不允许的话可以降低为中优先级。可单独形成一轮提测；中：如果时间允许，会做；低：可以不做。判断优先级最基本的原则是向钱看——对商业负责。不要用冠冕堂皇的理由，如公司战略、老板决策什么的来思考，要更直接的。一句话概括，需求的价值等于“产品在单位时间内创造的利润增幅”。
它可以分解为3个层面：
创造或提升价值；降低成本；提高产出效率。其中第1点是可以估算的。首先我们假定成本在第一个版本时就固定了下来，那么利润的增幅约等于收入的增幅。
这几条公式是估算收入的：
收入 = UV * UV转化率 * 单价。也可以用PV算；UV = 新增量 + 留存量；裂变的新增量 = 分享数 * 分享转化率；最终转化率 = 1 – 各环节的流失率之和。以上4个公式仅作为举例，还能继续把其中的变量拆分得更细，可留意它们跟价值的正负相关关系。我们要做的是评估需求能影响哪个因子以及程度如何，从而间接得到它对利润的贡献程度，以此作为量化手段来得出优先级。
这也就是所谓的数据驱动，其中的常量可以用现有数据、经验、业界数据、其它案例参照来确定。当然，常量在不同场景下还是会变的。
降低成本的某些方式也是可以量化的，比如提升性能从而降低服务器配置要求，或者进行数据压缩节省带宽，这甚至可以得出准确的成本值。除了各种机器投入的成本之外，最大的成本是人的薪酬。这方面的降成本手段通常是做自动化取代或部分替代人工，比如AI客服。
提高效率也就是提高单位时间的产出，一般是实行完毕才能得出它的价值，所以事前只能主观评定。自动化也是提高效率的方式之一，比如提升后台系统体验，让运营可以一键对用户推送通知或在多个平台发广告等等。
另外，通过重构、规范化等方式来解决历史遗留问题也能提高效率。而且效率也应包括质量的考量，能辅助整个迭代过程提高质量的手段也得考虑在内。
并行
团队人数足够多时，不仅是一个版本内的需求可以同时做，跨版本的需求也可以。当然，这时候应该也是多个产品经理同时参与的，最好是各自负责无关联的需求。如果能理解程序员的并行开发方式，知道合并代码的过程以及风险，那也许能把需求拆得更独立些。总体来说就是人和需求都要减少耦合。
还有一种并行的方式，可称作专项：一个大需求被拆分成多个小需求并在多个版本陆续上线。一些微服务、子系统的需求，相当于子项目，也可以看成专项。专项实施的前提是这个大需求足够的独立，跟主线版本的迭代基本没冲突。这进一步考验产品经理的需求整理能力。
更大规模的团队合作，问题就改变了，不是“这个版本要上线哪些需求”，而是“这个需求要在哪个版本上线”。也就是多个小团队围绕着各自的需求来开展工作，做完后再选择合并到哪个版本上线，这种模式常见于大型开源项目。
