目的与有用

如果说需求过载是一个隐性的致死因素，那不识目的就是一个显性的致死因素了。

不识目的，顾明思议，不知道做某件事情的目的是什么。

要知道，这是我接触的最多的问题之一了，许多时候，我们都不知道为什么要做某件事情，但我们自己却认为自己知道了。大部分产品经理甚至不知道为什么要做分享功能 但却做了。

这似乎很奇怪，分享功能不就是为了让用户分享出去让更多人知道吗？

这只是功能的效果不是分享功能的目的。

我们经常容易将结果看作是目的，那是因为结果相对于目的来讲，更容易被我们察觉，毕竟我们已经看了太多结果了，可目的只有我们自己挖掘，没有现成的。

分享的目的毫无疑问是为了增加产品的扩散面积，从而获得更多的曝光以及更多的转化。可这不代表什么东西都应该加一个分享。

分享需要符合的条件：

• 内容有传播性质，至少要符合炫耀

• 要有标题，且标题有点击欲望

• 内容要有质量，有质量才有转化

我常看到部分社交产品，只要是内容就加一个分享功能，毫无目的可言，许多我们可以判定不具备分享价值的内容也做了分享。

从移动端来讲，分享功能很容易，只需要调用相同的功能模块就可以了，然而，但凡是一个分享功能，必然伴随着一个H5产品的开发。

我们再来看一个案例：

产品上线1.0 我们做了手机号注册，微信注册，QQ注册，微博注册，找回密码，修改密码，退出，登录。

这些功能都是有用的， 但除了增加我们的开发成本，还有什么意义呢？

作为产品经理，在我们眼前放置的一个显而易见的门槛，是否掌握功能真正的意义，是否能正确区分目的与有用。

结果是那么的理所当然，目的却显得晦涩难懂。

有一些功能，是毫无疑问只有结果，没有目的的功能，典型的便是自动获取验证码

我在注册某些产品时，留意到一个玩法，用户在点击获取验证码以后，当收到了验证码，客户端会自动捕获用户收到的验证码并填充上去。

多么鸡肋的功能啊。他有用吗？ 当然有用，第一次接触时，还让我有点小兴奋，我满心期待这是多么人性化的功能，我不用再去看短信了。

然后，就没有然后了，产品本身与这样的小细节相差胜远，这样一个人性化的功能，毫无意义。

他有目的吗？ 要知道，节省了用户操作复杂度，只是这个功能的结果，可他却达不到任何目的。

功能的目的是服务于产品本身的，是要有价值的，不是漫无目的的惊艳想法。

就产品而言，什么样的功能都是有用的，但有意义的功能却显得那么稀有。

比如能够提高目标用户活性，参与度的功能是有目的的。能够带来新增的功能是有意义的。

只是单纯的取悦用户，是一种极为不尊重用户的行为，要知道，取悦不等同于对用户产生了价值。

于是，许多产品就这样死掉了，从始至终，都没有想过为用户创造了什么价值。

甚至，尚不清楚，取悦在真正的价值面前，不堪一击。

坦白说，一流产品大部分体验不好，但却经久不衰。

这便是分不清目的与有用。

目的转移这是另一个不识目的的表现形式，或者说是后续的坑。

其表现形式如下

• 我希望用户在产品的停留时间更长，于是我们做了社交板块（类似朋友圈）

• 社交板块的内容太单一了，想要有趣味一点（增加了音乐图片，表情）

• 发内容的用户太少了，我们要鼓励用户多发内容（增加了打赏）

• 用户打赏的钱要能取出来，不然就没意义（增加了提现）

• ……

是不是很熟悉的节奏，也许你无法定义这是个什么现象，但我相信大部分的产品经理都有这样的经历。

这是典型的目的转移。

我们来看看目的发生了哪些转移：

提高停留时间–> 提高内容趣味性–>提高发布内容频率–>提高发布刺激

这是一个很无奈的做法，也是一个大面积的重灾区，甚至说是无解的恶性循环。

从逻辑上来看待这个现象，似乎并没有任何问题，当用户停留时间不足时，我们自然要提高用户停留时间，当用户不发布内容时，我们自然要去提高内容发布频率

似乎没有毛病。

然而，这恰恰是最大的毛病，我们一直在用新的目的来弥补上一个未能达成的目的，陷入了一个恶性循环。

过于追求结果，忘记了对用户产生价值。

我们在做产品时，必然会为数据负责，设计一些功能去做数据增量，但这不代表要为了增量而去增量。

不论是迭代多少个版本，最核心的价值观是不能转移的。

这部分核心价值观往往并不在产品经理手里体现，而是由决策层做出的判断。

这也是导致这个现象的最本质原因之一，产品经理并不参与到核心价值观，只是被动的推动数据，于是就有了上述现象：过于追求结果，忘记了对用户产生价值。

微信的聊天系统，始终没有做消息已读提示，也没有群动态。

导致目的转移的原因在于，我们错将方法等量翻译成了目的。

社交体系不过是解决停留时长的方法之一，而增加语音图片也不过是解决内容可读性的方法之一。

许多功能只是解决方法，而不具备目的性质，真正的目的，仍然在于产品自身对用户的价值。

商业模式里的经典问句，也是我们作为产品经理必须时长反思的问句：

这款产品创造了什么价值，服务于谁。

建议：

与上一篇死亡原因相同，我还是提出几点关于这个问题的解决方法。

唯一最优先目的：

给自己或者给自己的产品设置这样一个参数唯一最优先目的。

这表示当任何其他目的与其产生碰撞时，果断的舍弃其他选项，保留唯一最优先目的。

对于产品来讲，唯一最优先目的往往等同于产品价值观，也就是产品设计之初想要为用户创造的价值。

微信的唯一最优先目的是聊天通讯， 也正因为如此，朋友圈与生活服务，永远不会在微信里占据过重的位置，微信的布局，也不会再发生改变。

当任何目的与唯一最优先目的发生碰撞时，果断的牺牲其他选项，保留唯一最优先目的。

与微信相反，支付宝便是不断的在动摇，不断的在工具与社交之间来回犹豫，徘徊。

作为旁观者，我们多次强调支付宝安安心心的做工具就好，但当我们成为主角的时候，却也时常范相同的错误。

唯一最优先目的的另一个作用在于帮我们去判断做什么与不做什么。

这就好比我们已经确定了一个中心点，而其他的需求都是分布在中心点周围的业务点。

当出现两个都很不错的业务时，借助判断亮点之间的距离，我们能清晰的决定做什么，不做什么

滴滴打车，已经拥有大量用户了，但我们可以清晰的看到滴滴所决定做的事情，一直围绕出行来做，而舍弃了社区或者社交

当产品聚集大量用户，且形成一定频率时，我们都会第一时间想到社交这条路，原因在于QQ，微信极大的证实了社交的潜在价值。

我们有理由相信目前市面上拥有海量用户的产品，都曾想过或正在思考用社交来给自己做利益加持，然而真正付诸于行动的少之又少。

便是因为在这个过程中，社交似乎与中心点的距离并不算近。

对比选择：

没有对比就没有伤害，话糙理不糙，这也是我遵循的另一个方法。

而且，这个方法与唯一最优先目的 配合使用，效果更好。

我们会错将结果看作目的进行判断，恰恰是因为缺少了对比。

前文已经提到过了，任何功能都是有用的，所以我们没有办法单独判断某个功能不好。

当我们单独去看待某个功能时，就会出现这样的结局，怎么想，这都是一个很有用的功能

然而，将两个或多个功能进行对比时，就必然会出现好坏之分。

可能我们会认为这两个功能不一样，没办法对比。

我们没办法判断 手机注册 功能 与 发布文章的功能谁好谁坏。他们完全不同。

如果，我们在增加一个条件，这个方法就成立了。

功能不一样，但我们的时间是相同的

在当前阶段，在最近的一个月以内，手机注册对用户产生的价值，与发布文章产生的价值，谁好谁坏呢

我们的时间是相同的，在不同的阶段，我们需要做不同的事情。

方法： 需求A，需求B，当前有效，选择当前最有效的需求进行开发。

这也是 MVP 方法的一种变型运用，在工作和生活中，实践效果都挺好。

许多需求，在对比判断的方法里，就能体现出优先级了。