起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識騎手提前確認收貨，初級產品經理要怎么處理這類復雜問題
作為一個初級的產品經理，有時候我們會遇到一些比較復雜的問題，我們應該如何應對呢？本文作者以“騎手提前確認收貨”為例，對這個問題展開分析，希望對你有幫助。
01
“如果你是外賣平臺的產品經理，你要怎么解決騎手提前確認收貨的問題？”
幾天前，我在網上看見有人在問這樣一個問題。
“如果你是某某產品經理，你要怎么解決某某問題”，這樣的問題，感覺經?？梢耘鲆?。
“產品經理”相關的討論，大概有1/3是這樣的問題。
作為一名初級產品經理，我每次看到這種問題，都會覺得有些不知所措。
就拿“騎手提前確認收貨”這個問題來說。
首先，騎手能夠“不守規矩”，說明業務設計上有漏洞，產品存在“錯誤”。
然后，已經有不少用戶碰到這種情況，并感到相當程度的不滿，說明已經影響到“用戶體驗”了。
那么，作為“產品”的經理，自然應該為產品負責，應該去糾正錯誤、優化體驗。
真是這樣嗎？
其實不然。
這并不是一個可以簡單解決的問題，它涉及到很多角色。
在這個問題的語境下，提問者想象了一個非常“強勢”的產品經理形象：有較大的決策權，能夠站在一個較高的視角，統籌全局，設計規劃產品策略，能夠指揮動員各部門進行配合，是一個“中央決策者”的角色。
同時，回答這類問題的，很多都是產品大佬。
所以，就更強化了這么一種錯覺，以為“產品經理”就是這么一種“指點江山”的角色。
然而，現實中，能夠做到這種程度的產品大佬，其實只是少數。
對于大多數產品人來說，情況完全不是這樣。
其實從一些公司的組織架構上，我們也能看出一點端倪。
比如說，產品崗，算上實習生也只有兩三人。
比如說，沒有獨立的“產品部”，而是并到運營部、設計部或技術部里面。
比如說，部門內沒有“總監”級別的領導，或者，雖然有，但不是“產品”總監。
我覺得，更常見的情況是，產品經理在公司內部是一種相對“弱勢”的存在。
初級產品經理，則更是如此。
我們向產品大佬學習，“高瞻遠矚”地去討論怎么“解決”這類復雜問題，固然是有意義的。
考慮到實際情況，從初級產品經理的角度，更加“務實”地，去討論怎么“處理”這些問題，我想，可能也是有些價值的。
所以，今天，我想以“騎手提前確認收貨”為例，結合自己的一些經驗，談一談“初級產品經理要怎么處理這類復雜問題”。
02
我們先來簡單分析一下，為什么說它是一個“復雜”的問題。
首先，我們來看看“確認收貨”這一業務本身。
“確認收貨”，這個概念很簡單，大家都清楚，我就不贅述了。
因為我們要去優化這個業務，所以在“動刀”之前，我們得先想想有沒有其他的可能。
首當其沖的問題是，可以不要“確認收貨”嗎？
嚴格來說，可以。
外賣從店里發出后，將“已發出”作為訂單的完成狀態，也不是完全不可以。
但是，一般不建議這么做。
拋開具體的業務因素，主要有2個原因。
1.在邊際成本可控的前提下，我們應該盡量提高數據的準確度。
多加一個狀態，花不了多大成本。而更準確的數據記錄，后續能挖掘出的業務價值，將會不成比例地增加。
2.已經做好的功能，如果不是出現嚴重問題，或者是大改版，一般不建議拿掉。
根據我的經驗，那些一直沒什么用的功能，一旦你拿掉了，非常詭異的，馬上就會有人要用到，然后來找你麻煩。如無必要，勿瞎折騰。
不能拿掉“確認收貨”，也不意味著，這個“確認收貨”的動作，一定要由“騎手”來觸發。
訂單涉及到的角色，簡單來說，有“用戶”、“騎手”、“商家”、“平臺”4個。
如果進行排列組合，可以有很多種情況。這里就不一一列舉了。
除了“騎手來確認收貨”外，還有以下3種看起來比較可行的方案。
用戶來確認收貨：
讓用戶來確認收貨，也就沒有騎手什么事情了。
乍看之下，好像能完美解決這個問題。
但是，其實不可行。
用戶不愿意去操作“收貨”，還在其次。
更重要的是，外賣有“超時賠付”服務。讓用戶自己“決定”收貨時間，會有道德風險。
平臺來確認收貨：
比如說，根據手機定位等因素，來自動“確認收貨”。
這種準確度很低，基本不可行。
騎手、用戶和平臺，共同完成“確認收貨”操作：
其實也就是，由騎手來完成“確認收貨”操作，然后引入其他角色對其進行監督。
比如說，要用戶也確認，才有效。
比如說，平臺進行定位監控，需要在收貨地附近的操作，才有效。
這是一種比較可行的折中方案。
其實吧，完全由騎手“獨斷”的情況，并不存在?，F實中，外賣平臺，就是采用這種方案的。
具體策略可以有很多種，但是不管采用哪種方案，總體上都存在一個問題：提高監督力度，就會相應地提高成本、降低效率。
比如說，我們可以要求騎手確認收貨時，提交一張自拍照。
那么，我們設想一下“辦公樓中午配送高峰期”的場景。
可能騎手自拍的那么一瞬間，后面的電梯就關上了，下一趟就是十幾分鐘之后的事情了。
中午的配送高峰期，經得起幾個“十幾分鐘”？
騎手的配送效率，會因此受到非常大的影響。
這就是為什么說它是一個“復雜”問題的原因了。
這里面有很多個維度，用戶的體驗，用戶的收貨習慣，騎手的配送效率，騎手的收入，騎手的體驗，平臺的監管成本，平臺的收入，平臺的商譽，等等。
一旦我們動了其中一環，不可避免地會影響到其它維度，很難做到“帕累托改進”。
因此，它不存在一個簡單的終極解決方案，而是一個各方進行博弈、互相妥協的平衡。
03
接下來，我們來看看，在公司內部，這樣的問題具體是按什么流程來解決的。
當然，不同公司情況不同，具體細節會有差異。這里我們抓大放小，暫時忽略這些細節差異。
首先，這個問題是誰先挖掘出來的？
雖然我們要求產品經理要懂用戶，要關注用戶，但是，公司里面并不是只有產品經理在關注用戶。
大概率上，這個問題會由以下部門發現并提出來。
客服部：
用戶有不滿，就會投訴?？头拥竭@類投訴多了，問題的嚴重性就會凸顯出來。達到一定程度，這個問題就會被提出來。
運營部：
一般會有運營同事在持續監控網上各平臺內關于自己公司的討論。用戶不滿的討論多了，有惡化的苗頭時，這個問題就得在公司內部提出來。
問題確立之后，一般是怎么提出來討論呢？
大致上，有2種情況。
1.在日常性的比較高規格的公司例會上，由發現問題的部門提出來。
這類日常性會議，可能一周召開一次。與會的有各部門領導和核心成員，還有老板。
一般來說，初級產品經理沒有資格參加。就算參加了，也只有聽的份。
2.發現問題的部門將問題反饋給領導后，將需求立項，組織相關部門進行協商討論。
這種情況，有時候需要產品經理與會，甚至需要由產品經理來組織。
但是，初級產品經理更多的是一個“組織者”、“執行者”的角色，不是“決策者”。
那么，討論之后，問題具體要怎么解決呢？
1.有的時候，問題并不需要解決。
比如說，雖然表面上看起來“群情激奮”，但其實只是少數人的不滿。大多數用戶可能并不在乎這個問題。他們只是“沉默”，沒有發聲而已。
而為這少數人進行優化，可能成本上不劃算。
所以，不進行處理，保持這個平衡就行了。
2.有時候，問題需要處理，但是沒有產品經理什么事。
解決問題，不是只有“技術”一種方式，還可以通過“管理”。
比如說，質檢部門，或是其他類似部門，定期隨機地電話回訪用戶，排查這種“提前確認收貨”的情況，然后對有問題的騎手進行處罰公示。
這樣，付出較低的成本，就能很好地改善這個情況。
3.有時候，需要一整套解決方案，而產品經理只是負責其中一部分。
比如說，因為配送效率是“紅線”，不能對“騎手側”動手。那么，我們可以對“用戶側”進行管理。
它可以是一套涉及多部門的解決方案：
- 客服部，設計一套安撫用戶情緒的話術，并在難以安撫的時候，按規定給用戶發放優惠券。
- 運營部，監控網上的負面聲音，對于情緒強烈的，主動聯系安撫。
- 產品經理，在APP內設計體現騎手困難的內容，以爭取用戶的理解。在騎手確認收貨后，把“投訴反饋”的入口放在突出的位置，確保用戶在情緒升級之前，能被引導到客服那里，由客服來解決。
- ……
04
很多時候，產品經理，尤其是初級產品經理，并不是一個“中央決策者”。
初級產品經理，往往只是一個“執行者”，而且往往只負責整個解決方案中的一部分。
這和很多人想象中“指點江山”的形象，相去甚遠。
當然，不是“決策者”，也不意味著可以“置身事外”。
作為產品經理，我們很多時候，肯定是需要參與進來的。
那么，面對這些復雜問題，初級產品經理應該怎么處理呢？
以下談幾點建議。
1.要能夠準確評估問題，并及時將問題升級。
其他部門，因為他們的日常工作大部分只涉及到部門內部，所以他們對跨部門的協作不是很熟悉。
所以，有時候他們會把這些問題，不明就里地提到產品經理這里來。
我們接到這些需求后，要對其進行評估。
當發現不是簡單修改APP設計就能解決時，要及時將問題升級。
2.做好干系人管理，寧濫勿缺。
雖然初級產品經理不怎么參與決策，但有些時候需要由我們來組織協調各部門之間的協作。
比如說，聯系各方開會討論，向各方同步進度，等等。
這種時候，我認為，最應該避免的就是，有缺漏，該聯系的人沒聯系到。
這可能會導致整個方案設計出現重大紕漏，或者在后續推進過程中難以得到相應干系人的積極配合。
所以，我們需要“寧濫勿缺”。把沒關系的人也拉來了，不可怕。把有關系的人漏了，才可怕。
3.在討論中，需要就產品設計難度和成本，提出自己專業的意見。
整體來說，其他部門，對產品設計開發的具體情況，是不了解的。
這就導致，在討論方案時，他們可能會提一些“強人所難”的要求。
我們參與討論，并不完全是來“接受任務安排”的。對方案的可行性，我們是需要進行一定程度把控的。
因此，我們需要就產品設計難度和成本，提出自己的意見。并根據當期討論的情況，提出更合適的方案。
4.產品設計、項目跟進過程中，要有全局思維。
產品經理，并不是完全“聽命行事”的。
在一些局部，我們也是需要進行很多“決策”的。
比如說，策劃PRD的時候。
比如說，項目跟進中出現突發情況，需要產品經理解決的時候。
這個時候，我們需要清楚，我們不是在單獨處理眼前這個細節問題，我們負責的是整個解決方案中的一部分。
因此，我們需要站在整個解決方案的高度，按照方案的核心思路，去設計和解決問題。
作者：簡明產品論，個人公眾號：簡明產品論（ID：JianMingPM）
本文由 @簡明產品論 原創發布于人人都是產品經理，未經許可，禁止轉載
題圖來自 Unsplash，基于 CC0 協議
騎手行為心理：
超時收貨確認影響績效，會被罰錢
潛在場景：
1.商家出貨不及時，配送員等待時間較長
2.騎手同時拿多單，導致部分訂單存在配送超時風險，然后提前確認收貨
3.天氣原因，交通原因導致配送超時
場景對應解決方案：
1.建立商家出餐時長預測模型，出餐時長超過一定時間對商家做出懲罰，騎手配送不予懲罰
2.為提升賺錢效率騎手一次性領取多單情況無法避免，否者會打擊騎手配送積極性
對應策略：
a.派單領取策略調整：所以在可領取多單的情況下，首先根據歷史大數據去查看，騎手同時領取超過多少單時存在超時風險，針對該閾值設置領取單數限制規避超時問題；領首單和尾單間隔超過多長時間時會存在延誤風險，領單時給予騎手提示配送風險。
b.配送效率優化：多單情況下為騎手進行線路規劃，提升配送效率
c.提前確認收貨被投訴，給予一定時間段0派單、被投訴多次進行懲罰并延長0派單時長，給予用戶優惠券補償
3.惡劣天氣情況下單少推準時寶并給予用戶安撫話術說明，降低騎手延誤賠付問題。
個人覺得這個不應該首先思考，為什么要提前收貨？
1.因為系統計算的時間不充足？交通原因；餐廳原因；騎手原因；其他因素。
2.利益出發。提前收貨，可能帶來的投訴風險，考核等。
如果能把這些因素控制住騎手為啥要提前收貨呢？
1、交通原因、餐廳原因等這些因素是客觀因素，也是不可控的。
2、解決辦法如你所說，增加配送時間，看似從“根”上解決了提前收貨的問題?，F在我們思考“提前收貨”帶來的問題是在哪一側，毫無疑問是在“用戶側”的。
3、現在返回來說增加配送時長能否解決上述問題，你換位思考作為用戶，在中午點了一份餐想在既定的時間美美的吃一頓，然而餐廳離你不是太遠大概1-2km,一看時間一個小時，你會怎么想？作為騎手你會怎么做？所以你這個問題最終又繞回到了用戶側，說白了還是不解決問題。
4、從投訴風險入手，讓騎手在點擊提前收貨時面臨被投訴等處罰風險，這看似也能解決問題。但站在騎手角度出發，他一方面擔心在規定時間配送不到而面臨處罰（因客觀因素無法把控而導致配送超時），一方面擔心配送不到點擊提前收貨而面臨處罰，這是一個讓騎手很糾結的事，時間長了會影響騎手積極性從而影響APP的大眾口碑，同樣又繞回到了用戶側。
5、我真實的體驗也是這樣，單位附近有幾家餐廳原來都是1-20分鐘左右貨到，現在直接調整為50-70分鐘左右（我回想時間更改的這段時間，貌似提前收貨的問題真的沒發生過了0.0），下雨天之類的更甚，所以我在基于此前服務的基礎上不止一次的對客服提出我的困惑。
6、我只在一種情況下對上述問題有過“理解”就是之前的某個下雨天，騎手打電話過來說明原因，我也理解，并且因為騎手態度很好，給了好評。
7、我認為產品真的應該在基于自身原因的思考下最大程度的站在用戶側考慮問題，而不是一上來就把問題拋出來，而拋出來的大部分原因是不可控的，這可能會讓決策層很頭疼，同樣也不是一個好的職場行為方式。有點啰嗦了，希望對你有幫助。
謝謝，這幾個點值得我反思。
我之前還讀過一篇文章，系統通過數據測算外賣小哥30分鐘剛好能送到的訂單，系統會把預計時間縮短成28分鐘，這樣外面小哥就會很著急送。
這好像是一個簡單問題，并沒有復雜度吧。給騎手增加一個風險閾值，當提前確認收貨的風險成本大于收益時，騎手就會降低提前收貨的動機。
騎手確認送達的button僅在用戶定位地址小于100米的時候可以觸發，用戶中途修改地址需要再移動端操作說明。
定位總會有誤差；而且會出現外賣小哥路過你家樓下就點了“確認收貨”，小哥先送即將超時的訂單，再給你送。