後台產品經理與web/客戶端產品經理的職業發展方向有什麼不同？

01-04

後台產品更偏重產品業務、產品邏輯，和web/客戶端的產品設計上有很大不同，這兩者的工作有多少是重合的部分？兩者分別的職業發展方向有什麼不同？

後台中邏輯，前台偏體驗，設計思路都應該是一樣，未來的職業發展不僅僅跟目前實際工作有關，而且跟日後所遇到機遇+眼界+未來公司業務密切相關，如果單純從工作上看不同，前者可以去當項目經理··

後端產品是什麼？

產品經理這個詞，可以以很多種形式進行分類。個人的觀點是對產品的設計規划到具體實施的整個生命周期和價值的實現負責的人就是產品經理。一個完善龐大體系下的產品的產品經理就是CEO本身；而互聯網上單獨一個可獨立運轉的模塊其實也構成一個產品，其背後的產品經理可能是產品人員、運營人員、技術人員或設計人員。

無論如何，體系中總會有一個人主導完成工作並明確整個工作需要達到的關鍵方法和成果，同時起到了開發者和使用者溝通的橋樑作用，我一般就把他叫做產品。

今天要說的不是被大家用各種場景思維、用戶體驗、用戶價值、運營轉化各種轟炸已經概念泛濫的前端產品經理（先為前端產品經理經常被當作UI默哀三分鐘），而是一般默默躲在伺服器後端，每次都拿出一堆別說用戶不理解，老闆也很少細看的文檔的後端產品經理（為後端產品經理和項目經理經常混為一談默哀三分鐘）。嗯，有些時候由於To B業務一般都是後端產品經理的範圍，很多人也會把後端產品稱為B端產品。

前端產品經理的關鍵詞在於：用戶、場景、體驗、轉化、價值挖掘。在根據用戶和市場挖掘需求。

後端產品經理的關鍵詞在於：業務、邏輯、跨越、結構、控制、數據。在根據業務和發展規劃需求。

後端產品經理的價值在於什麼呢？舉個例子。像京東天貓這樣的電子商務網站，我們看到的商品背後涉及一整套的類目配置、商品錄入、上架、審核的各個業務流轉業務；每次搜索涉及整套的商品排序和展示策略；購買下單時涉及背後的庫存鎖定、抵用券的計算、支付介面的調用；而交易後的數據會同時統計到商家後台的數據已各種視圖顯示出來等等等...在用戶看來完成一個簡單的」購買「過程，在用戶互聯網上極致的交互操作背後，為保障其背後支撐的複雜的業務邏輯和業務結構順利運轉，還需要優秀的後端技術人員和產品經理的辛勤工作。

後端產品經理是整個後端業務需求的整理者，需要串起整個業務的前中後所有流程。後端業務往往並不像前端需求那樣簡單易於理解，而且會涉及信息輸入者、信息處理者、信息接收者、信息管理者出現完全不同的情況，這

要求後端產品經理的首要目標就是理解業務的全貌，能夠讓業務正確的運轉並對效果進行評估，能將充滿個性化理解與執行的業務過程通過與業務各端人員進行平衡和協調以確定標準化方案。

後端產品的一般特徵？

後端產品一般會具備下述一個或者幾個點需要進行設計與考慮：

1.業務流轉 - 多節點效率配合

業務會需要在不同的操作者、模塊、系統中流轉，複雜的業務流轉的梳理是產品經理一個最基礎也是最重要的工作之一。產品經理需要認真考慮如何將業務拆分為必要的節點，並正確設計好節點之間的關係。保障不好業務流轉，後台運營人員要罵娘加班，HR天天面臨人力壓力，技術天天手工寫資料庫。很多時候，除了技術之外，各角色之間的實際關係與作用也需要考慮在內。

2.管理配置 - 信息管理操作

後台對數據的標準化錄入、導入、狀態管理、數據修改等，核心在於通過後台操作影響前端的生成、展示、功能、活動、資源信息等。前端包括文字詳情、活動頁面、展示列表、價格參數等都是後台配置管理的範圍。配置後台在初期往往是交由開發者處理即可，但隨著系統關聯度的上升，功能之間的相關影響，運營操作效率對業務的影響，以及後台可能的開放過程，管理配置功能往往複雜類似矩陣化結構，需要一個優秀產品經理的把控。當然有些時候產品的修改反而會造成不利影響，因為主要操作者「已經習慣了」原有產品。

3.系統對接 - 內外數據交換

對接內部外部的不同系統，以各種形式包括爬取、導入、介面或服務形式傳輸數據。產品經理需要認真考慮系統與系統之間的關係，以及數據之間的同步和調用方式。與外部合作盤活生態是開放的互聯網必不可少的一部分。如果產品涉及業務夠複雜或是老闆談下的合作項目越大，就有越多的精力花在對接的梳理上，所以經常會在各種奇怪的對接會議上看到產品經理的角色存在。

4.演算法策略 - 數據轉化輸出

將數據重新進行處理輸出，常說的人工智慧、大數據也是其中一種應用方式。可應用範圍從滴滴的車單派送、百度的搜索引擎、qq每天的彈框廣告到信用徵信、人臉識別、垃圾郵件過濾都屬於計算機演算法的研究範圍。屬於互聯網產品中最講究技術的部門。如何能夠將前沿技術和實際的商業應用做結合，如何來評估演算法策略的在實際應用中目標和效果，如何利用技術優勢保持行業領先，是這個領域的程序員和產品經理最關注的事宜。

5.統計分析 - 業務價值挖掘

簡單來講就是將業務複雜的過程進行數據化的監控。可以是操作的數據日誌，可以是購物車每一層的轉化率，可以是某類目產品的訂單變化情況...需要將數據重新進行一些列的數據埋點、數據收集、數據清洗、數據挖掘、數據建模、數據可視化，以通過數據對業務進行分析、理解，並影響業務和工作的進展。最終的產物可能是一個excel，一個dashboard也可能是一個改變公司的數字。人員眾多的大型商業公司的可能會需要成立專門的BI部門負責，如果公司不大，很多時候還是需要一個產品經理結合業務來把控需求。

6.安全管控 - 數據保護

對整個後台系統進行管理，保障合適的人接觸和使用到合適的功能及數據，同時保證不要被一些弱智的設計導致數據錯亂、誤操作及安全泄露。包括賬號管理、許可權設計、流程式控制制、操作留痕、防呆設計、備份同步都屬於從安全可控角度考慮的範圍。有些時候業務會涉及很多資質類

哪些是後端產品

CRM、ERP、DSP、DMP、訂單、支付、爬蟲、搜索、精準化、活動、財務......

後端產品的核心關鍵詞

業務——後端產品經理推進的是整個業務環節的完成，不完成整個業務環節永遠得不到及格分數。

邏輯——複雜多方如何經過產品經理層層梳理找到最優化的標準化解決手段，需要處理紛繁錯雜的邏輯關係不出錯。

跨越——跨項目溝通、跨部門協調、跨公司交流、跨行業學習。

結構——系統結構，運營人員關係，各種複雜度、穩定性、擴展性都需要有序的模塊化的考慮進去，以達到最大效率的設計結果。

控制——開發周期可控、業務風險可控、實現手段可控、許可權可控、數據可控、流程可控、錯誤可控。

數據——後端的核心輸出圍繞就是數據

後端產品的項目工作流

認知-&>關聯-&>重構-&>執行-&>修正

認知——通過文檔、溝通、學習等各種方式了解業務、了解業務背後的邏輯、了解業務執行的人的痛點和利益點、了解原有系統關係和關鍵點、了解項目的資源和時間期望等，收集項目資料與行業知識。

關聯——將資料進行重新整理，勾畫出各條關係結構與流程，整理關鍵的要素與信息，獲取相關的資源支持，掌控可控資源。

重構——將信息、要素、資源進行重新整合，設計出系統架構並拆分填充細節，確認核心功能點與迭代計劃。

執行——推進項目的立項、方案的確立與資源的到位，進行項目的開發。

修正——對項目結果進行評估，將執行結果要素重新整合進入下一期工作流。

後端產品經理的核心能力

業務把控能力/全局把控

溝通交流能力/資源整合

技術知識經驗/可行判斷

邏輯整合能力/思考設計

項目管理能力/執行推動

後端產品的常用工具

VISIO——用例圖、流程圖、泳道圖、時序圖......在讓別人弄清楚之前，先讓自己弄清楚複雜的關係吧。

Xmind（其他腦圖亦可）——發散一下腦洞，把需要關聯的事務都放上去重新整理好。

EXCEL——真的需要把細項像矩陣一樣樣列出來，你看數據也經常要用的。

WORD——嗯，你需要寫的各種PRD、功能說明、介面關係、圖都在這邊。

資料庫查詢——你都能查的出來的東西技術就只有開發量沒有難度。

AXURE（其他原型工具亦可）——讓操作符合人性

PPT——和你的嘴一樣是對老闆神器

郵件、微信、QQ——找人學習、找人對接、找人交流、找人幹活、找人開會。

這個問題我有相當完整的經驗，有一定的發言權。

做後台產品經理，主要解決的是，如何提高內部運營的效率。

內部運營效率為什麼不高呢。原因有以下幾個：

1.沒有人梳理，各部門怎麼舒服怎麼來，導致整體流程不通暢；

2.有流程，不合理不規範或者沒有按照最理想的狀態運行；

3.系統邏輯不對或者不好用，業務部門不願意用；

4.由於業務快速擴張導致的混亂；

5.由於人員快速擴張，原來的系統不支持多人、多線程、接力操作或者分段操作。

所以，做後台產品經理，要關注的是內部運營，在這個過程思考業務流程，思考產品思路，思考結構，鍛煉自己的溝通能力。

如果一定要說職業方向，後台產品更像是老黃牛，你的工作的效率可以通過數據來表達結果：經過你的努力，業務運行效率提高了多少，原來多少時間做的現在只要幾分鐘就做完了。

你做得好，可以做項目經理，做COO。

前台產品經理，面向的大眾的普通用戶，職業路子會廣很多，但是挫敗感會更多，原因如下：

1.大多數產品經理的大多數產品都是垃圾，抄襲，模仿，最後面臨下線或者停止運營。

2.你有99%的可能終生沒有機會做出偉大的產品，也抄不出來偉大的產品；

3.你要跟老闆、技術、設計、運營各個部門吵，討論，四處將就。

4.你得創業才能成就自己。

當然這個過程也會有巨大的成就感，特別是看著用戶蹭蹭蹭地漲。

前台產品經理的職業方向更像CEO，啥事都要管，啥事都要擔責任。

最近正在做這個角色，說說我的想法。

什麼是後端產品

這個概念的界定其實因人而異，因產品而已，因公司而已。後端產品我認為是產品形態以後端的形式來體現，沒有前端體現，或者不重視前端交互的產品。如果思考一下，可以發現有以下一些產品後端產品：

- 產品的介面。介面完全是由後端代碼實現，用於服務前端的web或app；有一些介面直接面向客戶，更加應該劃為後端產品；有一些微服務間的介面，或者部門間服務的介面，也可以視作這個範疇。

- 面向運營或運維的系統。例如公司運維需求使用的流量帶寬監控，機器負載監控；運營需要的，收入支出系統，客戶轉化率，客戶留存等等。

- 內部使用的工具系統。例如，公司內部研發的提升流程效率的工具（類似jira之類的），持續集成與持續交付所需的協作平台。

後端產品經理為什麼這麼少

從上面分析出來的幾類產品來看，可以看出為什麼後端產品經理這麼少。

- 職責與研發經理（或者負責人，或者架構師）有重合。在設計介面上，一般研發或者研發經理就可以給出介面文檔了。如果他們經驗豐富還好，如果經驗不足可能會導致介面設計的一些問題，例如通用性不足，介面鑒權漏洞，使用複雜度太高，容易導致性能問題，可能被攻擊等等。

- 有些產品由相關人員直接頂替了產品經理角色。比如內部系統，可能由內部推動該系統的人來負責產品設計了；比如運維繫統，現在說的devOPS就是在推動運維開發自己的系統，那當然也是由運維自己來設計了；比如運營系統，可能是公司的運營做了後端產品經理。

- 在公司規模較小時，看上去不需要後端產品經理。

後端產品經理要做什麼

實際上所有的工作與廣義的產品經理是一樣的，但是我覺得要注意以下幾點：

- 先弄清楚客戶是誰。例如，對外介面，客戶是真實客戶；但是運維繫統，客戶就是運維了。從正確的客戶那邊，才能收集到正確的需求。

- 學習與理解相關業務，不要意淫需求，也不要偏聽需求。後端產品與前端產品一個比較大的區別，是在於前端產品更重視引導客戶，而後端產品，客戶的需求已經很明確了。此時就要與多方進行溝通，理解業務，理解真實場景下的情況。

這裡舉兩個例子：

第一，我設計了一個機房帶寬監控系統，原本的設計是一個機房有一個交換機，採集上面的帶寬；但實際情況是，我們有兩個產品線，分別使用同一個交換機上的兩個出口，帶寬要分別採集；後來，我們又出現了一個機房多個交換機的情況。所以一開始的1對1的設計，是完全錯誤的。

第二，我設計了一個用戶成本核算的運營系統，原設計是將每個月一個用戶的用量上升，下降，新增用戶，流失用戶展示出來。但後來我們發現，用戶用量上升可能是被攻擊，用量下降可能是有流失風險，需要及時告警以通知運維和銷售。所以實際上展示是一方面，告警系統是另一個很重要的東西。

- 依舊需要有原型圖能力。說實話，沒有原型圖很難表明自己的意圖；同時後端產品也需要展示和交互的。

後端產品經理的職業發展

我覺得後端產品經理的職業發展道路，是比較難的。

在小規模公司，這個崗位不可能是專職設立的。

在大一些的公司，這個崗位職能可能被其他角色所瓜分。比如前面提到的，運維自己做運維繫統的產品經理，運營做運營系統的產品經理，研發設計對外的介面，等等。如果他們頂替產品經理，事實上，這些角色如果有產品思維和能力就還好，如果沒有則是很大的悲劇。

我也認為，後端產品經理自身最終應該落地在某個專職領域。例如，專註設計devOPS平台，專註成為業務運營專家等。沒有相應的專業領域知識，是無法體現出專業優勢的。

所以後端產品經理的後期發展可能是，某種框架或平台的專家，某個領域的業務專家。另外，後端產品實際更加能夠洞悉公司內部的結構和業務，也適合出來創業。

以上。

這兩者的工作從產品的角度來說沒什麼不同，要說不同只是用戶群體的不一樣，後台多數提供給運營或者業務較強的用戶使用，以實用性為主。前端多數面向大眾或特定群體用戶使用，以易用性為主，注重場景。

硬要說和職業發展扯上關係，取決於你自己的邏輯思維而已！

可能不是很恰當，但是可以意會一下。

前端產品相當於化妝的，而後端產品經理類似醫生。

所以搞前端的需要了解當前流行妝容，大眾的審美習慣，以及各種化妝工具及用法。

而搞後端的更多需要了解其核心工作原理，且需要對症下藥。