两步掌握产品数据驱动式迭代
⇨⇦
本篇文章主要讨论：面对高复杂业务的B端产品，如何运用数据去精准指导B端产品设计，帮助我们找到每次产品设计中的症结，并进行针对性优化。
最近又一轮的创投圈资本寒冬到来，以往依靠融资进行持久战的引流，拉用户，广告变现这一漫长的C端打法已经不再被资本市场所推崇，而是转变为追求如何快速变现，一单就有一单钱的短投资周期模式。而此时B端产品的优势也就凸显出来了，毕竟说一千道一万，拿到钱才是真的。
作为B端产品，由于常常要与不同的业务线进行交互，他们的角色众多、需求存在差异甚至相互矛盾，这也就造就了产品后台业务的复杂性。那么如何保证在复杂业务设计时依旧能为企业用户提供最精简的流程？
这就需要引入数据驱动来进行产品迭代，一方面帮助我们发现系统问题，另一方面指导我们去完成迭代。那么就让我们来看看B端产品如何进行数据驱动？
首先在这里要讲一讲：B端数据驱动中的两个误区
误区1. 唯日活论
B端产品不是C端产品，这两者在本质上有着鲜明的区别：B端的用户体量不会大。举个例子来说最近大火的社交软件子弹短信上线30天，用户总数近750万，但是反观B端的龙头产品：有着阿里撑腰的钉钉，在无数资源投入下运作了4年才勉勉强强的宣称企业用户到达5000万。其用户增速与用户体量高低立下一眼就能看出来。
但是这就说明子弹短信取得商业上的巨大成功了吗？钉钉就是一款失败产品吗？我并不这样认为，作为B端产品的钉钉由于用户多是企业用户，相对于C端产品天然性的有更高的付费能力与意愿，产品的变现速度更快，开发成本回本周期更短。就拿我们之前在钉钉商店上线的插件来看，月均流水就能打破50万元，这是C端产品根本无法比拟。
那这个时候如果我们还是唯日活论，去一味追求B端产品的日活就是毫无意义的。B端产品真正应该追求的是高净值客户而不是用户数量。
误区2. 虚荣指标
首先我们要知道任何一款产品的本质核心就是盈利，而且最好是能持续地盈利。我们所做的一切数据分析的核心就是监控产品核心指标，将数据进行可视化展示，为产品提供有价值的信息反馈。而所谓有价值的信息指的是：
哪些指标可能会影响产品发展与盈利；
哪些指标的改变可能会让你的产品有更大的盈利。
如果指标的数据分析最终不能指导负责人或开发者该如何让产品赚钱，按产品运作的说法，这些指标都属于＂虚荣指标＂。
像上面介绍的日活在B端产品中其实就是一个虚荣指标，可能你的B端产品用户量多，但是没有带来任何盈利，这对于我们来说就是无用的，最多只是取得了心灵上的自我安慰。当然这个问题不仅仅是B端产品，C端产品也存在同样的问题，在这我们先暂且不提。
到底怎么做
在前面说了这么多后，回到现实我们到底要怎么去实战操作呢？如何让数据帮助我们发现问题并解决问题呢？接下来我们就来谈一谈究竟如何打造有价值的数据体系。
B端产品抽象来看在某个时间段内使用的用户和业务规模是可预测的，因此我们需要更适合更精准的一套数据分析体系，也就是要依据自身的核心业务去量身打造数据体系。具体来说需要以如下2个方向着手：
着手方向1：流程效率
所谓流程效率就是衡量一个流程需要用户去执行完的复杂度，具体来说这里有如下四个具体指标可以进行衡量：
（1）横跨系统的个数
涉及交互的系统个数，比如客服系统，中间连接了商家后台、仓储、物流、支付，这里的数字就是5；
（2）参与此流程的人数
我们所涉及的一个流程，需要几个人参与，如三级审批，这里需要一级审批人，二级审批人，三级审批人，因此共有发起人4位；
（3）信息流转页面数
还是审批流这个例子，这里具体是指每位用户完成审批其需要跳转的页面数，比如这个审批流：
图1.原审批流
前后经历了4个页面。当然在这我们其实可以完全删减为如下3个页面：
图2.优化后审批流
在整个流程中去掉审批列表，当用户点击审批消息时直接进入审批详情，可不要小看这里只是减少了一个环节，如果系统数十个模块都减少一个，那累积效应就很大了。
（4）单用户操作次数
用户在这个页面中完成动作需要进行几部操作，例如：审批中我们点击审核 → 填写5-10个汉字（20-40次键盘操作） → 点击同意 → 确认是否同意 → 点击关闭弹窗 → 点击左上角返回 → 点击下一个审批事项，总计7次操作。
为什么要这么做呢？
作为一个成熟的B端产品，它面向企业内部需求明确，因此其存在的核心意义在于帮助用户更高效的去完成任务而不是继续添加负担。所以我们产品的重点就应是帮助用户提升效果，减少成本，规范流程，我们不能单纯的依靠感觉去评估，而是需要一个精准的数字去告诉我们当前产品的复杂程度并去找到这里问题的所在。
让我们以一个我以前生产中的例子来看看上面的指标如何发挥作用。
我们有一款面向企业的管理系统，在我们的软件中带有付费套餐，客户可以根据自己的需求来购买。之前由于历史原因我们的产品内部购买历史都是由财务手工统计，现在由于公司市场部需要，我们要开发一个统计客户消费的模块，而客户的消费类型可分为如下两类：
产品内购：客户可直接在产品内部进行服务购买，购买后需要财务确认，再由CRM用户将此订单信息进行记录，随后解除用户在产品内的权限。
线下成单：通过线下销售团队去线下完成产品销售，与打款确认流程，随后将信息录入系统，由于线下销售一般拥有一定的灵活性，因此我们的系统要支持销售的自定义用户套餐修改，比如多赠送几个套餐包等操作。
在这样的业务背景下我们可以设计出第一版的付费管理流程：
图3.流程A业务交互
接下来让我们对CRM中这个付费记录流程的效率开始评估：(我们以需要人接入的页面为统计基准)
在我们按如上拆解了后，就对这个流程具体的用户复杂度有了清晰的认识，我们的系统单独一个信息记录就需要3个系统与6个页面的跳转，这对于一个记录流程来说是太过于臃肿了。好在找到问题后就可以有的放矢地进行优化。
首先我们分析下＂横跨系统子项＂，＂参与此动作的人＂这两个指标由于这其中三者每个都有专业分工所以无法精简，那么我们就锁定了我们的优化方向在信息流转页面与操作上进行优化。
仔细来看流程A的设计思路其实是以技术实现最简单为导向的，我们将所有的操作与逻辑判断都交给了用户，用户推一步流程进一步，那么是不是所有的动作都是用户必须要去完成的呢？带着这个出发点，我们就得到了流程B：
图4.流程B业务交互
既然要去减少信息流转页数与操作次数，那么我们必须要去大量引入系统判断逻辑来完成：
第一个优化内容：这里财务已经确认到款了，那项目必然为付费状态，此时完全不需要CRM用户再去修改付费状态，系统就以财务确认为触发点进行状态自动修改。
第二优化内容：由于是产品内购，所以我们所有的购买信息都是标准化且可以直接获取到，那么此时完全不需要再让CRM用户去录入一遍购买信息与权限，直接使用系统内置信息就行了。
第三个优化内容：作为优秀的产品设计必须要考虑到意外性与扩展性，假设就是出现要去调整付费信息与权限的场景，如果我们直接武断的拿走调整功能，届时系统就不再支持了。但是这个场景又不是非常高频，所以要如何设计呢？
这里我们就引入了判断，如果CRM管理员不做任何修改，信息流与权限流直接就使用默认而出现了意外情况可以随时上线调整，这样就解决了这个看似矛盾的问题，同时也将绝大场景下操作进行了精简，由2步操作变为了0步与低频的1步。
在做完上述优化后让我们再看一下两者的流程效率对比：
通过这样拆分我们清楚的看到了这次优化的效果，优化最高提升了接近76%的操作，这对于一个流程来说几乎是脱胎换骨的提升。
着手方向2：功能生命周期
这里的概念相对于上面的来说就很容易理解了，功能生命周期由软件生命周期演化出来的一个参考维度，是指一个功能从上线到迭代被更新或替代的时间周期。通过这里我们可以看出来产品设计能力的高低，能力高决定功能生命周期长，反之就短。
对于B端产品来说假如一个功能生命周期过短，都意味着每次的开发人力被浪费了，此外更严重的是新的可盈利的开发时间被延误。所以不仅仅再是此功能需要返工，同时新的模块开发进度也被耽误，从而造成是两倍以上的损失。
例如：我们开发的审批模块，由于前期的调研不够充分上线后发现，不支持多人会签功能，此时需要重新返工开发，这样就是标准的0月生命周期。
所以我们要在上线后统计历次版本中各功能生命周期，并努力去延迟其寿命。在这给大家一个参考值，B端的良性生命周期：一般为3至4个自然月。
大家可以根据这个指标来进行自测，看看自己产品中是否也有这样的问题。
最后
B端产品在去年成为市场新宠，不是因为它本身业务体系在最近时间内发生了什么翻天覆地的变化，而是因为C端的人口红利已经随着这些年的发展消失殆尽，资本和市场自动转移关注到难啃的企业业务上，所以说如何在新的一轮浪潮中去站稳脚跟，是每个B端产品人都要思考的问题。而这里数据就是我们解决问题的最佳工具，帮助我们去了解＂人＂，了解人的需求，了解人性。
相关阅读
设计的底线：不要让产品成为用户额外工作