骑手提前确认收货，初级产品经理要怎么处理这类复杂问题

简明产品论 2023-07-24 06:45:54

01

“如果你是外卖平台的产品经理，你要怎么解决骑手提前确认收货的问题？”

几天前，我在网上看见有人在问这样一个问题。

“如果你是某某产品经理，你要怎么解决某某问题”，这样的问题，感觉经常可以碰见。

“产品经理”相关的讨论，大概有1/3是这样的问题。

作为一名初级产品经理，我每次看到这种问题，都会觉得有些不知所措。

就拿“骑手提前确认收货”这个问题来说。

首先，骑手能够“不守规矩”，说明业务设计上有漏洞，产品存在“错误”。

然后，已经有不少用户碰到这种情况，并感到相当程度的不满，说明已经影响到“用户体验”了。

那么，作为“产品”的经理，自然应该为产品负责，应该去纠正错误、优化体验。

真是这样吗？

其实不然。

这并不是一个可以简单解决的问题，它涉及到很多角色。

在这个问题的语境下，提问者想象了一个非常“强势”的产品经理形象：有较大的决策权，能够站在一个较高的视角，统筹全局，设计规划产品策略，能够指挥动员各部门进行配合，是一个“中央决策者”的角色。

同时，回答这类问题的，很多都是产品大佬。

所以，就更强化了这么一种错觉，以为“产品经理”就是这么一种“指点江山”的角色。

然而，现实中，能够做到这种程度的产品大佬，其实只是少数。

对于大多数产品人来说，情况完全不是这样。

其实从一些公司的组织架构上，我们也能看出一点端倪。

比如说，产品岗，算上实习生也只有两三人。

比如说，没有独立的“产品部”，而是并到运营部、设计部或技术部里面。

比如说，部门内没有“总监”级别的领导，或者，虽然有，但不是“产品”总监。

我觉得，更常见的情况是，产品经理在公司内部是一种相对“弱势”的存在。

初级产品经理，则更是如此。

我们向产品大佬学习，“高瞻远瞩”地去讨论怎么“解决”这类复杂问题，固然是有意义的。

考虑到实际情况，从初级产品经理的角度，更加“务实”地，去讨论怎么“处理”这些问题，我想，可能也是有些价值的。

所以，今天，我想以“骑手提前确认收货”为例，结合自己的一些经验，谈一谈“初级产品经理要怎么处理这类复杂问题”。

02

我们先来简单分析一下，为什么说它是一个“复杂”的问题。

首先，我们来看看“确认收货”这一业务本身。

“确认收货”，这个概念很简单，大家都清楚，我就不赘述了。

因为我们要去优化这个业务，所以在“动刀”之前，我们得先想想有没有其他的可能。

首当其冲的问题是，可以不要“确认收货”吗？

严格来说，可以。

外卖从店里发出后，将“已发出”作为订单的完成状态，也不是完全不可以。

但是，一般不建议这么做。

抛开具体的业务因素，主要有2个原因。

1.在边际成本可控的前提下，我们应该尽量提高数据的准确度。

多加一个状态，花不了多大成本。而更准确的数据记录，后续能挖掘出的业务价值，将会不成比例地增加。

2.已经做好的功能，如果不是出现严重问题，或者是大改版，一般不建议拿掉。

根据我的经验，那些一直没什么用的功能，一旦你拿掉了，非常诡异的，马上就会有人要用到，然后来找你麻烦。如无必要，勿瞎折腾。

不能拿掉“确认收货”，也不意味着，这个“确认收货”的动作，一定要由“骑手”来触发。

订单涉及到的角色，简单来说，有“用户”、“骑手”、“商家”、“平台”4个。

如果进行排列组合，可以有很多种情况。这里就不一一列举了。

除了“骑手来确认收货”外，还有以下3种看起来比较可行的方案。

用户来确认收货：

让用户来确认收货，也就没有骑手什么事情了。

乍看之下，好像能完美解决这个问题。

但是，其实不可行。

用户不愿意去操作“收货”，还在其次。

更重要的是，外卖有“超时赔付”服务。让用户自己“决定”收货时间，会有道德风险。

平台来确认收货：

比如说，根据手机定位等因素，来自动“确认收货”。

这种准确度很低，基本不可行。

骑手、用户和平台，共同完成“确认收货”操作：

其实也就是，由骑手来完成“确认收货”操作，然后引入其他角色对其进行监督。

比如说，要用户也确认，才有效。

比如说，平台进行定位监控，需要在收货地附近的操作，才有效。

这是一种比较可行的折中方案。

其实吧，完全由骑手“独断”的情况，并不存在。现实中，外卖平台，就是采用这种方案的。

具体策略可以有很多种，但是不管采用哪种方案，总体上都存在一个问题：提高监督力度，就会相应地提高成本、降低效率。

比如说，我们可以要求骑手确认收货时，提交一张自拍照。

那么，我们设想一下“办公楼中午配送高峰期”的场景。

可能骑手自拍的那么一瞬间，后面的电梯就关上了，下一趟就是十几分钟之后的事情了。

中午的配送高峰期，经得起几个“十几分钟”？

骑手的配送效率，会因此受到非常大的影响。

这就是为什么说它是一个“复杂”问题的原因了。

这里面有很多个维度，用户的体验，用户的收货习惯，骑手的配送效率，骑手的收入，骑手的体验，平台的监管成本，平台的收入，平台的商誉，等等。

一旦我们动了其中一环，不可避免地会影响到其它维度，很难做到“帕累托改进”。

因此，它不存在一个简单的终极解决方案，而是一个各方进行博弈、互相妥协的平衡。

03

接下来，我们来看看，在公司内部，这样的问题具体是按什么流程来解决的。

当然，不同公司情况不同，具体细节会有差异。这里我们抓大放小，暂时忽略这些细节差异。

首先，这个问题是谁先挖掘出来的？

虽然我们要求产品经理要懂用户，要关注用户，但是，公司里面并不是只有产品经理在关注用户。

大概率上，这个问题会由以下部门发现并提出来。

客服部：

用户有不满，就会投诉。客服接到这类投诉多了，问题的严重性就会凸显出来。达到一定程度，这个问题就会被提出来。

运营部：

一般会有运营同事在持续监控网上各平台内关于自己公司的讨论。用户不满的讨论多了，有恶化的苗头时，这个问题就得在公司内部提出来。

问题确立之后，一般是怎么提出来讨论呢？

大致上，有2种情况。

1.在日常性的比较高规格的公司例会上，由发现问题的部门提出来。

这类日常性会议，可能一周召开一次。与会的有各部门领导和核心成员，还有老板。

一般来说，初级产品经理没有资格参加。就算参加了，也只有听的份。

2.发现问题的部门将问题反馈给领导后，将需求立项，组织相关部门进行协商讨论。

这种情况，有时候需要产品经理与会，甚至需要由产品经理来组织。

但是，初级产品经理更多的是一个“组织者”、“执行者”的角色，不是“决策者”。

那么，讨论之后，问题具体要怎么解决呢？

1.有的时候，问题并不需要解决。

比如说，虽然表面上看起来“群情激奋”，但其实只是少数人的不满。大多数用户可能并不在乎这个问题。他们只是“沉默”，没有发声而已。

而为这少数人进行优化，可能成本上不划算。

所以，不进行处理，保持这个平衡就行了。

2.有时候，问题需要处理，但是没有产品经理什么事。

解决问题，不是只有“技术”一种方式，还可以通过“管理”。

比如说，质检部门，或是其他类似部门，定期随机地电话回访用户，排查这种“提前确认收货”的情况，然后对有问题的骑手进行处罚公示。

这样，付出较低的成本，就能很好地改善这个情况。

3.有时候，需要一整套解决方案，而产品经理只是负责其中一部分。

比如说，因为配送效率是“红线”，不能对“骑手侧”动手。那么，我们可以对“用户侧”进行管理。

它可以是一套涉及多部门的解决方案：

客服部，设计一套安抚用户情绪的话术，并在难以安抚的时候，按规定给用户发放优惠券。
运营部，监控网上的负面声音，对于情绪强烈的，主动联系安抚。
产品经理，在APP内设计体现骑手困难的内容，以争取用户的理解。在骑手确认收货后，把“投诉反馈”的入口放在突出的位置，确保用户在情绪升级之前，能被引导到客服那里，由客服来解决。
……