天天喊“刚需、高频、痛点”，我们可能更缺的是衡量指标

wz***

帮助产品经理们建立较为完善的数据指标评估体系，更好地帮助产品功能的优化和迭代。

对于我们做产品的人来说，最痛苦的点，可能就是产品做出来之后，被客户喷“使用繁琐，体验太差”，被老板DISS“你的产品切不到痛点”;，诚然一个产品好不好，不能凭产品经理的个人喜好，也不能由于极个别用户的负面反馈，而对产品进行全盘否定，我们更多需要根据大量的数据反馈，同时结合尝试来进行判断。我们从产品入行的时候，就被行内大咖教育，做产品要做“刚需、高频、痛点”，但是却从没有人去告诉我们，如何通过观测数据去验证我们做的东西是否是满足这三个核心要点，本文旨在帮助产品经理们建立较为完善的数据指标评估体系，更好地帮助产品功能的优化和迭代。

首先请容许我按照自己的理解，重新对“刚需、高频、痛点”的做些定义：

①刚需是相对于“弹性需求”而言的，从字面意思就可以理解为是硬性，人们需要的东西或者必须要做的事。

②高频则是指需求欲望在一定周期内产生的频次。

③痛点则是指用户在满足自己需求的过程中，遇到的最大障碍。

那么评估指标怎么定？主要就是下面这一句话：

刚需看渗透、高频看人次、痛点看能耗
一、刚需看渗透
渗透率原本是市场营销中的一个概念，指企业的实际销售量在市场潜量中的百分率。但是我们可以将的使用范围进行衍生，大到行业覆盖度，小到产品中的某个功能特性：比如互联网渗透率是指使用互联网的网民与总人口数之比，用于表达互联网渗透到普通民众生活的程度。而对于某个app的产品来说，我们提出一个新的概念叫做“功能渗透率”，是指当前使用该功能的人数占整体使用产品的人数比例，这个指标可以较为客观的反应出，当前功能对于使用产品的人群的覆盖度，功能渗透率越高，则说明该功能是用户当前使用产品的核心功能，也即在当前产品形态下的大部分用户刚需。

以一款教育app为例，这个产品中主要包括看资讯、听课程、做题库等产品特性，相关的产品功能渗透率如下：

从数据中我们就不难发现，10个人来使用该产品，7个人看资讯，2个人听课程，1个人做题库，看资讯这个功能点能覆盖到大部分的用户。而对于一款教育产品来讲，其最终目标是帮助用户拿证过题考试的，所以这个数据结果其实乍一看是反常识的，我们大部分人会认为结构化的课程才应该是用户最需要的内容及功能，有些颠覆我们的认知，然而是什么原因导致的，我们就需要进一步做些反思了，有可能是功能刚上线，知悉的用户数量不多，也有可能是上线运营乏力，还有可能是内容不够给力，又或者是产品交互体验不行，技术老是出bug等，这些都需要进行具体的下钻分析。

同时我们还需要注意以下几点：

①渗透率的数据可以帮助你验证你设计的需求解决方案，是否被大多数用户所认可，而不能判定说渗透高的就是刚需，渗透低的就是普通需求，刚需与否还是需要通过产品经理对业务的洞察去判断，渗透率更多的是以“后验性”指标而存在的。

②刚需是根据用户完成的业务目标所达成的任务而定的，离终点越近的越是刚需，我们可以根据用户的需求层次画一个同心圆，从里到外由强变弱。还是以教育类app为例，可以得到以下的图解：

总之如果数据展示出来，发现理想和现实中有落差，那我们就要不断找原因，不断调优，持续逼近理想的最优解。

二、高频看人次
人次是指用户在一定时间、一定范围内重复出现的行为次数。对于我们日常的生活来说，普通人可能一辈子就买一次房，十年去换一部车，他们在人生的尺度上其实是个低频的，但是在你要买车的前三个月的时候，你选车的需求被激发，每天看各类购车资讯的行为又变成了短时间的高频需求了，所以这里必须强调它是一个相对的概念，我们不能脱离场景去说这个。

我们来看一个支付宝的经典案例：

逆袭的工具型产品-支付宝

2003年的时候，支付宝仅仅只是淘宝的一个子功能，作为网上交易的信用担保工具；

2004年末，支付宝开始逐步从淘宝体系中分拆，成为了一个的独立的第三方网络支付平台；

2008年，支付宝发布移动电子商务战略，从PC端业务开始往移动端迁移，推出手机支付业务，同年公共事业缴费正式上线，支持水、电、煤、通讯等缴费；

时至今日，支付宝已经不断的扩宽它的使用场景，支付宝及其本地钱包合作伙伴已经服务超12亿的全球用户，俨然成为我们手机里面的超级工具app，就算我们不是每天都去淘宝网购物，生活中的线下支付每天也必然会使用到1次或多次支付宝，可能是点外卖，可能是便利店的结算，又或者是公交车刷码；

支付宝的发展史就是低频的工具型app最好的逆袭，不断的渗透到各个可以使用到支付的场景中，网上购物也许是个低频的场景，但是线上线下的各类交易中的支付就是一个高频的场景，每天全世界各地都在发生着各种交易，小到在学校门口买2元钱的汽水，大到购买万元的笔记本电脑，这些一旦全部聚集在一个平台上进行操作，那将是一个非常海量的数字，这其实就是为什么现在有很多工具型app在疯狂的叠加场景化的功能，其实目的也就是在于“集低频为高频”。

那如何判断我们做的功能中哪些是低频哪些是高频呢？我们还是以刚才的那款教育app为例，需要注意的是不同功能在相同的时间区间里面，它们的频次是不一样的，同样一个功能在不同的时间区间里面，按天看、按周看、按月度看，频次也都是不一样的，这款app主要提供看资讯、听课程、做题库等产品特性，相关数据如下：

所以我们从上面数据中会发现，资讯是个高频的功能点，而课程和题库是低频的，同时还会发现一个有意思的趋势，一般而言越是高频的功能点，随着时间跨度变大，它的人均频次的增幅越快，越是低频的功能点，它的人均频次的增幅越慢，当然也有一些特例。所以如果产品中希望把课程和题库的人次也提高的话，可以考虑把冗长的课程，拆分成一个个小的知识点-短视频进行播放，把动则百八十道题目的题库，拆解成每日一题的低门槛任务。

总之如果你的产品切中刚需但低频的需求话，可以考虑以下2种方案去提供使用人次：

①集低频场景为高频场景

②低频场景前置或拆分转为高频场景

三、痛点看能耗
开篇已经提到痛点是指“需求被满足过程中，行为路径上的最大阻碍”，而在这条达成任务目标的道路上，我们一般都会付出3样东西“体力、脑力、心力”，这三者的付出加在一起就是我们完成任务的一个整体能耗了。

①体力一般是指用户完成目标付出的实际行动，诸如在app中完成注册操作，要输入手机号、验证码等，做饭时要先洗菜，切菜，炒菜等过程，这些每一步的完成，最后才指向用户最终完成任务的通路。

②脑力一般是指用户对达成目标的思考，思考是要花费能量的，思考的时间越长，花费的能量就越多，所以我们可以通过检测用户完成任务时在一些页面的停留时长的合理性来判断，我们的产品是否给用户造成了困扰，使他确实是感觉不知所云了。

③心力一般是指用户调动和控制情绪的耗费的能力，正向的情绪基本不耗费能量，使人感到轻松，而负面的情绪，则使人感到不适，诸如郁闷、疑惑、焦虑、愤怒等情绪。

所以无论是体力、脑力、心力其实归于本质来说，都是在消耗我们自身的能量，人的一切动作其实都符合最小作用力原则，也即“能不动手就不动手，能不用脑就不用脑，做人最重要的就是开心囖”，这个是人性所致。所以如何解决痛点，其实就是让用户较小的消耗自身能量。

下面再来说说关于三力的消耗如何用数据去进行评估，我们依然以app为例：

①体力的消耗我们一般可以记录用户在app中完成任务的交互步数，跳转的页面个数等，如果想做到更加精细化，甚至可以统计用户点击任务中每个按钮之间的键程长度以及点击的次数等，但是这个取决于公司用研的投入产出比了；

举一个大部分app的通用案例-登录注册：

用户首先进入app之后，跳转到引导页，然后注册页面，输入手机号，获取验证码等等，但是其中用户还会碰到各种问题，比如手机号输错，验证码获取延迟，验证码输入错误，密码设置不符合平台规则，手机号被注册过等等，这些无形都会使得用户完成任务的步数增加，体验下滑。操作步数一般是由于产品设计以及业务本身属性影响的，所以在交互路径优化时，需要注意在用户走到弯路的时候，及时给予提示，或者将问题直接化解，比如有些app在注册时，直接获取手机的本地手机号，这样就避免了手机号输入错误的尴尬了。

一般来讲，用户不会全部都按照我们理想化的行为路径去进行操作，中途会遇到很多用户的跳失。所以大部分情况下会是下面一个情况：

任务达成的用户的平均交互深度>平台设计的最短交互路径深度>流失用户的平均交互深度

这基本是一个恒定的不等式，我们只能努力通过产品的优化，让两端的大于号都无限趋近于等于号，才能达到较好的用户体验。

②脑力的消耗我们通常可以通过完成任务的时长来进行判断，或者更准确的说是用户的业务处理时长，这个要把用户完成操作之后系统的响应时长给排除开。

业务处理时长是因人而异，因事而异的，有些人业务熟练，就能很快达成，有些事较为复杂，就需要花费更多的时间，这种更多被主观因素的影响，所以我们大部分时候看人均时长，看新老用户的人均时长，然后再看时长的整体人群分布比，来评估任务整体完成耗时水平的差异，从而想办法去做进一步的优化。

比如现在市面上的一些app产品进入之后，新手就会看到一层半透明的蒙板层，去引导你怎么去玩转里面的功能，这个其实就是在帮助用户快速上手，不会去满屏幕的找入口，重要的事情说三遍"不要让用户想，不要让用户想，不要让用户想"，让他跟着你设计的洋流漂洋就好。

③心力的消耗目前我们很难有很直接的定量指标，大部分只能通过用户的对每个功能点的定性反馈来评判了，我也很期待未来手机app可以记录用户的表情变化，给脸部的表情进行识别和打分，那么就可以实时同步了情绪变化了，来判断用户是否遇到了困难或者不开心了，进而可以定向的去优化，当然未来技术成熟，可能法律法规依旧是不容许的，所以大部分的时候，这一类检查只能做一对一的焦点小组访谈了，很难做到大数据的采集分析。

但是我们依然可以通过一些常识性的体验，找到评判的方法，比如我们使用app时突然的闪退，打开一个页面时等了10多秒，购买产品付款时提示我余额不足等，这些都会给我们在完成任务时带来糟糕的体验。所以我们可以把这几个大致分为3类：

（1）第一类是错误类，包括网络报错，加载失败，APP端闪退崩溃等；我们可以把的各类错误的影响人数，以及影响次数作为核心指标进行衡量，比如报错的接口名称、操作系统、网络状态等都是常见的下钻维度。

（2）第二类则是时效类，比如加载时长，审核时长，后端的接口返回时长等；我们可以把一些关键页面的平均加载时长，重要接口（被频繁调用）的返回平均时长作为核心指标进行衡量。

（3）第三类则是业务类，比如验证码输入有误、手机号被注册、优惠券不能使用等；我们可以把用户在完成任务中，返回的各类业务提示进行统计分析，来看看通常用户在走到那一步给卡壳了。

最后的结语
产品能不能做起来，取决的因素有很多，战略方向、竞争格局、服务质量、产品体验、运营活动等都会影响产品的成败，希望本文能够帮助各位产品经理大大们建立自己的数据体系，带上度量标尺，更好前行。

最后如果看完后，啥也不记得，请记住这张表，期待大家能做出让用户、公司、自己满意的三赢产品。

作者：囧囧童鞋 来源：囧神产品观（jspvision）