产品设计体会(6009)再侃KPI

2008年末的一次茶话会,大家又对KPI乱喷了一阵,有些想法,不妨再乱说一番,反正KPI这个东西也不是我们能定下来的,下面有些内容经过简化,有些内容不便细说,大家看看就好。

之前的模型,把产品的KPI细分成两个:付费用户数由销售部门来背,活跃度(=活跃用户/付费用户)由产品部门来背。产生的问题上一篇有过描述,根本性的一句话:付费用户中有相当的用户并没有真正的用过产品(原因很多,比如有类似手机销售里骗“返点”的做法),不可能变成活跃用户,而销售部门和经销商一心冲用户数,也不管这批人的死活。

到底怎么解决这个问题我也想了很久,这几天发现,必须要引入之前一直经常提,但从未真正体会到其重要性的职能部门——服务部门。渠道不仅仅是销售的渠道,还是服务的渠道。联想一下传统的商品,如家电,在通过卖场建立了销售渠道以后,必然有落地的售后服务网点,而我们卖的是软件,也就意味着并不像买推广那样卖出去就完事,而是需要有面对面服务的,这就意味着经销商必须要做服务,而我们也只能依靠经销商做服务(可怜的是,这批经销商是做推广起家的,服务力量实在是弱)。当然,我们作为厂商对经销商的控制也就要分两条线走,如图。

思路继续下去,就是要变两步走为三步走。通过一系列的定义,给出一个“使用用户”的概念,而对于KPI,不是回归到大家一起背所有,而是进一步细分为三块:

Ø 付费用户,销售部门背,让“用户”买下来;

n 现状是“经销”与“代理”模式混合存在,我们也不妨默认“经销商先批发再零售”。

Ø 使用率(=使用用户/付费用户),服务部门背,让end user用起来;

n 产品卖出去,是指完成“厂商购买者”的一步,购买者可能是经销商,可能是中小企业老板,但很可能不是end user,服务要完成的就是让打通产品到end user的路。

Ø 活跃度(活跃用户/使用用户),产品部门背,让end user用好。

好理想啊,如果这样,我们就轻松多了。更理想的一个做法,对经销商的两条线监控都要和直接利益“钱”,挂钩,并不是销售完了就给钱,而是服务不好也不给钱,这样也就不怕使用率上不去了,本质上是将KPI下放到经销商那里,你们赚了钱,也该多背点……

产品设计体会(6008)事关KPI

KPIKey Performance Indicators永远都是悬在头上的一把利剑。

最近想到一个KPI的问题,应该普遍存在的:将整个产品的KPI分解到各个部门来背,付费产品最明显的两个KPI

Ø  用户数——多少人买;

Ø  活跃度——多少人真的在用;

那就卖的部门管第一个,做产品的部门管第二个吧,看上去很合理,但是做起来似乎会有矛盾。

市场/销售部门的KPI是“用户数”,所以会要求产品为付钱的人做,这样一来就比较看重“噱头”,目标是所有愿意付钱的人,销售能力越强,能卖的范围就越广,也就是说会卖给更多的非产品部门定义的“目标用户”。公司是要赚钱的,通常商业驱动产品,市场销售去卖,我们在后面做,有点像妓院,老鸨拉来什么样的爷,小翠是没权利选择的(头牌除外,头牌的特点就是只做大客户,定制服务),只能照单全收。

产品部门的主要KPI是“活跃度”,用户开始用了,产品能不能粘住用户很考验我们的功力,所以我们想的是为使用者做,希望产品都是自己定义的“目标用户”在用,因为想满足所有人就是所有人都不满足嘛。而对于企业用户来说,拥有购买决定权的人与产品的使用者基本肯定不是一个人,和其他的个人互联网应用很不一样,这就是一个痛苦。

以上是产品第一年的问题,第二年开始情况又复杂一点,就多出了“续签率”这样的一个常见的KPI。一般来说“续签率”和“活跃度”是正相关的,按照常理,市场销售在第二年会开始背“续签率”,那么产品部门的日子就要相对好过一点。

另一方面,开发的KPIbug数和项目的完成情况,所以人之常情,会想砍需求,尽量少做、做自己有把握的(测试的KPI是上线后故障数,很容易和开发统一战线),那么会导致产品人员与技术人员讨论的时候发现互相耍的不是一套拳。

好了,跳出来看,大老板这么分解KPI肯定有他的道理,也许不这样做问题更大,也许变成每个部门都要对所有事情负责,就是所有事情都没有人负责,没有清晰而唯一的目标反而让人纠结,不过我还没想透。