编辑导语：从微信用撤回功能开始，很多平台都有了撤回的功能，这个功能对于很多人来说简直就是福音，可以解决一些手误等发出去的消息；但是我们发现微信的红包没有撤回功能，这是为什么？本文作者分享了关于微信红包为什么不支持撤回的思考，我们一起来了解一下。

前两天在一个群里看到一个小伙伴问大家微信红包为什么不支持撤回，大家踊跃发言；有说红包相当于礼物，哪有送人礼物还要回去的道理，有说这个需求没多大价值，有说资金流可能会出问题的等等。

这都不是我想要的答案，于是我就回复了一个答案；我是这么回复的：

1）红包是什么本质是社交礼物的一种，哪有送人礼物还要收回来的道理，那可能出现的场景就是：

• 发错了想撤回；
• 不想发了，想撤回。

看起来是大众的需求，毕竟每个人都可能犯错，但是低频、非刚需。

2）价值是什么

• 对用户：解决了部分人在部分场景下的小问题；
• 对产品：满足了这部分用户的需求；
• 对平台：没啥大的价值。

3）成本是什么

• 对用户：可能有人利用这个规则去恶意退回红包，影响到其他人的体验，甚至有人利用这个机制产生诈骗行为；
• 对产品：不光需要考虑撤回的成本，还需要考虑已经发出去的钱、扣出去的手续费，额外的功能处理等等；
• 对平台：技术成本、运营成本、客服成本等等，还有一堆问题在路上了。

综合来看就是，用户有一定的需求，但整体实现的成本远大于价值，不做也不会有什么大的问题。

转账也有类似的问题，更好的方式应该是事前增加防错手段，事后通过异常流程来个例解决，而不是为了照顾1%的人，可能牺牲掉99%的人。

我的答案就正确么，未必，可能真不是这些原因，只是我在这里瞎扯，我想和大家讨论的是一种思考的方法。

当你面临一些产品决策的时候，你做决策的依据是什么，比如判断这个功能到底要不要做，比如分析XX功能为什么要这么做，以及分析XX功能为什么不这么做？

你是如何思考和判断的，你的思考过程和决策依据是什么？这些才是重要的，答案本身并不重要。

下面就来聊聊我当时是怎么思考这个问题的，主要分为两部分，一部分是如何评估的方法，一部分是为什么要进行这种看起来很费劲的评估。

一、如何评估需求要不要做

再怎么强调这块也不为过，我理解的产品流程是先做正确的事情，再正确的做事情。

具体来说就是先判断要不要做，然后评估能不能做，最后才是如何做，以及如何做好，而不是上来就是我们要做XXX，一二三XXX，balabala。

如何评估可以通过这几方面展开：

• 需求、价值、成本；
• 综合考虑产品定位、时机。

需求成立，价值大于成本的时候，可以考虑做，然后再结合着产品定位、时机来综合判断要不要做，下面来分别看下。

1. 需求、价值、成本

主要考虑的其实就是这三方面，需求本身、做这件事的价值，实现的成本。

1）需求

产品的原点是用户和需求，是我们要给用户解决什么问题，而不是一拍脑袋，我们有什么资源，我们做了个什么什么，你们来用吧。

具体来看就是：

用户、场景、需求：即我们究竟要解决什么人，在什么场景下的什么问题。

这几个问题想的越真实，越清楚，成功的概率越高。

大众、高频、刚需：会影响到多少人，本身的频次是怎样的，是不是刚需？

这些东西决定了产品解决问题的影响范围，以及产品的价值。满足2个条件就有机会，满足1个条件也还行，1个都不占，那真的要好好思考思考了。

需求过程与一致性：我们即将要解决的问题，在需求满足的过程中么，与产品的核心价值是否一致呢？

产品最核心的价值就在用户问题被解决的路径上，那我们目前想解决的这个问题在不在这个主路径上。

比如作为一个打车平台，我们要不要做小游戏，让用户在车上无聊的时候玩玩游戏，用户的核心路径是打车，那要不要做？

需求存在，才有聊后面事情的可能性，不然也没必要聊，下一步是价值与成本的评估。

2）价值与成本

价值就是做这个事情我们的预期收益，成本就是为了做这件事我们需要付出什么。

价值

价值可能会有很多种，我重点思考的维度是这么几个，用户价值、产品价值、业务价值、竞争价值。

用户价值很好理解，就是做这个事情对用户有什么价值，可以进行前后的对比。

比如解决之前，用户都是怎么做的，解决之后的表现怎样，有没有效率更高，有没有解决的更好？比如上文打车案例中，没做小游戏之前，用户在车上的时间是怎么渡过的，小游戏和这种方案相比，效率如何？

产品价值就是这件事对产品有什么价值，对产品的核心价值有什么影响，能反应在什么数据指标上？

比如上文提到的打车，做了小游戏对产品的核心价值，也就是打车有什么价值？会带来什么数据指标的提升？

业务价值就是对其他业务的一些影响，对整体业务目标和商业目标会有什么影响。

比如新用户免广告，大概率能提升用户的留存，但会影响广告收入，那要不要做?

竞争价值就是从竞争的角度来看，会有什么影响，能不能强化我们的竞争优势？毕竟我们是在一个市场中，除了我们，还有其他玩家。

综合这几个维度来看，对于要不要做一个事情，我们会有一些基本的判断，然后再来看成本。

3）成本

其实成本有很多很多，我们通常可能只看到价值，忽略了很多的成本。

比如产品说我们做个相册功能吧，用户能上传图片，能装扮自己的主页，其他人也能看到，还能促进一些社交，挺好。

做个图片上传就完了么？当然不是，还有很多事情要做，比如怎么引导用户去上传？上传了的图要不要审核？审核出了问题的图要怎么处理？一直上传违规图的账号怎么处理？用户更换失败后投诉怎么处理？一些时期不支持换图怎么处理？等等…

这些都是潜在的成本，都是需要考虑进去的，而不是只看到了价值，丝毫不考虑成本。

具体来看有这么几类潜在成本：

用户成本：对用户自己有什么影响，对其他用户，其他角色有什么影响？

产品成本：对产品的核心功能，对其他业务会不会有什么负面的影响？

竞争成本：对竞争来说会有什么影响，会不会刚培育好市场，然后就被别人一锅端走了？

还有刚刚聊到的那些技术成本、运营成本、推广成本、风险等等，这些都是需要考虑的。

只有当我们判断这个事情的价值大于成本，至少说将来价值会大于成本，这个事才是可进一步探讨的。

需求成立，价值大于成本，可以考虑做，但也并不是满足这些条件，就一定会做，还需要考虑产品定位、时机这些要素。

2. 综合考虑产品定位、时机

千团大战的时候，很多团购公司都开始卖货，卖各种商品，化妆品、服装、红酒等，而且商品团购卖的更好，看上去需求成立，价值也大于成本，要不要做？

现在我们看到了结果，千团大战到现在只剩下美团、点评，而且已经合并了。

美团外卖联合创始人沈鹏在一次访谈中这样说过这个事情：

王兴在美团成立一年左右的时候，就在内部讲明白了一个定位——美团要做本地生活服务电商的霸主，而不是商品团购。商品团购再好，也不是美团的主要业务。

这是当时美团做出决策的依据，也是美团获胜诸多因素中的一个关键因素。

产品定位决定了产品是什么，也决定了产品不是什么，这是我们决策的重要依据。

即使符合产品定位，还需要考虑时机，是不是当前阶段最重要的事情，是不是当前阶段最有价值的事情。

在《幕后产品》中师母分享了一个网易云音乐的案例，要不要做专辑收藏这个功能，最开始的时候是没做，之后重新考虑的时候，又做了这个功能，这就是基于产品阶段和时机的考虑。

综上来看，用户需求成立，价值大于成本，决定了这个事可以考虑做还是不做，然后再结合着产品定位，当前的阶段目标来判断要不要做。

二、为什么要评估？

有的人可能觉得这么评估好麻烦啊，确实有些，但也不用什么东西都这么评估，在一些重大功能的决策上多考虑就好。

这个背后的逻辑其实是我们的时间、精力、资源都有限，做了A就做不了B了，我们要做的就是做价值最大的事情，到底是捡了芝麻丢了西瓜，还是捡了西瓜丢了芝麻，主要看判断能力。

很多需求可能本身就不值得做，比如一个版本做了20个需求，有多少是真正有价值的？

有很多需求本身就是伪需求，特别是当需求发起者不是用户的时候，伪需求本身就脱离了场景和用户，不会创造什么价值。

有的需求可能是存在的，但解决了就有价值么？有没有遇到过一些不痛不痒，可做可不做的需求？

有的需求可能是有价值的，但可能价值小，成本高，导致整体的ROI（投入产出比）是负的，这种需求其实很多，需要我们谨慎考虑。

即使在ROI（投入产出比）为正的需求里，时间资源都有限，哪个最重要？先做哪个，后做哪个？

经过这么层层的筛选，其实值得做的需求并没有多少，而且很坑的是只有捡了之后，你才能分辨它是芝麻还是西瓜，我想做的就是锻炼先行辨别出是芝麻还是西瓜的能力，然后捡西瓜丢芝麻。

俞军老师在PM12条里有这么一条：

决定不做什么，往往比决定做什么更重要。

这是产品经理非常重要的能力之一，共勉。

最后简单的总结下全文：

• 大前提：需求成立，价值大于成本；
  • 需求：用户场景需求、大众高频刚需否、需求全过程与一致性；
  • 价值：用户价值、产品价值、业务价值、竞争价值；
  • 成本：用户成本、产品成本、竞争成本、技术成本、运营成本、推广成本、风险、机会成本等；
• 小前提：符合产品定位，适合当前阶段。

同时满足大前提和小前提，就符合要不要做的条件了，至于能不能做，如何做，如何做好，后续会分别再写对应的文章。

本来打算写一下朋友圈的案例，但文章太长了，就没写，当做互动思考吧，欢迎留言一起讨论。

Q&A：朋友圈是微信很重要，也大众、高频的一个功能，为什么不把朋友圈放在底Tab？

以上，就是本文的主要内容，欢迎斧正、指点、拍砖…

#专栏作家#

王家郴 ，公众号：产品经理从0到1，人人都是产品经理专栏作家，喜欢网球和骑行的产品汪，目前奔走在产品的道路上，漫漫产品路，与君共勉。

本文原创发布于人人都是产品经理。未经许可，禁止转载

题图来自 unsplash，基于 CC0 协议