高階產品如何提出有效解決方案?(1方法論+2案例+1清單)
編輯導語:每一件事情總有它的解決方案,在工作中亦是如此,而有效的解決方案,一定是具有系統性的。作者以一個工作案例為導入,分析有效解決問題,希望對你有所啟發。
有效的解決方案,一定是系統性的解決方案。
什么是系統性解決方案?
從系統結構(或連接關系)入手,而不通過改變癥狀(即只解決當前問題)或原因(即通過改變人,包括自己與他人)解決問題的解決方案。
什么意思?
北京疫情要求全民核酸,前期每次社區志愿者都是通過移動式喇叭,從早到晚,間歇性的進行宣傳,目的只是想讓所有居民均參與核酸,避免有遺漏,從而導致疫情擴散。
志愿者不可謂不盡心盡力,居民不可謂之素質低下,可每次依然有不少遺漏之人。
后期則采用進出公共場合、辦公樓以及乘坐公共公交,必須72小時內核酸(前期甚至是48小時)的政策。
同時推出兩大賦能性措施:一是構建大量方艙,且提供免費核酸檢測,便于常態化核酸的便利性;二是檢測結果與地鐵公交系統打通,以及所有公共場合嚴查72小時核酸,如不滿足條件者,直接無法出行。
現階段的疫情常態化防疫,保證72小時核酸檢測正常方可進出公共交通、場所的政策,取得了階段性的有效進展,這就是系統性的解決方案所發揮的應有作用。
【復盤】前期與后期的防疫解決方案,關鍵變化就是從通過改變人去解決問題(即要求志愿者更努力的催,居民更自覺檢測),完全轉變成系統性的解決方案(即改變居民出行、工作與核酸檢測的關聯關系)。
一、案例:如何在數據與資源受限情況下,通過有效解決方案實現業務目標?
假如你作為一名產品經理(簡稱PM)入職一家新公司,負責構建其輔導老師工作臺,基于【需求是1,方案是0】方法論指導,完成前期的調研,并完成了相關的用戶體驗地圖以及產品架構圖規劃(如下圖所示)。
當你準備落地時,發現有兩個關鍵性的限制條件:
- 你所必需的數據均存儲在中臺產研側,你方作為業務方無法直接讀取與運用;
- 你可用的研發資源有限,不足以支撐有效解決大版本迭代更新。
比如當前學員列表顯示的是全部學員(包括在讀以及退課、轉班等),而輔導服務只針對在讀學員即可,至于退課、轉班等失效學員,列表中需剔除。
即使如此小的一個需求,但受上述兩個關鍵限制條件(即學員以及狀態數據不在你方數據庫,以及研發資源限制),技術判斷為當前研發模式無法實現,或即使可以周期也非常長,且只能按照不完美方案執行。
此時,下面3種選擇,你會怎么選?
- 選擇一:告辭,我不干了,此處不留爺,自有留爺處;
- 選擇二:將此問題上升,讓你的上級與研發leader介入,協助解決此問題;
- 選擇三:改變自己的需求方式,提前構建需求緩沖池,保證整體需求可提前規劃與排期。
我建議你哪個都別選,為什么?
選擇一是一種逃避問題的解法,對于新入職的你,還不至于;
選擇二是一種癥狀解。即上級領導的支援次數是稀缺的,此方案只能解決當前一個需求的問題,無法持續;
選擇三是一種原因解。即我改變不了別人,那我至少可以改變自己的工作方式,但效果有限;
我建議你可以從系統層面去尋求根本解,而不是通過癥狀解(即僅解決當前問題)或原因解(即通過改變人,包括自己在內)去解決。
二、什么是系統?什么是才是系統根本解?
系統=目標*要素*連接關系
上述案例中,你作為業務PM的目標是:用最低成本、最高效率完成輔導工作臺的構建,以此實現服務品質的規模化復制。
關鍵要素是:規?;瘓F隊(即輔導老師)、業務產研與中臺產研;
連接關系是:輔導老師的規?;掌焚|與人效的提升,依賴業務產研的支持;而業務產研因數據受限制于中臺產研(雙方卻各自有自己的目標),資源受限制于編制與研發模式,導致難以有效進行工作臺的建構,從而導致服務品質難以規?;纬梢粋€負向增強回路。
如果要形成系統性的解決方案,則需從三個關鍵要素的目標與關聯關系入手,方可探尋到根本解。
中臺產研的目標是:盡可能通用化所有能力,用最小投入賦能更多業務線;
輔導團隊的目標是:盡可能快的用上更高效的系統,以便盡快提升人效,實現服務品質規模化;
你作為業務PM的目標與輔導團隊的目標一致,卻與中臺產研目標有所差異。
從系統論的解決思路中,核心就是從多方目標與連接關系入手。
首先,中臺產研目標是最小成本的通用化,那你就可以將你的輔導工作臺的建設目標,當做其通用化的子集,形成雙方目標的一致性;
其次,從連接關系看,則可采用專項雙方進行混合共建的研發模式,改變你們雙方的研發模式,由雙方各自為戰的模式,變成雙方協同作戰的模式。
案例最終采用了專項形式共建通用化工作臺的方案,雖工期與預期有差距,但最終也完成了上線,并實現了整體最優的策略。
此方案既達到中臺產研通用化最小成本的目標;也實現了業務產研側的輔導工作臺的建設,雙方一起實現了對輔導團隊的規?;掌焚|的系統層支撐,從而達到整個系統(即公司)的最優解。
三、擴展:如何有效解決需求方隨意提需求,浪費產研資源問題?
作為一名業務型PM,你可能會遇到業務方隨意提需求的問題。有時苦口婆心1小時,方才拒絕了一個不合理小需求;有時你迫于無奈,被迫接受了一些需求,上線后發現無人使用,導致你被研發吐槽,公信力下降等問題。
此時如果有下面3個選擇,你會選擇哪個?
- 選擇1:每個需求都當面對接,不合理需求就“動之以情,曉之以理”的柔性拒絕;
- 選擇2:你努力提升自己辨別真假需求與說服人的能力,并定期給需求方的KP(關鍵決策人)進行培訓與宣貫,讓他們具備識別需求、理解產研成本的意識;
- 選擇3:你構建一個需求緩沖池,并建立一種周會制,與關鍵KP進行需求準入情況、優先級與進度共識與同步。
無論你選擇哪個,均正常,它們可能是你所處不同階段、不同業務環境所能采取的解決方案。
我想提供一個第4選擇,供你參考。即讓需求方與產研方共背雙方的績效目標與成本。
為什么呢?
選擇1其實屬于癥狀解,每次只能解決當前的問題;
選擇2屬于原因解,即通過改變你跟需求方的能力模型解決問題;
選擇3屬于弱化版的根本解,即通過改變需求方與產研方的連接關系,讓需求方來匹配產研方的目標以及工作模式;
選擇4是典型的根本解,即通過改變需求方與產研方的目標,讓雙方形成共同目標與連接關系,結構性的解決問題。
當然,受限于企業組織架構等問題,選擇4的實操成本可能比較大,鑒于此我們至少可選擇3作為可落地方案。
四、總結
方法論:從系統結構(或連接關系)入手解決問題,而不通過改變癥狀或原因。
即根本解才是系統性解決方案,而不是癥狀解跟原因解。
- 癥狀解就是只解決當前癥狀的解決方案。比如案例中只解決當前那個需求的方案;
- 原因解則是通過改變人(包括自己與他人)解決問題的方案。比如案例中PM自己構建緩沖需求池(或軟磨硬泡洗腦研發要給力);
- 根本解則是通過改變系統的目標、要素與要素之間的連接關系的解決方案(即系統=目標*要素*連接關系)。比如案例中業務產研與中臺產研采取共建模式進行專項構建的通用化工作臺方案。
實操清單:
- 先識別系統(如一個企業或部門)中的關鍵要素(如企業角色);
- 梳理清楚關鍵要素的關鍵目標(如角色A目標是增收,角色B目標是降本增效等,或是角色對應OKR與北極星指標等);
- 梳理清楚關鍵要素之間的結構或連接關系(如因果鏈、增強回路、調節回路、滯后效應等);
- 確認關鍵要素之間目標的差異,并找到影響結果的關鍵要素之間的連接(重點關注負向增強回路與調節回路);
- 弱化關鍵要素之間目標的不同,基于相同目標重構雙方共同目標,并基于此將負向增強回路或調節回路切斷,形成新的增強回路;
- 將目標、關鍵要素以及連接關系所生成的解決方案(一定不是依賴改變人,而是改變結構),與相關角色之間形成共識,并落地成為制度、流程、規則、策略等(如有必要可輔以產品化的工具支撐);
落地執行,在執行中收集反饋進行優化迭代,最終形成一種可執行、可落地的方案。
#專欄作家#
邢小作,微信公眾號:邢小作之家,人人都是產品經理專欄作家。一枚在線教育的產品,關注互聯網教育,喜歡研究用戶心理。
本文原創發布于人人都是產品經理。未經許可,禁止轉載。
題圖來自Unsplash,基于CC0協議
對根本解還是一知半解??
求問用戶體驗地圖是用什么畫的~?
其實核心就兩點;1,靈活的應對問題,遇到推動阻力的時候動態應變,弱化彼此(人與人,或事與事)的立場沖突;2,對于頻發性的問題要習慣于建立管理流程和規范,降低任意雙方的直接碰撞幾率,讓事情的處理具備緩沖條件。
順便一說,做決策前請先搞懂自己在企業內的角色,以免越權和故作聰明,職場或者說產品經理崗位做久了至少需要有明確的權責劃分的概念。
嗯,可以這么理解,只是建立管理流程和規范等,只是系統化解決方案的其中一種手段。通用性與底層邏輯性不如系統化解決方案
從系統結構(或連接關系)入手解決問題,而不通過改變癥狀或原因。即根本解才是系統性解決方案,而不是癥狀解跟原因解。
沙發一下~哈哈
最開始核酸檢測的案例,簡單理解就是上管理手段?對不?
不是,管理手段頂多可能算是系統性解決方案之一,核心還是要從居民出行與核酸檢測的關系,以及志愿者與核酸檢測關系兩條關聯關系中入手進行解決問題。它可能是一種管理手段,也可能只是一個流程或制度等,而它們都可能會借助系統化的支持(如健康碼或地鐵刷卡系統)。