B端产品的需求大多与用户的业务强相关，如果对于业务或者场景没有深入理解，设计的功能往往不能解决实际的业务问题。本文将从三个维度：分析需求、需求排序、需求描述来复盘分享关于需求的一些方法论。

作为产品经理，不论是参与项目迭代，抑或是处理事务或者日常和用户、服务端同学沟通，都会接到各式各样的需求。而B端产品的需求大多与用户的业务强相关，如果对于业务或者场景没有深入理解，设计的功能往往不能解决实际的业务问题。

回顾最近分析处理和设计满足的需求，笔者将从三个维度：分析需求、需求排序、需求描述来复盘分享关于需求的一些方法论。

一、分析需求：区分需要和想要

在分析需求前，先区分一下需要（need）和想要（want）。

需要是用户真实的诉求或真实存在的问题，而想要只是用户自己表达的一种解决方案。也就是需要其实是内在表现，而想要是外在表露。

举个例子，假如用户说他想喝可乐，他的诉求可能是渴了，可能是刚买了炸鸡想搭配可乐吃，可能是好久没喝可乐了想回味一下味道……“想喝可乐”是想要，“渴了、想搭配炸鸡一起吃、回味味道”才是内心的真实需要。

而需求则是结合实现成本和带来的价值（给用户带来的价值、给公司带来的价值）来满足用户需要的产品待优化问题。

也就是说需要和想要是从用户角度出发，需求则是从产品角度出发。

（1）用户提的大多是想要，而不是需要

如上述示例，假如用户真实诉求是渴了，这时候提供一瓶矿泉水便可以解决他的需要，相反提供可乐并不能解决他的真实需要，因为可乐会越喝越渴，用户喝完可乐后还会来找你提需求，比如要雪碧。

用户大多数提的其实是想要，也就是他想要某工具或功能解决他遇到的某个问题，但这并不是他背后的真实诉求。产品经理要做的就是找到其真实诉求，防止做出的功能最后用户不买单，不能解决用户真实问题。

（2）接到需求别着急落地，先摸清用户真正的需要

B端产品的需求业务属性那么强，但是用户并没有意识去表述自己的内在需要，产品经理该如何去挖掘他的真实需要呢？

一方面可以让用户在表述需求时，尽可能描述清楚业务场景和遇到的业务问题，我们可以从他的描述中主动了解他遇到的真正问题。

另一方面可以多针对用户的描述提问“为什么”，为什么用户有这个诉求？为什么用户想喝可乐？为什么会渴？……多问几次，就可以看到用户的真实诉求。

所以接到需求后不要着急落地设计方案，先想清楚需求背景和用户遇到的问题，可能用户遇到的问题通过已有方式就可以很好解决。同时问清楚需求背景和业务情况也便于判断这是否是个性化需求，从而采取不同的应对策略。

（3）不要被亡羊补牢的需求蒙蔽双眼

假如用户突然要两箱冰镇可乐，并且了解到用户的真实诉求是现在夏天每天出很多汗所以会很渴。这时根据渴的诉求建议用户买两箱矿泉水并不是最好的方案，因为这有点亡羊补牢。

用户遇到的问题是每天都会很渴，这时候需要去了解为什么用户每天出很多汗，是运动多吗？还是天太热了？……如果用户反馈说是因为空调坏了所以每天出很多汗导致很渴。这时帮助用户最好的方法是联系空调师傅尽快修好空调，这样才能解决用户面临的本质问题，满足用户的真实需要。

（4）注意需求提出方

用户想要两箱可乐，我们不妨问问这个需求提出方是谁，是用户本人还是他的领导。

这样可以看到这个需求是从管理视角出发还是用户视角出发，从而决定后续设计思路。如果是领导的需求，我们后续设计功能便要从管理者角度出发设计。比如可以在可乐上免费打上“继续努力”等字样，满足管理员利用可乐做奖励的管理视角诉求。

同时这样也能明确需求优先级。假如用户的领导负责部门日常用品的采购，并且和我们的信用往来良好，这时候将此需求优先级提高，可以促进更好的合作。

二、需求排序：划分需求优先级

（1）需求没有满足不了的

在和用户或服务端聊需求时，常常被问“这个需求能不能实现”。其实需求并没有能不能实现一说，只有根据需求合理性和价值来决定是否要实现和排期相关的问题，所以我们不能和用户说这个需求因为我们的架构或技术等原因做不了。

（2）需求漏斗

如果需求合理，并且本着需求没有满足不了只有优先级的原则，我们需要有判断需求优先级的工具。其实网络上介绍判断需求优先级的方法很多，我这里也只是在工作实践中总结了一套自己使用的方法，这是一个“需求漏斗”，如下：

产品价值观：

作为第一层漏斗，会将不符合产品价值观的需求过滤掉。比如用户想弄虚作假，想删除或修改一些关系户的测评成绩，因此提出修改测评成绩的需求。这和我们的产品价值观违背，我们不做这样的需求。

业务战略：

这一漏斗指看公司最近的战略如何。假如战略是要做MVP，那着重实现能把流程跑通的需求，假如战略是要改善用户体验，则着重优化能提升体验的需求。

kano模型：

kano模型释义不再赘述，kano模型对需求主要分三类：基本型、期望型、兴奋型。划分的标准可以按照：

• 基本型：业务闭环类的需求，需求不实现则流程跑不通；
• 期望型：效用类的需求，比如提升操作便利性（批量操作）；
• 兴奋型：体验类的需求，比如满足好奇心、得到安慰等的需求，类似用户操作任务完成后出个动画鼓励。

每个类型内可能又有很多需求，基本型的需求都要做，期望型、兴奋型的需求则看紧急重要程度以及带来的商业价值有多大，综合考虑来排级内的需求优先级。

开发成本：

最后一层漏斗更多针对于已经开启迭代，比如进入开发或进测试了，需求发生变更的时候。这时的需求大概率不影响业务跑通，可以视开发成本和排期安排优化。

如果已经快上线或影响较大但不是基本型需求，可以记个问题，待产品上线后再在后续迭代里优化。

三、需求描述：清晰表述，指导设计

在分析完需求后，针对合理的需求我们就要设计功能来满足了。需求作为串联整个迭代线的要素，描述清楚很重要。因为需求不仅是和各团队沟通的桥梁，也指导着自己设计产品时不要走偏。

（1）利用用户故事还原场景，梳理流程

可以通过用户故事还原场景，梳理用户解决问题的流程。这样不仅能描述清楚需求，也便于检查自己设计的功能能不能解决用户的问题。

在描述用户需求时，主要说清楚用户、环境、时机、问题、之前解决方案。

描述需求：用户在什么环境下，出现了什么时机， 遇到了一个什么问题，之前是通过什么方式解决的。

如：炎热的夏天，大二同学张三宿舍的空调坏了，流了很多汗感觉到很渴，之前通过每天喝大量的冰镇可乐解决口渴。

在自检设计方案时，主要说清楚用户、环境、时机、目标、介质、动作、结果。

设计方案自检：用户在什么环境下，出现了什么时机，带着一个目标，通过某些介质采取了一系列动作，完成某一特定任务（解决了某问题）。

如：炎热的夏天，大二同学张三宿舍的空调坏了流很多汗，为了解决口渴，张三到店买了水并且联系空调师傅修好了空调，之后不再因为宿舍炎热而流汗口渴了。

（2）用正确功能解决需求

用户如果是因为口渴了才来要可乐，我们应该建议他买矿泉水，这样才能解决他的需要，而不是喝完一瓶可乐用户还渴，然后我们再给用户一瓶可乐。

再比如HR通过给应聘者打标签来标记自己联系过哪些人，避免再次联系时重复联系，我们应该提供类似“已联系”的筛选条件筛选用户，而不是用A功能解决B场景。

（3）区分主场景和次场景

如果访谈需求，发现用户背后的诉求和场景多样，甚至有矛盾，这时候怎么处理呢？

比如：删除文件夹，文件夹下的文件要不要删除？

有的用户表达是删除文件夹代表这个文件夹已经废弃了，里面的相关文件也不需要了，需要一起删掉。有的用户删除文件夹只是想整理一下文件，对于珍贵的文件还是想保留下来的。

出现了矛盾场景我们需要根据功能定义来定义主次场景。满足主场景，次场景可以用一个更合适的功能满足。我们定义的文件夹就是一个分类打包，里面的文件一定是因为有相似属性才放在一起，所以删除了文件夹里面的相关内容也应该删除，所以前者是主场景，后者次场景其实是用户想整理文件夹，我们可以提供类似批量转移文件的功能实现文件的重新归类。

（4）“这样设计可不可以？”取决于能不能解决用户的需求

在设计功能时，有时会不自主考虑这些问题：这个技术可以实现么？怎样设计技术实现成本才能最小？现在我们的能力支持这样吗？这样设计了会影响到现有的业务流程或出现逻辑更复杂的情况，要不要舍弃这种设计？……

其实要不要这么设计取决于用户有没有这个诉求，能不能实现用户的需求，而不是技术、设计方案与现有流程冲突等的影响，后者应该为前者服务，不能倒置。

作者：佛系少年；微信公众号：大强的产品成长记，进行交流和探讨。

本文由 @ 佛系少年 原创发布于人人都是产品经理。未经许可，禁止转载

题图来自Unsplash, 基于CC0协议