如何做一個優秀的後台產品經理？優秀的後台產品經理有哪些？
類似電商後台、內容審核的後台產品都來說說吧。
先啰嗦下自己的經歷，自己曾經在噹噹網工作兩年做後台產品經理，目前在一家互聯網金融公司做app產品同時兼任後台產品，我一直想把自己在噹噹的兩年工作經歷總結一下，寫出來，分享給大家。一方面可以給一部分新人借鑒下自己的經歷，另外一方面，就是想好好總結下自己，剖析下自己。
第一部分：新人如何轉型成為一名後台產品經理
大學畢業之後在上海混跡近四年，沒什麼多大成就，之後來到北京成為一名北漂。網上投簡歷，找工作，鑒於之前工作經驗，多多少少有個大概方向，就是互聯網相關的工作，網上投遞的公司大大小小也有100多家吧，陸續接到的面試有將近20家，大公司去過京東、搜狐、三星，小公司亂七八糟一大堆。直到在面試過程中慢慢發現一個職業更適合我，那就是產品經理；對於產品經理我並不陌生，之前在遊戲公司工作時，公司就有產品經理，但那個產品經理其實是遊戲項目運營經理，主要負責一款遊戲的運營，和現在我從事的互聯網產品經理還是有本質差別的。
當我發現這個產品經理具體工作內容時，頓時很感興趣，之前在富士康工作時也具體做過這些執行的工作，主要就是用axure畫一些線框圖，當時公司的職位是產品策劃，並沒有專業的產品經理。總之，找到這個方向之後，心中頓時明白了很多，也有明確的方向，最後通過網上搜集資料，更加詳細的了解產品經理的具體工作和職責。一次機緣巧合接到噹噹的面試通知，心中小激動又擔心自己無法通過，懷著忐忑的心還是去面試了。和hr聊天還是比較輕鬆的，一個比我還小的妹子，畢竟自己也工作將近四年，溝通表達還是可以的。之後，和自己未來的上級面試，對產品的理解和看法都還不錯，也算通過；在之後，和當時負責交易組的高級產品經理面試，問了很多細節問題，還好我態度比較端正，當時還準備了一些自己畫的原型圖和競品分析，也許是這些打動了這位高級產品經理，也最終錄用了我。其中的廢話不多說了，因為最近也在面試招人，分享下自己當時能順利入職的心得吧。1、極度的渴望心理（當你極度渴望成為一件事情時，你就會調動自己全身的能量去朝這個方向努力）。如果這個人對這份工作無所謂，只是當作一個工作而已，那對不起，你沒有熱氣和激情，你很難能發揮的更好。2、盡自己所能，做好充分的準備（當我明確產品經理的方向後，我不在面試採購、銷售、運營的崗位，而是全心投入產品經理的面試準備中，最開始一次面試，我連prd都不知道具體英文代表什麼，非常慚愧，知道自己準備的還不夠，還不夠）3、表現出你的熱情（和第一條有點類似，極度渴望的心裡會讓你積極努力，而你外在表現出的熱情就來源這種內心的渴望，面試你的人會感受到這種熱情，這種態度）4、溝通表達要合理（自己當時不是職場新手，所以溝通表達能力沒多大問題，說話方式和語調都要表現的職業化一點）最後，雖讓我離開噹噹了，雖然很多人抱怨噹噹，雖然很多外界對噹噹質疑，但我只想說感恩，真的是感恩。第二部分：我負責的第一個項目如何開展工作的當我正式入職噹噹之後，才發現產品經理的工作比我想像的要複雜要難的多。我入職前兩個月，沒有專門帶過大項目，連中等的項目都沒有負責過，只是參與，為什麼呢？
1、整個業務流程很複雜，我在沒有對整個業務流程熟悉的情況下，自己負責獨立的項目會出問題，領導也不放心。我簡單說下為什麼複雜，先從人事上說起，噹噹有60多個產品經理，200多個研發，70多個測試，60多個運維，10多個ued成員。光研發就大大小小的組分了十幾個，你要熟悉這些研發組的人員，他們具體負責的事情，要能找到相應的人，這需要時間同時也需要技巧。2、對整個項目流程不熟悉，不清楚需求如何建立，如何分析，如何內部評審，如何外部評審，prd要寫到什麼樣的程度...等等。總之，因為噹噹的管理還是比較規範的，所以才需要了解那麼多的流程規範，也就是說不能在短期內完全負責一個項目。重點來了，我是如何獨立負責自己的第一個項目呢？首先，我已經知道對應的開發和對應的測試是誰，然後寫產品方案並不算難，但是要寫出符合領導要求的產品方案還是比較難的，就去模仿，去學習，找領導諮詢，最後也能搞定。其次，在研發過程中，會遇到一些溝通的問題，那就多跑跑腿，電話溝通麻煩。在然後就是產品要上線驗收，自己怎麼弄，不知道如何驗收，就厚著臉皮問測試姑娘，配置host，資料庫，建立測試帳號。再然後，就是自己看測試用例，自己寫測試用例，讓測試同事幫忙造數據，自己去體驗用戶流程，涉及到一些技術邏輯，自己去查找資料庫，修改數據，學習簡單的sql語言。就這樣，在一個個小的項目中去學會如何溝通，知道對應的上下游流程在哪裡，對應的人在哪裡，對應的系統架構在哪裡。這些開始的經歷，還不足以讓我勝任一個合格的後台產品經理，先總結下一個新人該如何快速適應大公司的流程里，如何快速上手產品經理崗位。1、快速掌握自己負責的產品線所有的業務知識和流程。（知道目標用戶是誰吧，知道如何操作吧，知道上一步在哪裡，下一步又到哪裡吧）。2、了解和你相關的產品業務線、對應的產品經理、對應的開發組、測試組。3、快速掌握整個產品工作流程。每一步要輸出什麼文檔？顆粒度要精細到什麼程度？如何發起會議？寫會議紀要？召開會議？
升級版：當我以現在角度去看待這段成長過程中，我覺得自己成長的還是太慢了，太低效了，如何更短時間掌握這些東西，又不會出錯。1、用表格把公司的組織架構梳理出來。- 公司各個部門組織什麼，對應的leader是誰。
- 產品研發部門各個部門成員和leader，以及他們對應的工作內容和所負責的事務。
- 記錄他們的聯繫方式：qq、姓名、職位、郵箱、手機。（相信我，越詳細越好，對你以後的工作開展會大大提高效率）
2、用筆記記錄下來整個公司的工作流程、產品研發流程、甚至一些小的管理規範。
- 產品工作流程怎樣的，具體各個節點該做什麼，和別的公司有無差別。（需求收集、產品設計、產品評審、立項、排期、研發評審、研發階段、用例評審、測試階段、准生產環境、產品驗收、線上環境）。
- 固定會議時間，每周周會、部門例會、小組會議、業務會議等等。
- 如何組織會議、邀請成員、使用wiki、一些工作流程的東西。
3、熟悉掌握你所負責或參與的產品線。
- 業務流程要自己多試試幾遍，然後畫出流程圖，或者收集相關的資料備份下來。
- 要整理一張數據表結構，知道一些關鍵數據的狀態和標示，比如：訂單狀態有多少種，分別有哪些前置和後置條件。
- 其他類似產品架構圖、數據狀態圖、過往的項目資料、研發資料等等。
2、了解別人：後台產品經理對需求的把控往往來源公司內部，要切深去了解目標客戶部門的業務流程，才能發現其中的痛點，而不是盲目的自己去想產品方案。在強調一次，一定要親自體驗業務部門流程，針對他們提出的需求進行分析，找到需求背後的本質需求。
3、深挖方案：產品方案設計，第一步肯定是自己負責產品內部的方案設計，如何運行，如何運轉；4、影響邊界：另外非常重要的一點，就是要分析出所有可能影響到的產品線，哪怕一個細小的功能，都要進行這樣的分析，動一發而牽全身，在電商行業公司是經常有的。5、項目管控：一個大型的項目涉及到的里程碑太多，任何一個環節溝通不到位，出了問題就有可能導致整個項目delay。6、提前通知：這個最容易留坑，很多人修改了需求，邏輯活著某個數據節點，沒有及時通知其他人，這就導致最後上線出現bug，也會造成責任的推諉7、反覆驗證：項目上線了可不是萬事大吉，往往很多產品經理淪落為功能產品就是因為做完就撒手不管了，認為自己完成了。而其實呢，你做的真正滿足用戶的需求了嗎，還有需要改進的嗎，這些如果不仔細驗證，很容易陷入一種做的很多，對的很少。8、及時總結：和第七條差不多，總結包含項目總結，數據總結，功能驗證等等，哪怕其中一個小錯誤也要及時總結，發現問題，及時修正；在進入下個項目時就能避免類似的錯誤發生，這是自我提高最好的辦法，就是多多總結。只能拋磚引玉兩句電商方面的首先做優秀的後台產品經理，那基本知識應該知道：
- 用戶管理（即CRM，針對用戶應該關聯哪些信息）
- 類目管理（除基本的導航外還涉及屬性管理等）
- 庫存管理（sku spu概念要清楚採購、售賣過程中這些基本單元的狀態如何變化）
- 訂單管理（涉及訂單狀態流轉，基本應該有多少步，哪步會涉及到關聯庫存，庫存狀態隨之變化，以及哪部應由誰來操作，進而引出後台許可權管理）
- 許可權管理（後台哪些角色可以查看、操作哪些信息）
- 其他（諸如網站促銷系統（很複雜不詳述了），專題CMS系統，操作人員本身的操作日誌數據後續可擴展為KPI基礎數據等等）
如果要達到優秀水平，從個人理解來說：
- 功能的可擴展性—能預估出當前整體業務前景，從而在設計功能過程中確保可擴展性，有步驟的推進功能
- 數據挖掘—本部分可以分為兩點：
- 後台產品不僅僅是支持類的工作，由於整體把控著網站的業務流轉，所以若發展到一定量級，需要了解有哪些關鍵實時數據可以反映特定環節業務運轉是否健康，即可以通過數據第一時間定位可能發生的問題
- 可以通過後台銷售、採購、用戶方面數據深入挖掘（或至少了解數據價值），分析優化現有方案策略或進而發現新的增長點影響業務
經驗有限，水平一般…沒說清楚或有問題的地方歡迎指正交流：）
- 後端產品是什麼？
產品經理這個詞，可以以很多種形式進行分類。個人的觀點是對產品的設計規划到具體實施的整個生命周期和價值的實現負責的人就是產品經理。一個完善龐大體系下的產品的產品經理就是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——找人學習、找人對接、找人交流、找人幹活、找人開會。
去查一下領域設計吧，其他的就不多說了
竟然有人邀請我……謝 @cent VIN 邀。
十分謝謝了，謝謝這份看得起。目前仍覺得自己懂的東西很少，做事情還有太多不足之處。
不知道什麼時候有底氣再回來更新回答。共勉吧。答主目前在線旅遊企業，部門日支付訂單30萬，日流水6000萬，後端技術經理，負責客服系統，在線諮詢系統，財務系統，BI，報表系統，參與訂單系統設計，負責的工作內容原來的產品走了快1年了，也兼職了產品的工作。
一般想做後端產品的同學邏輯和理解能力都不會弱，一個新業務聽業務方描述一遍，大致的業務流程圖肯定需要能畫得出來，優秀的後端產品不是完全按照業務方描述的去畫，而是可以根據你的經驗去優化業務方的流程。
後端產品的溝通能力必須要強，因為你需要平衡客戶需求與開發的矛盾，把業務方的需求翻譯成技術能聽懂的話，把技術方的困難描述給業務方聽，努力做一個大家都喜歡的人，因為你很多時間需要去說服別人接受一個對誰都不完美的方案。
後端產品會收到很多瑣碎的需求，所以你需要有條理性，平衡開發資源與需求的緊迫程度，併合理安排你的資源。
後端產品必須主動，主動與系統使用方溝通，了解使用方的困難與業務後續發展規劃，提前設計你的系統，最好參與到資料庫設計中去，以便提高你的系統擴展性。
後端產品同樣需要對數據敏感，與前端不同，他們關注轉化率，你需要關注你的庫存波動，訂單完成率，客人售後服務請求的完成率，財務收入波動，應收應付與實收實付是否有異常等等，數字的異常可能會讓你及時發現系統的問題，進行修改。
最後，後端的產品需要一顆強大的內心，你作為一個支撐方，可能看到前端很風光，單量的增長，轉化率的提升，不要羨慕，做好自己的事。
雖然你的重要程度可能是在你準備離去時才體現，但你做的系統可能會陪伴你的公司很久，後端系統同樣一個方案，不同人推進完全是不同的效果。兩年後你再和你以前的同事聊起，你會發現，他們用的還是你曾經設計的那套產品。
最後，後端產品拼的是經驗，你曾不知所措，你將久病成醫。我從我期望合作的後台產品經理的角度，回答下這個問題吧，給大家參考。1.後台產品經理職位多是為了解決業務問題而設立的。這就決定了後台產品經理的職責是解決問題，而不是創造體驗。他需要掌握和業務人員溝通的方法，以獲得深入的，正確的，全面的信息。2.後台產品經理應該可以把獲得的信息，抽象成業務流程，並基於有效的業務流程完成產品設計。3.後台產品經理應該具有一定研發知識，最起碼能夠堅定的知道自己的設計可做，否則會被研發支的，北都找不到。如果能做到以上幾點，我就會認為他是一個優秀的後台產品經理。至於具體的業務流程，其實說實話，就算電商，這家和那家，也會有較大不同，有經驗是好事，但是很難照搬的。
1.理解業務邏輯，系統的思考後台的產品框架,思考各個菜單頁面滿足了什麼需求，給用戶（一般是運營，客服，財務）帶來什麼價值。
2.滿足需求後，操作是否便捷（如批量操作，導入導出功能)3.報表數據是否準確，哪些需要數據需實時查詢。其實後台產品在某些程度更考產品功力，除了在Ui和一些體驗層面可以不用太高要求，其他要求都不算低。呃。。。嘗試著去回答一下樓主的問題
首先說下個人理解的「優秀」定義：
1、熟悉業務，這點無可厚非，如果在沒有熟悉業務的情況下即使在下的功能也會答非所問。在熟悉業務的同時還要了解一些財務和審計的一些基本常識，曾經看過一篇關於產品經理面試的題目，是要做一個登錄頁面，這裡先賣個關子，大家可以想下如果是你來做的話流程是什麼樣的。
2、文檔和工具軟體：本來打算把溝通放到第二點來介紹的，但是最近的一些項目經驗讓我發現其實一個邏輯清晰的PRD或者原型更有說服力。 一個產品經理產出的項目的文檔大概涉及 流程圖、功能圖、原型圖、PRD、操作手冊、如果沒有項目經理的情況下還要有一些例如待辦列表、排期計劃等文檔，每個文檔的用處就不一一細說了，一般情況來說這些文檔是要在項目開始之前就需要輸出的，在項目過程中的時候隨著需求的細化和迭代要及時維護產品文檔。當然，特殊情況會特殊對待；再來說下工具軟體，包括Axure、viso、xmind、雲筆記、ppt、excel、word等工具，建議樓主多熟悉axure等原型工具，只有熟悉了才能做好布局、交互等。
3、溝通能力：包括跟業務方的溝通、跟技術的溝通、跟項目經理的溝通、跟直接領導的溝通。跟業務方的溝通最多的時候是在了解需求，在對業務沒有十足把握的時候建議不要閉門造車（因為還有一句話是出門合轍），多去理解需求方的真實目的是什麼，有些比較有經驗的產品經理會在過程中直接跟需求方確定實現方案，但其實對我個人來說不太建議這樣， 我習慣的方式是：了解需求-&>評估方案-&>跟業務確認方案的可行性-&>N次迭代{修改方案-&>確認方案}。 跟技術的溝通要複雜一些，首先你要了解點技術，知其然即可，類似於資料庫、欄位、事務、鎖、前端、JS等等，要確保跟技術在聊方案的時候是在同一個頻道上，我不太認為技術會騙產品開發的難易程度，除非個人恩怨（呵呵），對於個人來說我想看到的是產品和技術站在一個良性的對立面，大家對於同一件事「共同」找尋一個最好的解決方案，千萬不要讓產品或者技術一家獨大。當然溝通過程中產品經理可以適當的賣一些人情給技術，認定他們的方案，當然是在不違反大原則和業務事實的基礎上。
4、數據分析能力：有些產品經理在上線之後就不太關注項目了， 但其實我更習慣於看一些主要數據，會發現一些交互的邏輯頁面的展示邏輯等有很大的改善空間。 通過分析整體的數據可以知道會不會有一些風險，可以了解點更多的項目情況，可以有助於確定更進一步的發展方向，曾經我在看數據的時候發現一個小的邏輯錯誤，然後推導出有更大的風險存在，結果是追回了差不多20w的損失。
先寫到這， 要去開會了。最後說一點，我們在項目的實施過程中一定要清楚業務干係人的習慣和其工作動向，因為系統的驗收、系統的使用、系統的發展都受業務干係人的思維影響。 我們經常注意到如果需求方有離職的動向的時候，他的需求的優先順序就會被降低。
我的一點個人心得。
1.後台產品經理需要對業務非常熟悉，了解業務的走向，還得清楚業務邊界，本次的方案對上下游的影響。
2.後台系統主要是為內部人員使用，比如運營，客服，財務等，在做項目時不能憑自己拍腦袋決定，需要使用人員一起討論，系統的易用性，複雜度需要控制。
3.可擴展性，不要只想到當前的場景，要想得長遠，不然你會不斷的重複做同一個需求。這一點需要經驗積累。
後台產品經理 要想做好， 一定要懂點財務
優秀的後台產品有美團周總@周強
後台產品應該更注重功能邏輯的完整，考慮清楚流程上的各種可能性了解各個數據流模塊，在保證功能完整的情況下儘可能提高開發敏捷度，這點上有點類似項目經理吧
我不想做後台，與職業發展不符。我是跟著大牛過來做事，只有後台系統安排給我了。雖然是一個人負責整塊，但是擔心之後的發展不好
現在大家都好懶，這種問題都不願意回答了。。
我是一個初級的後台產品經理，跟樓主同問，期待大牛！
推薦閱讀：
※如何搭建一個支撐大規模用戶的服務？
※C++ 後台開發面試時一般考察什麼？
※C++開發轉後台還是Android？
※應屆生做基礎架構適合加入大公司成熟的部門么？
※mac下python爬蟲亂碼問題?