產品經理的平衡之道——追尋技術和產品之間的平衡

在做了幾年的互聯網產品后,嘗試了2b,2c,商業化,中后臺,工具型等諸多維度下的產品方向后,越來越多的發現,就產品經理這個崗位而言,我們開始承擔平衡者的角色。

本文將從產品解決方案設計與實施的矛盾,來討論產品是如何在其過程中體現平衡之道的。

-------------------------------

由于社會化生產協作的需要,我們一方面,在工作流程上,處在業務,商務,運營,市場,銷售等團隊的下游,同時也是交互視覺研發測試等團隊的上游;另一方面,我們在工作內容上,往往也成為了需求項目或是產品本身的第一負責人,在很多團隊,產品甚至的職責本身,產品也本身包含了項目經理的角色,當組織范圍足夠大之后,更多的我們開始面臨,多個產品團隊的協作,多個業務線的協助,中后臺支持團隊的協作等等,偌大一個項目,動不動也就牽扯到了十幾個業務線,七八個中臺服務,甚至在某些互聯網巨頭組織內部,還可能會跨多個事業群,通力協作以達成項目目標。

因而,我們說產品經理在日常工作中,無可避免的需要在各方之間進行平衡,需要在各個視角下進行平衡,最終找到一個問題的最優解或是滿意解。當組織范圍越大,項目復雜度越高,涉及團隊越多,這種平衡就顯得明顯。更準確和真實的描述,可能不是協作,而是各個獨立團隊的利益成本博弈。

當我們無法從戰略層面,強勢進行需求目標推進時,各方必然會陷入局部目標的考量和評估中, 又或者是盡管有集團在戰略層面的傾斜支持,但在實際落地上,所謂的協作關系,自然也會演化成組織內的利益分配、資源內耗、撕逼扯皮。這種情況非常真實的發生在今天的每一個互聯網大廠,項目發起方,通常是主產品發起方,開始舉步維艱推進著一個可能涉及到幾百人的項目,諸多合作方其實并不關心的需求,因為在局部視角下的利益低程度相關性,冷漠和阻力也就成為了最為真實的情況。

理所應當的,當一個訴求,與合作的某一團隊利益完全無關,那這種冷漠在局部視角下,恰恰已經是資源配置的最優解了。但當目標在更高層面,有這深切意義和價值,但在某些局部場景下,又無法凸顯出來的時候,這種本質由組織結構帶來的弊病,就無法隱藏,而這種根深蒂固于組織中的問題和矛盾,絕不是一兩個場景下的訴求,就能夠順帶解決的。就像縱使是古往今來的圣人一般,也難以改變環境,組織結構的變革何其困難,又會觸碰到多少既得利益者的蛋糕,那么,我們該何去何從呢?

最常見的處理方式,便是上升處理,于是組織內,有了各種各樣的撕逼和上升會。不得不說,這種組織內部隨著時間演進演化出的處理方式,確實目前為數不多高效且可實施的解決方案。這種處理方式的本質,在于將原本就是全局問題的部分(這種全局問題,既可以使縱向協作流程的全局,也可以是橫向其他產研團隊的全局),歸還到全局的領導者本身,因此,就實際情況而言,往往也是最有效的。

于是,可怕的事情出現了,我們迷戀于這種處理方式,以至于,在很多時候,忽視了這些所謂的全局(高層)問題,是項目需求問題本質帶來的,還是解決方案帶來的,我們提出了一種基本忽視了諸多合作方價值訴求 的方案,給合作方團隊或是 上下游帶來了高昂的成本和難度,但實際上,業務方的價值和意義卻十分有限。

舉一個多團隊協作中為滿足業務要求互相撕扯的例子,

業務需求方,希望能夠在某個大流量場景,進行商品文案化展示時。盡管商品推薦本身,是非常成熟的能力,但是在進行商品信息轉文案信息話信息加工時,由于部分業務特殊優惠限制,文案拼參等特殊處理的工作,接口服務的tp999本身壓力較大,難以滿足前端頁面的訴求,在這個場景下,考慮到用戶體驗,又必然對推薦出的商品sku進行必要的庫存校驗。上述流程涉及多個上下游團隊,滿足前端性能要求,各方處于自身難度和利益,均不愿做優化和讓步,因此該需求難以推進,此時,產品平衡業務方和多個研發團隊的利益矛盾,講庫存校驗調整為全國庫存校驗并稍作緩存,通過一定程度的需求降級,達到了技術和業務實現的平衡,避免了無盡的撕扯升級。

在舉一個技術成本資源的例子,

業務方希望用戶能夠查詢到,業務線為用戶提供的各種優惠明細信息,該部分數據底層存儲在訂單中臺,作為也業務平臺如果要存儲幾十個億級別的訂單數據,則需要在向中臺數據存儲部門申請存儲資源,該流程繁雜冗長,切申請量級較大,業務價值有限,基本不可能拿到期望量級的redis存儲資源。這時,我們回到業務目標的最初出發點,嘗試需要解決的問題,解決用戶不信任權益在訂單中實際產生價值的問題,露出全量訂單明細固然是一種合理的解決方式,但代價過高。這時,運籌學思想下,我們放棄尋找代價極高的最優解,而是尋找滿意解。嚴格意義上說,這種方式無法解決部分吹毛求疵用戶的需求,但產品解決方案本身,就從來不應該被定義必須完美解決所有問題,當我們能夠以高效的方式解決多大多數核心問題時,就以足夠,換句話說,這才是解決方案的本質,在已有資源的限制下,去尋求問題的高效解法。于是,我們選擇給用戶露出近3個自然月的訂單,極大的減少了存儲資源,甚至不再需要額外的存儲自愿申請,問題就得意解決了。

由此可見,產品解決方案本身或是產品設計本身,就是在以高效可行的方式,去分析和解決本質問題。解決方案不一定能夠解決所有用戶(客戶)的所有問題,解決方案也往往不是完美最優解,但解決方案卻必然是諸多約束下能夠解決問題且能達獲得可行滿意解。

----------

后續,會在講一講,產品解決方案,是如何在業務目標和用戶價值之間,尋求平衡的。

?著作權歸作者所有,轉載或內容合作請聯系作者
平臺聲明:文章內容(如有圖片或視頻亦包括在內)由作者上傳并發布,文章內容僅代表作者本人觀點,簡書系信息發布平臺,僅提供信息存儲服務。

推薦閱讀更多精彩內容