中臺產品經理的工作內容瑣碎、日常需求量大，工作內容難以管理，價值難以量化。如何管理好中臺產品的日常工作，值得每一位中臺產品經理思考。作者分享了他日常工作思考與總結，希望對你有所啟發。

中臺產品經理的工作多為接收前臺業務線需求、抽象設計產品架構、處理各種線上問題，日常需求量大、工作瑣碎，工作內容難以管理，價值難以量化。如何管理好中臺產品的日常工作，量化體現日常工作的價值，成為每個中臺產品經理都要思考的問題。

近期國內大廠都在爭相學習亞馬遜，通過文檔來組織和管理日常工作，在周、月、季維度檢查工作進度，用同一片文檔承載了工作規劃、管理、周報、月報、季報的職能，減少了管理者和一線員工的攢匯報材料的工作量，非常實用。

筆者結合自身實際工作實踐總結出一套文檔，用以管理相對成熟的中臺產品的日常工作，下圖是文檔模版。但文檔終究只是一種管理形式，后文分享關于中臺產品日常工作和價值的思考，這些思考最終形成了文檔的目錄結構和文檔內容的填寫原則。

一、中臺產品的兩個基本特點

1. 中臺產品服務于前臺產品

中臺產品可能不直接為業務人員或用戶提供服務，但一定為前臺產品提供服務，前臺產品通過集成中臺產品能力來為最終的用戶提供服務，這意味著中臺產品除了要建設帶有人機交互界面的各類用戶端、管理端外，還需要建設以 API/MQ/SDK/大數據 為產品形態的開放服務，以便前臺產品可以通過 API/MQ/大數據 來集成中臺能力。以下幾個例子來進一步說明這個特點：

• 訂單中臺：在以電商業務為核心（例如京東零售、淘寶天貓）的公司里，一般來說都會建設訂單中臺，使用到訂單中臺的前臺有淘寶APP、天貓APP、閑魚APP、商家工作臺、小二工作臺等。一方面為了讓這些前臺產品I查詢消費者或店鋪的訂單，訂單中臺提供了一組API；一方面訂單中臺為了能讓公司內部的運營同學迅速排查異常訂單的原因，提供了一個訂單運維平臺；另一方面為了讓各業務線看到自己的訂單量、交易金額等數據，訂單中臺將自身數據抽到大數據平臺，大數據平臺將訂單數據加工成各類看板提供給各類角色。
• 賬號中臺：賬號的注冊、登錄、密碼修改能力是每個系統最基本的能力，企業通常期望通過一套賬號為客戶提供多種服務。例如支付寶、淘寶、天貓、咸魚等APP公用一套賬號體系，這些APP各自提供了賬號密碼安全登錄、密碼修改的能力，這些能力統一由賬號中臺提供；商家開放平臺、商家工作臺等PC端系統也公用一套賬號體系，這些系統通過引用賬號中臺的單點登錄SDK來為客戶提供統一的登錄頁面；當賬號密碼發生修改時，賬號中臺發送MQ，各系統收到MQ后強制退出當前賬號，要求用戶重新登錄。

2. 中臺產品提供領域統一服務

中臺產品針對產品所屬領域，提供統一領域服務，統一領域服務意味著在中臺產品的日常工作中可能要做兩件事，一是如果企業里存在同類服務，那么應該想辦法替代掉這個服務；如果中臺產品內部針對同一個能力存在多項服務，那么應該想辦法合并這些服務；這兩部分工作就是消滅煙囪，是領域服務治理工作的一部分，最終目的是降低研發成本、提升支持業務的效率。這樣說可能有點饒，還是以訂單中臺和賬號中臺為例來說明這個特點。

• 訂單中臺：公司決定依托于淘寶、天貓業務的訂單模塊建設訂單中臺，訂單中臺建設初期，閑魚有自己的訂單模塊；訂單中臺建設兩年后，開始想辦法用訂單中臺能力替代閑魚的訂單模塊，替代成功后閑魚訂單模塊的產研資源合并到訂單中臺并做人員裁剪，由此節約了研發硬件、人力成本；訂單中臺建設三年后發現給淘寶、天貓、閑魚提供的訂單查詢能力完全是三套不同的能力，需要各自升級運維，于是構建了通用的訂單查詢能力，將原有三套不同的能力的底層切換到通用能力上，這樣就進一步提升了產品服務迭代的效率。以上中臺產品的演變過程可以總結為「提供統一領域服務」的過程。
• 賬號中臺：賬號中臺建設初期，淘寶、菜鳥各有一套賬號，使得商家使用兩個產品時要創建兩套賬號，為了提升商家體驗，賬號中臺合并了這兩套系統，商家下的淘寶賬號、菜鳥賬號被合并到了一起，統一管理，最終菜鳥裁掉了自己的賬號團隊，并且將賬號數據和賬號權益統一托管在賬號中臺進行管理，即提升了商家體驗，又降低了研發人力、硬件成本。

3. 實際工作應用

中臺產品的這兩個基本特點決定了產研團隊的工作內容和工作方式，在月報模版中，「業務洞察」章節關注前臺BP的產品規劃，「產品廣度價值」章節和「領域服務治理」章節關注領域服務的“統一”程度。

二、驅動中臺產品工作的三股力量

1. 業務變化

在業務產品變更、運營流程變更等業務發生變化的情況下，除前臺產品一定會隨之變更外，中臺產品也要識別是否需要更新自身能力，這里有幾類中臺產品，他們受業務驅動的路徑大不相同：

• 基礎型中臺產品：例如賬號、權限、打印、支付，這些中臺產品支持的業務線范圍非常廣，但自身能力建設受業務影響一般比較小，因為基礎能力幾乎不因具體上層業務發生變化，例如支付中臺，不管做什么樣的電商業務，對于支付中臺來說需要提供的支付能力總逃不過余額支付、借記卡支付、信用卡支付、貨到付款這么幾種。
• 單據型中臺產品：例如訂單中臺、運單中臺、商品中臺、店鋪中臺，這些中臺產品的領域劃分就是根據業務交易或運營過程中的流程環節或涉及的實體來的，一旦業務訴求發生變更，這些中臺產品的能力必然要隨之變更，但這類中臺產品一般不直接服務于客戶或者業務，躲在前臺產品的后面。
• 職能型中臺產品：例如人資中臺、財務中臺、客服中臺，這些產品嚴格來說不能算是中臺產品，因為其本身已經服務了一個具體人群，但考慮到企業往往把他們定義為業務中臺（業務中臺的各職能部門服務于各個業務線），同時在系統架構上這些產品確實是服務于各個業務線的，所以也劃分到中臺里來。這些中臺產品的建設一方面受直接服務的人群的影響，另一方面首具體業務線影響。例如財務中臺，財務人員變更出賬的規則，則財務中臺肯定會發生變更，業務線人員增加了費用科目，財務中臺肯定也要發生變更。

2. 用戶之聲

除了滿足業務的訴求外，中臺產品還需要在該領域內深度解決終端用戶、前臺產研、各級老板等各類用戶角色的痛點/槽點，分為幾塊工作：

• 終端客戶體驗：前臺通過集成中臺能力來為用戶提供服務，中臺能力弱、服務不穩定一定影響最終的用戶體驗。用戶對于終端產品的槽點一般也要通過IT團隊分發到中臺，例如用戶抱怨無法按XXX條件篩選訂單、不能使用余額和銀行組合支付，這些可能是由于中臺能力不足導致，如果是做ToB業務，則還需要特別注意KA客戶的反饋，KA客戶的訴求往往直指中臺基礎能力的不足。、
• 前臺產研體驗：影響前臺產研體驗的點一般為中臺產品的能力完善度和接入使用中臺能力的過程中的體驗，翻譯成大白話就是有沒有這個能力，用起來方不方便。在這里特別要提到的是這個接入能力的建設，接入能力也是中臺產品的一項能力，接入能力強，則各BP接入使用的成本就低，接入能力弱，則會造成比較差的體驗，影響中臺產品推廣。
• 各級老板訴求：例如客服老板抱怨異?？▎翁?，這說明中臺的單據狀態機和異常監控能力可能不完善；例如業務老板想做充值卡業務，則財務中臺就需要建設余額支付相關的能力。老板的訴求其實可以歸為業務訴求，但老板的訴求往往涉及多個中臺產品建設大量0-1的能力，所以老板的訴求往往需要當一個項目來做，系統性地補充一批中臺能力。

3. 研發預算

一般來說，在負責的領域服務范圍不變的情況下，中臺的研發預算應該不變或逐年減少，這與中臺建設的終極目標——降本增效 是一致的。具體的：

• 建設初期：中臺有大量從0到1的能力建設，這階段的研發投入可能會在最初基礎上有所增加；
• 建設中期：但是當中臺能力建設兩三年之后，中臺產品的工作就在單純的能力建設基礎上增加了提升服務效率相關的工作——如何更快更好地服務用戶，這個階段預算就不再增加，或者說叫做業務增長但預算不變；
• 收益期：業務增長但預算不變的狀態通常只持續一兩年，此后應該看到中臺建設的收益，包括人力和硬件在內的研發預算都應該逐年降低，通常這個階段會進行領域服務治理相關的工作；

以上提到兩個關鍵工作——提升服務效率、領域服務治理；

• 提升服務效率：一般指提升接入效率和需求吞吐的效率，其中，提升接入效率重在能力的標準化上和配套文檔的完善性上，個人對于能力標準化的理解是同類能力只有一個或少數幾個服務入口（服務入口指研發上的API或功能頁面）、同一個能力的幾個服務入口的區別清晰易懂、API等技術服務有清晰的SLA承諾、不同種類的問題有清晰的的答疑流程機制，配套文檔的完善性體現在用戶能通過文檔對號入座找到想用的能力、能力有配套的使用說明、有常見使用場景的最佳實踐；提升需求吞吐效率重在架構設計和研發過程管理上，架構設計得好則能低成本的拓展能力，不至于業務要一個什么能力就得重構系統，研發過程管理得好則可以提升研發資源利用效率，近年的敏捷開發過程即可有效提升團隊交付速度和質量，但對產研任務拆解的要求較高。
• 領域服務治理：一般指煙囪治理和數據治理，其中消除同類系統（煙囪治理）能顯而易見地降低研發人力、硬件成本，這在前文已經講過；數據治理指的是領域服務內的垃圾數據清理（清理商品中臺N年內從未上架過的SKU）、數據分級儲存（將半年內的數據存儲在MySQL內，半年外的數據結轉到硬盤）、數據分層查找（近三個月內訂單可在200ms查找到，近三年訂單可在1000ms內查找到）等，這些措施能夠有效降低硬件成本。

4. 實際工作應用

在月報模版中，以上驅動因素所帶來的影響被體現在了「業務洞察」和「領域服務治理」兩個章節中，「業務洞察」關注業務組織架構、業務產品規劃、領導層的重點項目，并思考產品側要采取的行動；「領域服務治理」章節編寫領域內的煙囪、數據等各種“亂象”的治理目標和進展，治理過程是一個非常漫長的過程，在不同階段設置不同的治理目標，通過3年左右的時間讓領域內的服務逐漸變得整潔、高效。

三、影響中臺產品設計的兩個因素

1. 領域知識

對領域認知的深刻程度決定了中臺產品設計的好壞，認知又分為理論和實踐兩部分。

1. 理論知識：一般來說一個領域的理論知識不隨所處行業發生改變，例如訂單領域關注交易要素的記錄，其中交易要素包括交易主體、所購產品、交易地點、交易方式、交易金額、支付方式等，在零售、物流、金融行業都是一樣存在這些要素。理論知識通過書籍、總結即可學來，學習起來并不是十分困難。
2. 實踐知識：一般中臺產品由在公司呆了3年及以上經驗豐富的產品經理負責設計，這個產品同學在這個企業對這個領域的實踐（踩坑）則形成了這家企業對這個領域的獨特訴求，例如訂單領域在零售行業中交易產品的是具體的商品，商品有庫存即則可售，但在物流行業等賣服務的行業，則要考慮產品供給和產能問題，例如你想寄快遞到新疆偏遠村莊，一般快遞是不支持的（產品供給問題），例如你想退貨需要1小時內上門取件發現預約已滿，因為快遞員的數量是固定的，服務了別人就沒法服務你了（產能問題），這就是訂單領域在物流行業的特殊領域知識。

擁有理論知識后就可以設計出最基本的產品架構，擁有實踐知識后才能完善出適用于這家企業的產品架構，切實解決企業業務問題。

2. 同行/競品

常見的產品設計過程中就會參考同行做法或者競品的做法，但中臺產品因其“躲在前臺產品后面”、“為前臺服務”，出現了兩個很有意思的現象：

• “市面上沒有競品可以參考”：例如訂單中心，誰也不知道阿里的訂單中心到底是什么樣的，因此設計訂單中心的時候幾乎只能靠自己對于領域的理解和企業的實際需求來。
• “市面上的競品沒有可參考性”：每家企業情況不同，即便都是訂單中心，兩家企業的設計可能也是完全不同的。

這兩個現象導致大多數產品經理在設計中臺產品的時候只從企業自身需求出發，近乎閉門造車，他們忽略了同行企業在發展過程中的趨同效應，兩家客戶群原本完全不同的企業為了獲取更多層次的客戶一定會相互借鑒，因此同行現在擁有的能力雖然我們現在不需要，但在設計中卻可以考慮到，以便將來迅速擴展出所需能力。另外市面上雖然找不到直接競品，卻能從同行的前臺產品中推測出競品的能力和實際，例如我們發現閑魚的訂單居然可以在淘寶中查到，由此推測訂單中臺同時具備B2C和C2C兩種訂單的交易能力。

3. 實際工作應用

在月報模版中，「業務洞察」章節的一個子章節就是競品動態，一般寫競品新上的能力或運營政策、我方是否應該跟進。依據領域知識做出的產品建設規劃則體現在「領域能力建設」章節中，并且設有「認知迭代」子章節，目的是不斷驅動大家思考，加深對于領域的認知。

四、衡量中臺產品價值的兩個維度

獨立的中臺產品并不能為客戶提供完整的業務服務，因此不能直接用業務的收入、交易轉化等業務指標中臺產品的價值。但不意味著中臺產品與最終業務達成毫不相干，事實上，中臺產品的好壞直接影響影響客戶的系統使用體驗，可以想見訂單查詢慢、賬號被盜號會給用戶帶來多么糟糕的體驗。

另一方面，前中臺架構的初衷就是提升研發效率，因此一定需要衡量中臺產品帶來的企業效率提升。根據筆者實際的工作經驗，將中臺產品價值衡量維度拆為深度和廣度。

1. 產品價值的深度

指的是產品創造了多大的單點價值，單點價值指的是單次使用你的產品和其他同類產品的差異，例如現在要新做一個淘特APP，直接使用訂單中臺和自建訂單管理能力在研發成本、周期上有多大的差異，訂單中臺提供的訂單創建、訂單列表查詢、訂單詳情查詢等核心服務相比于自建服務的穩定性高多少。通常又可以從以下幾個維度衡量產品價值的深度：

終端用戶體驗：前臺通過集成中臺能力來為用戶提供服務，因此中臺產品一定影響最終的用戶體驗。

• 技術類體驗：如果前臺產品通過API等形式使用中臺能力，那么相應的指標是訂單查詢速度、訂單查詢成功率、下單速度等，這類指標一般由研發同學負責，但可能需要產品同學一起來優化（詳見后文領域服務治理）。
• 產品類體驗：如果前臺產品還嵌入了中臺產品的人機交互頁面，或者中臺產品提供獨立的管理端供用戶專門完成某種任務，那么相應的指標就與一般的工具型產品沒有差異，常見的有完成XXX任務的體驗、解決XXX問題的速度。

研發成本和效率：中臺產品如果做不到降本增效，那就失去了做中臺產品的最基本價值。

• 前臺：通過接入中臺產品，前臺開發某個功能的周期縮短XX%；前臺建設某類功能的研發成本減少XX%；
• 中臺：通過優化中臺產品架構/系統架構，需求交付效率提升XX%，研發人力減少XX，硬件資源減少XX；

企業成本和效率：有些中臺產品會直接影響企業，例如財務中臺的好壞直接影響出賬效率和回款效率，風控中臺的好壞直接影響資金利用效率和客戶投訴率，這類指標就沒有模版可言，完全取決于領域特性。

2. 產品價值的廣度

產品價值的深度證明了產品創造價值的潛力，但只有大家實際使用你的產品了才能創造實際的價值，這點與典型B端產品是一樣的。衡量產品在多大范圍內創造了價值的角度有兩個：

• 系統覆蓋率：中臺產品服務于前臺，那就得衡量服務了多少前臺，通用的指標有系統覆蓋率 = 使用中臺能力的系統數量 / 有該領域能力需求的系統數量，也可以按業務線來衡量 服務復用率 = 使用中臺能力的業務線數量 / 有該領域能力需求的業務線數量，通過服務復用率可以看出我們需要與哪些業務線開展合作，通過系統覆蓋率可以看出與各業務線實際合作的進展以及產品實際推廣使用的進展。
• 業務覆蓋率：最終產品應該通過服務業務創造價值，所以最終還是要看業務維度的覆蓋率，通用的指標有 需求覆蓋率 = 實際使用了該中臺能力的需求數量 / 總的需要使用該能力的需求數量，單量覆蓋率 = 該能力影響的單據數量 / 總單量。

系統覆蓋率是純技術視角的產品應用范圍，通常來說應該通過提升系統覆蓋率來間接提升業務覆蓋率。

3. 實際工作應用

通過以上兩個角度，結合實際領域服務，可以演化出多種指標，例如注冊成功率、訂單滲透率等，形成產品的價值指標體系，并持續追蹤這些價值指標的變化，如下圖示例：

在實際工作過程中，我們基本都是產品能力建設（深度）和產品推廣使用（廣度）兩手抓，但每個階段工作總有側重點，一般來說將某個指標當做全年工作的北極星指標，每個季度每個人負責提升北極星指標下面的一兩個子指標。所以在實際的產品月報中，只記錄本階段要優化的指標，并針對這個指標開展工作計劃、進度追蹤，具體格式如下：

特別的，我們單設一個章節來做認知迭代，很多時候我們都是邊摸索邊做事，并非有一個想法就一定能落地，所以一定要總結經驗。在「認知迭代」中，針對產品當前的處境，設置幾個問題，引導大家持續思考。通用的問題有：

• 現在的衡量指標是否合適，是否能反映產品真實的效率和體驗?
• 現在的衡量指標是否合適，是否能反映產品真實的使用范圍?
• 現在舉措沒產生預期效果的話，原因是什么？是否需要采取其他舉措？
• 有哪些新的關鍵合作伙伴？
• 消滅XXX煙囪真的有價值嗎？

根據實際情況還可以設置跟領域相關的問題，例如：

• 現在的訂單查詢速度夠快了嗎？
• 現在的賬號中臺接入過程夠便捷了嗎？

寫在結尾

在月報模版中還有注解了諸多關于月報編寫的技巧，、筆者個人習慣是 在同一個文檔模板上每月產生一個文檔（簡稱月報），文檔中的模塊的內容按照周、月、季度不同的頻次更新，并且所有內容均由一線同學更新。在本文檔實踐后，不再需要一線同學寫周報，筆者自己不用再專門寫月報、季度工作規劃，同時產品線紛繁復雜的工作也得到了有序管理，一線同學工作更加能長期聚焦到目標上，受益匪淺。

需要特別注意的是，文檔中的表述都要簡潔，寫到關鍵的定性定量描述即可，沒有關鍵信息模塊可以空著不寫，切勿長篇大論，稍不注意控制這個文檔就會變得又臭又長，筆者建議控制在10~15分鐘內能閱讀完的篇幅范圍內。

關于中臺產品的建設規劃可以看我的另一片文章《如何做好B端產品規劃？這“一攬子工具”幫到你！》，祝大家工作順利年年加薪！