NPS悖论

NPS(Net Promoter Score),译作“净推荐值” ,是一种计量某个客户将会向其他人推荐某个企业或服务可能性的指数。不知什么时候被引入互联网产品界,被各种产品经理视为神物。wikipedia

之前也曾经做过NPS的收集工作,也曾经非常迷恋NPS。但最近一段时间的思考发现,似乎很难获得一个非常有效或者参考比较高的NPS。

为什么?主要是“收集”。我们知道NPS是一个非常泛(general)的指标,因此绝大多数的NPS获取方法都是在各种问卷调查的最后一项来一句:“请告诉我们您向他人推荐XXX的倾向是:1.2…..10”,非常常见,有时候还会在一些线下的实体店里遇到类似的问题。

首先的问题是:填表悖论。这个不知有没有专门的定义,我只是拍脑袋想起来这个词。什么意思呢?其实很容易理解,那些愿意回答你的产品的调查的人首先就已经有较高的推荐意愿了。试想,如果我都不喜欢或者厌恶你的产品,我还愿意花时间告诉你反馈吗?尤其是同类产品的获取相对容易的时候。也许这也是NPS的计算方法非常“苛刻”的一部分原因,去抵消掉填表悖论的影响。

另一个问题,其实是接着上一个问题。一个极度理性的人是不会浪费一丁点时间在一件没有后续结果的事情上的(除非被逼无奈,如果你的产品能让一个理性的人没有别的选择,相信我,你不需要NPS,你只需要数钱即可)。从这个角度来说,你的调查最终只会遇到两类人:

1. 感性的人

2. 对产品抱有强烈喜爱的人

后者不用说了,他们的回答一定会提升NPS,至少不会拉低,而前者呢?就非常难说了。感性的人的结果是非常主观的,饱含各种偏见,几乎是一种随机结果。你真的确定要用主观感觉来衡量你的产品好坏吗?除非这种感觉数据足够多,并且一定要在用户一使用完马上来做(以减少其他因素影响主观印象),也许才能获得有参考意义的数据。可获取这个数据我还是觉得很悲观的。

说成这样,难道就要抛弃NPS吗?当然不,只是我们需要特别警惕NPS的收集,同时要知道NPS的参考价值有多少。不要盲目,否则就是“迷信”了。

苦闷的项目经理

项目启动会议开始, 项目经理拿出自己的项目计划信心满满的想要告诉大家接下来的项目实施应该如何展开. 可是刚刚开始就被需求分析师和产品经理质疑:
模块划分不合理,应该按照业务场景制定发布计划.
这意味着项目经理原本按照功能和系统模块制定的计划被90%的推翻.
为什么会有这样的问题?
项目经理的技术出身导致其对项目的scope估计无可避免的过早考虑到设计(甚至是代码重用)
而产品经理和需求方更多关注的是产品提供的feature,或者说一个”完整的”功能点.在scrum里我们称为”用户故事”.
而项目经理的项目计划又有两份,一份是给”上面”看的,也就是用户,产品经理,需求方;而另一份是给”下面”看的,也就是系统设计/开发人员.而这里显然是第一份.因为关注点不同.
这也是项目驱动(project-oriented)和产品驱动(product-oriented)的交付方式和内容的不同.
项目驱动更多的是在整个项目结束后交付完整的代码和所有的功能.因为项目(开发)的周期相对较短.
而产品驱动则是要在不同的阶段都要交付feature和功能(当然你觉得每个阶段都可以用项目驱动来做也没什么不妥),同时还要兼顾整体的系统设计和重用性/维护性等问题.因为产品(开发)的周期通常较长,夜长也就梦多了,开发周期可能同时伴随的维护任务和设计重构.在产品驱动模式中,项目经理需要更好的平衡能力和全局掌控能力.

项目启动会议开始, 项目经理拿出自己的项目计划信心满满的想要告诉大家接下来的项目实施应该如何展开. 可是刚刚开始就被需求分析师和产品经理质疑:

模块划分不合理,应该按照业务场景制定发布计划.

这意味着项目经理原本按照功能和系统模块制定的计划被90%的推翻.

为什么会有这样的问题?

项目经理的技术出身导致其对项目的scope估计无可避免的过早考虑到设计(甚至是代码重用)

而产品经理和需求方更多关注的是产品提供的feature,或者说一个”完整的”功能点.在scrum里我们称为”用户故事”.

而项目经理的项目计划又有两份,一份是给”上面”看的,也就是用户,产品经理,需求方;而另一份是给”下面”看的,也就是系统设计/开发人员.而这里显然是第一份.因为关注点不同.

这也是项目驱动(project-oriented)和产品驱动(product-oriented)的交付方式和内容的不同.

项目驱动更多的是在整个项目结束后交付完整的代码和所有的功能.因为项目(开发)的周期相对较短.

而产品驱动则是要在不同的阶段都要交付feature和功能(当然你觉得每个阶段都可以用项目驱动来做也没什么不妥),同时还要兼顾整体的系统设计和重用性/维护性等问题.因为产品(开发)的周期通常较长,夜长也就梦多了,开发周期可能同时伴随的维护任务和设计重构.在产品驱动模式中,项目经理需要更好的平衡能力和全局掌控能力.