思考 - B端需求该如何判断

编辑导语：B端用户需求是以企业目标为导向的，组织通过购买力满足对组织目标的欲望；我们可以将B端需求分为三大类，分别为业务需求、用户需求、产品需求，从这几个点出发进行需求的判断；本文作者分享了关于B端需求该如何判断的思考，我们一起来了解一下。

其实这算是一个老生常谈的问题了，相关的话题真的很多很多。

产品经理最重要的能力之一是判断需求优先级；判断优先级的三个方法……类似的文章也有很多，从产品小白到产品总监，各个阶段的产品都在这个问题上有输出。可能也是我学艺不精，虽然看了不少理论，但是经常到实操的时候又会觉得，我明白所有的道理却依然容易在商家一句“你不做我就用不起来”这句话下被迫屈服。

前一段时间在做一个行业SaaS，竞品早在二十年前就开始布局抢占市场，也奠定了这个行业软件化的一些标准和基础；我司在近两年刚入局，其实我并未觉得我司晚入局就占了下风，毕竟现在的技术和产品理念之于20年前进步得不是一点半点，甚至觉得现在是一个很好的契机，现在这个行业的各位老板大部分其实也就30~40左右，经历了那么多年互联网的洗礼，对于公司业务互联网化其实接受度也会更高。

但是正当我磨刀霍霍准备大干一场的时候，接连几个迭代的节奏打得我措手不及，甚至觉得产品进入了“项目制”的陷阱，走上了和外包公司一样的“不归路”。

当商家再一次说出了“你们没有这个功能我就用不了你们的产品”，并且我老大感觉就要屈服的时候，我终于勇敢站起来说了“不”。这一波操作让我成功避开了一个挖坑的机会，后续证实，商家依然用得好好的，这一事实也让我再一次深思了一下B端需求该如何判断的问题。

其实我总结的主要分三步：

你要知道你的目标客户到底是什么情况，从客户规模、到他们的用户周期、业务流程、员工的学历水平、互联网了解程度、年龄、性别、平均在职时间、上下班时间……

B端和C端很大的区别在于，C端往往是跟用户直接对话，谁买单大概率谁用；而B端则基本都是跟老板讲，老板买单，实际上是员工在用，老板只用一些全局性的功能。

所以除了要了解买单的老板的需求外，还需要关注实际使用产品的普通员工。我见过老板花20万定制，但是员工觉得不好用实在推不下去就搁置了的产品；也见过老板每天追着员工使用产品，但是数据还是不齐的情况……B端面向企业，每个企业都有自己的管理方式，但最终执行的人往往才是影响产品使用数据的人。所以，这部分人也是你的目标客户，也是你需要重点了解的。

几年前，我认为所有的产品在设计之初就应该是有目标客群的，但是后来发现，我们理解的目标客群是不一样的。用我跟我前主管的一段对话来说明下。

我：“老大，我们今年的目标是什么啊？主要针对大商家还是小商家？”

主管：“这个行业全部的商家。”

我：……

对话的背景在我们刚接到项目没多久的时候，产品刚刚开始做，你说它有目标客户吗？有啊，这个行业的商家啊，但是当时我心里就在想：这是问了个寂寞。我们是有最终的目标，但是每个阶段的目标客户其实也应该是不一样的，应该找到行业商家的明显区分点。

我总结了下，一般来说有以下几种分法：

1）看人数

这是最基本也是最简单的的，一般而言，人少的功能复杂度相对较弱，人多的涉及协作方更多，所以功能也就越复杂。

具体分层的一般可以通过各种方法（包括但不限于：直接问商家、查工商资料、发问卷等）获取到行业部分商家的员工人数，再稍微做个人数分布图就大概知道怎么划分了。

2）看业务流程

这应该也是很多产品在用的，虽然同属于一个行业，但是每家业务流程也略有不同，比如小说行业，晋江和长佩都有作者平台，但是对于发布的内容，一个是先审后发，一个是先发后审。

但是由于都是一个行业的，主流的业务流程也不会有很多套，一般来说，拆分几种主流的就行了，当然也可以将多种业务流程集成同时到一个系统，那样的话，系统相对而言灵活度就会更高。

3）看商家竞品的使用情况（对于软件化的接受程度）

这个是我自己跟商家battle了好久之后总结出来的，这一年多老实说我一直认为这个东西不重要，因为不管用不用竞品，我们的目标最终都是把你拿下。

但是由于一边要兼顾已经使用竞品的老商家的各种数据（一般而言，使用了竞品的商家数据都会比没使用过的要复杂）；一边又要不断地去跟没用过类似产品的商家讲为什么我们不做xx功能，因为他已经被验证为用处不大还拖垮效率了。

这一年，我为老商家妥协过，做过针对主流竞品的批量导入；也跟新商家解释过，为什么他们要xxx功能我没做。这两种商家的诉求真的很不一样，曾经有新商家的员工因为我们的下拉滚动条做得不够明显而说我们产品不好用，后来我们告诉他可以用鼠标滚轮解决这个问题；有些老商家主动提出让我们开放部分api接口让他们可以自己做些别的东西。

所以，互联网化真的真的是一个不可忽视的问题，也许我们已经习惯了整天对着电脑做很多事情，也习惯了周围不是985，就是211的优秀的同学们；但是至少中国而言，我们的大学生比例到现在也才10%左右而已，所以，不是所有人都能马上get到你一些神奇的逻辑的。

了解商家员工的文化水平对于你的产品规划有着极其重大的影响，达摩院用的产品丢出来几个人能用明白，人家也还是做起来了，究其原因还不就是你压根儿不是人家的目标用户。

所以，对于目标用户的了解，是拿到产品第一步就必须要做的，不然你就等着后来疲于应付各方需求，然后最终演变成面向简历迭代吧。

其实我觉得，第一步你真的正儿八经搞明白了，这一步就没那么难了。但是有一点我还是得说，做SaaS也好宗教节日，别的工具型产品也好，最套路的一个核心宣传就是：降本增效，这几个字我觉得真的是放诸四海皆准啊；所以往往看到产品里有这样的说明，我心里一般都是吐槽这是不知道怎么写了（但是不得不说这几个字很吸引老板们的注意力）。

当然，也不是说这个目标是不对的，这是最终的目标。

但是不同行业可以达到这个目标的方法都是不一样的，你需要去挖掘的是关键步骤和路径，所以第一步要做的是，知道目前商家的效率和成本损耗在哪些地方，而不是想当然认为人家就是物流那步耗损大，审核效率低……之类的，大部分结论都是需要数据来支撑的。

找到你不同层级客户的核心问题后再去做，大方向至少是没错的，但是不要太指望用面向A类客户的功能打动B类客户。核心问题点就是不一样日签打卡，除非你认为A类客户的解法是行业最优解，然后强制把B类客户扭转成A类客户。

（但是题外话说一句，虽然我做SaaS，但是我从来不认为任何人有能力真的能找到一个行业的最优解并把它推向给所有商家。）

核心诉求完了就是通用功能，这个和商家个性化需求往往对立，商家就是觉得自己这套流程特别好，这儿加个评分，那儿加一个监控，但是他如果不提，你会发现别的商家完全没有这个意识；这种就得好好判断下了，是好还是不好，对于这种不好用已有数据说话的功能就需要你发挥你强大的专业素养了，反正自己去判断。

但是！千万！！！千万！！！不要为了满足一个不肯妥协的商家就被迫加这种需求，然后给做成自定义配置的，你心里想的是，不用你可以关掉，但是我以以往经验告诉你，这种功能，除了提这个需求的商家会开心，剩下的90%的商家、开发、测试……各种人都是在吐槽：SB产品（当然，做PaaS平台的当我没说）。

你经历了那么多，好不容易说服你自己这个个性化需求不能做，但是接下来你一定会面对运营同学的狂轰滥炸、商家的“没有我就用不了”之类的话、可能面对强势的业务方，主管也会妥协：就做了吧，这个功能很简单，不碍事的。

告诉你！这种话不能听！如果你真的认真分析过这个需求，拿着你的论据，跟运营，跟商家，跟主管去battle，实在说不通，你再让告诉主管之后的风险点，让主管拍板。

总而言之，努力争取。

不要因为现在嫌麻烦就随便妥协了，认真讲，你现在妥协之后挖的坑都要你自己跳下去然后再把自己埋了。

当然，也不鼓励那种跟老大吵地脸红脖子粗的，老大决定要做肯定也是有原因的，原因告诉你你就听着，不告诉你你执行就对了，毕竟很多功能其实也不影响主线任务。非要上升到价值观那步说明你跟这个团队气场不和，那其实也没必要争了。

做B端真的是一个整天秃头但是又挺有意思的事情的，希望做B端的小伙伴都能从工作中得到一些成长。

本文由@重九 于，

题图来自Unsplash, 基于CC0协议