作为产品经理，每天都在接触大量的需求，有来自产品本身的完善性需求、来自用户的反馈性需求、来自业务或运营的改善性需求等。
作为产品经理，你是否也遇到过，面对一些需求，内心万马奔腾，表面尴尬一笑。
“请给我一个五彩斑斓的黑！”，可能是大部分产品经理在面对一些不合理需求时时，内心真实的写照。
除了不合理需求外，其实很多时候对需求的理解偏差，都是我们的需求方不知该如何合理地表达和陈述一个需求导致的。
需求方们可能是做运营的、做销售的、做财务的，也有可能是我们最宝贵的用户们。
他们大部分是非产品和技术背景，所以会从本我的角度去理解自己面对的产品问题，然后以自己理解的方式提出来。
例如运营提了这么一个需求：
想在后台一下子看到所有的订单数据，然后分区域筛选。
而此时的产品一次只能展示20条，然后需要翻页查询。这时候我们是去把每页展示20条变成200条呢，还是采取其他的办法？
上面例子中，首先，我们可能先从技术角度理解一下，数据展示为什么要分页？
列表式的数据，例如全部订单、朋友圈内容、微博内容等，都是分页展示的，每一次我们翻几屏，就会有一个加载的过程。
理论上，我们可以一次性把所有的数据全部先取回来然后展示。但实际上，受限于网络请求过程中大数据量的获取，会造成网络请求时间过长而影响用户体验，如果数据量比较大的情况下全部加载，用户等待的时间会比较长。
所以，通过分页加载的设计，单次请求数据量控制在合理范围内，缩短单次加载时间，给用户及时反馈，同时将大量数据分片分次加载显示，在系统性能上也会优化不少。
回到运营的需求，我们把单页加载数据量由20改为200能解决问题么？显然不能，因为运营要看的是全部数据并做筛选。
而从提需求的角度把问题拆开看，经过了解后，运营的需求实际是这样的：
运营希望查看所有订单中处于待出库状态的订单，然后通过区域筛选这些订单分别分布在哪些地方，最后分别汇总加和计算每个区域待出库订单的总金额。
而现有的产品里，实际上真正无法满足的点在于，对最后筛选出来的订单进行分区域求和操作。并且，订单列表分页显示，筛选结果无法一次看全。所以才引出了运营提出的这个需求。
我们从前文中提到的运营需求“想在后台一下子看到所有的订单数据，然后分区域筛选。”中可以看到，这个“分区域求和”的核心问题并没有表达出来。
而解决这个问题的产品方案，实际上是给运营提供一个批量导出的功能，运营在后台通过筛选功能筛选出数据后，然后一键导出所有的结果数据到Excel文件里，然后在文件里进行求和操作，并且把文件分发给其他需要的运营团队。
在上面这个例子里，产品需求是分页显示，而问题确是没法求和，产品方案却是一个导出功能。
很多时候，产品经理们都是在面对和处理这样的需求，我们作为专业方，没法要求各种背景不同的需求方以同样的专业方式来给我们提需求，所以，挖掘核心关键需求的能力就非常重要。而挖掘需求，是有章可依的。
接下来，我将提供一个我经常使用的挖掘需求的方法，供你参考。
一、谈需求前，先明确问题是什么
首先，每一个需求，在我看来都是一个“问题”。前面有提到，这个“问题”可能是来自产品本身的功能不完善、来自用户使用过程中的问题或习惯、来自业务或运营的一些特殊场景需要。
例如上面例子中，就是一个运营在实际业务开展中遇到的一个特殊场景需要，而恰好现有的产品功能不支持。但运营又没有把遇到的核心问题表达出来，却提出了一个产品方案。
所以，谈需求前，先明确问题是什么。我通常会问我的需求方，“你遇到的问题是什么？”，是操作习惯问题，还是在做某一个任务时，现有的产品无法满足。
引导需求方，把问题场景聊出来。
“问题”不是“我要一个...功能”，而是“我在做...时，为了达到...的目的，需要通过产品完成”。
前文例子中的“问题”是订单按状态分区域金额求和，而不是“看所有订单数据，再分类筛选”。
二、说需求时，先别讨论解决方案
其次，讨论需求的过程中，把焦点放在问题上，明确需求场景，即“谁在做什么时遇到了什么问题”。
很多时候，讨论着讨论着就会变成对产品方案的讨论会，即讨论如何做，而忘记了原本要解决的问题是什么，回过头来，却不知道要解决的问题是啥。这种情况非常常见。
产品经理要成为沟通的组织者，引导需求方把关键问题和场景描述出来，而具体的产品方案可以在理解并明确问题之后，结合现有情况做综合考虑。
什么是沟通组织者？就是以“问题”为导向和主线，定义问题是什么，以及组织商讨如何设计问题的解决方案。沟通过程中一旦产生偏差，沟通组织者需要及时把与会者拉回来，回到定义问题和解决方案的轨道上。
聚焦“问题”，而非“方案”。产品经理只有做好沟通的组织者，才能合理的引导需求方把关键问题表达出来，从而针对问题设计产品方案。
三、聊需求后，明确边界和优先级
定义清楚需求对应的问题，确认了需求解决方案后，最后一步就是明确需求边界和优先级。
需求边界就是问题边界，明确需求边界的目的是保证需求对应问题的纯粹性，一个需求解决一个问题，如果一个需求对应多个问题，就拆分成子需求。这样既可以保证需求的原子性，也便于在研发阶段做任务拆分。
例如前文的例子中，需求边界就是将现有订单列表按条件筛选导出。如果再增加一个其他的筛选条件或者对列表做排序处理，就处于需求边界范围外的事，可以再独立成子需求。
最后一步，就是明确需求的优先级。需求方往往会觉得当下的问题都很紧急，恨不得提出的需求今天满足，明天上线。
但资源永远都是有限的，无论是产品还是设计或者是研发资源，都无法同时满足所有的需求。所以，需要对需求进行优先级划分，目的在于实现有限资源的高效利用。
划分需求优先级也有几种办法，首先是对需求进行分类，例如bug类的需求，是产品的线上问题，如果影响到线上产品的用户使用，就需要立刻修复并上线。这属于非常紧急的需求。
还有就是正常的需求，根据需求对应的用户价值和业务价值进行衡量，用户价值高或业务价值高，可优先支持。
其次，对需求的紧急程度进行分类，有的需求重要但不紧急，可以放缓处理。例如给用户提供批量快捷操作的需求就不如解决一个搜索bug来的紧急，但它们都很重要。
面对需求方，产品经理需要在方案达成一致后，进一步达成需求优先级的一致，下一步好进行设计和研发资源的跟进和分配。
最后
作为产品经理，每天从我们面对的需求中去提炼挖掘需求的方法，并学会引导需求方描述问题而非解决方案，成为沟通组织者。这个过程的不断重复，会逐渐培养和加强自己分析问题和解决问题的能力。
当你再次面对“我要一个五彩斑斓的黑”这样的需求时，是否有办法、有对策去化解需求呢？
上述，就提供给你一个如何正确提产品需求的方法框架，供参考！
------------------END------------------
