干货分享 | B端产品的指标设计思路

6 评论 12668 浏览 85 收藏 13 分钟

编辑导语:很多时候我们都是靠指标进行判断,在B端产品中也是如此,指标可以帮助我们进行分析和推理,特别是对平台和业务进行分析时可以用到;本文作者分享了关于B端产品的指标设计思路,我们一起来看一下。

关于指标,我们都知道其作用在于将定性的事物转换为可测量的数量,将解题的思路从语文变为数学。

其次,指标能够帮助我们将产出与收益量化,B端产品也是如此;推理的思路遵循B端产品的价值:降本增效,“本”指的成本,“效”指的效率及效果。

本文将基于此分享平台和业务2个角度的指标设计方式,年末也是考核的季节,希望这篇文章能给大家带来一些帮助。

01 平台指标

B端产品的指标设计思路

平台指标的设计思路,源于目前所负责产品的设计方法,分别是:质量及安全、效率及成本。

理解为:保障质量以及安全的前提下,提升效率、效果,并降低成本。

1. 质量及安全

B端产品的指标设计思路

质量及安全,二者相互依存、密不可分;前者侧重进攻,后者侧重防守。

B端产品的指标设计思路

质量,用于衡量产品能否使用。安全,则决定产品在使用时的稳定性。

从需求类型看,前者侧重功能性需求,后者则重非功能性需求。对应的流程类型分别是核心流程与异常流。

B端产品的指标设计思路

质量及安全也是衡量产品可用性的重要维度。

可用性指产品正常使用的概率或时间占有率,其衡量指标是系统可用时长以及不可用时导致的经济损失。

系统可用时长的计算公式是系统正常的使用时间和总时长之比。基于此公式,我们的目标是避免系统不可用或减少异常时长。

B端产品的指标设计思路

从可用时长向下拆解过程指标,分别是发现率、发现时长以及影响时长。

发现率,用于衡量监控的覆盖度;发现时长,用于衡量监控的敏捷性;影响时长,则用于衡量问题响应及解决的时效。

保障了质量与安全,才有资格谈论效率与成本。

2. 效率及成本

质量与安全,保障我们拿到及格分,效率与成本才是加分项。

B端产品的指标设计思路

B端产品源于高频的需求被固化为功能或者产品,目的是提升需求实现效率,其次是降低人力成本。

如果提升的效率无用或降低的人力成本无法覆盖实现成本,这样的产品还是不要做了。

1)效率

B端产品的指标设计思路

B端产品的提效绝不仅是面向业务,还会面向平台的运营、研发以及测试。

只有支持团队的效率提升,才能投入到提升“质量及安全”以及“效果”的相关工作之中。

所以拆解的角色会同时包含支持方与业务方,并以此向下推理。

工作效率的衡量指标是完成每件工作的时间成本,分解的方式从支持方出发可以使用需求流程,从业务方出发可以使用操作流程。

当然还有咨询、审批、反馈等流程也同样适用此种拆解方式。

不妨遵循这个思路回答,我们所提升的效率包含了哪些环节?

2)成本

B端产品的指标设计思路

人力成本:

世界和钱有关,所有的结果指标都应与金钱挂钩,才能便于我们计算投资回报率。

上一小节所说的时间成本,也应将其转换为人力成本,再与研发成本比对计算收益。

非人力成本:

非人力成本即人力以外的其他成本,包含设备成本、服务成本等。

这两点都比较通俗易懂,简单举2个例子。如:优化了算法,运算资源的减少,费用也随之减少;减

少了短信的字数,短信的成本减少了。

在这里需关注的是,降本提效不要拘泥于产品。解决问题的方法有很多,包括预算控制、成本考核、业务规划等都是非常好的办法。

02 业务指标

假设所负责产品真切地在解决有价值的问题,那么“质量与安全”是及格分,“效率与成本”能让我们加分拿到良,但业务指标做的好才能够拿到优。

产品之所以存在,是因为用户希望借助它做某件事,而企业会因为这件事获得某些收益,只不过在B端产品,用户变成企业内部的成员。

衡量收益的数字,实质上就是业务指标:

B端产品的指标设计思路

ROI的计算公式,相比传统的计算方法额外多了一个参数:“负向指标经济价值”。

道理也很简单,每发一篇公众号文章,有人关注也会有人取关,有正向也当然会有负向。

但这并不是说不需要继续运营了,而是要让分子大于0,并且尽可能的靠近、超出分母。

B端产品的指标设计思路

以上图的第二个例子进行解读,假设是某东Plus会员年卡,临近过期用户仍未进行续费,这时平台运营会将这部分用户推送至外呼专席,由外呼同学引导用户进行续费。

过程指标体现了结果指标的完成方式,要提升结果指标的经济价值,要么减少完成过程的损耗,要么提升完成结果的单价。

而负向指标,即这种运营行为可能导致的损失,主要分为绝对损失和概率损失。

绝对的损失是费用,如短信、电话外呼等。概率损失则与行为息息相关,如第一个例子中的取消关注。

负向指标同样需要换算为经济价值,如:1个公众号粉丝的费用,1个小程序UV的费用。

将指标拆解、定价完毕,工作就完成了一大半,指标的拆解方法和后续的产品设计方在此前的文章也有过许多的解读,在此也就不再赘述了。

03 指标的阶段性

做B端,其实挺难的;很多事情做好了是本份,做差了就会不及格。

为了避免只能体现苦劳,无论是什么样类型的B端产品都面临一个问题:怎么体现价值?更往前一步,不同阶段应该体现什么样价值?

前面2节阐述了不同角度的指标拆解方式,本节想和大家分享不同阶段关于指标的思考。

B端产品的指标设计思路

今年经历了1个B端产品0到1到100的过程,也简单将其抽象为了4个阶段,分别是“服务、规范、优化、扩展”。

1. 服务

如前文所述,B端产品源于高频的需求被固化成为功能或者产品。

这也意味着有许多的逻辑此前是在不同的部门在不同的时间段以不同的方式实现的,而要体现产品能用,最底线目标是能够向前兼容。

这也是命题为服务的原因,和业务、产品、研发甚至是测试了解旧有逻辑。

而产品的试运行阶段,迁移亦或者新上线看到的满满都是风险,很难看到收益。

你会发现自己以前的规划没有那么的美好,再顶层的设计也应变不了千变万化的业务,那个时候我更多想的是能用就足够了。

2. 规范

服务的目的是为了规范。通过服务,我们了解了业务,完成了社交,打通了链路。

最终完成了规范的前提,保证产品最核心的这件事有了统一的出口,才能够控制变量,才能够进行比较。

这个阶段更多的是在填上一个阶段的坑,把以前轻视、非阶段性重点的目标捡起来优化。

优化完毕后,才能算得上所有人都在做相同的事情,才能基于功能以及运营的标准化,做到可溯、可管理、可复用、可优化。

规范,也意味着站稳了脚跟,才能去谈安全和效率。

3. 优化

经历了服务及规范阶段,意味着苦劳的分拿到了。但这个阶段过后,如果我们仍以此作为自身的价值体现,那意味着你要被淘汰了。

优化阶段,是输出影响力的阶段。

统一实现规范,能够优化平台指标。统一运营规范,能够了解不同业务的运营情况,从而进行旧运营模式的优化以及新运营模式的开展。

所以指标聚焦在成本及效果。

4. 扩展

扩展源于,碗里的奶酪总会吃完的,优化也是有上限的。再往前走,应该覆盖新的领域。

一方面是拥有了上一个项目的技术、产品、人脉储备,另一方面影响力的输出也让你再次推行新事物时阻力会更少。

覆盖的方向,目前是基于自身对产品上下游进行拓展。

至于说指标是什么?也许和前三步一样,也许会有新的想法。等我走完了这个阶段,再看看有什么变化吧。

04 写在最后

产品其实很像一个圈,圈的尽头又是旧的起点。现在回想这么多的重构,有多少是真的因为必要性呢?又有多少项目能真的产生价值?

写到这里其实还有些伤感,产品和产品经理相互依存的日子能有多长呢?这又是不是“再生一个”的原因?这么看来计划生育似乎和产品规划也没有啥区别了。

#专栏作家#

WISE,微信公众号:Becomewiser,人人都是产品经理专栏作家。腾讯产品经理,专注于精细化运营、用户数据体系建设等领域。

本文原创发布于人人都是产品经理 ,未经许可,禁止转载

题图来自Unsplash,基于 CC0 协议

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 大佬好,我感觉去做B端产品是很少会用到质量;安全;效率;成本这几个维度来衡量。更多的使用业务指标来衡量价值,但是B端有很多迭代确实提高了一些效率或降低了成本,但是很难通过业务指标来衡量,是只有我一个人这么感觉么o(╥﹏╥)o

    来自北京 回复
    1. 朋友你好,业务价值是最重要的价值。如果不拥抱业务其他的都是空谈,这一点我是非常认可的。但我会从这里拆出业务视角和业务指标。

      从视角看效率、成本和稳定性,从业务指标看最终结果,而质量和安全是稳定的关键。

      之所以量化前面的指标,关键在于某些阶段你很难创造业务价值那应该怎么描述自己的工作呢。比如说建立数仓,应用于业务之前都是负向的。

      如果是业务后台那核心指标是业务指标,但如果是工具平台很多业务指标可能就和工具平台没有什么关系了。

      回复
    2. 个人理解是,基础指标的质量、安全、使用效率更适合衡量基建模块基建,比如CRM的电话服务的服务稳定性、工单量。
      而业务指标的成本、业务效率更适合给到业务模块,如CRM的线索管理、公池管理等。
      业务价值的ROI中,负向经济价值、成本是在方案设计就会考虑且降低的内容,比如CRM的成本=新业务模式需要配置,负向经济价值=可能引起客诉。对于部分业务来说这两块相对固定,不一定会作为核心指标来观测。

      上文的分歧点在,回答的同学做业务模块更多偏好业务指标,作者是基建模块和业务模块都做过(从职业选择文中得知),会有更全面的认知。整体逻辑如上文,区别是落到自己的业务里应用吧。

      B端业务中,做基建模块的人应该少于做业务的人。以及市面B端公司大多都是非大厂,基建能力大多外包,业务作为主营收模块,人员占比更高。
      从需求方体量角度来说,关注业务指标的效率、成本的人会更多哈~期待这块的深挖~

      来自上海 回复
    3. 也欢迎一起多多交流哈。

      回复
    4. 你不是一个人。不过我觉得B端产品,默认是需要保证质量和安全的,在这两个的大条件下,再去看降本增效。遇到的同样的问题也是降本增效比较难衡量,对外的还好点,有业务方可能会提供一个业务指标,对内的工具就更难了。比如说我做了一个工单记录功能,它可以把同步的技术支持变成异步,目的是为了提高技术支持的工作效率;这里就涉及到一个问题,之前的工作效率用什么数据指标来考核,为了这个指标可能我需要先统计之前的情况,但往往这个数据在企业内部是没人去统计的。这个时候就陷入困境,不知道该怎么破了。大佬们,如果有好的建议求指导

      来自北京 回复
    5. 我的一点想法,对比改进前后工作流程中节省的时间成本,比如耗时降低了多少比率;或是节省的技术资源在其他地方发挥了多少价值,找找可以量化描述的数据。

      来自北京 回复