产品死亡原因之「不识目的」

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

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

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

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

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

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

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

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

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

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

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

建议：

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

唯一最优先目的：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

对比选择：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

关于作者

枯叶，近 6 年经验的产品经理。擅长社交，社区，细分群体挖掘。微信公众号：枯叶咖啡馆。

相关阅读：《产品死亡原因之「负担过载」》

（编辑：源码网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!