作為一個初級的產品經理，有時候我們會遇到一些比較復雜的問題，我們應該如何應對呢？本文作者以“騎手提前確認收貨”為例，對這個問題展開分析，希望對你有幫助。

01

“如果你是外賣平臺的產品經理，你要怎么解決騎手提前確認收貨的問題？”

幾天前，我在網上看見有人在問這樣一個問題。

“如果你是某某產品經理，你要怎么解決某某問題”，這樣的問題，感覺經?？梢耘鲆?。

“產品經理”相關的討論，大概有1/3是這樣的問題。

作為一名初級產品經理，我每次看到這種問題，都會覺得有些不知所措。

就拿“騎手提前確認收貨”這個問題來說。

首先，騎手能夠“不守規矩”，說明業務設計上有漏洞，產品存在“錯誤”。

然后，已經有不少用戶碰到這種情況，并感到相當程度的不滿，說明已經影響到“用戶體驗”了。

那么，作為“產品”的經理，自然應該為產品負責，應該去糾正錯誤、優化體驗。

真是這樣嗎？

其實不然。

這并不是一個可以簡單解決的問題，它涉及到很多角色。

在這個問題的語境下，提問者想象了一個非?！皬妱荨钡漠a品經理形象：有較大的決策權，能夠站在一個較高的視角，統籌全局，設計規劃產品策略，能夠指揮動員各部門進行配合，是一個“中央決策者”的角色。

同時，回答這類問題的，很多都是產品大佬。

所以，就更強化了這么一種錯覺，以為“產品經理”就是這么一種“指點江山”的角色。

然而，現實中，能夠做到這種程度的產品大佬，其實只是少數。

對于大多數產品人來說，情況完全不是這樣。

其實從一些公司的組織架構上，我們也能看出一點端倪。

比如說，產品崗，算上實習生也只有兩三人。

比如說，沒有獨立的“產品部”，而是并到運營部、設計部或技術部里面。

比如說，部門內沒有“總監”級別的領導，或者，雖然有，但不是“產品”總監。

我覺得，更常見的情況是，產品經理在公司內部是一種相對“弱勢”的存在。

初級產品經理，則更是如此。

我們向產品大佬學習，“高瞻遠矚”地去討論怎么“解決”這類復雜問題，固然是有意義的。

考慮到實際情況，從初級產品經理的角度，更加“務實”地，去討論怎么“處理”這些問題，我想，可能也是有些價值的。

所以，今天，我想以“騎手提前確認收貨”為例，結合自己的一些經驗，談一談“初級產品經理要怎么處理這類復雜問題”。

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 協議