编辑导语：在当今激烈的市场竞争中，C在如此激烈的市场竞争中，端产品拼尽全力追求实现，B端产品相对C突出了端产品的优势。B没有数据的驱动，端产品就无法更好地发展。本文围绕着它B关于端产品和数据驱动，推荐感兴趣的合作伙伴阅读。

最近又一轮风险投资圈资本寒冬来临，以往依靠融资引流持久战，吸引用户，实现广告C端打法已经不再被资本市场所推崇，而是转变为追求如何快速变现，一单就有一单钱的短投资周期模式。而此时B端产品的优势也凸显出来，毕竟说一千道一万，拿到钱才是真的。

作为B端产品往往需要与不同的业务线互动，角色多，需求差异甚至矛盾，导致产品背景业务的复杂性。那么，如何确保在复杂的业务设计中仍能为企业用户提供最简洁的流程呢？

这需要引入数据驱动进行产品迭代，一方面帮助我们发现系统问题，另一方面引导我们完成迭代。让我们看看B如何驱动终端产品的数据？

一、两个误区

首先，我想在这里谈谈：B端数据驱动的两个误区。

1. 误区1. 唯日活论

B端产品不是C端产品本质上有明显的区别:B终端用户数量不会大。比如曾经着火的社交软件子弹短信上线30天，用户总数近750万，但另一方面B领先产品：凭借阿里巴巴的支持，在无数资源投资下运营了4年，宣布企业用户达到5000万。一眼就能看出用户增长率和用户量。

但这是否意味着子弹短信在商业上取得了巨大的成功？钉钉是失败产品吗？我不这么认为。B与企业用户相比，端产品的钉钉多为企业用户C端产品自然具有较高的支付能力和意愿，产品实现速度更快，开发成本回报周期更短。以我们之前在钉店推出的插件为例，月平均流量可以超过50万元，这是C端产品无法比拟。

在这个时候，如果我们还是唯日活论，盲目追求B端产品的日常生活毫无意义。B端产品真正应该追求的是高净值客户，而不是用户数量。

2. 误区2. 虚荣指标

首先，我们应该知道，任何产品的核心都是利润，最好是可持续的利润。我们所做的所有数据分析的核心都是监控产品的核心指标，可视化数据，为产品提供有价值的信息反馈。

所谓有价值的信息是指：

哪些指标可能会影响产品的开发和利润；哪些指标可能会使你的产品获得更大的利润。

如果指标的数据分析最终不能指导负责人或开发人员如何赚钱，这些指标属于虚荣指标。

就像上面介绍的日常生活一样B端产品实际上是一个虚荣指标，也许你B终端产品用户众多，但没有带来任何利润，这对我们来说是无用的，最多只能获得精神上的自我安慰。

当然，这个问题不仅仅是B端产品，C端产品也有同样的问题，我们暂时不提。

二、到底怎么做

说了这么多之后，回到现实，我们应该如何实际操作？如何让数据帮助我们发现和解决问题？接下来，让我们来谈谈如何建立一个有价值的数据系统。

B抽象地说，端产品在一定时间内使用的用户和业务规模是可预测的，因此我们需要一个更合适、更准确的数据分析系统，即根据自己的核心业务量身定制数据系统。具体来说，我们需要从以下两个方向开始：

1. 启动方向1:流程效率

所谓流程效率，就是衡量用户需要执行一个流程的复杂性。具体来说，有以下四个具体指标可以衡量:

（1）横跨系统的个数

涉及交互的系统数量，如客户服务系统，中间连接商户背景、仓储、物流、支付，这里的数量为5；

(2)参与此过程的人数

我们涉及的一个过程需要几个人参与，比如三级审批，需要一级审批人、二级审批人、三级审批人，所以有四个发起人；

(3)信息流页数

或者审批流这个例子，这里具体指的是每个用户完成审批需要跳转的页数，比如这个审批流:

图1.原审批流

前后经历了四页。事实上，我们可以将其完全删除到以下三个页面：

图2.优化后审批流程

在整个过程中删除审批列表。当用户点击审批信息时，直接进入审批细节。不要低估这只是一个链接。如果系统中的几十个模块减少了一个，累积效应将非常大。

(4)单用户操作次数

用户需要做几个操作来完成这个页面的动作，例如，我们点击审批 → 填写5-10个汉字（20-40 → 点击同意 → 确认是否同意 → 点击关闭弹窗 → 点击左上角返回 → 点击下一个审批项目，共7次。

为什么要这样做？

成熟B端产品对企业内部需求明确，其核心意义在于帮助用户更有效地完成任务，而不是继续增加负担。

因此，我们产品的重点应该是帮助用户提高效果，降低成本，规范流程。我们不能仅仅依靠感觉来评估它，而是需要一个准确的数字来告诉我们当前产品的复杂性，并在这里找到问题。

让我们以我以前生产的一个例子来看看上述指标是如何工作的。

我们有一个面向企业的管理系统，在我们的软件中有餐，客户可以根据自己的需要购买。

由于历史原因，我们的产品内部采购历史由财务人工统计。现在，由于公司营销部的需要，我们需要开发一个统计客户消费的模块，客户消费类型可分为以下两类：

产品内购:客户可以直接在产品内购买服务，购买后需要财务确认，然后由CRM用户记录订单信息，然后解除产品中用户的权限。离线订单：通过离线销售团队完成离线产品销售，支付确认流程，然后将信息输入系统。由于离线销售一般具有一定的灵活性，我们的系统应支持销售定制用户包的修改，如提供更多的包。

在这样的业务背景下，我们可以设计第一版的付费管理流程:

图3.流程A业务交互

接下来，让我们是对的CRM开始评估付费记录流程的效率:(我们以需要人访问的页面为统计基准)。

在我们按以上拆解后，我们对该过程的具体用户复杂性有了清晰的了解。我们的系统需要三个系统和六个页面跳转才能单独记录一个信息，这对于一个记录过程来说太臃肿了。幸运的是，在发现问题后，我们可以有针对性地进行优化。

首先，我们分析了跨系统子项和参与此行动的人两个指标。由于三者都有专业分工，无法简化，因此我们锁定了信息流通页面和操作优化的优化方向。

仔细看流程A其实设计理念是以技术实现最简单为导向的。我们把所有的操作和逻辑判断都交给了用户，用户推了进一步的流程。所有的动作都是用户必须完成的吗？有了这个起点，我们就得到了流程B：

图4.流程B业务交互

既然要减少信息流页数和操作次数，就必须引入大量的系统判断逻辑来完成。

第一个优化内容：这里的财务已经确认了付款，项目必须付费，此时根本不需要CRM当用户修改付款状态时，系统会以财务确认为触发点自动修改状态。

第二个优化内容:因为是产品内购，所以我们所有的购买信息都是标准化的，可以直接获取，所以这个时候完全没有必要让步CRM用户输入购买信息和权限，直接使用系统内置信息。

第三个优化内容：作为优秀的产品设计必须要考虑到意外性与扩展性，假设就是出现要去调整付费信息与权限的场景，如果我们直接武断的拿走调整功能，届时系统就不再支持了。但是这个场景又不是非常高频，所以要如何设计呢？

这里我们就引入了判断，如果CRM管理员不做任何修改，信息流和权限流直接使用默认和事故可以随时在线调整，以解决这个看似矛盾的问题，但也简化了绝大场景下的操作，从2步操作到0步和低频1步。

完成上述优化后，让我们来看看两者之间的流程效率比较：

通过这种拆分，我们清楚地看到了这种优化的效果，优化最高提高了近76%的操作，这几乎是一个过程的重生。

2. 启动方向2:功能生命周期

与上述概念相比，这里的概念很容易理解。功能生命周期由软件生命周期演变而来的参考维度是指功能从在线到迭代的时间周期。通过这里，我们可以看到产品设计能力的水平。高能力决定了长功能生命周期，否则就很短。

对于B对于终端产品，如果一个功能的生命周期太短，这意味着每次开发人员被浪费，更严重的是，新的盈利开发时间被推迟。因此，不仅该功能需要返工，而且新模块的开发进度也被推迟，造成了两倍以上的损失。

例如，我们开发的审批模块发现，由于早期研究不足，不支持多人签署功能，需要返工开发，这是标准的0月生命周期。

因此，在上线后，我们应该统计以往版本中所有功能的生命周期，并努力延长其寿命。这里有一个参考值，B端的良性生命周期：一般为3至4个自然月。

你可以根据这个指标进行自测，看看你的产品中是否有这样的问题。

三、最后

B近年来，终端产品成为市场的新宠，不是因为近年来其自身的业务体系发生了翻天覆地的变化，而是因为C随着近年来人口红利的发展，资本和市场自动转移关注困难的企业业务。因此，如何在新一轮浪潮中站稳脚跟是每一个B每个人都应该考虑终端产品。这里的数据是解决问题的最佳工具，帮助我们了解人、人的需求和人性。