提产品需求是运营同学的日常工作之一，看似简单，其实并不容易
这些反馈通常都不会很明确，需要运营同学进行整理挖掘、沟通调研进而提炼出需求
如果不经整理提炼就统统丢给产品跟研发同学去处理的话——会被鄙（qia）视（si）的…… 2.改进型需求和新建型需求： 它们俩是从1到10和从0到1的区别
我个人的建议是已有的产品如果改进优化后能用，尽量不要另起炉灶，除非是原有的产品从定位到风格全都跟新需求不一致
这里一方面关系到效率，能否快速运用已有产品达到业务目标，而不是只能等着新产品上线错过宝贵的窗口期；另一方面关系到借势，是否能够借助已有的流量或者品牌优势来加速业务目标的实现
这就要求运营对公司内部现有产品定位跟功能了如指掌，对公司外部可以利用的现成平台和资源也非常熟悉，从而能够根据需求制定出合理的问题解决方案，有时甚至可以不需要产品改动和新增就能达到目的
3.笼统型需求和精确型需求： 前者如：「现在这个编辑器太难用了换一个吧，好多代码格式都不支持」； 后者如：「需要一个除现在支持的代码格式外，还能够支持markdown语法的编辑器」
很多用户反馈的需求就是前者那样的，必须深入了解分析，否则过于笼统不具体的需求，是无法实现的，即使勉强上马，也一定会因为需求不明确而导致工期延误和反复修改，最终应付了事，所有参与人忙得够呛都不开心，宁可早期多用一些时间把需求搞清楚
为什么要从这些维度来划分呢，因为实现产品需求的资源通常是有限的，因此必须对需求的合理性和优先级做出明确判断，并以此来决定开发的资源投入以及排期先后
另外有些似是而非的「产品需求」，实际上并不是需求而是bug，bug和产品需求的区别及处理方式的不同如下： 产品需求： 针对还不存在的功能提的 解决的是「不好用」的问题 实现周期通常较长 发给产品经理处理（这个要看具体团队构成和分工，是否有专门的产品经理来处理需求，如果运营兼负责产品那就由提出需求的同学自己处理了） 产品bug： 针对已经存在的功能提的 解决的是「不能用」的问题 解决时间视bug严重程度，通常要求尽可能快地处理 可直接发给研发人员解决 提需求和提bug的流程 产品需求描述 产品经理通常需要把收到的各路需求整理成产品原型文档，但对于运营同学来说并没有那么严格的文档要求，只要让产品同学能够明白你的意思就可以；不过为了提高沟通的效率，有必要参照一定的格式来描述你的需求，这里举个我现在团队的例子： 1.需求名称： 产品名称+功能+提出时间，如「编辑后台改进产品需求-2015-8-17」 2.目的： 有助于产品同学充分理解你的需求的必要性和重要程度，如「为了提高编辑发稿的工作效率」或「为了统一网站整体风格而进行UI重新设计」
3.优先级和时间要求： 这个也很重要，因为产品经理通常会收到大量的需求，如何安排优先级处理顺序？如果你在需求里有明确的说明，那么处理效率会高一些
如「第一优先级，需要六月15日前完成」
4.需求描述： 说明用户身份（外部用户和内部用户的处理方式有区别），页面需要包含哪些元素，期待的布局和风格，排列顺序，是否必选项，有何特殊要求，是否需要查询及查询条件设定，是否需要权限管理等信息，尽可能详细，最好给出参考案例或类似竞品截图
什么情况下需要提产品需求 如果以上你都已经烂熟于心，对于如何提产品需求应该是没有问题了
但是且慢，知道怎么做只是最基础的，对于合格的运营来说，更重要的是判断要做什么和不做什么
用户的需求永无止境，运营不能只是需求的传声筒，需要深入分析用户需求背后的目的和隐藏的问题，如果能够用已有的产品达到的，就尽量不要重复建设做新产品；如果能用运营的手法解决的，更不必兴师动众地动用产品和研发；如果能够利用已有成熟的渠道跟平台借势推广的，又何苦非要做一个「自己的」独立平台一切从零开始呢？ 做加法永远比做减法容易，另起炉灶似乎也比在原有基础上修补改进要痛快（某些情况下，也被看做是业绩的体现），但是资源永远都有限，无论是人力还是时间，即使你有一组强悍的产品和研发同学 24 小时无条件配合，仍然要评估需求真实的价值有多少，衡量投入产出比
运营的强项在于给你一个产品，你能够发掘它的一千零一种用法（玩法）并将其传递给用户来满足业务的需求，如果一接到新需求就要做个新产品，而不是先看看运用已有的产品是否能够解决问题，运营自身的价值何在呢？ 案例一：数据分析后台 曾经有同事负责运营一个垂直专业领域的群组，提出要做一个数据分析后台，能够根据加入群组用户填写的个人信息自动生成各种维度的分析图表，「就像专业的数据分析报告那样」，他说
这并不是一个实现起来很简单的需求，虽然对用户的数据分析是有必要做的
但是该群组目前的注册用户只有几千人，且新用户增加速度非常缓慢，用户数据分析的时效性并不是非常高，因此最终解决方案是导出用户数据到Excel中，运营自己根据统计需求，利用Excel生成分析图表，至于是否像专业报告，那就看自己的Excel造诣啦~如果未来用户量和增长速度达到一定规模，人工统计无法满足，才是需要开发数据统计后台的时候
案例二：大会报名App 我所在的社区运营团队曾经负责组织公司的开发者大会报名，通过社区各个渠道向开发者用户进行宣传，使用的是社区的活动报名系统，可以汇聚各个渠道的报名数据到后台数据库
有同事提议说开发一个大会报名App，以后组织大会都可以让用户通过App报名，这样推广时只要通过App推送提醒就可以啦~~~我说你这个创意不错，你先想法让用户都装上这个App，然后
就没有然后了
总之收集到需求后，先问自己以下几个问题： 目标足够明确吗？ 已有的产品确实无法满足工作要求吗？ 已有产品的缺陷已经极其影响工作效率吗？ 成本是否合适？ 如果答案有任何一条是否定的，那就需要重新审视这个需求的合理性，并且和需求方积极沟通确定最终解决方案
↓↓↓ 人人都是产品经理APP新版上线，点击” 阅读原文 “立即下载