你可能手头有一堆的需求list等着排期，但是下个版本做些什么该如何抽丝剥茧的决定呢，今天来聊一下怎么制定迭代的需求清单。

需求要从哪里来

从用户来

C端来说用户画像是个好东西，你能清楚的知道你的用户定位，心理，偏好，基于数据可以分析出下一步的需求；B端来说用户池是个好东西，需求反馈和客户拜访带来的需求往往的是需要探寻背后业务深度的；需求从用户来是需求构成的一部分。

从竞品来

别人有的，你不见得有，产品的核心竞争力在于一条维度。比如微信就是通信，snap就是拍照，支付宝就是支付，知乎就是内容。因此什么才是你的产品的核心维度，要非常清楚，挖掘竞品功能背后的需求才是竞品分析的重要之处，否则也就是只能抄抄功能改改交互了。当然，如果你的产品还处于起步阶段，可以多看看成熟的竞品功能，无害啊，因为这个时候抢占市场更重要，如果还有的抢的话。

从创新来

怎么让你的产品，feature或功能具备只被模仿不被超越的核心竞争力，往往来自于差异化的竞争，单一功能如何与整个产品的核心功能产生关联，不同模块的横向连接性也是不容易被模仿和超越的，可以从这个方面入手。

从技术角度来

如果你的产品还存在这样那样的终端崩溃，弱网下体验不优的情况，在数据监控的配合下，多去找技术大牛和大神们聊一聊，看看是否有对应的措施不断提升和优化，这部分的问题有可能是某个版本的最重要的事情。

从公司决策来的需求

这个，大家都懂得。 但是想补充的是，需要产品经理去理解公司政策及背后的故事再去做，不然会浪费大量的在沟通和调整方案上，不要让工作变繁重。

我个人还比较推崇产品的调性，这个也是判断需求做与不做的重要因素之一，不过因人而异。

当然一个需求最终要不要做，要看价值，这个也是支撑你从需求产生到落地再到上线接受审视的关键信念呐

长期规划也很重要

产品或者业务线或者一个模块功能都需要有一个半年期或者一年期的长期方向规划，你希望自己的产品一年后的目标是什么？用户留存率达到60%？产品NPS值提高至8以上？还是获得更高的日活？

这意味着需要做一个长远期的规划来确定每个迭代的小目标，这又意味着你的每个迭代中会有一个贯穿始终的任务，会有几个突出的亮点任务以及日常反馈或者数据上带来的临时调整，或者是一个feature的不断优化，快速迭代迅速验证和调整。

小迭代需求最好聚焦3个feature OR story

举个例子，如果你的公司迭代周期为6周一迭代，这意味着开发周期大概在3周，还要进行测试-集成测试-灰度-全网，这意味着这会要求产品经理不可大而全的什么需求都想做，必须聚焦，结构清晰的解决目前你的产品或者你负责的业务线遇到的问题，创造产品的机遇也是你的leader希望看到的，这也会帮助你让公司其他的部门。比如运营，市场的同学更好去理解迭代的重点。

需求清单确定后，就是后续的细化清单框架，制定核心的feature list和简要说明，和团队及leader再度确认，和技术团队确认可行性，落地原型推进UI设计，跟进开发，还原上线，等待来自用户的检阅。

如果是小的创业团队，可能更简单点，大家讨论一下就可以确定下个迭代做什么了~\(≧▽≦)/~轻松加愉快。

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