产品死亡原因之不识目的

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