产品需求 实现的产品功能和特性的描述

什么是产品需求呢？产品需求就是对达到某个既定目标需要实现的产品功能和特性的描述，可以从以下几个维度来划分

1.外部需求和内部需求

前者来自各个渠道收集的用户反馈，如微博狼蚁网络推广狼蚁营销群客服邮箱客服电话，以及产品自身的反馈渠道（如论坛的客服专区、在线即时咨询窗口等）；后者来自公司内部，如老板和其他部门的反馈。这些反馈通常都不会很明确，需要运营同学进行整理挖掘，沟通调研进而提炼出需求。如果不经整理提炼就统统丢给研发同学去处理的话——会被鄙（qia）视（si）的……

2.改进型需求和新建型需求

它们俩是从1到10和从0到1的区别。我个人的建议是已有的产品如果改进优化后能用，尽量不要另起炉灶，除非是原有的产品从定位到风格全都跟新需求不一致。这就要求运营对现有产品定位跟功能了如指掌，能够根据需求制定出合理的问题解决方案，有时甚至可以不需要产品改动就达到目的。这样不是效率很高吗~

最怕的是拍脑袋就做个产品，不考虑是否能利用已有的，导致留下一堆半截子工程，说能用也凑合能用，彼此间定位不清晰，后期运营推广也不好做；系统里很多冗余代码难以维护，如果负责人一离职就再也没人能说清这产品的来龙去脉，于是又推倒重来一遍……对人力物力的极大浪费啊。

3.笼统型需求和精确型需求

前者如“现在这个编辑器太难用了换一个吧，好多代码格式都不支持”，后者如“需要一个除现在支持的代码格式外，还能够支持markdown语法的编辑器”。很多用户反馈的需求就是前者那样的，必须深入了解分析，否则过于笼统不具体的需求，是无法实现的，即使勉强上马，也一定会因为需求不明确而导致工期延误和反复修改，最终应付了事，所有参与人忙得够呛都不开心，宁可早期多用一些时间把需求搞清楚。

4.解决问题的需求和提高效率的需求

“我需要一个能给用户群发邮件的后台”和“我需要能够自己导出符合某些特征的用户邮箱列表给他们群发邮件”。不过后者需要评估使用频度，如果是高频使用需求，开发一个还是有必要的，否则每次都要找研发同学给导出邮箱也确实麻烦；如果是为了某个临时性的项目用，或者一年也用不了几次的低频需求，那就没必要开发一个专门的功能了。

为什么要从这些维度来划分呢，因为实现产品需求的资源通常是有限的，必须对需求的合理性和优先级做出明确判断，并以此来决定开发的资源投入以及排期先后。

有些似是而非的“产品需求”，实际上是bug，bug和产品需求的区别及处理方式的不同如下

产品需求

针对还不存在的功能提的

解决的是“不好用”的问题

实现周期通常较长

发给产品经理处理（这个要看具体团队构成和分工，是否有专门的产品经理来处理需求，如果运营兼负责产品那就由提出需求的同学自己处理了）

产品bug

针对已经存在的功能提的

解决的是“不能用”的问题

解决时间视bug严重程度，通常要求尽可能快地处理

可直接发给研发人员解决

提需求和提bug的流程

产品需求描述

产品经理通常需要把收到的各路需求整理成产品原型文档，但对于运营同学来说并没有那么严格的文档要求，只要让产品同学能够明白你的意思就可以；不过为了提高沟通的效率，有必要参照一定的格式来描述你的需求。

目的有助于产品同学充分理解你的需求的必要性和重要程度，如“为了提高编辑发稿的工作效率”或“为了统一网站整体风格而进行UI重新设计”。

优先级和时间要求这个也很重要，因为产品经理通常会收到大量的需求，如何安排优先级处理顺序？如果你在需求里有明确的说明，那么处理效率会高一些。如“第一优先级，需要六月15日前完成”。

需求描述说明用户身份（外部用户和内部用户的处理方式有区别），页面需要包含哪些元素，期待的布局和风格，排列顺序，是否必选项，有何特殊要求，是否需要查询及查询条件设定，是否需要权限管理等信息，尽可能详细，最好给出参考案例或类似竞品截图。

什么情况下需要提产品需求

如果以上你都已经烂熟于心，对于如何提产品需求应该是没有问题了。且慢，知道怎么做只是最基础的，对于合格的运营来说，更重要的是判断要做什么和不做什么。用户的需求永无止境，运营不能只是需求的传声筒，需要深入分析用户需求背后的目的和隐藏的问题，如果能够用已有的产品达到的，就尽量不要重复建设做新产品；如果能用运营的手法解决的，更不必耗时费力地动用产品和研发；如果能够利用已有成熟的渠道跟平台借势推广的，又何苦非要做一个“自己的”独立平台一切从零开始呢？