优秀的B端产品关注什么？对于如何做好产品，红衣教主周鸿祎在他的《极致产品》中总结了三个关键字：刚需、痛点、高频。这对我们产品的设计给出了一套
非常明确的方法论，只要符合这些条件，相信做出来的产品，其成功率会高出很多。这其实是针对个人用户产品所总结的，也就是我们所说的C端产
品。由于C端用户需求的不确定性和迷惑性，所以才需要这些针对性的方法供于评判，便于我们用来审视和改造我们的产品。那对于B端产品呢？我
们是否也能总结出相应的方法来帮助我们做好这一项产品工作呢？这就是我们这篇文章所需要解决的问题。在我看来，除了专门面向企业或机构用户
所设计的产品外，我们通常所说的后台，如果其用户为企业人员，那同样也可以被认定为B端产品。比如C端APP产品的业务后台，用于运营人员
响应及处理APP业务请求功能的产品，就属于这一类。B端产品和C端产品为什么会有区别？最本质是用户对象的不同，C端产品为个人用户创造
价值，而B端产品则为企业创造价值。用马斯洛需求层次理论可以概括个人需求，而企业则更简单，为了效益。因此在这个基础上所构建的产品理论
就有了根本性的不同。那优秀的B端产品需要关注什么呢？对此我同样总结了三个关键字来概括，这便是：闭环、高效、低成本。01闭环对于企
业业务经营活动，通常都是有一条完整的流程来支撑。而B端产品通常首先要做的工作便是还原业务，也就是将现有的线下业务流程转化为线上软件
系统执行的产品流程，以便构建高效的业务支撑能力。因此，B端产品经理必须要深入到业务中去，走到线下，实地学习和调研。就像我当年在做汽
配物流产品时，为了熟悉线下业务流程，多次亲自去到线下门店。从收件、录单、拣货到跟车配送，送达收款，最后返回结算，完整经历和感受了这
整个业务过程。可以说，B端产品经理如果只坐在办公室里，仅听别人讲述需求是不够的，这样很难做好产品工作。因为你对业务没有实际的感知，
也不知道在这个过程中会出现哪些分支流程以及相应的处理办法，甚至原本该有的核心流程都会被遗漏掉。产品流程对于整个B端产品设计至关重要
，是产品需求的核心骨架和整体脉络，是我们产品构建的基础。所以完整的产品流程是达成产品可用的基本要求，但如果要想产品做得好，那就要求
，在产品流程上实现闭环，是做好B端产品关键要求。那如何实现产品流程闭环？核心流程闭环，促进业务再循环产品流程完整是说，从起点到终点
，业务能够正常地走完，这对产品而言其实只是基本要求。而产品流程闭环，则是指完成一次业务流程，都可能会对下一次业务流程起到促进作用。
这就是一个良性的正向循环。这么说可能有点抽象，下面通过两个案例来说明一下。对于贷款业务，在风控系统做审核时，我们会拉取此贷款用户信
用相关数据进行综合评估审核，最后得出审批通过的结果，然后发放贷款。此用户按照约定的贷款期数完成所有还款后，可能某个时间又需要再次贷
款，这时用户会再次申请。而此时，我们的风控系统识别到此用户有过贷款记录，而且还款表现良好，于是综合评估结果表现更好了。此时风控系统
对部分环节作了跳过处理，加速了审核时效。最后快速放款。这一次贷款用户同样按时还款，当用户结清贷款时，系统自动对此用户重新进行了评估
，最后给他提高了5000元的额度，并通过短信和APP通知了用户。用户觉得非常开心，决定后面有需要时继续在这里贷款。发现没有，上面的
例子中，每正常完成一次业务流程，都可能会对下一次的业务流程有促进的作用，而实现的这种效果就是闭环。我们在做B端系统时，在核心流程上
就需要多考虑这样的问题，是否可以从流程上实现相互的促进，加速我们的业务循环？再举一个是关于淘宝退货的例子。通常，我们在淘宝上购物，
收到商品发现商品不满意时，会申请退款退货。当退货退款申请被卖家同意后，我们需要将商品寄回，然后将寄件的物流单号上传淘宝并提交，然后
等待卖家收货验货确认后将款项退回来。但是后来淘宝做了一次流程优化。就是当退货的物流单号上传提交后，如果发现买家是一位购物行为记录良
好的淘宝会员，则会自动发起极速退款，由淘宝先行垫付，退款立马到账，不需要等卖家收贷验货确认。这个极速退款功能给用户的体验非常好。极
速退款流程的触发，就是源于淘宝用户历史购物行为积累的结果。也就是前面正常的业务流程对后续业务流程重复产生了积极的影响。这就是产品流
程的良性循环，是闭环。闭环的结果是什么？简单来说就是：前端顺爽，后端提效。什么意思？就是后端业务运营实现了效率提升，而后端又通过前
端产品赋能，给用户提升了用户体验，让用户觉得产品越用越爽。这样的B端产品才能称之为好产品。02高效高效一词很容易理解。就是要让我
们的业务高效运转。B端产品作为业务后端运营的承载者，除了实现基本的信息化外，更要实现高效化，进一步助推业务运转效率。那么，我们如何
才能做到高效呢？首先，产品设计要遵循用户的操作习惯。产品经理在做产品设计时，通常会有自己的专业考量。也就是说，会按着自己的理解和思
考去做设计。这是很正常的工作逻辑，原本并没有多大问题。但如果对业务状况不了解，对业务熟悉度不够，很可能就会出现背道而驰的结果。举个
例子。我在做汽配物流产品时，有一个录单的功能的设计就出现过这样的问题。录单功能的应用场景就是汽配商把货品送过来要寄出，我们的录单员
就需要将货品信息录入到订单系统中。设计前确定好了录单所需要的字段，随后便开始按照自己的理解去设计表单。其中在设计“货品数量”这个录
入项时，我考虑到便利性，则采用下拉选项框而非输入框，因为通常用户更喜欢做选择而不是输入。同时还减少了校验逻辑及其它异常流程的设计。
结果产品上线后，却收到了录单员的“积极”反馈。她说，能不能把下拉框改成输入框，因为她们操作时都是直接用键盘的，不用鼠标，鼠标太慢了
。看吧，没想到自己的自作聪明遭遇了打脸。同时，她还说，建议把表单的字段顺序调整一下，因她们是对着纸单来录的，顺序一致会更方便些。另
外最好还能支持tab键切换录入项。按着她给的建议，我重新调整了设计，上线后她反馈说“现在好用多了！”。为了搞明白有多好用，于是我亲
自到线下门店去。最终发现她们录单时，眼睛看着纸单和显示器，然后双手只在键盘上盲敲，鼠标完全不用，2~3秒时间内就把表单给录好了。而
此时窗口外排着长长的队伍，如果系统在操作上快不了，你可以想象一下这业务效率……C端产品讲体验，而B端产品要效率。不是说B端产品不用
关注体验，而是其体验的尺度很大程度上就在于操作是否高效。我们在做B端产品时，对原有的C端用户体验思维需要打上问号，问一下自己这样的
做法是否有助于提高效率？而要让自己有更直观和清晰的判断，则是多深入一线去体验和感受业务的执行过程，认真观察一下操作者在工作中的种种
细节。其次，专项解决效率痛点问题。在B端产品中，效率是核心关注点，而有些问题则极大地阻碍了效率的提升。如果这些问题不能解决，那产品
的价值将大大降低。对于这类问题，我们需要投入专门的精力去解决。那么我们该怎么做呢？我认为可以从两方面着手。一是从产品方案层面，考虑
最优解。有些问题不是说没办法处理，只是没有很好的办法去从根本上解决。像这种情况，我们要考虑的就是如何减少这样的问题，尽可能地提升效
率。而且很可能我们的担心是多余的，如果最终发现优化后的方案能应对绝大部分的情况，那对于效率提升就是绝对可观的。同样举个例子。在汽配
物流业务中，我们会代收货款。汽修门店客户收货后会将货款和运费一同支付给我们，由于货款额较大，他们通常会在闲时通过银行转账方式将款项
支付过来。这种的付款量并不在少数，而这就造成了我们入账结单的极大麻烦。因为无法知晓款项是谁转账过来的，这就需要人工逐个去查询，核对
，确认。这无疑增加了很多不必要的人工成本。为了解决这个问题，我考虑能否在订单结算系统中增加一个自动入账的功能。所谓自动，就是通过对
银行收款记录中的金额与未付款订单金额进行比对，如果发现是一致的，那这个款项很可能就是相对应的。那如果金额一致的数据不是一一对应，而
是一对多呢？这种可能性肯定是有的，也就是说不同的订单，最后的要支付的金额一致，这种可能性太大了。想到这，感觉此路不通。但认真想想，
这种不同订单相同金额的情况真的会有很多吗？我决定不作臆测，要拿数据来说话。于是我让技术抽取几个日期段的订单数据进行统计，比如连续3
天内，同一金额的订单数量。结果出乎我的意料，同金额的订单数据多至3单，少则为0单。也就是说这种情况占比不到2‰，这个数量级几乎可以
忽略不计嘛！经过以上分析，最后确定了就这个方案来实现自动入账，同时设计手动入账的功能，用来处理无法自动入账的情况。最后，产品上线，
银行转账入账工作几乎直接减为0，大大降低了工作量，极大地提升了业务效率。二是从技术方案层面，考虑可行解。有些难题，在产品层面可能很
难有什么有效的方法来解决，如流程优化、交互优化等。而需要使用技术革新手段来实现问题的根本性地解决。也许你会问，这不是程序员的事吗？
其实不尽然。对于这类问题，之所以成为问题，就是因为常规的技术能力没能解决。所以再把这样的问题直接抛给技术团队，很可能也未必会有结果
，因为他可以直接告诉你解决不了。但作为一个优秀的产品经理，我们是不能放任这样的问题去持续困扰业务的。那么我们该怎么做呢？那就是主动
思考和寻求可能的方案，然后不断地与技术进行探讨，以激发技术的思路。在这个时候，就是考虑产品经理的技术理解力和思考力了。这也就是为什
么很多B端产品岗位在招聘要求中都写着要求技术背景的原因了，因为没有技术背景，通过产品解决问题的思路会存在很大的局限。比如在做贷款业
务产品时，用户需要在我们线下门店签署相应的纸质合同。而这些合同的数量很大，不同的合同就有10几份之多。我们的业务系统中，合同打印就
是一个很必要的功能。但操作人员反馈打印合同太麻烦，多个合同需要逐步个点击打印，效率非常低。为此，我们决定实施专项优化。刚开始时，我
提出让系统自动根据配置的签署份数来设置打印份数，免去手动录入份数的操作。结果发现做不到，因为打印是直接调用浏览器的打印功能，没有任
何接口能力让程序去设置打印份数。技术也无能为力。后来，我又考虑将要打印的文件转换成PDF格式，是否就可以解决这个问题？因为PDF格
式跟浏览器的兼容性要比DOC文档好太多。但技术经尝试确认后仍然行不通。但后面技术想到了一个办法，直接将要打印的文档内容转化为多张图
片，如果要打印多份，就重复生成多份图片，最后将这些图片按顺序拼接生成一个PDF文档，然后再执行打印操作。这样无需设置份数，就可以实
现多份打印了。按照同样的思路，也就可以实现了批量合同一键打印了。但这个办法仍然存在一个问题，就是打印文件的字体清晰度问题，因为是图
片，打印时存在缩放导致清晰度降低。但咨询过法务同事，其表示能看清没问题。这确实是一个可行解。最后功能上线，线下人员使用后赞不绝口。
为什么一开始技术解决不了的问题，后面还是解决了？这很大程度上在于产品经理主动思考寻求方案，不断地去激发技术的解题思路。就像上面的例
子，利用文件转换的思路，最终找到了可行的方案。不管产品层面还是技术层面，都是通过解决效率障碍来提升产品的价值，继而实现业务的高效运
转。03低成本产品的研发需要耗费大量的人力，物力和财力，这是企业所要承担的成本。但为了扩大营收，企业对内通常会实施降本增效来促进
这一目标的达成。而作为产品经理，我们在产品研发上则多要考虑成本因素，尽可能地将我们的产品打造成“便宜好用”的产品。曾经我一个同事说
过一句话，我认为非常有道理，他说：“做出复杂的产品不是本事，把复杂的产品做简单才是”。同理，我认为“做出复杂产品不是本事，能用低成
本的产品方案解决问题才是”。那么，我们如何在产品工作中实现低成本呢？一是合理的产品方案。我们做产品，通常不是为了解决某个具体问题的
，而是为了解决某一类问题。所以在做需求分析时要明确，这是长期要满足的需求，还是只是当下要解决的一个问题？对于长期要满足的需求，我们
对产品方案的要求便是要符合3个标准：通用性、复用性、拓展性。这就是我们要达成的，合理的产品方案。符合这些标准的产品方案，可最大程度
地避免重复开发，反复修改。这也就大大降低了开发成本。通用性，是指产品功能不直接针对某个具体问题作解决方案，而是要抽象出来，做通用化
的设计，以满足这一类的需求。比如，在贷款业务中，在资金机构匹配确定后，则由这个机构负责放款。但后来某个资金机构提出，他们需要对放款
额度做一定的限制，如贷款额度不能超过抵押资产的7成。但在某些地区，我们又没有其它资金机构用来替代选择，当触发限额的情况下就无法进行
放款了。为了能让这笔贷款订单能正常完成放款，公司提出了要将贷款金额进行拆分成两笔贷款，一笔为满足机构额度要求的金额，由机构发放。而
剩下的部分则转化为信贷订单，则由自有的平台资金进行发放。需求明确了，那就要考虑产品方案。业务方认为可以直接为这个机构增加一个额度判
断及拆分逻辑，这样其它机构就走原有流程。如果这么做，那就明显成为了一个定制化的需求。这是不通用的，假如又有一个机构有这样的需求呢，
是否又要再做一次开发？通过进一步了解，发现后续接入的资金机构仍然可能存在这样类似的要求。于是这就属于持续化的需求，需要考虑通用化的
方案进行实现。最后就通过引用配置项的方式，将需要执行拆分逻辑的机构、额度要求记录下来。以配置信息来决定是否要走额度拆分逻辑，这样后
续增加新的机构时，也能同样适用。尽可能地避免采用定制开发和硬编码方案去做产品实施。复用性，就是指一个功能，如果是其它产品或模块也同
样需要，就应该将之设计为可被多个模块复用的方案进行开发。而不必为了同一个功能重复发明轮子。拓展性，是指更为灵活的设计，可以接纳后续
可预见需求的增量拓展。这样的设计，在需要的时候可以轻松进行迭代开发，而不是功能重构。这些不再展开说明，大家应该都能理解。当每一个需求引入时，都能按这样的思路去分析我们的产品方案，则可以避免后续不断地返工，这是通过产品方案设计实现成本节省的最好方式。二是灵活的解决办法。对于短期性的临时需求，或者是非高频需求，我们则应该采用更为灵活的解决办法去处理。对这类需求不必讲究过多的产品设计原则，用户体验等，只要能解决问题，简单粗暴一点又何妨？正所谓大丈夫做事不拘小节。快速解决问题，将更多的精力和资源投放到更有价值的事情上，这是降本增效。这也是产品经理做事成熟的一种表现。以上便是我对做好B端产品的主要观点。我认为只要我们的B端产品只要满足闭环，高效，低成本三个要求，相信这样的产品一定不会差。一定会赢得客户的支持和认可。 |
|
