B端产品经理必备技能：常用的四个B端产品需求分类方法

我们在使用手机上的C端APP时，很多APP在第一次使用时除了知道它的产品分类外，对它具体的功能一般知之甚少，然后在使用过程中会不断探索它的玩法和价值。

但是这种情况在B端产品中是不存在的，因为一个B端产品在设计好之后其所有功能都要用标准参数一条一条列在合同里。即客户在上线我们产品时，对我们产品所具备的功能是心中有丘壑的，这也是B端产品的商业性质决定的。

这篇文章我就按照B端产品的招标参数和合同里的参数对需求进行分类，并结合KANO模型，方便大家更好的理解B端产品的需求。

以我们公司产品为例，我们在审核招标参数和合同时，会将参数需求分为以下四种：

1. 标准版参数
2. 高级版参数
3. 定制参数
4. 不响应参数

与KANO模型对应关系如下：

一、标准版参数——基本需求和魅力需求

先说标准版参数与基本需求，B端产品标准版参数基本是业务的主流程，要能满足用户的核心需求。

比如我们公司的手术室麻醉信息管理系统，最基本的需求就是要能满足麻醉医生术前访视、手术排程、术中麻醉记录、术后苏醒记录、术后访视的记录。

这个领域所有软件的标准版参数最基本的要求就是满足这个基本流程的信息化，且大部分厂商的这一部分功能差异不会太大。这也是我们在入职这个行业之后，需要第一时间熟悉的主业务流程。

再说魅力需求，因为通常大部分客户购买的都是我们的标准版参数产品，所以既然各厂商的基本需求都能满足的时候，我们就要在基本需求上做魅力需求来吸引客户注意力，提高客户满意度了。

比如针对产品的手术排程功能，除了提供基础的通过拖拽形式的便捷排程，在此之上我们设计了智能排程的功能，将麻醉医生排程的效率提高三倍以上。

并且针对B端产品大多重业务逻辑，不重用户体验的现状，我们将产品的用户体验从页面展现上做了很大的提升。以至于我们给客户展示产品demo时，客户都会下意识的说一句“你们的界面看着还是蛮舒服的。”

这些需求魅力型的需求，从业务流程上来说没有必要，不做也不会降低客户对我们产品的满意度，但是做上之后一定是能提升客户的满意度。各个公司设计的魅力需求根据每个公司的实际运营情况不尽相同，这就要由客户来决定哪些是让他更满意的需求了。

二、高级版参数——期望需求

有些客户希望我们除了满足核心的麻醉业务流程外，还能针对围手术期更大程度的进行信息化管理，并根据信息化的管理实现数字化各种业务的统计，甚至能覆盖部分手术护士与麻醉医生合作的相关工作内容。

当行业内较多客户都拥有这些期望需求时，我们就会将其放到高级版的产品参数中，由用户选择性进行购买。避免为部分用户上线多余功能也避免部分用户想用而我们又不能满足的情况。

比如麻醉计费功能，通常在医院是由麻醉医生开具处方单，然后由护士统一的录入到HIS（医院信息系统）中。这中间就会有一个由护士进行信息转递的过程，客户就希望能够优化掉这个流程，让麻醉医生能够通过我们的系统直接进行麻醉项目的计费，然后将计费结果通过接口发送到HIS中，避免人为的信息转递失误。

所以我们的高级版参数就会设计这些较多客户都会提出的超过基本需求之上的期望型需求。

三、定制参数——期望需求

上面第二点中的高级版参数我们提到它要满足一个条件，就是较多客户都有这种期望需求。

而还有一些少数客户也会针对他们医院的实际部分特殊业务场景提出一些期望需求。这些期望需求通常只是为了满足某个客户的现场情况，我们就会与医院商定好需定制的需求功能，专门为其设计研发。

比如我们有一个客户提出，有些情况下病人在做完手术后可能会进行非计划的二次手术，但是他们不希望重新开启一台手术记录，要求我们能够支持这种特殊情况下打破原有手术流程的设计。

这个改动不仅仅影响的是手术中的记录，所有跟患者信息相关的记录都会被这些手术流程的关键节点所影响，属于比较复杂的需求。

但是鉴于这个客户在某个区域还是比较有影响力，对我们的产品口碑可能会产生影响，我们将这个需求纳入到了定制需求中，为其设计和研发了满足其要求的手术流程。

所以我们的定制参数是为了满足少量重要客户提出的超过基本需求之上的期望型需求。

四、不响应参数——无差异需求和反向需求

首先说无差异需求，无差异需求就是指做了和没做对产品和客户的业务而言都没有什么影响，这种需求通常考虑到成本等原因不会进行响应。

比如有的客户会提到，是否能把手术室的人员值班做到麻醉信息系统中，这个需求与麻醉医生的业务是毫不相关的，可能只是手术室的管理者想借着手术室中现有的信息系统顺便给放进去算了，所以这种需求我们的产品不会对其进行响应。

然后是反向需求，这个就需要很仔细的进行甄别了。因为从客户的角度来看他们不可能去提一个影响他们体验的需求，我们也不可能去提一个对产品有负面影响的需求。那么反向需求是怎么来的呢？

反向需求通常是隐藏在客户的期望需求中，客户为了解决他的一个问题提出一个需求，但是这个需求不一定能很好的解决问题，甚至会为产品带来更多的问题。

这就要求我们在评估客户需求的时候一定要多问几个为什么来避免这类需求的产生，比如客户为什么提出这个需求？他想解决什么问题？有其他更好的实现方式吗?这个需求会带来什么延伸问题？

一、定制化B端产品的需求分类

首先我们先了解一下什么人会对产品提出需求：

第一种是直接负责这个项目的甲方负责人，他们一般会对产品整体有个需求概况，他们虽然是负责人，但并不一定有多了解具体业务；

第二种是管理人员，他们是直接对业务负责的管理人员，这类人员一般会提出一些偏管理的需求，他们更加注重如何通过一个工具系统性的去管理好这个团队；

第三种属于公司中高层，他们关心的是宏观的数据希望能够从大量数据中看到公司未来的走向，所以这类人更加会提出一些数据分析的需求，如驾驶舱；

最后一种是产品的直接使用者，或者说是使用频次最高的人员，这类人员是业务的主要执行者，他们更关心其业务是否全面覆盖，操作是否简单等需求。

所以我总结B端定制化产品的需求一般分为四类：分析类需求、管理类需求、业务类需求、操作类需求。我们将需求分类之后，就能对症下药，找到需求的根本面目。

二、如何分析需求？

B端产品体术需求最频繁的一类人群就是使用频率最高的，涉及模块最广的业务人员，此类人员需要在系统中完成日常的工作，稍微遇到一些不好用或者操作操作繁琐的功能，都会让他们感到烦躁。他们一般会这样提需求：“我要在XX页面增加一个XX功能”“这个页面太不好用了，XX功能用起来太麻烦了，能不能简化一下”。

第一种需求属于自认为我很了解这个系统了，我可以直接为产品设计需求，你只要照做就行了；但我要告诉你的是，如果你照做了，那么这个需求90%会进行变更，因为他根本不知道他要的是个什么样的需求，这样做出来之后他才意识到自己要的根本不是这样的功能。面对这类人，我一般会问这几个问题：这个需求能帮你解决什么问题？为什么会有这个想法？换一种形式可不可以？

举个例子：在给某个公司的采购部门做系统的时候，他们有一个独立的统计室来统计应付账款，有个统计员和我说，我要把入账列表改成默认展示当天入账日期的入账单；很显然这个需求不是很合理，我问他我说为什么要这么做，他说你就改就行了，现在这样很不方便。那我和他说，你问问其他同事愿意这么改吗，如果你们都有这个需求那我可以考虑，然而最终结果是很大一部分不能接受这么改，我又问他我说你为什么要这么改，他和我说了，他想看今天入账的供应商和总额，其他统计员也有相应的需求。

原来想看今日入账的供应商和金额才是他最终的目的。需求明确之后我们完全可以有N个方式去满足他，但绝对不是用他的这种形式，最后我们都很愉快的解决了这个问题。

第二种则属于目的性强的选手，他不管你怎么去简化这个流程，只是觉得这个流程太复杂，操作起来一点都不方便，最好有一个按钮，一点这个按钮系统就能把他所有的事情都做完才好。这类需求处理不好，他会一直吐槽你的产品不好用，严重的会对产品造成很不利的影响。

提出这类需求的人有两种：第一种是对之前的操作流程固化了，不想去花时间学习新的流程（尽管你的流程很标准）。面对这类人，我建议直接告诉他设计如此，如果需要修改流程，可以找项目负责人或者你的领导，同意后可以修改。不要试图和他解释什么，要和他的领导去解释这个流程有多标准。

第二种人属于帮助你改善产品中不合理的地方，面对这类人， 要仔细和他沟通细节，让他说明那些地方用起来不顺手，然后询问他有什么好的建议和想法吗，记下但不要照做，回去后好好梳理现有流程和他提出的建议，如果觉得确实有改的必要，务必想好所有关联性流程后进行修改。

例如我在给采购部门做线上询价时，一个业务员对我说，每次我做询价的时候需要在采购单页面确认好我要询价的物料，然后再去询价页面增加一个询价函，这样操作太繁琐了，能不能直接在采购单页面直接询价呢。他这个想法不错，但是采购单页面的单据是主从表的关系，不能在这个页面加询价功能，这就是苏杰老师提起的，认真听但不要照着做。最后我用一种方式完美解决了这个问题。

另外这类使用者还会提出一些系统上没有涉及到的业务，这类业务可能是他们公司特有的业务，再权衡利弊后可视情况选择做与不做。大致可以从资金、开发难度以及业务占比等方面进行考虑。

例如我在做某个公司的检化验系统，一个化验员对我说，对于新物料的检验不应该由我们部门发起，因为我们不知道什么时候来新物料，供应商把物料送到公司时，会第一时间到库房去提交到货单，所以应该由库房接收到货单的同时发起对物料的化验请求。

以上我列举了操作类需求和业务类需求如何去分析，接下来介绍管理类需求如何去做，因为分析类需求不属于我的专业，所以我不能给你们提供更好的建议。

以上我们说到了管理人员一般会根据他所管理的职能去提一些管理类的需求，这类需求是很有意思的，管理类需求做的好，可以把你的产品提升一个很高的等级，使你的产品在同类产品中脱颖而出。

管理类需求思考的出发点和操作类、业务类是不同的，需要你站在管理者的角度去考虑问题，但有一点是不变的，就是目的。管理者提这个需求一定是想达到某个管理的目的，记住在管理者眼中，系统就是个管理工具，他希望系统能帮助他去约束员工，为他提供管理数据，所以管理者提出的需求一般围绕这两点展开。

还是以上述采购部门的例子举例，他们的采购部长找我说，希望我能做一个采购计划的限制，每个月只能申报两次采购计划，分别在月初和月末，我说为什么啊，这个直接让你手下就能办到啊，告诉你的小弟让他们限制申报部门不就完事了。他说他的小弟由于各种原因会不好意思拒绝申报部门的计划，这样我就很烦恼，我希望通过系统去做这件事。然后我就答应他了，但是我给他留了个最高权限，因为真的有申报部门有极特殊情况下，不能不给人家报不是，但是这次你面对的是采购部长，如果没有正当理由，那你就想想怎么混过去吧，这样就形成了一个闭环管理。

当然管理者的需求也不是不可以拒绝的，这个采购经理跟我提另一个需求的时候我就给拒绝了，他说采购员经常把计划处理了，但是他并不在系统上做完成标记，希望我能做一个弹窗提醒，每隔一段时间就去提醒他一次，我告诉他在其他公司不是没有这么做过，但是没有效果，业采购员会直接关闭这个窗口。建议你把这个计划处理效率放到采购员的KPI中，对他有了直接利益加持就有了动力。然后没过多久他又找我做了一个采购员KPI的模块，因为这招太好用了。

五、总结

上述就是我基于我们公司从参数的角度对产品需求进行的分类，通常在现实中一个需求划分到哪个类别中还会有更复杂的考量，比如客户的影响力、需求的成本等等，这些我们有机会在探讨。

希望大家以后在和需求打交道的过程中，去主动思考每个需求应当所属的分类以及原因，加深我们对产品和业务的理解。