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

作为一个初级的产品经理,有时候我们会遇到一些比较复杂的问题,我们应该如何应对呢?本文作者以“骑手提前确认收货”为例,对这个问题展开分析,希望对你有帮助。

01

“如果你是外mài平台的产品经理,你要怎么解决骑手提前确认收货的问题?”

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

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

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

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

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

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

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

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

真是这样吗?

其实不然。

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

在这个问题的语境下,提问者想象了一个非常“X”的产品经理形象:有较大的决策泉,能够站在一个较高的视角,统筹全jú,设计规划产品策略,能够指挥动员各部门进行配合,是一个“X决策者”的角sè。

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

所以,就更强化了这么一种错觉,以为“产品经理”就是这么一种“指点jiāng山”的角sè。

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

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

其实从一些X的X架构上,我们也能看出一点端倪。

比如说,产品岗,算上实xí生也只有两三人。

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

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

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

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

我们向产品大佬学xí,“X远瞩”地去讨论怎么“解决”这类复杂问题,固然是X义的。

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

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

02

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

首先,我们来看看“确认收货”这一X本身。

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

因为我们要去优化这个X,所以在“动dāo”之前,我们得先想想有没有其他的可能。

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

严格来说,可以。

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

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

抛开具体的X因素,主要有2个原因。

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

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

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

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

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

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

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

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

用户来确认收货:

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

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

但是,其实不可行。

用户不愿意X作“收货”,还在其次。

更重要的是,外mài有“超时赔付”X。让用户自己“决定”收货时间,会有X风险。

平台来确认收货:

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

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

骑手、用户和平台,共同完成“确认收货”cāo作:

其实也就是,由骑手来完成“确认收货”cāo作,然后引入其他角sè对其进行X。

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

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

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

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

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

比如说,我们可以要qiú骑手确认收货时,提交一张X照。

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

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

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

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

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

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

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

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

03

接下来,我们来看看,在X内部,这样的问题具体是按什么liú程来解决的。

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

首先,这个问题是谁先挖掘出来的?

虽然我们要qiú产品经理要懂用户,要关注用户,但是,X里面并不是只有产品经理在关注用户。

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

客服部:

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

运营部:

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

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

大致上,有2种情况。

1.在曰常性的比较高规格的X例会上,由发现问题的部门提出来。

这类曰常性X,可能一周召开一次。与会的有各部门X和核心成员,还有老板。

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

2.发现问题的部门将问题反馈给X后,将需qiú立项,X相关部门进行协商讨论。

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

但是,初级产品经理更多的是一个“X者”、“执行者”的角sè,不是“决策者”。

那么,讨论之后,问题具体要怎么解决呢?

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

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

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

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

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

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

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

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

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

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

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

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

04

很多时候,产品经理,尤其是初级产品经理,并不是一个“X决策者”。

初级产品经理,往往只是一个“执行者”,而且往往只负责整个解决方案中的一部分。

这和很多人想象中“指点jiāng山”的形象,相去甚远。

当然,不是“决策者”,也不意味着可以“置身事外”。

作为产品经理,我们很多时候,肯定是需要参与进来的。

那么,面对这些复杂问题,初级产品经理应该怎么处理呢?

以下谈几点建议。

1.要能够准确评估问题,并及时将问题升级。

其他部门,因为他们的曰常工作大部分只涉及到部门内部,所以他们对跨部门的协作不是很熟悉。

所以,有时候他们会把这些问题,不明就里地提到产品经理这里来。

我们接到这些需qiú后,要对其进行评估。

当发现不是简单修改APP设计就能解决时,要及时将问题升级。

2.做好干系人管理,宁滥勿缺。

虽然初级产品经理不怎么参与决策,但有些时候需要由我们来X协调各部门之间的协作。

比如说,X各方X讨论,向各方同步进度,等等。

这种时候,我认为,最应该避免的就是,有缺漏,该X的人没X到。

这可能会导致整个方案设计出现重大纰漏,或者在后续推进过程中难以得到相应干系人的积极配合。

所以,我们需要“宁滥勿缺”。把没关系的人也拉来了,不可怕。把有关系的人漏了,才可怕。

3.在讨论中,需要就产品设计难度和成本,提出自己X的意见。

整体来说,其他部门,对产品设计开发的具体情况,是不了解的。

这就导致,在讨论方案时,他们可能会提一些“强人所难”的要qiú。

我们参与讨论,并不完全是来“接受任务安排”的。对方案的可行性,我们是需要进行一定程度把控的。

因此,我们需要就产品设计难度和成本,提出自己的意见。并根据当期讨论的情况,提出更合适的方案。

4.产品设计、项目跟进过程中,要有全jú思维。

产品经理,并不是完全“听命X”的。

在一些jú部,我们也是需要进行很多“决策”的。

比如说,策划PRD的时候。

比如说,项目跟进X现突X况,需要产品经理解决的时候。

这个时候,我们需要清楚,我们不是在单独处理眼前这个细节问题,我们负责的是整个解决方案中的一部分。

因此,我们需要站在整个解决方案的高度,按照方案的核心思路,去设计和解决问题。

收藏 (0) 打赏

以上内容不错,打赏支持一下!

打开微信/支付宝扫一扫,即可进行扫码打赏哦,分享从这里开始,精彩与您同在
点赞 (0)

声明:本站所有教程资源,如无特殊说明或标注,均为本站原创发布。任何个人或组织,在未征得本站同意时,禁止复制、盗用、采集、发布本站内容到任何网站、书籍等各类媒体平台。如若本站内容侵犯了原著者的合法权益,可联系我们进行处理。

雄发创业网 自媒体是如何赚钱的 骑手提前确认收货,初级产品经理要怎么处理这类复杂问题 https://www.xiongfawang.com/2125.html

常见问题

相关文章

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

分享本文封面