B端产品，将业务内具有共性的模块进行整合，提供产品化功能，将资源整合共享。作者结合自己的工作经验，从三个维度谈谈“如何让B端产品看起来有价值”，希望对你有所启发。

对内B端产品，主要通过将业务内具有共性的模块进行整合，提供产品化的服务的功能，为企业提供资源整合共享、降本增效的作用。

但是这些“降本增效”产品的价值衡量和展现，是一个时常困扰着新手B端产品的问题。它既不像SAAS类B端产品一样可以通过销售业绩来说明功能上的价值，也不像C端产品一样有庞大的用户群体数据来说明功能价值。

(资料图)

想起我在作为新人B端产品时，经常会被问到“你做的这些功能有什么用”这些问题。仔细盘一下自己做的功能，却又是“给这个功能加个开关”、“给这个报表加个筛选项”这些杂活，导致我在初入职场的时候时常在周会上吃瘪。

但在几年的工作摸索中，自我感觉多少在这些方面有一定的心得，就当作一次自我的总结和复盘，下面结合自己个人的一些经验聊聊“如何让B端产品看起来有价值”这个话题。

整体分为3个模块：

一、打造价值

首先，你的功能要有价值。

1. 贴合业务：深入一线了解业务，迎合各方需求

对内B端产品由于以下原因，往往较难真正地做出价值较高需求的功能：

产研团队与一线割裂，容易闭门造车。需求提交链路曲折，收到的多是失真的二手需求。

为了解决这些问题，就需要建立信息获取途径，比如：

业务对接群：如果产研部门能够与业务直接接触，便可以与业务负责人和相关一线执行成员拉群，业务会定期反馈系统问题和使用体验，我们能从这些反馈中挖掘业务的痛点和需求。如果业务反馈较少，我们也可以定期进行回访，主动收集业务在后台上的使用情况和需求点。业务反馈入口：如果产研部门不能够直接与业务接触（这种情况可能出现在公司架构复杂或者处于保密要求等场景），可以在业务部门能够接触到的功能放置反馈入口。比如，系统角落可以放“我要反馈”等功能入口。一线轮岗流程：B端产品设计是一件“从群众中来到群众中去的事情”，但很多产品未必亲自使用过自己设计的功能。这导致我们的功能设计出发点其实是脱离了实际业务场景的。而且一线业务人员由于认知和产研团体不同，一线业务的反馈不一定能准确抓到功能的点。因此由我们自己扮演一线业务人员去进行功能体验，就能够解决上面提到的“脱离群众”和“认知不同”的问题，更准确挖掘到有价值的需求点。业务交流会议：有时候线上的沟通并不能准确收集到业务的准确反馈，业务可能有时候出于情面等因素的考虑，不会直接吐槽系统。通过面对面的交流，能够直接看看业务是怎么上手操作我们的系统的，能够通过交流的过程判断业务对系统的真实想法。

结合实际情况搭建信息获取途径之后，在这些信息获取的过程中，我们需要了解：

业务架构：

《幕后产品》中有对公司的业务架构、产品架构、信息架构关系进行过描述：

互联网产品架构的终极场景是架构公司的战略和业务，这需要很好的商业意识、业务洞察、战略规划和架构能力来相互配合。除了天才外，这样的架构能力并不是凭空产生的，而是在工作中逐步积累、学习得来的。产品经理接触架构工作的起点是信息架构，当我们开始涉猎产品架构时，需要思考信息架构、产品架构，乃至未来的业务架构之间的关系，从而抽象一些发展架构能力方面的要素，让自己进步得更快。

中台部门是辅助业务部门而存在的。协助业务部门完成战略/商业上的成果是中台部门的终极目标，了解公司的业务架构能够辅助我们了解公司的战略和商业逻辑，从而在产品功能设计层面迎合公司的最终目标，从而做对公司有价值的内容。

短期目标：

通过了解业务架构，我们可以知道公司的长期战略。但是作为一线的产品设计，我们也是需要通过一个个较小的功能来到达这个长期战略的。

因此，短期目标的设置也很重要：

合理的短期目标设置能够使得产品有阶段性价值交付。如果一个大版本要花费一个月的时间，不妨将系统拆解成MVP版本-优化版本1-优化版本2……的形式，每周进行交付，通过数据来展现功能价值。否则容易在“不了解开发排期的”领导面前，显得我们只有交付的那一周是又在工作的。合理的短期目标设置能够起到长期目标检验的作用。长期战略的设立其实是有一定的“赌”的成分的，因为市场变化日新月异，没有人能100%准确预测市场的走向。因此小步快走的开发方式就可以快速通过小版本的反馈来纠正大战略的错误，从而走向正确的战略目标。

通过和业务对齐短期的打法和目标，可以更好地走向长期目标。

多视角信息：

在与业务沟通的过程中，我们可以接触到使用产品的多种角色。与多角色进行沟通，有助于我们更清楚地了解我们自己设计的功能的情况。

（1）一线业务

实际使用情况：我们需要了解在一线业务人员的手上，功能是被怎么用的。有时候设计出的功能，可能不一定按照我们的想法被使用。所以我们应当在这个过程中发现这些问题，并在后续版本中纠正，以适配业务的需求，提升后台使用效率。

比如，可能我们设计一个功能工作流程出来，想着业务是通过A-B-C-D的步骤去完成业务的，但实际上，业务可能由于习惯或者人力不够等原因直接是操作A-D的步骤。

实际使用卡点：一线业务人员在实际使用的时候，往往会存在一些地方觉得难用。我们可以通过访谈发现这些点，记录以便后续安排优化。

改动想法：一线业务人员在使用的过程中也会有自己的想法，听取这些想法可协助我们进行功能的规划，以便在后续版本中结合需要满足这种需求。

（2）一线管理

业务目标：从一线业务人员上，只能看到功能的具体使用细节，没法从更高维度去了解业务。所以需要从一线管理上了解业务的短期目标，以便在业务目标层面满足业务。比如业务近期的现状是产品维稳期，重点是做用户召回，我们就不能在这个时候做拉新相关的工具功能优化。

管理情况：一线管理人员需要对业务人员进行管理，通过管理相关的功能挖掘一线执行上的问题以及验收一线对于战略目标的实现效果。通过这个流程了解业务的管理情况和业务评价方式，挖掘其中的业务改进点。

改动想法：收集一线管理对于功能拓展上的想法，更好地符合业务目标进行功能搭建。

（3）上级管理

战略布局：了解公司整体战略布局，系统的后续规划贴合战略目标，避免工具设计的南辕北辙。比如，可能我们设计一个自动营销的功能出来，想着能够拉动业务销售业绩，但是最终业务却说目前业务处于衰退期，那我们大费周章整的功能可能就发挥不了大作用了。

2. 合理分配：正确配置开发资源，效益最大化

基于信息收集流程了解到的业务细节优化、业务目标、战略布局，我们可拟定对应的长期、中期、短期的功能规划。但是由于技术成本是有限的，有限的时间并不能满足所有的想法。我们便需要合理分配开发资源，使得整体效益最大化。

（1）合理分配各种需求的投入，最大程度满足多方需求

张小龙说，“每天都有几亿人教我做微信”。但是微信并没有所有需求都满足，因为他心里有自己的一杆秤。同理我们对于各方反馈的需求，也不是每个需求都必须要去做的。优先符合公司战略布局，其次是业务目标，再到一线场景，优先高价值的需求，才能更容易在复盘的时候拿出高价值的成果。

但是只做高价值需求也不好，一线体验没有保证，积累太多怨言，传到上级耳里，也会影响上级对于咱们个人能力的判断。因此需要进行对外管理：

1）适当满足需求

一线细节优化可适当满足，选择低成本的穿插在版本规划中，提高各方使用体验，更容易获得正向反馈。

2）达成共识

与一线业务、一线管理、上级管理进行沟通，填平信息差，让他们知道“我们也是有难处的”、“我们不是故意不做需求的”，寻求业务的理解，避免积累太多怨言，影响到我们团队评价。

除此之外，还可以进行功能抽象，使得一个功能可以尽量满足其他的拓展场景，避免重复造轮子，形成一个功能多种用法。

比如，一线业务出于群发生日祝福的场景，提出一个“短信群发”功能。这时候我们对需求进行抽象拆解，去思考下：

1）只有生日场景需要推送吗？用户新注册、首次下单、流失的时候是否需要群发呢？

2）只有短信场景需要推送吗？邮件、IM聊天、站内信场景是否需要群发呢？

3）只能进行文字信息群发吗？图片、消费券、链接、小程序这些内容是否需要群发呢？

4）群发功能只群发吗？是否可以涵盖用户圈选、后续跟踪维护、数据复盘等方面的能力呢？

……

思考完这些后，你的功能可能就不只是“短信群发”了，而是能服务多业务场景的“群发中心”。

（2）提炼需求核心，快速验证功能价值：

业务提需求的时候，可能会说得天花乱坠，什么都想要有，什么功能都很牛逼。但是实际上资源有限，功能价值是否这么高也是不明确的。所以不可能花很多时间在一个价值不明确的需求上。我们需要提炼出其中的核心功能点，快速验证需求价值。待业务流程跑通后，再考虑细节的优化。比如：

公司想要搭建一套专门用来维护核心用户群体的CRM系统，打通产品业务形成产品-客服的业务闭环。成熟的CRM系统包含维系功能、用户信息管理、数据复盘等模块，每个模块又可衍生各种小的功能点，比如维系功能可以有电话外呼、邮件维护、IM聊天等。一整套系统可能开发排期都要一个季度了，业务不太可能等这么久才推进。这时候我们可以分为多个短期目标分期交付：

阶段一：人力或者第三方工具完成核心的维系能力，搭建系统工具辅助核心业务搭建，即是MVP最小化可行产品。比如使用企点搭建核心的沟通业务，技术实现用户管理列表类功能，辅助业务进行客服挖掘-信息维护-数据分析的流程。

阶段二：自研实现核心维系能力，搭建B端产品大框架。利用人力或者一些工具来弥补系统的不便。

阶段三：完成所有必须的功能点，完善系统能力。

业务想做用户画像标签体系，打通上下游业务，那如果全部实现，可能上下游业务部门需要排期，且画像体系需要搭建数据采集、存储、打标等功能，整体成本很大。因此可以参考上面提到的分为多个短期目标分期交付的方案：

阶段一：采用人工在上游业务圈选标签用户，再快速在下游业务进行针对性运营，观察标签是否真的有作用，从而验证标签体系的价值。

阶段二：搭建自动化圈选用户并达标的功能，打通其他业务并进行同步。

阶段三：完成数据可视化、自定义编辑规则等完善的功能体系。

3. 挖掘价值：了解你的系统价值所在

通过与一线业务的交流，可以清晰地知道公司的战略目标、分析我们系统在达成这个战略目标的过程起到什么作用，便可挖掘我们的系统价值所在，以更好地结合系统价值进行设计和运营工作。根据个人的经验，价值点大致可分为：

（1）收入提升

直接收入提升：

即帮助公司赚了多少钱，直接使用收入金额就可以证明系统价值。但很少有对内B端系统能够有直接拉收的作用（除非是可以将整套系统进行销售的SAAS），更多都是起到间接收入提升的作用。

间接收入提升：

指辅助公司赚了多少钱，可以结合公司的阶段性战略目标的指标来判断。

比如公司新上了一款C端产品（产品导入期），想要进行小规模测试。B端产品通过从帮助公司从历史项目数据中筛选了一批核心用户，并通过邮件、短信进行了营销触达，从而帮助产品导入了多少新增用户，这批新增用户质量也符合预期。这说明B端产品在这个过程中是发挥了作用的。

比如公司的C端产品的核心能力得到了验证，希望加大获客规模，并加大商业获利（产品成长期）。B端产品这时提供了利用算法的智能推送系统，通过用户画像辅助业务进行千人千面的营销推送，大大提高了营销的总收入和总单量。这说明B端产品在这个过程中是发挥了作用的。

（2）效率提升

指系统的使用者进行业务时候，同样的时间内处理的业务内容的提升。

比如，CRM系统，原本一个人力能够一天维护100个核心用户，在引入知识库、AI智能对话、群发操作等功能后，一个人力能够一天维护200个核心用户，这就是效率提升的体现。

比如，内容审核系统，原本内容审核一个人力一天最多审核1w的内容，在引入机器审核、聚类算法等功能后，一个人力可以审核2w的内容，这也是效率提升的体现。

（3）成本降低

人力成本降低：

这一块有点类似于效率提升，指原本业务需要多少个人，系统可以使得需要的人数减少多少个。

比如，团队开发出了智能客服对话系统，该系统准确率符合业务要求，那么业务上的客服数量就不需要这么多个了。（虽然有点不人道，但这也是B端产品的价值体现。）

比如，原本企业的非核心美术工作是进行外包的，现在引入了AIGC，这部分外包成本就完全不需要了。

物料成本降低：

假设企业原本某个业务会固定消耗一定的金额，但在系统出现后，这笔固定消耗就不需要了。

比如，公司在自建客服系统之前，是买的第三方的IM工具服务，每个月固定需要消耗一笔费用。现在内部自研一套客服系统，且该系统能满足业务需求，那么原本的固定费用就不需要了，这也是成本降低的体现。

二、发挥价值

1. 客户成功：让用户用好工具，系统不白做

对内B端产品对接其他项目的时候会存在“系统功能使用得不全”、“系统功能使用得不好”的情况，导致我们的功能没有按原本的设想发挥价值，甚至是产生负面的反馈，影响公司内部对于我们的评价。

为了解决这些问题，可以尝试成为内部的“客户成功”角色，采取主动的、以数据为导向的方法来帮助业务更加有效地使用产品，从而帮助业务部门取得更大成功。可执行措施如下：

（1）搭建用户指引体系，不要浪费每一个功能设计

在资源允许的情况下，可以用上操作文档、新手教程视频、后台指引功能、用户培训会议、线下手把手教学等手段，尽可能展现系统能力（价值可视化），并教会业务使用功能。避免由于不会用而用得不当，最终白瞎了功能的开发成本。

（2）构建产品模板，复杂的功能简单上手

这一步飞书文档其实做的很好，同样是在线文档功能，但是飞书通过深挖业务场景，使得产品更好用、更易用、更多人用。

同理，我们的B端产品也可以结合业务的实际场景进行模板的构建，比如营销推送系统，结合业务的拉新、维护、拉收等场景，构建不同的快捷配置模板，简化系统操作，使得更多人能够上手产品。

（3）教业务用得更好，培养用户习惯

业务在提需求的时候往往可能只提了A场景，但是系统可能在B场景下也能发挥作用。这时候就需要我们去告诉用户，XX场景下用这个功能也能够发挥作用。在这个过程中用户逐渐对工具产生依赖，提高系统使用频次和范围，我们才能够有足够多的需求点可供挖掘，才有足够多的案例去说明系统价值。

（4）对齐信息，达成共识避免误解

设计系统功能的时候，会考虑到技术方案问题、资源问题、时间成本问题，导致实际的效果与业务的想法不符合。有些业务就可能会抱怨，说什么“这个后台怎么这么丑”、“这个地方这么搞起来不方便”，这些抱怨有可能传着传着传到领导耳中，产生了“我们是不是能力不行”的疑惑。

这时候我们就需要主动与业务进行沟通，使双方达成共识，比如：

后台丑是因为没有足够资源，但是功能上目前满足了业务要求。某些地方使用起来不方便，是因为目前是MVP版本，快速验证业务思路，业务跑通了后续一定会修改。

如果成功舔好了业务（达成共识），说不定业务会主动向上反馈功能价值，提高后续系统价值汇报时的说服力。

三、价值交换

“打造价值”和“发挥价值”这两步让我们的B端产品能够在单条或多条业务线上发挥出近乎最大的价值，但这时对于其他业务、对于部门、对于个人来说，还并不是价值最大化的。通过主动的价值交换，我们可以在这些方面也获取更大的价值。

1. 推销产品：和更多的业务价值交换

一般系统需求的源于某个或者某几个业务部门，B端产品能够赋能这些业务部门固然很好。但是业务都可能存在自身的生命周期，可能会出现没有业务需要接入B端产品的“空窗期”。这种只和有限的业务价值交换的模式，对于B端产品是极其危险的。我们的价值来源极其依赖于这些有限的业务部门，一不小心可能就会被动失去价值。

因此学会像“SaaS行业销售”一样去推销自己的产品就很重要了。

这里想讲讲法德尔在《创造》一书中提到过的“产品故事”的观点：“简洁明快的故事很容易被人记住。更重要的是，它们也很容易被复述。当你的故事从其他人的嘴里说出来时，它就能打动更多的人，让更多的人购买你的产品。”

法德尔的观点虽然看起来更多适用于C端产品，通过用户故事来切入产品的核心能力。但是我们可以把这个“用户故事”转变成“用户案例”+“用户数据”，配合上好的产品故事的三个要点来讲好故事：

既要感性，又要理性；将复杂的概念简单化；让人想到那些亟须解决的问题——它聚焦于回答“为什么”这个问题；

除此之外，“故事”绝对不只是用嘴说说而已。

你产品的故事是它的设计、功能、图像、视频、客户的评语和建议，以及客户同客服人员的对话，是人们对你创造的这个东西的所见和所感的总和。

成功的“产品故事”包装，能让其他部门聚焦产品的核心能力。从而达成合作，拓展我们B端产品的业务边界，和更多业务价值交换，积累我们部门的自身价值。

2. 定期汇报：交换部门价值和个人价值

先简单讲两个可以证明B端产品价值的方法：

数据说明法：

阐述B端产品的价值最好的办法是通过数据进行价值展示。当我们B端产品系统的价值点之后，可以挖掘核心的数据指标，如收入提升的“营收金额”、效率提升的“服务量级”、成本降低的“降本金额”。然后通过对比历史数据（有功能前后对比）、行业标杆数据（可以通过找同类SAAS公司沟通打探），来论证系统的提升作用。

案例说明法：

当B端产品的核心数据提升不够明显的时候，可以通过挖掘业务上的案例进行辅助说明。比如风控系统挖掘到了产品中的什么风险，止损了多少金额。又比如数据中台工具配合业务进行了什么挖掘，达到了什么样的业务效果。

结合前文讲到的产品价值，我们可以汇总核心数据和成功案例进行价值的展现成报告定期向上进行汇报。数据复盘可包含上方讲到的数据指标体系的内容，并利用“客户成功”案例给系统工具背书，提升报告的说服力。

主做对内工具的中台部门在公司内部不一定站着很重要的地位，因为他们不是以盈利为目的的业务部门。通过数据定期汇报能够刷刷部门的存在感，即通过用系统价值交换部门价值。

当能够让部门在公司层面获得认可的时候，个人价值的必然随之提升，升值和加薪也不远了。

当然这个“邀功”的过程中必然少不了和其他部门的扯皮，这就要看我们能在“客户成功”步骤中达成多少共识了。

总结

总的来说，要让B端产品看起来有价值。先通过合理的需求让系统有价值，其次是让系统能够在业务上发挥价值，最终通过价值交换来赋能业务、赋能自己。

本文由 @柠檬饼干净又卫生 原创发布于人人都是产品经理，未经许可，禁止转载

题图来自Unsplash，基于CC0协议

该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。

标签：