在产品的整个生命周期中，一定会遇到各种各样的需求蜂拥而至，包括部门内部由于运营需要而提出的需求，领导心血来潮提出的需求，也有通过用户投诉或反馈得来的需求，以及通过你个人对自身产品和竞品的体验以及产品的数据分析得来的需求。

同时你还得负责项目的跟进，新版本的规划等等，在这个过程中你既要面对项目研发过程中的诸多问题，又时时刻刻面临需求的不断轰炸，这时候我们就会感觉到事务非常的多且杂乱。

所以，理清楚产品的整个规划的流程就非常重要，这套流程能够帮助自己理清思绪，让你知道你现阶段应该做什么，接下来要做些什么，这样才能让自己的工作非常有条理，也会让产品的迭代更有节奏。

需求管理

需求管理是做产品的人最首要也是最核心的任务，一款产品遇到的所有的需求最终都将汇集到我们产品人这边过来，如果没有及时做好需求的记录和把控，就很容易造成需求的遗漏，重复记录等，最后讲导致产品规划的混乱。

产品需求的产生主要有以下四种方式

1.产品研究

产品人每天至少需要对自己的产品以及竞品反复体验在30分钟以上，并记下体验过程中得出来的需求点。

2.用户反馈

每天定期查看产品的用户反馈后台，自建渠道包括qq群，贴吧，社交媒体是否有用户投诉反馈，清楚问题之后记下需求点，若是属于bug或者急需解决的需求，立刻反映给开发解决，若是属于不紧急的需求，则列入版本迭代规划中。

3.用户访谈

如果所在公司有资源，可以定期召集目标用户群体进行访谈，如果没有，也可以召集公司或者部门同事进行访谈，询问他们需求点在哪里，记录下来。

4.数据分析

产品人需要每天或者至少一周对产品进行全面的数据分析，输出数据日报或者数据周报，总结产品遇到的问题，得出需求点，记录下来。

需求管理表

产品版本迭代规划

每个特定的时间都需要对产品的现状进行一番梳理和总结，理清楚产品上线后的效果是怎么样的，接下来的方向应该怎么走。

做产品一定不能盲目地去加各种各样的需求，或者毫无目的地去做版本迭代。每个版本的需求一定都是基于产品目前的现状，市场的情况，最后基于产品发展的目的而去做的。

产品规划包括以下两点内容

1.月度数据分析

先对本月产品的数据情况进行分析总结，得出问题点，输出数据月报

2.需求汇总分析

在上文已经提到，我们每天都通过四种方式去采集各种各样的需求，现在就是运用它们的时候了。

我们就需要把之前收集到的所有的需求点以及数据月报得出来的需求点进行打包，结合数据月报得出来的结论进行综合分析，然后思考接下来半年的版本迭代规划。

例如我们接下来半年需要分为几个版本去迭代，每个版本分别要花多少时间开发，以及每个版本应该做哪些需求。

当然，有一些需求是无法确定什么时候做的或者是半年以后才有可能去做的，那么就把这些需求列入到“待定版本需求”中去。

版本迭代计划表（产品规划表）

做完产品版本规划之后，我们就已经把之前收集到的所有需求都封装到上面那几个表格中去了。

接下来我们依然需要每天进行需求的收集，但是收集到的需求不能马上添加到这几个表格中，而是仍然需要等下一个时间点来了之后，再次重复上文所说的产品版本迭代规划之后，再将收集到的需求添加到表格中去。

原型设计

半年的版本迭代规划做完后，对接下来新版本要做什么需求就非常清晰了，所以接下来就需要将新版本规划好的需求进行落地了。这一点就不需要我多说了，原型阶段应该是最简单的，每一个入门级的产品经理必经的阶段。这个时候的原型不需要做得很细，只要能够理清需求的逻辑就可以了，因为原型主要是用来和技术对接的，把需求讲清楚就可以了，更细节的产品逻辑需要通过完整的需求文档来描述。

技术对接

完成新版本的原型设计之后，此时上一版本的需求技术估计也差不多开发完了，那么接下来就是召开技术的对接会议，当然，撕逼是免不了的啦，你之前规划好的版本迭代计划一定会因为各种技术实现原因而大动刀子。

经过技术对接会议之后，我们需要将产品的需求点以及需求原型通过邮件发送给技术，让技术评估需求的问题点以及实现难度。评估结果出来之后，产品部门内部需要进一步地讨论，此时我们要做的就是去调整版本规划表的需求划分，例如有些需求这个版本不能实现的，就下移到下一个版本，有些需求压根不能实现的，就直接删除，有些需求实现难度太大的，就可以直接放到待定版本需求里面去。

需求文档

经过技术的评估，产品部门内部讨论之后，新版本的需求和原型基本就定下来了，此时并不能马上就把需求和原型递交给技术就完事了，因为原型毕竟是通过原型软件画出来的，不是通过文档写的，很多产品的细节逻辑无法很清晰地通过大量的文字写出来，这样会导致技术需求理解不清楚，这样后面就会导致各种各样的问题，不仅如此，在产品开发的过程中一定会遇到各种需求变更的情况，每一次对需求的修改都需要做一次记录，这样方便项目组查看，也有利于后续对需求变更记录的追踪。所以，总体来说，详细的产品需求文档是必不可少的。

项目跟进

项目跟进之前，产品人需要和技术去沟通需求实现的时间节点，例如前端的哪些需求在哪个时间点能完成，后端的哪些需求在哪个时间点能完成，将沟通后的结果输出成项目里程碑，产品人要做的就是盯着技术是否按照项目里程碑上面的时间节点完成需求的开发，如果不行，该赶就得赶，该撕逼还得撕逼，随时准备为项目顺利上线牺牲。