我们继续来讲恐怖故事，这次和大家讲讲，害死产品的另一个凶手，不识目的。
目的与有用
如果说 需求过载是一个隐性的致死因素，那不识目的就是一个显性的致死因素了。
不识目的，顾明思议，不知道做某件事情的目的是什么
要知道，这是我接触的最多的问题之一了，许多时候，我们都不知道为什么要做某件事情，但我们自己却认为自己知道了。
大部分产品经理甚至不知道为什么要做分享功能但却做了。
这似乎很奇怪，分享功能不就是为了让用户分享出去让更多人知道吗？
这只是功能的效果不是分享功能的目的
我们经常容易将结果看作是目的，那是因为结果相对于目的来讲，更容易被我们察觉，毕竟我们已经看了太多结果了，可目的只有我们自己挖掘，没有现成的。
分享的目的毫无疑问是为了增加产品的扩散面积，从而获得更多的曝光以及更多的转化。
可这不代表什么东西都应该加一个分享
分享 需要符合的条件
内容有传播性质，至少要符合炫耀
要有标题，且标题有点击欲望
内容要有质量，有质量才有转化
我常看到部分社交产品，只要是内容就加一个分享功能，毫无目的可言，许多我们可以判定不具备分享价值的内容也做了分享。
从移动端来讲，分享功能很容易，只需要调用相同的功能模块就可以了，然而，但凡是一个分享功能，必然伴随着一个H5产品的开发。
我们再来看一个案例
产品上线1.0 ，我们做了手机号注册，微信注册，QQ注册，微博注册，找回密码，修改密码，退出 登录。
这些功能都是有用的， 但除了增加我们的开发成本，还有什么意义呢？
作为产品经理，在我们眼前放置的一个显而易见的门槛，是否掌握功能真正的意义。是否能正确区分目的与有用
结果是那么的理所当然，目的却显得晦涩难懂
有一些功能，是毫无疑问只有结果，没有目的的功能，典型的便是 自动获取验证码
我在注册某些产品时，留意到一个玩法，用户在点击获取验证码以后，当收到了验证码，客户端会自动捕获用户收到的验证码并填充上去。
多么鸡肋的功能啊。
他有用吗？ 当然有用，第一次接触时，还让我有点小兴奋，我满心期待这是多么人性化的功能，我不用再去看短信了。
然后，就没有然后了，产品本身与这样的小细节相差胜远，这样一个人性化的功能，毫无意义。
他有目的吗？ 要知道，节省了用户操作复杂度，只是这个功能的结果，可他却达不到任何目的。
功能的目的是服务于产品本身的，是要有价值的，不是漫无目的的惊艳想法。
就产品而言，什么样的功能都是有用的，但有意义的功能却显得那么稀有。
比如 能够提高目标用户活性，参与度的功能是有目的的。能够带来新增的功能是有意义的
只是单纯的取悦用户，是一种极为不尊重用户的行为，要知道，取悦不等同于对用户产生了价值。
于是，许多产品就这样死掉了，从始至终，都没有想过为用户创造了什么价值。
甚至，尚不清楚，取悦在真正的价值面前，不堪一击。
坦白说，一流产品大部分体验不好，但却经久不衰。
这便是分不清目的与有用
目的转移
这是另一个 不识目的的表现形式，或者说是后续的坑。
其表现形式如下
我希望用户在产品的停留时间更长，于是我们做了社交板块（类似朋友圈）
社交板块的内容太单一了，想要有趣味一点（增加了音乐图片，表情）
发内容的用户太少了，我们要鼓励用户多发内容（增加了打赏）
用户打赏的钱要能取出来，不然就没意义（增加了提现）
……
是不是很熟悉的节奏，也许你无法定义这是个什么现象，但我相信大部分的产品经理都有这样的经历。
这是典型的目的转移
我们来看看 目的发生了哪些转移
提高停留时间–> 提高内容趣味性–>提高发布内容频率–>提高发布刺激
这是一个很无奈的做法，也是一个大面积的重灾区，甚至说是无解的恶性循环。
从逻辑上来看待这个现象，似乎并没有任何问题，当用户停留时间不足时，我们自然要提高用户停留时间，当用户不发布内容时，我们自然要去提高内容发布频率
似乎没有毛病。
然而，这恰恰是最大的毛病，我们一直在用新的目的来弥补上一个未能达成的目的，陷入了一个恶性循环。
过于追求结果，忘记了对用户产生价值
我们在做产品时，必然会为数据负责，设计一些功能去做数据增量，但这不代表要为了增量而去增量。
不论是迭代多少个版本，最核心的价值观是不能转移的。
这部分核心价值观往往并不在产品经理手里体现，而是由决策层做出的判断。
这也是导致这个现象的最本质原因之一，产品经理并不参与到核心价值观，只是被动的推动数据，于是就有了上述现象：过于追求结果，忘记了对用户产生价值
微信的聊天系统，始终没有做消息已读提示，也没有群动态。
导致目的转移的原因在于，我们错将方法等量翻译成了目的
社交体系不过是解决停留时长的方法之一，而增加语音图片也不过是解决内容可读性的方法之一。
许多功能只是解决方法，而不具备目的性质，真正的目的，仍然在于产品自身对用户的价值。
商业模式里的经典问句，也是我们作为产品经理必须时长反思的问句
这款产品创造了什么价值，服务与谁
建议
与上一篇死亡原因相同，我还是提出几点关于这个问题的解决方法。
也是我经常使用的方法。
唯一最优先目的
给自己或者给自己的产品设置这样一个参数唯一最优先目的
这表示当任何其他目的与其产生碰撞时，果断的舍弃其他选项，保留唯一最优先目的。
对于产品来讲，唯一最优先目的往往等同于产品价值观，也就是产品设计之初想要为用户创造的价值。
微信的唯一最优先目的是聊天通讯， 也正因为如此，朋友圈与生活服务，永远不会在微信里占据过重的位置，微信的布局，也不会再发生改变。
当任何目的与唯一最优先目的发生碰撞时，果断的牺牲其他选项，保留唯一最优先目的。
与微信相反，支付宝便是不断的在动摇，不断的在工具与社交之间来回犹豫，徘徊。
作为旁观者，我们多次强调支付宝安安心心的做工具就好，但当我们成为主角的时候，却也时常范相同的错误。
唯一最优先目的的另一个作用在于帮我们去判断做什么与不做什么
这就好比我们已经确定了一个中心点，而其他的需求都是分布在中心点周围的业务点。
当出现两个都很不错的业务时，借助判断亮点之间的距离，我们能清晰的决定做什么，不做什么
滴滴打车，已经拥有大量用户了，但我们可以清晰的看到滴滴所决定做的事情，一直围绕出行来做，而舍弃了社区或者社交。
当产品聚集大量用户，且形成一定频率时，我们都会第一时间想到社交这条路，原因在于QQ，微信极大的证实了社交的潜在价值。
我们有理由相信目前市面上拥有海量用户的产品，都曾想过或正在思考用社交来给自己做利益加持，然而真正付诸于行动的少之又少。
便是因为在这个过程中，社交似乎与中心点的距离并不算近。
对比选择
没有对比就没有伤害，话糙理不糙，这也是我遵循的另一个方法。
而且，这个方法与唯一最优先目的 配合使用，效果更好。
我们会错将结果看作目的进行判断，恰恰是因为缺少了对比。
前文已经提到过了，任何功能都是有用的，所以我们没有办法单独判断某个功能不好。
当我们单独去看待某个功能时，就会出现这样的结局，怎么想，这都是一个很有用的功能
然而，将两个或多个功能进行对比时，就必然会出现好坏之分。
可能我们会认为这两个功能不一样，没办法对比。
我们没办法判断 手机注册 功能 与 发布文章的功能谁好谁坏。他们完全不同。
如果，我们在增加一个条件，这个方法就成立了。
功能不一样，但我们的时间是相同的
在当前阶段，在最近的一个月以内，手机注册对用户产生的价值，与发布文章产生的价值，谁好谁坏呢
我们的时间是相同的，在不同的阶段，我们需要做不同的事情。
方法： 需求A，需求B，当前有效，选择当前最有效的需求进行开发。
这也是 MVP 方法的一种变型运用，在工作和生活中，实践效果都挺好。
许多需求，在对比判断的方法里，就能体现出优先级了。
