编辑导读：在工作中很多产品经理都会遇到这种情况：千辛万苦做好的功能上线后，前来验收的运营却说这个功能不是我想要的。明明这是按照运营的需求来做的，为什么会这样呢？本文作者针对这个问题展开自己的思考，希望对你有帮助。

相信不少产品经理都遇到过这样的问题，在做原型设计的时候感觉功能已经很完善了，但等上线后，运营验收的时候却说这个功能不是我想要的，然后又提出一堆待优化点和新需求。你可能会疑问，当时是按照运营所提的需求来做的呀，但最后运营为什么会变卦呢？

出现这样的问题，主要原因是因为需求分析不准确，导致产品设计的方向跑偏了，所以最后做出来的功能自然不能满足用户需求了。

笔者在入行前也曾多次遇到这样的问题，当时只觉得运营的需求太善变了。时隔多年，自己也积累了不少项目经验，今天就结合自己的经验做下复盘，分享一下个人感受（运营人员也是我们的用户，所以，以下文章均称为用户）。

《代码大全》的作者Steve McConnell报告说，产品60%的错误存在于设计中，而设计的错误60%的源于需求和分析活动。所以，能准确的挖掘到用户需求，对于产品经理来说是多么重要的事情。

01 用户所说的未必是真的

有一个说法叫“冰山理论”，它指的是一个人的“自我认知”就像一座冰山一样，我们能看到的只是表面很少的一部分，而更大一部分的却隐藏在更深底层，不为人所见，就像漂浮在海面上的冰山一样。

用户的需求也像一座冰山，有很大一部分隐藏在海平面以下，只有很少一部分需求暴露在海平面以上。

有时候我们收到用户需求后，也按他们的要求做了，但上线之后发现所做的东西并不是他们想要的，或者说是不完善的。

这时候如果你如果质问他们“当时怎么不说清楚呢？”，那他们就会反问你“你是产品经理，这些都是你该考虑的，我只负责提需求”。

这时候你应该责怪谁呢，是怪自己还是怪用户。事实上他们所提的需求只是他们已经意识到的，更深层次的需求隐藏在冰面下那些没有意识到的需求，当然没法告诉你了。

这就给我们的需求调研工作带来了很大的困扰，这时候产品经理就应该从自己专业的角度上触发，帮他们找到那些隐藏在冰面下的需求。我们经常所说的需求挖掘，主要就是找到隐藏在冰面下的需求。

所以，用户的需求分成意识到的需求、无意识的需求、进一步的需求三种。

• 意识到的需求：在海平面以上的需求，通常是一些困扰用户的问题，或者是用户自己能想到的功能。大部分产品经理在调研的过程中获取到的都是这一类的需求；
• 无意识的需求：它是用户在实际工作场景中“没有意识到的问题”，这种问题需要产品经理对业务有一定的理解才能发现。只有对这类场景能做到“感同身受”的话，产品经理设计的过程中才能够设计出更合理、更高效的方案；
• 进一步的需求：对于用户遇到的问题，他们毕竟只是普通的工作人员，并不是技术专家。因此对于他们自己遇到的问题也没有办法提出关键的解决方案。因此需要产品经理对问题充分理解的前提下，选择合适的实现方式以创造用户未想到的功能；

举个例子，夏天的时候男生们都喜欢到操场上打篮球，打到中途口渴的时候一般都会到自动售卖机上买饮料。请问，对于打篮球的男生来说他们的意识到的需求是什么？对，他们的需求是想喝水解渴。

那没有意识到的需求是什么？他们想喝水的目的，首先是因为运动激烈，水份消耗过快，所以想要喝水口渴。另外激烈的运动会让身体产生大量的热烈，他们想给身体降温。

那进一步的需求又是什么呢？男生们出去打篮球往往是穿上篮球服，随身带着手机就出门了，但是打篮球总会弄着双手，如果用手机支付的话就会弄脏手机，这时候如果这个售货机能提供刷脸支付的功能，对于男生来说就是解决了他进一步的需求了。因为在刷脸支付技术没有出现以前，他们是不知道不用手机也可以实现支付的。

所以通过这样的场景设想，我们就可以整理出男生打球的过程中意识到的需求是喝水接口，无意识的需求是想要喝冰水，进一步的需求是刷脸支付。

02 如何抽丝剥茧，抓住真正的需求

首先，我们应该把用户需求做个分类，只有将需求做好分类，我们做需求挖掘时才能有的放矢。

我们可以将用户的需求可以分成基本需求、期望需求、兴奋型需求。

• 基本需求就是一个产品必备的需求，这类需求是即使用户不说，在做产品设计时也应该考虑的。
• 期望型需求就是用户期望做到的，一般是用户能比较清晰的知道的，一般是用户提出来的。
• 兴奋型需求就是超预期的需求，一般是用户没有意识到的，也就是隐藏在冰山下面的需求。

一个产品一般会经过导入期、成长期、成熟期和衰退期四个阶段。

在产品的导入期应该着重满足用户的基本需求。在产品的成长期应该选择性地去满足用户的期望型需求，并且完善原有的需求。在产品的成熟期关注更加细节方面的需求、体验性的需求，以及挖掘其他隐性需求，也就是超预期的需求。产品的衰退期，这时候产品经理需要考虑怎样去挖掘更多新的需求去满足用户，甚至开拓新的产品项目。

那么，我们应该怎么去挖掘用户的需求呢？我们怎么判断他们所提的需求就是他们想要的呢？

首先让我们先来看个例子，妈妈带小明一起出门逛街，小明突然说“妈妈，我我渴了，想喝水”，这里的想喝水是小明的基本需求。因为小明说的“口渴”是现状，而水能解渴，应该顺便给他买瓶矿泉水。

所以我们通过上面简单的案例可以看出，需求分析的第一步就是逻辑推理。通过用户所提的需求进一步进行逻辑推理。小明“口渴了”案例逻辑推理就是：口渴—水能解渴—买矿泉水。

但是，如果妈妈给小明买瓶矿泉水真的能满足他的需求吗？不一定，那如果他刚出门才喝过水，刚一出门路过奶茶店就说自己渴了，那可能是他想喝奶茶了。如果给他买瓶矿泉水就不能满足他的需求了。

所以，完全通过逻辑推理并不能他需求挖掘完整，也许还会出现错误的需求，我们还要加入情景分析才能挖掘出正确的需求。

综上所述，我们可以将需求挖掘整理以上公式：

【什么人】（角色）

【什么业务场景】-【遇到什么样的问题】-【客户有什么需求】

【现在是什么样的】-【期望的步骤】-【可选的解决方案】-【最终方案】

基于这个公式，我们在挖掘需求的时候，可以先在合理的范围内，设定不同的用户和不同的场景，然后将不同的用户匹配到不同的场景，就像排列组合一样，分析他们的目的。

03 听取用户意见，但别照着做

在通过各方收集到相应的需求之后，产品经理还需要懂得如何对需求进行管理。收集到需求的时候，注意建立需求池对需求进行记录和整理。

我们在做产品设计时还有一个很大的误区，就是全盘听取用户意见，用户提什么需求我们就做什么需求。

产品的需求可以说是无上限的，大量的堆积需求，会使得产品非常臃肿，而且毫无特色，而需求的过多，还会导致工期过长，拖慢了产品推出市场的进度，对产品百害而无一利。

因此，产品经理需要了解产品的加减法。需求如何处理？在什么时候需要加？什么时候减？在需求收集阶段，我们一直在做需求的加法，不断地增加需求的量，增加所有能够得到的需求。在进行需求分析、需求评审的时候，我们则需要不断地对需求做减法，确认了需求之后，需要对需求进行优先级排序。减掉的需求并不代表这以后都不会使用，所以记得先保留着不删。

我们应该听取用户意见，但不要照着做。正确的做法是听取各方意见，准确分析他们的需求和期望，结合各方意见最终做出最产品价值最合理的决策，这才是产品经理的职责所在。

我们应该紧盯我们的产品目标，对于产品目标有利的需求和建议就采纳，对于产品目标不利的需求和建议就舍弃。

并且结合产品所处的阶段对需求紧急程度进行排序，按时间周期实现分部实现产品目标，从而实现产品的价值最大化。避免出现在导入期紧盯用户期望型需求，成长期期紧盯用户兴奋型需求的情况。

上面花了大量篇幅来讲如何避免需求不准确导致需求设计失误的问题，为什么要花大量篇幅讲呢？因为在前期控制失误的成本和效率都要比事后控制容易的多。

回到标题，如果功能已经上线了，并且用户说功能并不是自己想要的怎么办？

需要分类讨论，如果功能完全不满足需求，并且与所提需求完全背离，这属于产品经理的重大失误，只能紧急停用，一切推到重来。

如果能部分满足需求，可以申请延期发布，等进一步改进后验证通过再发布正式环境。

如果只是体验不好，能基本满足用户需求，可以上线后等待下一个版本去做迭代优化。

作者：青锋，公众号：PM知库

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

题图来自Unsplash，基于CC0协议。