後台產品經理與前端產品經理？

01-05

我在視頻公司做產品經理已經1年了，發現對技術還是了解較少，所以準備轉戰做做後台產品經理豐富自己的技術相關，然後再來做前端產品，這樣ok嗎？對自己以後做前端產品有幫助嗎？如果以後換了家不是視頻的公司，後台肯定不一樣，能觸類旁通嗎

作為一個基本啥都做過的產品經理來稍微說一下後端產品的事情。

後端產品是什麼？

產品經理這個詞，可以以很多種形式進行分類。個人的觀點是對產品的設計規划到具體實施的整個生命周期和價值的實現負責的人就是產品經理。一個完善龐大體系下的產品的產品經理就是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、功能說明、介面關係、圖都在這邊。

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

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

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

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

利益相關。原樂視網媒資資料庫及用戶中心工線後台產品經理，現職優酷主站負責各端播放頁及播放器。

其實我的回答是，對做前端產品沒有幫助。反而在你轉回前端的時候會發現一個更嚴重的問題，你會考慮開發成本多過用戶體驗。

其實我去樂視以前（實習階段）做的是一些開發工作，做過嵌入式，數據挖掘還做過伺服器運維。已經對一些基礎的網站常用知識點有了皮毛的認識。但是當我真正開始工作了之後，希望轉行至產品方向，得到的建議是：「做過開發想轉產品的話，建議從後台產品經理做起。」

因為實話說，從我的經驗來看，後台產品需要掌握的知識點綜合來說就是，在保證功能完善的情況下，提高開發便捷度以及盡量減小後期維護成本。因為後台的功能布局已經有很多成熟的模板，產品經理很容易就可以找到適合當前後台的模板，直接套嵌使用，而不需過多地擔心用戶體驗。即使需要重新開發功能界面，工作量也比前端產品小得多。

但技術難度方面，如果對前後端技術一點都不了解的話，開始會很難上手，而且和開發溝通起來會非常困難。在這個反覆的過程中會非常打擊題主的自信心，並且其實即便學習了後台的一些簡單開發邏輯，日後也很難應用到前端產品的實踐上。

前端產品則不同，前端產品經理在推動需求的時候需要考慮的用戶體驗成本遠遠要比後台產品大得多，如果依然帶著後台產品的思維模式，很容易就會陷入「這個功能這麼難做，也提升不了多少體驗嘛，不如不做噻……」這個死循環當中，比如我。

所以我的建議是，如果題主深知自己在技術方面的薄弱點，可以從幾個平時可以接觸到的點開始學習。（因為好像看上去題主的目標最終還是做前端產品嘛）視頻網站的技術有很多大塊，界面開發，前端開發，播放，播控，P2P……先從感興趣的開始找個平時需求不太多的實習生或者新員工好好學習，或者下班之後請該塊負責的技術大牛吃吃飯……遠遠比兩眼一抹黑一頭扎到後台做產品好的多……

我自己負責的產品線主要以後端為主，我覺得沒什麼必要。技術相關的知識對做前段產品沒有直接的幫助。很多前端產品經理都搞不清楚後台服務的邏輯，設計出來的文檔很多時候會被開發挑出很多毛病。我認為這並非他們缺乏技術知識，而是單純的自己功課做的不足。如果你是想更好的設計前端產品，可以通過閱讀其他產品線（後端）的PRD來了解。當然前提是其他pm寫的文檔ok。

我認為設計產品需要分清楚平台和業務，不要耦合在一起。平台是通用的，思路可借鑒。業務部分，無論是用戶產品還是商業產品，跨行業可以借鑒的不是太多。

個人覺得產品經理對技術的了解不是用前端和後端來區分的。前端更注重交互，功能，用戶使用場景和用戶體更多驗服務於C端。而後端則要考慮功能的完整性，邏輯性以及模塊整體的無遺漏，更多服務於B端。

這裡並不是說做前端產品就不需要注重功能邏輯的完整性，而是做前端更注重於簡潔，考慮哪個點更是用戶想要的，更切合產品的商業目的。比如商城的前端一件商品的顯示，對用戶來說只需要展示商品圖，商品名稱，商品簡介，商品價格和購買按鈕就OK了，其他不重要的或不需要向用戶展示的東西隱藏進子頁面或者不展示給用戶看就可以了。但是對於後端要考慮的東西就多的多了，除了前端展示的以外還要包括商品的庫存，商品的ID，商品上架，商品下架等功能，以及使用這些功能對於前端和其他地方的影響都要考慮到，考慮全，否則會出問題。

從邏輯性來看，後端&>前端。從易用性來看前端&>後端。

但是對於前端的設計和考慮，個人覺得並不比後端簡單，相反要比後端複雜。

這裡就需要產品經理有較高的知識廣度和深度，前端的設計不僅僅要貼合商業目的，還要貼合用戶需求，考慮人性，要考慮變現途徑，要考慮用戶生命周期，產品生命周期。

一個按鈕位置放的不好都有可能造成損失，一個交互（小公司大多產品也也擔任交互職責。）設計的不好都要被開發噴，如果作為一個前端的產品經理對於主流的技術不了解，對於主流的軟體玩的不多，交互了解不多可能轉到後端去更無從適應。

當然後端對於技術了解會更深，了解的更細，甚至多數是項目經理出身，這些也是專業度的需求。但是作為一個前端的產品經理，對於技術這塊更多的是要靠多看多調查多泡泡論壇，而不是轉向後端。

還有就是，千萬不要在和開發對接的時候跟他們談技術，自己了解就OK了。

做後台需要的不是對技術的深入理解，而是對業務邏輯的深入理解。

如果題主只是為了了解更多的技術，那麼大可不必轉做後台，做後台可能你對技術接觸會更加的多，但是在前端上用處確實不大。

但是做後台產品能對你的邏輯能力有一個質的提升。產品經理把已有的業務模式「搬」到系統邏輯中，達到滿足業務發展或提升業務效率的目的，這對產品經理的邏輯能力是一個巨大的挑戰，設計的流程中在思考如何滿足新業務的前提下還需要考慮邏輯是否合理，數據如何傳遞，異常情況處理，是否與舊業務流程發生衝突，往後如何做拓展等等方面的問題。

扯遠了，回到題主的問題，想了解技術的話還不如好好花時間學學前端開發的技術。

不建議。我認為這種提升「技術理解能力」的方法是走彎路。

我沒有題主做產品經理的時間長，我自己曾經做過兩年後端開發，現在剛轉做產品經理3個月，目前在做技術營銷類產品經理（據說是傳說中的 growth hacker），to B 和 to C 、前端和後台的產品我都做過（因為 leader 說要把我直接扔到海里學游泳 [再見][微笑]）。就我自己淺薄的了解來談幾句。就我這短短的幾個月產品經理的經驗來看，to B 和 to C 是很不一樣的兩種產品，對於這兩種產品經理的能力要求也是有差別的。

2C 的產品可能更加註重用戶體驗以及商業目的比較重，然而 2B 的產品則是比較注重流程的邏輯性、使用人員的便捷性但是不講究美觀和體驗。怎麼說呢？在種田上面積累的農業經驗是比較少能用在養魚上面的。

如果題主覺得自己技術不夠的話，完全可以業餘時間自學一些編程，哪怕時間不夠自己看看技術書和文檔都可以達成產品經理所要求的技術能力。另外就是多和你的技術人員們溝通。一旦溝通能力 get，其實技術理解能力也不是要特彆強就可以搞定的，而且就我自己的經驗來看，和開發們溝通有一些時候就是一個磨合的事情。如果是為了產品設計得更合理，我覺得看看文檔就可以了。況且，更不要提後端的產品經理你應該也應聘不上的，這類產品經理一般需要有技術背景的。實際上，是懂技術--&>後台產品經理，不是後台產品經理--&>學習到技術；如果你不會技術則應該是後台產品經理--&>做出一坨後台產品--&>邊哭邊自學技術--&>做出好一點點的後台產品--&>循環前面步驟繼續自學。

再小提一句產品經理的職業規劃相關的見解，我認為產品經理應當在最初這幾年就確定自己適合做的產品風格，這不但包括選擇 2B OR 2C，還包括你擅長哪種產品——社交類、內容類、娛樂類……等等這一切對於每個人都是不同的，而你到底適合哪個不但是你的興趣所在，也是你曾經所有的經歷所造就的。

另外就是已經工作一年的產品經理，個人認為應該不再想著「怎樣提高技術能力」這種初級問題上面了，產品經理有更多更加重要的事情需要學習，技術這種事對於PM來說我覺得都應該是隨手來一發、很風輕雲淡的事情。作為一個曾經的程序員，我必須要告訴你知乎以及技術論壇上很多程序員抱怨產品經理不懂技術，不要被他們洗腦了，雖然懂技術重要但是絕對沒有重要到那個程度。

以前做c，後來做b，現在bc都做，應該還算有點資格不請自來。

最開始C入手，某大型電商做支付轉換。說白點就是做商詳往後購物車0.5（中間推薦頁）、購物車1（購物車列表頁）、購物車2（個人配送支付發票信息）、購物車3（支付）、購物車4（支付成功）。

購物車東西特殊，所有的改動都是和oms緊密相關的，oms就偏後台了。所以當時做c的時候，需要了解很多b的知識。

後來去了某大型旅遊ota公司做。。額，做一個事業部的支持。

支持包括該事業部產品的前台呈現訂單流程及erp支持等。基本bc都得做。

再後來去了某新興獨角獸公司（去之前不是），那真是客串了所有bc的產品線。

現在稍微安穩了點，開始專心做b。

明天更~

關於題主的問題，很多人提到過，而且本人親身體會過。前後台都做過一段時間。

就我的經歷來講（不喜勿噴啊。。），前端更重要的是交互效果和用戶體驗，良好的用戶體驗效果是一個產品成功不可缺少的一點，而且前端元素較多，考慮的更多是對人性的合理把握，當你的產品能讓客戶消耗最少的時間成本而達到最大的收益，那麼你的產品就是成功的。

對於後台來講，考慮更多的是整個系統的邏輯性，還要考慮按照技術的思維去開發，而且現在後台技術已經有很多成功的模板，很多時候直接嵌入，並不需要太多的研究。

就題主的情況，我不建議先去後台然後再轉回來。因為後台習慣了那種邏輯思維，再回前端，你會發現你考慮的成本問題會大於客戶體驗，這對前端設計來講是個災難。

而且對於專業知識來講，完全可以在論壇、貼吧、自購書籍等方式完善。

題主加油。

做產品其實是種方法論，重視方法論的培養在一個產品經理的成長中是很重要的。

雖然行業不同具體的業務邏輯會有些差別，但處理問題的思路大體是相通的，所以關鍵在於通過外在的事情提升做事的能力和方法。

至於技術，產品經理要不要懂技術，爭論已久https://www.zhihu.com/question/19554113/answer/152645172

個人意見你可以看一些技術的公眾號了解大概的思路，這樣有助於和開發相處，對接時也不至於過於被動，尤其小一點的公司，流程不是很完善，產品要推動項目，這時候技術懂得稍微多一些會比較主動些，倒是和你做前端後端產品關係不是很大，做後端邏輯思維倒是可以提高不少，這是真的。

做產品就是雜學一些，設計懂一些，技術了解一些，運營知道一些，推廣聽說過一些，這些東西主要在於平時留心，用心。

往根上說，產品經理這個工種其實是搞服務的（此處會心一笑）。

目前看應該經歷過三類

前台後台演算法，每一類都有不同的側重。尤其是前兩天看到了精準化演算法的prd後，瞬間就顛覆了我對prd的認知觀。

前端是給UI打個樣，後台是給開發打個樣

萬事萬物相生相融，最高的功夫是無招勝有招。放手干吧，別再擔心這個那個的。

最近一直在做後台產品，我覺得相比前端產品來說，後台產品顯得沒有那麼虛，會更加務實一些，對於產品經理業務上以及相關知識上的要求也要比前端產品更加明確。在最近的工作中，我總結了幾個後台產品的特點。

1.後台產品需求較為明確，但要求對業務更加熟悉

做後台產品，一般來說需求不會像C端那樣模糊，往往很多時候是不需要我們去做調研和分析，而是業務直接推進到需求。甚至對於一些為了配合前端所需要做的產品，比如CMS，需求會更加明確，即前端所需要配置的內容直接推到後台做相應內容即可。相對於C端產品面對用戶時需要分析用戶的行為，畫像，心理預期等等，後台產品對於這方面簡直少之又少。

但是，需求的明確並不代表需求的簡單。做後台產品，需要對業務內容十分的了解。因為後台產品的業務邏輯會更加的複雜，同時流程性會更強。大量的欄位堆積及繁瑣的操作都需要產品經理去思考，將整個流程梳理清楚。在當前操作下哪個欄位需要保留或者去除；這條記錄的狀態會流轉到哪裡，出現什麼樣的情況；閾值情況下會產生什麼，如果有前端頁面，所對應的前端頁面是否會受到影響；一個頁面的那麼多操作會不會有衝突的地方；這些都需要建立在產品經理對業務的足夠熟練上。產品經理必須得將整個業務流程了解透徹，才能在出現問題的情況下及時解決，減少錯誤的發生。

2.後台產品欄位需要整理甄別

前文也提到了，後台產品的好多頁面往往是以列表形式，表格形式出現的，所以這一定會涉及到大量的欄位與數據。我們之前做過一個ERP系統，幾乎每一個一級二級頁面的都是以列表的形式展示的，所以欄位大概會有二十多個，並且每一條數據都會涉及到。

這個時候，如何有效的甄別欄位，讓之後的操作人員用起來不會覺得繁瑣、東西很多同時又能滿足業務需要就比較考驗產品經理了。甄別欄位，第一步就是從業務方面去推動。在ERP系統裡面，統一屬性的頁面（比如商品頁面）索引列表的欄位所需要的信息大致是相同的，比如供應商，訂單號，商品名稱，商品圖片等可以辨別商品的信息，然後不同的列表再加上這個列表相關的信息即可。但是商品信息所涉及的欄位也特別多，所以產品經理在整理列商品屬性的欄位時，也要根據當前頁面的業務選取適合這個頁面的屬性。比如在進行庫存檔點的時候，我需要了解的欄位是商品庫存，商品規格，商品圖片等，這個時候供應商等欄位就不是很必要。而進行商品入庫操作的時候，供應商又是必不可少的欄位。

所以在我們做後台產產品的時候，不要只是將欄位粘貼複製到需要的地方就好了，這樣雖然不會遺忘出錯，但是會使你的系統更加臃腫，難以使用。

3.後台產品需要用共通的東西串接

最近在做一個關於合同相關的系統，有之前的一套老系統作為參考。看到了之前的系統特別的繁雜，所有的東西都是在一個層級全部鋪開去操作的。合同在不同的流程階段有不同的狀態，可奇葩的是這套系統並沒有一個流程的概念，所有需要流程轉化的地方都是通過合同號等相關信息去檢索，然後與之前的狀態並無相關再另外新開一條記錄來進行操作的。這無疑加大了操作者的工作量，同時誤操作的幾率也大大增加，可能會出現一個合同有多個狀態的情況，同時當操作者想要檢索該合同時，不同的狀態下都有記錄，還需要他自己去辨別。所以當操作者第一次操作這個系統的時候，一定會很懵逼。

但其實這個系統是有可以進行串接的東西的，即合同的狀態，那麼上述的所有操作流程完全可以基於合同的一個狀態流轉去進行。這樣，所有的操作都會變成有序的，流程清晰且不同的操作路徑都是唯一的，一是可以簡化操作流程同時也不會出現上述的種種情況。

我們在做後台系統的時候，不同的板塊往往由於業務原因很多時候都是可以關聯的。如果可以關聯的操作，我們在沒有特殊情況下完全可以讓它進行關聯。一方面，關聯操作可以讓操作者的工作量減少，如果有相關的欄位可以直接帶過來而不需要手動去輸，這樣也可以減少誤操作。另一方面，對於唯一性的操作尤其是狀態流轉的這種操作直接關聯操作可以極大的減少錯誤頻率。

4.後台產品邏輯性會非常強

後台產品的邏輯性相對來說邏輯性會更強一些。因為後台會涉及到大量的數據處理，並且不同的數據進行不同的操作會產生不同的結果。各種限制條件等等也是在後台進行設置的，在不同的情景下所要涉及到的業務內容一般也會有不同。比如在用CMS配置前端頁面的時候，用戶端所看到的可能只是一個限時搶購的頁面，但是後台配置的時候，我們在考慮到最基本的時間限制條件之外，還要考慮到這個活動與其他活動發生衝突的時候怎麼辦，進行限時搶購的商品能不能進行下架處理，開始時無庫存了此時要手動配置成什麼狀態等等許多可能前端用戶並沒考慮到的情況都需要在後台體現出來。

那麼，如何有效快速的理清複雜的後台邏輯呢？我認為對於一般有狀態流轉或比較標準的流程化後台可以從以下幾個步驟去著手考慮：①首先將所有流程先跑通一遍，不要去管其他發生的情況以及其他與主流程無關的跳轉。②在將這個流程整理出來之後，根據業務將其劃分為幾個模塊，每一個模塊作為一個單獨的流程進行內容的填充。③最後將一些在不同模塊之間有跳轉鏈接關係的副流程鏈接在一起。經過以上這幾個步驟，一個簡單流程的邏輯大致就可以理清楚了，然後不同業務組合到一起。

5.交互細節要求不會很高。

我們在做C端產品的時候，對用戶的感受特別看重，因為一些小小細節往往決定著你是否能在競品中勝出。但是後台產品的用戶對於這些細節並沒有特別在意。因為他們的最終夙願並不是希望這款產品用的有多麼爽，而是希望這款產品可以減少自己多少的勞動力，縮短了多少的工時，提高了多少的產出。所以在這個時候，產品的業務性就要比交互細節性更強。

當然，這並不是說後台產品的交互不重要，只是說對於細節方面不回要求很高，但是整體交互還是需要去認真思考的。比如這個按鈕應當放在什麼位置才能簡化操作，哪些地方需要著重處理給操作者以警示，這個操作是以彈窗的形式還是新頁面的形式去進行等等都是需要思考的交互方式。

所以一般在設計後台產品的時候，我們對於一些大的可以影響或者警示操作者的交互要比一些從心理方面出發的交互細節要更加註重。

6.相關知識的補充

其實對於後台產品來說，市面上好多成熟的系統都已經做的比較好了，並且大多數可以叫的上名字的系統（CRM,CMS,ERP等等）都長得大同小異。所以一個產品經理要了解你做的東西都是比較方便且目的性都會比其他產品強太多的。比如要在做一套ERP系統的時候，就可以去了解一下SAP公司的相關係統，這種前人經過無數次試驗的打磨出的優秀系統參考意義極佳。

===============2016年5月10日回答===============

一入後台深似海！

--------------Part 1-----------------

題主你以為這樣問就能瞞過人民群眾雪亮的眼睛么？表逗，我們大群眾已經知道你的問題隱含了以下幾個核心問題點：

1.如何評價前端產品經理？
2.如何評價後台產品經理？
3.現在自己從前轉後，有成之後強勢回歸前端，各位談談看法。

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

作為塵世間一個迷途小書生，在下見識有限工作也有限。在下也很怕麻煩，所以就算誤人子弟，為了避免麻煩，在下嚴格按照國家有關規定匿名了。手機碼字，還望汪涵。

我盡量保持中肯哈，受限見識，難免管中窺豹。

-------------問題1-------------

如何評價前端產品經理

優勢：前端產品經理往往重交互、界面、形態美學，往往較為擅長產品展示形態方面。很多後台還是人海戰術靠人工處理，但是毫無妨礙它的用戶激增和粘性增高的產品，往往就是有個好前端。

劣勢：社交、內容類產品還拉不開明顯劣勢，到商品類、資金類產品工作時。往往遇到最多的就是技術制肘。很可能你同一個界面多了一個欄位參數，技術就會提醒你，又大改業務介面和數據結構………你如果熟悉業務還好，不熟悉的話後面基本是技術主導的劇情。一面倒的劇情沒什麼好說了。

-------------------問題2------------------

如何評價後端產品經理

優勢：環境所逼練就的嚴密賬戶邏輯、業務邏輯、多模塊跨模塊的配套改造邏輯。===往往白頭髮很快多出來。一個邏輯往往經歷自己的百般蹂躪千般玩弄萬般打磨，才能有把握避免技術一邊倒的劇情。同時，比起前端產品經理，除了快速消化需求，還得提升需求設計的深度。你得想想業務後邊可能會出現幾種常見玩法，對應需要的後台能力。哦，別忘了要提醒開發做好後向兼容，免得下次推倒重來。

劣勢：去除前端產品經理華麗的技法，在溝通層面可能會稍微缺失。同時，容易過分較真，畢竟後端的設計更加強調關聯的邏輯，即使這條邏輯鏈還長過你的DNA鏈，後端的pm往往都要求自己要熟練。這固然不是什麼劣勢，但和前端pm一起站在老闆面前，老闆往往覺得前端的pm更加勞苦功高。老闆才不管這個界面可以花式玩法主要是後台強大架構支持。

下雨天，這答案有人看再把問題三的回應弄上來吧。

============2016年8月17日更新=================

-------------------------------問題3---------------------

題主前轉後再回歸====談談看法。
1、有必要前轉後，搞過後台尤其是搞過基礎能力的需求管理，產品經理可以拓展自己的深度。同一個功能用不同的技術來實現，比對各方案優劣，根據後續運營的方向規劃或者猜想，市場的走勢，用戶心智模型使用習慣等要素去選擇方案。當然不是說只有後台產品經理可以這麼做，前端產品經理也可以這樣做。只不過就必要性而論，前者較高於後者。

2、再回歸。路都是一步步走出來，一步一個腳印，走著走著也許你就不願意重新走回前端。類似的也有2C類產品經理轉成2B類，然後再走回2C類。這個沒有定勢。

===========以上是個人看法===========

===========以下是個人感想===========

這兩年「用戶體驗」這個詞已經不較於之前熱門流行。

用戶體驗是什麼？

可用、易用、好用、品牌、友好……這樣的形容詞你要是喜歡我能說一百幾十個。這些都是很主觀的指標。

你只需要記住：用戶體驗就是同維度一個功能的對比度。

跟你公司沒關係、跟你沒關係，跟用戶很有關係。前兩年，我看到那些用戶體驗為王的文章，字行里滿滿是「跪舔用戶哪怕吮癰舐痔」的主張，我都覺得噁心。

在那些論調看來用戶體驗主要和界面有關，字體字型大小顏色色彩基調……

極少人會覺得提高一下處理效率，多開一個業務能力，比起調調界面顏色字體更優於提升用戶體驗。是是是，我知道界面色調字體直觀。在基於自己系統的各種限制之下，把同一個功能對比度提高========我指的是讓別人做襯托的那種對比度，看得見的看不見的地方都儘力去做，這就很不錯了。

前端、後端恰恰基本上能夠構成一個互補之勢。一個讓你專註干界面的要素，一個讓你專註干後台的能力，好比跑步兩條腿，基本上腿長一致會優於長短腿。注意，我說的是基本上，不是絕對。我沒遇到過只做過前端沒接觸過後台但又可以在做前端的時候完美兼容後端的產品經理，或者是只做過後端沒接觸過前端但又可以在做後台的時候無暇面向前端的產品經理，即使如此，我也不否認存在少量這樣的鬼才。

為什麼扯這個呢？

行業和企業縱向、橫向對比都有差異性和共通性。前端和後端也一樣。這種挑戰其實不必過於擔心，試錯也是產品經理的一個權利，只是要珍惜把握試錯的機會。

就我個人而言，我建議你去嘗試一下後台產品經理。重新認識自己，重新定位自己。

經歷跟你有些相似，原來也是做前台產品經理的，後來進入金融行業做系統。（前台+後台）

很多2C的互聯網企業都是前台為主導，2B的大多數都是系統型產品。

這個問題主要看你對自己的定位是如何的？

我認為如果是互聯網產品經理，那麼前台產品經理會更加貼近，而後台的產品經理更像是技術型產品經理。

我曾經問之前接觸過的產品經理是否知道系統邊界、時序圖、涌道圖，發現無一知曉，前後台的工作性質差的還是很多的。

前台注重用戶體驗、交互設計；後台注重的邏輯性，功能的有效組織。

後台的系統就像一張嚴密的大網，更多的考量需產品經理如何編製這張網，而不考慮如何把它編的美觀易用。

所以關於第一個問題，從後台回到前台，是很難的，因為工作性質不同。

至於幫助，對你的邏輯思維能力會有很全面的提升，跟技術溝通也會簡單很多，可以自己權衡。

第三個問題：後台產品經理當然是負責後台的產品設計，怎麼變你說了算。但是同一行業的的後台肯定是有很多共性的，之前的經驗可以借鑒。

我是做後台產品的，後台產品最重要的是要理清楚事情的邏輯，以及每一個流程節點的各種可能性。

鄙人2015年畢業，先是做了前後台（主要偏向前端，因為後台很簡單），一個初創項目，自己從0到1，負責前後台，還做一些運營類的工作，起初對交互設計比較感興趣，所以做APP的交互設計十分開心。（興趣是最好的老師）。

後來又做了第二款APP，最近半年在一家大型IT公司，做後台產品經理。

背景介紹完了，言歸真正。

前端產品經理，主要偏向交互設計，以及場景設計，與運營端直接相關，比如運營說節假日了，希望做個有趣的H5，這個就需要產品經理和運營共同頭腦風暴了。可能成功了，運營的功勞，失敗了，產品背鍋。哈哈~又引申出一個產品經理必備能力，數據分析，可以通過各種第三方平台或者自己公司產品線有對應的後台數據分析。

後台產品經理，注重邏輯思維，將業務流程轉化為邏輯流程（產出visio腦圖、流程圖）。

產品經理共性：

1、邏輯能力

雖然有點廢話哈。不管前台還是後台，都是需要去思考設計邏輯的，只是前端更偏向於場景化。

2、項目管理能力

這個比較重要，一般來說一個產品的從需求調研到產品設計開發上線以及後續的跟蹤調查，都是需要PM（產品經理/項目經理）去推動的，除非是特別大型的團隊，有專門的項目經理。

3、溝通表達能力

輸出PRD、PPT，要能讓業務部門、開發、boss都能看懂。

在過方案、需求評審以及開發過程中一些資源互斥等情況引起的糾紛等，都是需要產品經理去協調，推進，最終的目的就是產品按時上線，並且為公司帶來收益。

感覺後端產品更注重邏輯，前端產品更注重對用戶的體驗，交互設計等等的要求會更高吧。

前端和後台產品需要的能力差別很大，看個人偏好和對自己未來的規劃。

不過現在市場對前端產品的需求更大些，而且個人預測未來市場對後台的需求會越來越少，基於場景化的前端產品以及平台級產品會更具競爭力。

前端產品需要幾個核心能力：

1、業務場景設計能力

2、用戶體驗和交互設計能力

3、基於數據分析的產品優化能力

後台產品需要的幾個核心能力：

1、業務場景抽象能力，基於各類場景抽象成相應的業務單元，並將業務單元組合形成可操作的業務功能

2、把握業務運營的痛點，後台產品面向的直接用戶更多是運營人員，必須要把握運營的痛點

3、項目管理能力，並不是說前端不需要項目管理能力，但是項目管理能力對後台產品來說要求更高，如何在稀缺資源、進度和需求間平衡。做過後台或平台產品的同學應該懂我意思。

其實樓主並不一定需要在前端和後台中做出抉擇，如果最終希望往前端走，其實平時多與後端和研發的同學溝通，相信後台的東西也是輕鬆掌握的，對產品經理來說應該具備這樣的學習能力。

後端比前端產品要求高但是後端產品出去找工作面很窄前端產品經理要了解市場比較多；後端要對供應商行業業務非常熟悉做過後端是個非常寶貴的經歷然後再做前端市場了解市場需求了解用戶明白怎麼產生想法到落地的過程需要的綜合素質非常多