本篇文章来源于我产品工作中的思考，可能和你在别处看到的不太一样，希望你能赏脸一读！今天聊聊如果你是外卖平台的产品经理，骑手提前确认收货，初级产品经理要怎么处理这类复杂问题？
01
“如果你是外卖平台的产品经理，你要怎么解决骑手提前确认收货的问题？”
几天前，我在网上看见有人在问这样一个问题。
“如果你是某某产品经理，你要怎么解决某某问题”，这样的问题，感觉经常可以碰见。
“产品经理”相关的讨论，大概有1/3是这样的问题。
作为一名初级产品经理，我每次看到这种问题，都会觉得有些不知所措。
就拿“骑手提前确认收货”这个问题来说。
首先，骑手能够“不守规矩”，说明业务设计上有漏洞，产品存在“错误”。
然后，已经有不少用户碰到这种情况，并感到相当程度的不满，说明已经影响到“用户体验”了。
那么，作为“产品”的经理，自然应该为产品负责，应该去纠正错误、优化体验。
真是这样吗？
其实不然。
这并不是一个可以简单解决的问题，它涉及到很多角色。
在这个问题的语境下，提问者想象了一个非常“强势”的产品经理形象：
有较大的决策权，能够站在一个较高的视角，统筹全局，设计规划产品策略，能够指挥动员各部门进行配合，是一个“中央决策者”的角色。
同时，回答这类问题的，很多都是产品大佬。
所以，就更强化了这么一种错觉，以为“产品经理”就是这么一种“指点江山”的角色。
然而，现实中，能够做到这种程度的产品大佬，其实只是少数。
对于大多数产品人来说，情况完全不是这样。
其实从一些公司的组织架构上，我们也能看出一点端倪。
比如说，产品岗，算上实习生也只有两三人。
比如说，没有独立的“产品部”，而是并到运营部、设计部或技术部里面。
比如说，部门内没有“总监”级别的领导，或者，虽然有，但不是“产品”总监。
我觉得，更常见的情况是，产品经理在公司内部是一种相对“弱势”的存在。
初级产品经理，则更是如此。
我们向产品大佬学习，“高瞻远瞩”地去讨论怎么“解决”这类复杂问题，固然是有意义的。
考虑到实际情况，从初级产品经理的角度，更加“务实”地，去讨论怎么“处理”这些问题，我想，可能也是有些价值的。
所以，今天，我想以“骑手提前确认收货”为例，结合自己的一些经验，谈一谈“初级产品经理要怎么处理这类复杂问题”。
02
我们先来简单分析一下，为什么说它是一个“复杂”的问题。
首先，我们来看看“确认收货”这一业务本身。
“确认收货”，这个概念很简单，大家都清楚，我就不赘述了。
因为我们要去优化这个业务，所以在“动刀”之前，我们得先想想有没有其他的可能。
首当其冲的问题是，可以不要“确认收货”吗？
严格来说，可以。
外卖从店里发出后，将“已发出”作为订单的完成状态，也不是完全不可以。
但是，一般不建议这么做。
抛开具体的业务因素，主要有2个原因。
1、在边际成本可控的前提下，我们应该尽量提高数据的准确度。
多加一个状态，花不了多大成本。而更准确的数据记录，后续能挖掘出的业务价值，将会不成比例地增加。
2、已经做好的功能，如果不是出现严重问题，或者是大改版，一般不建议拿掉。
根据我的经验，那些一直没什么用的功能，一旦你拿掉了，非常诡异地，马上就会有人要用到，然后来找你麻烦。如无必要，勿瞎折腾。
不能拿掉“确认收货”，也不意味着，这个“确认收货”的动作，一定要由“骑手”来触发。
订单涉及到的角色，简单来说，有“用户”、“骑手”、“商家”、“平台”4个。
如果进行排列组合，可以有很多种情况。这里就不一一列举了。
除了“骑手来确认收货”外，还有以下3种看起来比较可行的方案。
1、用户来确认收货。
让用户来确认收货，也就没有骑手什么事情了。
乍看之下，好像能完美解决这个问题。
但是，其实不可行。
用户不愿意去操作“收货”，还在其次。
更重要的是，外卖有“超时赔付”服务。让用户自己“决定”收货时间，会有道德风险。
2、平台来确认收货。
比如说，根据手机定位等因素，来自动“确认收货”。
这种准确度很低，基本不可行。
3、骑手、用户和平台，共同完成“确认收货”操作。
其实也就是，由骑手来完成“确认收货”操作，然后引入其他角色对其进行监督。
比如说，要用户也确认，才有效。
比如说，平台进行定位监控，需要在收货地附近的操作，才有效。
这是一种比较可行的折中方案。
其实吧，完全由骑手“独断”的情况，并不存在。现实中，外卖平台，就是采用这种方案的。
具体策略可以有很多种，但是不管采用哪种方案，总体上都存在一个问题：
提高监督力度，就会相应地提高成本、降低效率。
比如说，我们可以要求骑手确认收货时，提交一张自拍照。
那么，我们设想一下“办公楼中午配送高峰期”的场景。
可能骑手自拍的那么一瞬间，后面的电梯就关上了，下一趟就是十几分钟之后的事情了。
中午的配送高峰期，经得起几个“十几分钟”？
骑手的配送效率，会因此受到非常大的影响。
这就是为什么说它是一个“复杂”问题的原因了。
这里面有很多个维度，用户的体验，用户的收货习惯，骑手的配送效率，骑手的收入，骑手的体验，平台的监管成本，平台的收入，平台的商誉，等等。
一旦我们动了其中一环，不可避免地会影响到其它维度，很难做到“帕累托改进”。
因此，它不存在一个简单的终极解决方案，而是一个各方进行博弈、互相妥协的平衡。
03
接下来，我们来看看，在公司内部，这样的问题具体是按什么流程来解决的。
当然，不同公司情况不同，具体细节会有差异。这里我们抓大放小，暂时忽略这些细节差异。
首先，这个问题是谁先挖掘出来的？
虽然我们要求产品经理要懂用户，要关注用户，但是，公司里面并不是只有产品经理在关注用户。
大概率上，这个问题会由以下部门发现并提出来。
1、客服部。
用户有不满，就会投诉。客服接到这类投诉多了，问题的严重性就会凸显出来。达到一定程度，这个问题就会被提出来。
2、运营部。
一般会有运营同事在持续监控网上各平台内关于自己公司的讨论。用户不满的讨论多了，有恶化的苗头时，这个问题就得在公司内部提出来。
问题确立之后，一般是怎么提出来讨论呢？
大致上，有2种情况。
1、在日常性的比较高规格的公司例会上，由发现问题的部门提出来。
这类日常性会议，可能一周召开一次。与会的有各部门领导和核心成员，还有老板。
一般来说，初级产品经理没有资格参加。就算参加了，也只有听的份。
2、发现问题的部门将问题反馈给领导后，将需求立项，组织相关部门进行协商讨论。
这种情况，有时候需要产品经理与会，甚至需要由产品经理来组织。
但是，初级产品经理更多的是一个“组织者”、“执行者”的角色，不是“决策者”。
那么，讨论之后，问题具体要怎么解决呢？
1、有的时候，问题并不需要解决。
比如说，虽然表面上看起来“群情激奋”，但其实只是少数人的不满。大多数用户可能并不在乎这个问题。他们只是“沉默”，没有发声而已。
而为这少数人进行优化，可能成本上不划算。
所以，不进行处理，保持这个平衡就行了。
2、有时候，问题需要处理，但是没有产品经理什么事。
解决问题，不是只有“技术”一种方式，还可以通过“管理”。
比如说，质检部门，或是其他类似部门，定期随机地电话回访用户，排查这种“提前确认收货”的情况，然后对有问题的骑手进行处罚公示。
这样，付出较低的成本，就能很好地改善这个情况。
3、有时候，需要一整套解决方案，而产品经理只是负责其中一部分。
比如说，因为配送效率是“红线”，不能对“骑手侧”动手。那么，我们可以对“用户侧”进行管理。
它可以是一套涉及多部门的解决方案。
（1）客服部，设计一套安抚用户情绪的话术，并在难以安抚的时候，按规定给用户发放优惠券。
（2）运营部，监控网上的负面声音，对于情绪强烈的，主动联系安抚。
（3）产品经理，在APP内设计体现骑手困难的内容，以争取用户的理解。在骑手确认收货后，把“投诉反馈”的入口放在突出的位置，确保用户在情绪升级之前，能被引导到客服那里，由客服来解决。
（4）……
04
很多时候，产品经理，尤其是初级产品经理，并不是一个“中央决策者”。
初级产品经理，往往只是一个“执行者”，而且往往只负责整个解决方案中的一部分。
这和很多人想象中“指点江山”的形象，相去甚远。
当然，不是“决策者”，也不意味着可以“置身事外”。
作为产品经理，我们很多时候，肯定是需要参与进来的。
那么，面对这些复杂问题，初级产品经理应该怎么处理呢？
以下谈几点建议。
1、要能够准确评估问题，并及时将问题升级。
其他部门，因为他们的日常工作大部分只涉及到部门内部，所以他们对跨部门的协作不是很熟悉。
所以，有时候他们会把这些问题，不明就里地提到产品经理这里来。
我们接到这些需求后，要对其进行评估。
当发现不是简单修改APP设计就能解决时，要及时将问题升级。
2、做好干系人管理，宁滥勿缺。
虽然初级产品经理不怎么参与决策，但有些时候需要由我们来组织协调各部门之间的协作。
比如说，联系各方开会讨论，向各方同步进度，等等。
这种时候，我认为，最应该避免的就是，有缺漏，该联系的人没联系到。
这可能会导致整个方案设计出现重大纰漏，或者在后续推进过程中难以得到相应干系人的积极配合。
所以，我们需要“宁滥勿缺”。把没关系的人也拉来了，不可怕。把有关系的人漏了，才可怕。
3、在讨论中，需要就产品设计难度和成本，提出自己专业的意见。
整体来说，其他部门，对产品设计开发的具体情况，是不了解的。
这就导致，在讨论方案时，他们可能会提一些“强人所难”的要求。
我们参与讨论，并不完全是来“接受任务安排”的。对方案的可行性，我们是需要进行一定程度把控的。
因此，我们需要就产品设计难度和成本，提出自己的意见。并根据当期讨论的情况，提出更合适的方案。
4、产品设计、项目跟进过程中，要有全局思维。
产品经理，并不是完全“听命行事”的。
在一些局部，我们也是需要进行很多“决策”的。
比如说，策划prd的时候。
比如说，项目跟进中出现突发情况，需要产品经理解决的时候。
这个时候，我们需要清楚，我们不是在单独处理眼前这个细节问题。我们负责的是整个解决方案中的一部分。
因此，我们需要站在整个解决方案的高度，按照方案的核心思路，去设计和解决问题。
