做产品有很多指导方法论，从很多角度解读了如何做一个更好的产品。但是，理论和实践总是隔着一定的距离，将理论落地需要有一套详尽的方法论。笔者针对这个问题构建了一套评估指标，帮助大家更好落地。
对于我们做产品的人来说，最痛苦的点，可能就是产品做出来之后，被客户喷“使用繁琐，体验太差”，被老板DISS“你的产品切不到痛点”。
诚然，一个产品好不好，不能凭产品经理的个人喜好，也不能由于极个别的用户反馈，而对产品当前的状况进行全盘否定。
我们从产品入行的时候，就被行内大咖教育，做产品要做“刚需、高频、痛点”。但是却从没有人去告诉我们，如何通过观测数据去验证我们做的东西是否是满足这三个核心要点。
本文旨在帮助产品经理们建立较为完善的数据指标评估体系，更好地帮助产品功能的优化和迭代。
首先，请容许我按照自己的理解，重新对“刚需、高频、痛点”做些定义：
刚需是相对于“弹性需求”而言的，从字面意思就可以理解为是硬性，人们需要的东西或者必须要做的事；
高频是指需求欲望在一定周期内产生的频次；
痛点则是指用户在满足自己需求的过程中，遇到的最大障碍。
那么评估指标怎么定？
主要就是下面这一句话：刚需看渗透、高频看人次、痛点看能耗。
一、刚需看渗透
渗透率原本是市场营销中的一个概念，指企业的实际销售量在市场潜量中的百分率。但是，我们可以将使用范围进行衍生，大到行业覆盖度，小到产品中的某个功能特性。
比如，互联网渗透率是指使用互联网的网民与总人口数之比，用于表达互联网渗透到普通民众生活的程度。
而对于某个APP产品来说，我们提出一个新的概念叫做“功能渗透率”，是指当前使用该功能的人数占整体使用产品的人数比例。这个指标可以较为客观地反应出当前功能对于使用产品的人群的覆盖度，功能渗透率越高，则说明该功能是当前用户使用产品的核心功能，即当前产品形态下的大部分用户刚需。
以一款教育APP为例，这个产品中主要包括看资讯、听课程、做题库等产品特性，相关的产品功能渗透率如下：
从数据中我们就不难发现：10个人来使用该产品，7个人看资讯，2个人听课程，1个人做题库——看资讯这个功能点能覆盖到大部分的用户。
而对于一款教育产品来讲，其最终目标是帮助用户拿证过题考试的，所以这个数据结果乍一看是反常识的。我们大部分人会认为结构化的课程才应该是用户最需要的内容及功能，有些颠覆我们的认知。
然而，是什么原因导致的，我们就需要进一步做些反思了。有可能是功能刚上线，知悉的用户数量不多；也有可能是上线运营乏力，还有可能是内容不够给力；又或者是产品交互体验不行，技术老是出BUG等，这些都需要进行具体的下钻分析。
同时我们还需要注意以下几点：
渗透率的数据，可以帮助你验证需求解决方案是否被大多数用户所认可，而不能判定渗透高的就是刚需，渗透低的就是普通需求。刚需与否还是需要通过产品经理对业务的洞察去判断，渗透率更多的是作为“后验性”指标而存在。
刚需是根据用户完成的业务目标所达成的任务而定的，离终点越近的越是刚需，我们可以根据用户的需求层次画一个同心圆，从里到外由强变弱。
还是以教育类APP为例，可以得到以下的图解：
总之。如果数据展示出来，发现理想和现实中有落差，那我们就要不断找原因，不断调优，持续逼近理想的最优解。
二、高频看人次
人次是指用户在一定时间、一定范围内重复出现的行为次数。
普通人可能一辈子就买一次房，十年去换一部车，他们在人生的尺度上其实是个低频的。但是，在你要买车的前三个月的时候，你选车的需求被激发，每天看各类购车资讯的行为又变成了短时间的高频需求了。
所以，它是一个相对的概念，我们不能脱离场景去说这个。
我们来看一个支付宝的经典案例：
2003年的时候，支付宝仅仅只是淘宝的一个子功能，作为网上交易的信用担保工具；
2004年末，支付宝开始逐步从淘宝体系中分拆，成为了一个的独立的第三方网络支付平台；
2008年，支付宝发布移动电子商务战略，从PC端业务开始往移动端迁移，推出手机支付业务；同年公共事业缴费正式上线，支持水、电、煤、通讯等缴费。
时至今日，支付宝已经不断扩宽它的使用场景，支付宝及其本地钱包合作伙伴已经服务超12亿的全球用户，俨然成为我们手机里面的超级工具APP。就算我们不是每天都去淘宝网购物，生活中的线下支付每天也必然会使用1次或多次支付宝，可能是点外卖，可能是便利店的结算，又或者是公交车刷码。
支付宝的发展史就是低频工具型APP最好的逆袭，不断渗透到各个可以使用支付的场景中。网上购物也许是个低频的场景，但是线上线下的各类交易中的支付就是一个高频的场景；每天，全世界各地都在发生着各种交易，小到在学校门口买2元钱的汽水，大到购买万元的笔记本电脑。
这些一旦全部聚集在一个平台上进行操作，那将是一个非常海量的数字。
那么关于人次的指标一般都有哪些呢？
以刚才的那款教育APP为例：
需要注意的是，不同功能在相同的时间区间里面，它们的频次是不一样。同样一个功能在不同的时间区间里面，按天看、按周看、按月度看，频次也都是不一样的。
这款APP主要提供看资讯、听课程、做题库等产品特性，相关数据如下：
所以，我们从上面数据中会发现，资讯是个高频的功能点，而课程和题库是低频的。同时，还会发现一个有意思的趋势：一般而言，越是高频的功能点，随着时间跨度变大，它的人均频次的增幅越快；越是低频的功能点，它的人均频次的增幅越慢，当然也有一些特例。
所以，如果希望提高课程和题库的人次的话，可以考虑把冗长的课程，拆分成一个个小的知识点-短视频进行播放，把动则百八十道题目的题库，拆解成每日一题的低门槛任务。
总之，如果你的产品切中刚需但低频的话，可以考虑以下2种方案去提高使用人次：
集低频场景为高频场景；
低频场景前置或拆分转为高频场景。
三、痛点看能耗（步数和时长）
开篇已经提到，痛点是指“需求被满足过程中，行为路径上的最大阻碍”。而在这条达成任务目标的道路上，我们一般都会付出3样东西“体力”，“脑力”，“心力”，这三者的付出加在一起就是我们完成任务的一个整体能耗了。
体力指用户完成目标付出的实际行动，诸如在APP中完成注册操作，要输入手机号、验证码等，做饭时要先洗菜，切菜，炒菜等过程，，这些每一步的完成，最后才指向用户最终完成任务的通路。
脑力指用户对达成目标的思考，思考是要花费能量的，思考的时间越长，花费的能量就越多。所以，我们可以通过检测用户完成任务时在一些页面的停留时长来判断，我们的产品是否给用户造成了困扰。
心力指用户调动和控制情绪所耗费的能力，正向的情绪基本不耗费能量，使人感到轻松；而负面的情绪，则使人感到不适，诸如郁闷、疑惑、焦虑、愤怒等情绪。
所以，无论是体力、脑力、心力，归于本质来说，都是在消耗我们自身的能量。人的一切动作其实都符合最小作用力原则，也即“能不动手就不动手，能不用脑就不用脑，做人最重要的就是开心囖”，这个是人性所致。
所以，如何解决痛点，其实就是让用户消耗较少的自身能量。
下面再来说说如何用数据去评估三力的消耗，依然以APP为例：
1. 体力的消耗
我们一般可以记录用户在APP中完成任务的交互步数，跳转的页面个数等。
如果想做到更加精细化，甚至可以统计用户点击任务中每个按钮之间的键程长度以及点击的次数等，这个取决于公司用研的投入产出比。
举一个大部分APP的通用案例-登录注册：
用户进入APP之后，跳转到引导页，然后注册页面，输入手机号，获取验证码等等。其中，用户还会碰到各种问题，比如手机号输错，验证码获取延迟，验证码输入错误，密码设置不符合平台规则，手机号被注册过等，无形中会增加用户完成任务的步数，体验下滑。
操作步数一般受产品设计以及业务本身属性影响，所以在交互路径优化时，需要在用户走弯路时及时给予提示，或者将问题直接化解。比如在注册某些APP时，直接获取手机的本地手机号，这样就避免了手机号输入错误的尴尬。
一般来讲，用户不会全部按照我们的理想化行为路径去进行操作，中途会遇到很多用户的跳失。
所以，大部分情况会是像下面这样：
任务达成的用户的平均交互深度>平台设计的最短交互路径深度>流失用户的平均交互深度
这基本是一个恒定的不等式，我们只能努力通过产品的优化，让两端的“>”都无限趋近于“=”，才能达到较好的用户体验。
2. 脑力的消耗
通常可以通过完成任务的时长来进行判断,更准确的说是用户的业务处理时长，这个要把用户完成操作之后系统的响应时长给排除。
业务处理时长因人而异、因事而异，有些人业务熟练，就能很快达成；有些事较为复杂，就需要花费更多的时间。这更多被主观因素影响。
所以，我们大部分时候看人均时长，看新老用户的人均时长，然后再看时长的整体人群分布比，来评估任务整体完成耗时水平的差异，从而做进一步的优化。
比如进入一些APP产品之后，新手会看到一层半透明的蒙板层，去引导你怎么去玩转里面的功能，这个就是在帮助用户快速上手，不会满屏幕找入口。
重要的事情说三遍，让他跟着你设计的洋流漂洋就好。
3. 心力的消耗
目前我们很难有直接的定量指标，大部分只能通过用户对每个功能点的定性反馈来评判；我也很期待未来手机APP可以记录用户的表情变化，对脸部表情进行识别和打分。实时同步情绪变化，来判断用户是否遇到了困难或者不开心，进而可以进行定向优化。
当然，未来技术成熟，可能法律法规依旧是不容许的。所以，大部分时候，这类检查只能做一对一的焦点小组访谈了，很难进行大数据的采集分析。
但是，我们依然可以通过一些常识性的体验，找到评判的方法。比如我们使用APP时闪退，打开一个页面时等了10多秒，购买产品付款时提示我余额不足等，这些都会给我们在完成任务时带来糟糕的体验。
我们可以把这几个大致分为3类：
错误类：包括网络报错，加载失败，APP端闪退崩溃等；我们可以把的各类错误的影响人数，以及影响次数作为核心指标进行衡量，比如报错的接口名称、操作系统、网络状态等都是常见的下钻维度。
时效类：比如加载时长，审核时长，后端的接口返回时长等；我们可以把一些关键页面的平均加载时长，重要接口（被频繁调用）的返回平均时长作为核心指标进行衡量。
业务类：比如验证码输入有误、手机号被注册、优惠券不能使用等；我们可以把用户在完成任务时，统计返回的各类业务提示进行分析，来看看通常用户在走到那一步给卡壳了。
总结
产品能不能做起来，取决的因素有很多，战略方向、竞争格局、服务质量、产品体验、运营活动等都会影响产品的成败。
希望本文能够帮助各位产品经理建立自己的数据体系，带上度量标尺，更好前行。
