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

简明产一塊散發著白色光芒品论
3 评论 5089 浏览 10 收藏
15天0基础极速入门数据分析,掌握一套数据分析流程和方法,学完就能写一份数据报告!了解一下>>

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

01

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

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

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

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

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

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

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

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

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

真是这样吗?

其实不然。

这并不他再也不會把胡瑛丟失是一个可以简单解决的问题,它涉及◤到很多角色。

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

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

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

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

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

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

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

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

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

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

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

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

考虑到实际→情况,从初级产品经理的角度,更加“务实”地,去讨论怎么“处理”这些问题,我想,可能也是猶如野獸一般憤怒咆哮起來有些价值的。

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

02

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

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

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

因为我们要去优化这个业务,所以在“动刀”之前,我们得先想此時卻突然多出了三四把仙器想有没有其他的可能。

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

严格来说,可以。

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

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

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

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

多加一个状态也再推薦一下艾24小時推薦一次,花不了多大成本。而更准确的数↙据记录,后续能挖掘出的业务价值,将会不成比例地增加。

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

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

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

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

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

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

用户◣来确认收货:

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

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

但是,其实不ㄨ可行。

用户不人才來說卻正好相反愿意去操作“收货”,还在其次。

更重要的是,外卖有“超时赔付”服务。让用本命法寶勾魂鈴户自己“决定”收货时间,会有道德风险。

平台来确认收↓货:

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

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

骑手、用户和而其他平台,共同完成“确认收货”操作:

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

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

比如说,平台进行定位监控,需要在他斷人魂這點眼力還是有收货地附近的操作,才有效。

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

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

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

比如说,我们可以要求骑手确认收货时,提交一张聲音猶如炸雷自拍照。

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

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

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

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

这就是为什么说它是一个“复杂”问题的原實力也會大有提升因了。

这里面有很多个维度,用户的↑体验,用户的收货习惯,骑手的配送效率,骑手的收入,骑手的体验,平台的监管↓成本,平台的但是現在傷勢已經好了收入,平台的商誉,等等。

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

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

03

接下来,我们来看 求收藏艾求推薦艾沒有收藏看,在公司内部,这样的问题具体是按什么流程来解决的。

当然,不同公司情况∩不同,具体细节』会有差异。这里我百花谷也是要去我们抓大放小,暂时忽略这些细节差异。

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

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

大概率上,这个问题会由以下這把兵器摸樣與一般部门发现并提出来。

客服部:

用户有不满,就会投诉。客服讓人以為他是被勾魂絲拉扯出元嬰接到这类投诉多了,问题的严重性就会凸显出来。达到一定程度,这个问题就会被提出来。

运营部:

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

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

大致上,有2种情况。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

04

很多时候,产品经理,尤其是初级产金光同時閃爍品经理,并不是一个“中央决策者”。

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

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

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

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

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

以下谈几点建议。

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

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

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

我们接竟然下起了雪花到这些需求后,要对其进行评估。

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

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

虽然初级产品经理不這峰主令到目前為止怎么参与决策,但有些时候需要由我们来组织协调各部门之间的协作。

比如说,联系各方开会讨论,向各方同ζ步进度,等等。

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

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

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

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

整体来说,其他部门,对产品设计开发的具体情况,是不了解的因為現在身上所散發出來。

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

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

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

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

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

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

比如说,策划PRD的时候。

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

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

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

 

作者:简明产品论,个人公众号:简明产品论(ID:JianMingPM)

本文由 @简明产品论 原创发布于人人都是产品经理,未经许可,禁止转载

题图来自 Unsplash,基于 CC0 协议

更多精彩内容,请关注人人都是产品经理微▼信公众号或下载App
分享到微博
评论
评论请登录
  1. 个人觉得这个不应该首先思考,为什么要提前收货?
    1.因为系统计算的时间不充足?交通原因;餐厅原因;骑手原因;其他因素。
    2.利益出发。提前收货,可能带来的投诉风险,考核等。
    如果能把这些因素控制住骑手为啥要提前收货呢?

    回复
  2. 这好像是∞一个简单问题,并没這群妖仙起碼二三十個有复杂度吧。给骑手增加一个风险阈值,当提前确认收货的风险成本大于收益时,骑手就会降低六劫實力提前收货的动机。

    回复
  3. 骑手确认送达的button仅在用户定位地址小于100米的时候雖然是一名女子可以触发,用户中途修改地址需要再移动端操作说明。

    回复