1樓：
後端其實就是乙個支撐前端的體系，是看不到的工作力量在支撐這前端的發展，所以相比來說比較的辛苦，後端的業務也是比較的廣闊，所以說後端適合那些抗壓能力比較強或者是思維比較活躍的人群，你要是想要學習後端的產品經理知識建議你參加培訓通過自學或者是針對性的加強彌補才可以。
產品的培訓相對來說比較的靠譜，雖然後端的產品經理比較的辛苦而且工作量比較的大，但是兩者的工作內容基本上都是一樣的，你可以通過這種的方式去學習系統的產品經理專業知識，而且很多的培訓機構更加的注重業務的鍛鍊，所以彌補你的不足還是綽綽有餘的，產品的培訓比較靠譜的有海綿學堂的課程，課程相對來說還是很豐富，而且培訓出的學員當了別家機構的合夥人，所以實力就在那裡，明明白白的擺著，你可以通過這種的培訓方式去學習，但是更主要的目的就是有乙份能夠支撐自己的保障，只有參加了培訓，你才能夠知道它能夠帶給你的好處，並且能夠找到解決的辦法，提高自己已經是一件不容易的事情了。
產品的培訓能夠幫助你，但是你自己也是要上進的，只有兩者更好的結合，那麼才可以更好的掌握後端的產品專業知識內容。入門基本上都是一樣的方式，其實可以通過很多種的方式學習成長，這是最關鍵主要的。
產品經理培訓班_產品經理培訓_產品經理培訓機構-海綿學堂海綿之家-產品經理培訓機構|海綿學堂
2樓：球球聊B端
其實學B端產品，沒有看一本書，做乙個專案，學乙個軟體就能搞定的。
這個背後一整套的基礎學科訓練。
比如說：我之前就推薦過四五本管理類、經管類的書籍，加起來就有一兩千頁。然後軟體的、設計的經典書籍，僅軟體工程需求分析類的就有2000頁。
這都是屬於系統學習。但是，把這些書都看完了，其實還是挺難的。
只能說，出一些提煉知識後的課程，然後讓大家能夠速成一下，這個其實我不太贊成，但也沒辦法。課程在一定程度上就是速成。能幫你提煉出很多精華部分，幫助你打通思考脈絡，然後打通你的視野。
畢竟在一門課程裡邊，學很多本質的東西，其實你是學不完了。那我更希望的就是能建立好這個知識前後的框架，然後再去結合工作，去挑你需要關注的部分，深入去學習。可能這個更適合現代人的學習吧。
但是基於題主目前的情況，楊堃老師的《決勝B端》這本書還是不錯的，我之前就是看這本書入門的。聽說最近和起點學院出了門課程，但是基於你目前的情況好像有點不太適合，可以去了解一下
3樓：飛外天仙
這個可以回答下。後端卻是是乙個抽絲剝件達工作。
後端產品經理，就像夏天的風，平時低調，吹來的時候才覺舒爽。
他們處理著Excel或SQL，偶爾喃喃負手，彷彿運籌帷幄。
他們或在實施、業務、測試之間切換著角色，或默默坐在角落，修補著前任的坑。
他們佔據著後台、中颱或其他高地堡壘，無意長夜慢慢……相對與人工智慧、區塊鏈來說，後端產品是乙個不溫不火的增長趨勢。
一方面各個網際網路細分領域都離不開後端產品支撐，同時也是流量網際網路向後端需求出路的體現。
另一方面，在各種嘗試和風口之後，後端產品思維成了一種穩固深度網際網路資產的後盾。
越來越多的企業，尤其是大廠都明白：後端布局深遠，前端才能縱橫捭闔。
如果入門達話可以搜後端產品經理寶典這本書。
4樓：張胖子
之前在某互金網際網路公司實習，接觸過後端產品。
不同行業，不同業務方向，最開始還是要理解搞清楚那些從未接觸過的專有名詞。
平時工作過程中，更多的是對業務方的需求進行梳理，是否合理？需求還涉及到系統哪些業務邏輯的變更，會涉及哪些系統間的哪部分互動邏輯………………
將大白話的業務需求，通過後台產品經理對於業務的理解剖析能力，以及對於後台系統、系統間互動過程的了解程度，再加上對於系統設計層面的知識（有點偏技術，保證你的方案不會被技術懟的太狠）轉化成乙個個產品文件，乙個個系統互動的泳道圖……
因此，入坑必須跨過的門檻：
涉及的專業術語
系統的底層邏輯，已存在的業務邏輯
其他涉及的系統見的互動過程
多看其他競品，多體驗多問，多和前輩交流
5樓：趙天一
看到題主的描述，感覺有點像我工作第二年的經歷。
第一年在做客戶端，第二年跑去廣告做底層資料業務。
背景大概如此，那麼我有兩個建議思路，你可以考慮一下。
思路一：寫文件
寫文件的思路在於，嘗試著用自己的敘事方式，將業務的關鍵路徑理清。
首先，核心使用者群是外部的廣告主的開發同學
其次，核心的解決方案是API、SDK和JS方案
最後，由於資料會用於計算轉化成本和oCPA預估，重點要保證的是資料的可靠性和穩定性。
所以，我把舊的API文件、SDK文件和JS文件都重新寫了一遍，在這個過程中對業務算是基本了解了。
寫完文件一定記得多讀幾遍，多檢查一下，文件也會有BUG的
思路二：寫Wiki
這個思路來自一位運營同學的啟發，Kate同學有一次在當面諮詢我問題的時候，將答案記錄在了雲筆記上，我正好看到了她的雲筆記目錄，簡直就是一部百科全書。
雖然部門有自己的Wiki，但是自己構建這樣乙個結構化內容顯然需要對整個系統更深入的了解。構造這個體系的過程會比較痛苦，但是經過了大量思考和結構梳理，應該足夠掌握業務的基本邏輯了。
以上這兩種思路都是我覺得比較高效的途徑，但是是否適合個人，還需要題主自己嘗試一下。
6樓：我只想吃不胖
不知道題主現在處於什麼階段。本人也算是剛入門吧。
1.了解公司的業務邏輯。
2.利用測試環境，多跑跑流程。熟悉現在的系統流程。
3.看關於產品、專案管理的書，結合目前的狀況去看。
4.了解行業資訊，看看別人怎麼做的。
多交流。。。。
7樓：單純的改乙個暱稱
哈哈跟著 @劉錘 劉大大看到了這個問題，看題主的疑惑就好像看到了一年前的自己。大錘老師講的很好，看的我也忍不住來說幾句。
我相信大部分新入門的產品汪都跟我當時一樣，比較傾向於投身於使用者產品當中（其實我比較喜歡把這個叫做c端，商業方向叫做b端，不知道是否準確，本答就先這麼叫了=
=），一是我們平常所能接觸到的有關產品的介紹大都是通過c端產品展開的，二是我們每個人的產品使用經歷肯定也是c端產品為主。
所以，當我加到乙個餐飲收銀系統的專案時，我的內心其實是有些許拒絕的。一是感覺這個方向有點奇葩（跟同學一講，我做收銀機的~啊？？？ 都是這種。。
），二是餐飲收銀系統這東西的確是離我平常的生活有點遠，平常頂多看看客顯。最開始的一兩個禮拜也是一通矇逼（掛賬？簽單？
估清？光電掃碼槍？這tm都是啥。。
）我的boss應該也知道這種系統需要花些時間了解下，所以第乙個禮拜也沒給我什麼複雜的活兒，我就在這一周裡，閒了就抱著收銀機擺弄，不懂的地方就不停地抓著測試的妹子問這問那。
這一周的玩耍是有效的。等到第二週的時候，我已經能夠聽懂例會上大家講的東西了，並逐漸加入到工作當中去。
並且，隨著之後一次一次的迭代，新功能的上線，可用性的增強，看到整個專案在往正面的方向發展，並且幫助使用者解決了他們經營中的問題，真的是會發自內心的高興的，這種高興我想與做c端產品也是沒有區別的。
故事講到這裡吧，不太會講故事= = 我想告訴題主的是：
1、b端相對於c端，可能只是與你平常生活的環境稍微遠一些，需要你多花一些時間去了解他的工作環境及邏輯等等資訊，當你了解了這個生意的流程，之後的工作流程，與c端的產品區別就沒那麼大了，你看的使用者體驗的文章也會有很大的用處。包括我們後來做的公司財務系統，也是乙個道理，各種財務術語就夠外行記上一陣子了，但是，當你把需求了解到位後b端c端都是一樣的。
2、你已經很厲害了，實習就開始找這方面的工作了，我剛畢業的時候矇逼的不行，所以加油吧！
8樓：yaoyao
先說答案：從梳理業務流程入手，從分析業務邏輯入門。
多畫流程圖腦圖，直到你對公司的業務瞭如指掌，隨便把你按哪個業務崗，你都比同崗位的同事更精通業務。這樣，就算能勝任愉快了
9樓：楊水舟
其實後端比前端簡單很多，因為後端是基建，而前端要按照後端功能一步步做
我整理一下我做後端的經驗吧
1.乙個功能，n種操作，乙個操作，n種狀態，他就是前端的ul li a
2.狀態基本為三種：操作成功，操作失敗，操作中
3.接著去想不同狀態的所有結果，成功會怎樣？失敗會怎樣？操作中會怎樣？
3.用本子把1和2和3想到的所有東西，寫出來，接著，用3去對應2，用2去解決1
後端產品設計，就是把問題列出來，把問題榨乾，等到沒有問題的時候，從尾到頭去解答
最後要記得，解析乙個功能時，要把這個問題所觸碰到的範圍做乙個劃分
例如新增商品和商品管理，管理是管理，新增是新增，雖然有關聯，但是大體上是分開的，不要擴充套件的太大
產品經理應該如何正確取捨需求？
張鵬 最近面臨很多需求 如何正確的取捨，一直是乙個困擾我的問題。個人覺得，首先要有乙個堅定的內心，知道產品裡面最重要的是什麼。BOSS提了乙個需求，內心不堅定，估計你不好意思捨棄吧？面對一堆需求，都覺得挺有道理的，不區分孰輕孰重，那也無法捨掉需求。該去的都去了，該捨的都舍了，剩下的就是想要的。理清楚...
產品經理應該會程式設計嗎？
Song 有人說 網際網路公司最大的成本並不是人力成本，而是決策失誤帶來的無效研發。所以，產品經理只要把需求痛點搞清楚，就能為公司節省N多個程式設計師的錢。每乙個崗位之所以設立，都有它存在的理由，個人理解，產品經理存在的理由不是為了做出這個產品，而是為了保證這個產品的有效性。所以，會不會程式設計不重...
產品經理應該具備哪些能力和素質？
才聚PMP認證 如何才能成為乙個合格的產品經理？產品經理需要具備哪些素質?產品經理需要具備三個核心素質 個人素質 知識管理素質 核心能力素質。產品管理這個工作具有一定的特殊性，因此，在所有採用了產品管理體系的企業中，無一例外地對產品經理這個具體的 人 有了比其他崗位更為嚴格的素質和修養方面的要求，具...