Ⅰ 在IT和互聯網行業，產品經理是前端還是後端為什麼
我理解為：客服經理為前端！設計為後端支撐！說錯不噴！
產品經理既不屬於後端，也不屬於前端。
如果你的問題是指：產品經理是屬於前端研發人員，還是後端研發人員，那麼兩者都不是。因為嚴格來說，產品經理是屬於運營人員，在很多公司都歸屬於運營部門。
如果你的問題是指：產品經理是屬於前端銷售人員，還是後端研發人員，那麼答案也是同樣的：兩者都不是。
因為產品經理是溝通前端銷售人員，和後端研發人員的渠道。所以，你可以認為產品經理是前端和後端的中樞。
這個崗位需要把前端銷售人員接收到的用戶需求，轉換成具體的功能，在產品上實現。也需要把後端研發人員的能力，轉換成文檔或者其他材料，供前端銷售人員使用。
所以，產品經理既不屬於前端，也不屬於後端，而是兩者之間的中樞。
你好，謝謝你的邀請。產品經理，在互聯網行業，我感覺應該即使後端客戶經理，有事前端。產品經理負責從設計規劃到具體實施落地的整個生命周期和價值的。在一個物聯網企業一個產品經理其實就是企業的CEO；而互聯網方面一個可獨立運轉的子系統也可能構成一個產品，那麼她的產品經理可能是研發人員、銷售運營或者其他設計相關的人員。前端的工作主要在根據用戶和市場挖掘需求。後端的工作主要是根據業務和發展規劃需求。
當然在互聯網企業里有側重點，後端主要特點：梳理復雜的業務流轉、管理配置復雜類似矩陣化結構的功能、進行接內部外部的不同系統數據的對接、保持企業的產品技術優勢、對業務數據進行監與保護。
前端客戶經理主要特點：需求分析，完成產品設計、編寫產品需求文檔、和各方進行有效溝通、從初期的概念設計到上線後的數據分析和用戶反饋收集，不斷優化產品品質、推動項目開發進度、合理分配資源、有高效的時間管理策略和經驗等等
所以具體產品經理屬於前端還是後端，需要你個人的分析和公司需求策略決定！
這個前端、後端，如果是公司角度：
IT行業產品經理有可能屬於前端。類似售前的工作。
如果是技術角度：
產品經理分：前端、中台、後端、業務條線、全棧
產品經理要區分前端或後端，我們先從產品形態本身去看，傳統行業的產品偏於整套解決方案或軟體集成為多，要求產品經理技能傾向於解決行業問題，其中要參與較多產品方案中的技術方案的理解、研究與設計。而互聯網產品經理，獨立的商業模式，更多的to C 業務，導致產品形態區別於傳統行業，它更面向用戶與要實現的商業模式，產品的展現層需要更多的交互設計，雖然有很多產品經理配備了交互設計師，但交互仍是產品經理不可逾越的技能。
以上並非絕對，因為互聯網下一個時代也是向產業端發展，逐漸也形成了大量的解決方案，而另一方面傳統行業也在互聯網化，本身也孵化了大量的to C業務，所以傳統行業與互聯網行業在其軟體產品的結構是相互交織的。
前端與後端的定義也看公司怎麼定，不同公司有區別。
在我看來，此問題還是要回到產品經理的職能與工作職責，就是分析市場、定義產品、設計產品、迭代產品，趨向越來越好，實現產品的價值所在。所以，產品經理的深度應該是一個全棧產品經理，或者廣度理解是產品線產品負責人，就是前後都會。
1. 產品經理需要理解客戶的需求，需要不定期去和客戶交流，獲取對產品的意見和建議。需求調研和獲取階段，產品經理的角色屬於前端客戶溝通和落實需求的角色。
2.需求明確後，產品經理需要在研發組內部，進行需求講解，對開發和測試，UI設計等同事的問題進行解答。產品經理此階段的工作，偏向與後端溝通需求和細化需求的角色。
總結: 產品經理是鏈接前端客戶和後端研發的紐帶，溝通需求和協調研發資源實現需求。
產品經理：
第一、產品經理既不屬於前端也不屬於後端；
第二、產品經理的工作內容：
1、熟悉產品的需求，與需求方溝通產品的需求，或者根據現在市面上的功能，推導出產品出來；
2、根據收集的產品需求寫出產品稿；
3、與前端、後端的技術人員評審產品稿，核對產品稿的可行性；
4、當前端、後端的開發人員根據產品稿把項目開發出來後，產品人員還要初步驗收項目，產品人員驗收完項目後，才有測試人員介入去驗收。
所以說產品經理更像一個設計師的性質，但是又沒設計師的范圍大，因為前端、後端的很多實現方式，產品人員是不負責的，只是效果方面的范圍管控。
你好，很高興可以回答你的這個問題，希望我的回答對你有幫助，我認為產品經理是一個項目的交接人，和項目開發關系不太大。這是我個人的想法，說錯了別怪我哦。
都不屬於。算是技術開發、運營、設計的統籌與粘合崗位。
首先需要明確 產品經理的概念是什麼。
網路對產品經理的定位是 企業中專門用來負責產品管理的崗位，負責市場調查並根據產品、市場及用戶等的需求，確定開發什麼產品，選擇什麼業務模式，商業模式等。並推動相應產品的開發組織，還要根據產品的生命周期協調開發營銷運營等。
第二點，產品經理在不同的公司的定位是不一樣的。根據從屬部門不同會有不同的定位。有些小公司，產品經理的許可權很小。他們只需要根據上級提出的需求畫出原型，然後理順邏輯，負責最後功能把關，有些還兼任著測試等各種奇葩的任務。
大公司的產品經理，對整個產品的生命周期負責，從競品分析市場調研，到需求分析流程梳理，研發流程測試進度等等都會進行參與協調。
在IT或者互聯網行業，如果從這個業務或者整個公司的角度去看前端和後端，那麼產品經理其實應該屬於後端，因為站在業務或者公司這個宏觀角度，和客戶直接接觸的職位才應該算作前端，比如銷售，售前、售後咨詢等等。作為產品和業務的設計和規劃者，應該作為後端，比如產品，設計師，工程師等等。
但是，在IT和互聯網行業，通常不會以這樣一種宏觀角度去區分前後端，而是會細化到部門或者職位，而前端和後端通常會指技術崗位中的前端和後端，即前端工程師和後端工程師。而這兩個職位都不包括產品經理。
前端工程師是指做用戶端產品的工程師，主要包括用戶界面，用戶交互等。後端工程師主要是指做服務端業務開發，中間件、基礎設施等開發。
而產品經理主要是負責產品設計，包括功能設計，流程設計，產品交互設計等等。
綜上，前後端的區分主要是看在什麼角度上區分。而不是單純的某個職位屬於哪一端。
Ⅱ 前端和後端產品經理的區別在哪
一、前端產品經理：
也叫2C產品經理或C端產品經理或客戶端產品經理。主要面向普通用戶或被服務者。比如**點評客戶端，團購客戶端，打車客戶端等等。這類產品的特點是：
1、區分客戶端和商戶端，並且功能差異很大，一個提供服務，一個享受服務；
2、客戶端具有操作、購買、下單功能；
3、商戶端具有開啟、關閉服務，更新、上下架商品等功能；
4、客戶端產品前期靠運營、推廣獲得用戶，商戶端產品前期靠商務拓展人員去尋找合作商戶；
重前端產品代表：
比如手機QQ、微信、微博、知乎、網路搜索等，這類產品屬於是純前端產品，一般沒有後端界面或只有簡單的後端統計界面，前端產品完全不依賴於後端，每個版本都可以獨立運行。
二、後端產品經理：
也叫2B產品經理或B端產品經理或商戶端產品經理，主要面向的是商家或服務的提供者，開發商戶的商鋪或商品管理平台。
重後端產品代表：
比如某基金管理公司開發的股票交易系統、量化交易系統、面向企業數據安全的風險評估系統等，這類產品一般是純後端產品或者只有簡單的幾個前端界面，操作按鈕等。
Ⅲ 前端和後端哪個更適合轉產品經理
前端。前端相比於後端，更加適合轉崗產品經理，前端更加了解頁面設計的規則，慎巧也更接近用飢尺戶。
1、前端開發工程師是Web前端開發工程師的簡稱，2007年才真正開始受到重視的一個新興職業。
2、後端工程師隸屬於軟體研發工程師，是從事軟體開發相關工作的人員，其主要職責是平台設計、爛孝高介面設計和功能實現。
Ⅳ 產品經理必懂的前端技術
前端技術是指用來開發和實現客戶端產品的技術
Android、iOS、Windows Phone
Html、Css、JavaScript
Windows、MacOS、Linux
1、移動開發工程師（Android、iOS）
2、web前端開發工程師（H5）
3、桌面客戶端開發工程師（Windows、Mac）
布局原理應用與產品設計：
1、產品設計時考慮每一個控制項的邊界屬性（文本的最長展示範圍，不同屏幕尺寸的適配）
2、內容型控制項需指明內容對齊方式（文本展示框內容的對齊方式，圖片拉伸方式）
UI控制項三要素：
1、大小
2、位置
布局：線性布局、相對布局
3、外觀（內容）
所有的顯示問題，最終都歸結為適配問題，適配問題為移動開發的一大難題之一，產品經理需要了解適配原理，通過適配方案反向推出能降低適配難度的原型設計。
1、界面布局適配（相對布局）
2、應用素材適配
（1）Android：點9圖
（2）iOS：@2x、@3x
3、功能適配
Html頁面是 骨架 ，CSS是給Html頁面裝飾的 衣服 ，同一個Html頁面根據不同的CSS可實現不同的展示效果
Web頁面可實現對PC瀏覽器和手機瀏覽器的 適配 ，一套網頁可在不同的設備上呈現不同的展示效果
修改網頁內容不需要重新發布客戶端產品，只需要網頁重新更新，可進行 熱更新
Html：超文本標記語言
以 標簽 的形式表示網頁組成元素，通過瀏覽器解析還原成視覺頁面
CSS：層疊樣式表
定義統一 樣式風格 ，給Html頁面元素進行展示樣式渲染
Html5應用： 通過網頁 web技術 實現的客戶端產品，具備 輕量化、易維護 的特點
Native應用： 通過各移動平台技術實現的客戶端產品，具備 體驗好、功能豐富 的特點
混合應用： 結合Html5和Native應用混合實現，在Native中嵌套H5頁面代替部分功能，具備 動態擴展，高靈活性 的特點
1、設計產品原型時，結合產品思維與實現思維
2、組件化設計思路，從開發角度思考問題，設計可復用產品模塊
3、明確技術邊界，基於現有技術設計產品原型
Ⅳ 寫給產品經理之前端是如何展示後端數據的
移動互聯網的迅猛發展讓移動APP呈現出爆發之勢，這兩年更是移動開發程序員的春天。
今天的互聯網上充斥著產品與技術的撕逼。也許你會問產品經理到底要不要懂技術？由此引申出，產品經理到底要不要懂設計？產品經理到底要不要懂運營？產品經理到底要不要懂市場？產品經理到底要不要懂業務？這所有問題的來源都是大家對於產品經理的工作認識不一致。
每個人心中都有一個產品經理的定義，產品經理在技術方面更多的是去統籌和規劃。不是畫畫圖寫寫文檔就可以了。這裡面更多的需要的是對邏輯的梳理和拆分。
例如很簡單的一個app內嵌發紅包的活動，產品經理需要確定整個活動的流程。從用戶進入頁面的那一瞬間就應該被產品經理掌控。他的每一個步驟，每一個操作會帶來什麼結果，有哪些變數會導致活動進程失敗，這些都要產品去考慮。等到活動邏輯和過程全部梳理完成，下面就要進行拆分了。還是以發紅包為例，紅包中金額是客戶端寫死還是服務端進行計算，紅包領取資格需要服務端返回幾種結果，每種結果對應客戶端的提示是什麼，用戶領取紅包以後服務端需要記錄那些信息（帳號，uid，領取時間，金額，是否使用等），客戶端哪些地方需要加入計數器進行數據統計。總結起來其實就是，產品經理需要根據開發的每一個環節，將所有內容分類整理，並分發給不同部分的開發進行研發。最後，還需要給測試准備好check list，當測試按照check list測試完成以後，才可以上線。
以上種種都需要產品對前端如何顯示後端數據有一個清晰的認識才能規劃好數據如何展示。是APP寫死呢還是後台返回，在用戶任務進行的時候有哪些可能case。只有搞清楚這些，產品才能在實際的開發中掌握好整個項目的流程與進展，才能不被開發給糊弄。
簡單的說，前端僅僅將後端返回的數據展示在頁面上，不做過多的邏輯處理。前端需要關心的是，數據如何更好的展示出來，頁面效果如何做出來，以及其性能問題。
而後端就是負責對這些數據進行處理，提供給前端展示。
前端一般有H5、android、ios等多端界面。數據不要輕易寫死在前端裡面，不然到時候三端都要修改，費時費力。而將這些變化多數據讓後端進行處理，前端將這個數據取出來顯示出來就行了。
舉個例子吧，下圖是一個美團app首頁團購的展示效果
上方美食等8個icon一般為固定展示欄目，非特殊情況不會修改。那麼前端一般是寫死在app中，等到需要更新的時候更新app即可。
而下方猜你喜歡是一個列表，該列表數據經常變化，數據寫在服務端維護，app取出數據進行展示即可。
首先，前段對頁面的展示是分兩步走的。
第一、在本地繪制好界面，當然此時未連api會填充一些假數據，或寫一些默認值。
第二、連api進行數據獲取，將數據填充進界面。
既然如此，咱們簡單看下前端拿到的數據到底長什麼樣的吧。
現在前端獲取到的數據基本是json數據。
不需要特別懂裡面每一個的含義，只需要知道，前端通過"title"這個鍵名(key)就可以拿到"合輯護甲"這個值(value)。 "title": "合輯護甲" 這一整個就是俗稱的一個欄位。通過該欄位前端就可以獲取到列表的標題了。當然這個列表只是簡單的展示用，還有諸如圖片地址、優惠信息、已售份額等信息沒有提供，這就是缺少欄位的情況。
前後端就是通過這樣的一個定義獲取/傳遞數據的。
考慮到後期拓展、需求變更等，一般來說，涉及到計算的、可能有變動的，一律不要讓前端來弄。
還是剛才那個例子，在剛才那個列表中有一個「立減5元」的橙黃色tag。
這個tag信息，如果考慮不充分，比如說，後端只提供一個數字5，然後前端在其頁面寫死「立減x元」，x為填入後端提供的數字，顏色固定為橙黃色。這個如果需求不修改還好，如果後期需要新增一個「滿20減5元」的紅色tag不傻眼了嗎？
到時候只能通過升級app來解決，而且不升級的老用戶將永遠看不到這個紅色的tag。
所以說，考慮到程序的可復用和拓展性，需要產品將後期可能新增或變更的需求考慮好，和前後端進行溝通，讓前後端設計好實現，盡量降低程序的耦合和硬編碼。這才能使一個產品更加健壯以及讓苦逼的程序猿少加班的關鍵。
那麼剛才那個tag的需求如何設計才合理呢？
首先是tag顯示文字，全權由後端提供，可以是多個欄位，由前端進行拼接。然後是tag的顏色，提供幾種樣式讓前端判斷是一種可行的辦法，但是直接提供tag的色值給前端的這種方式無疑給前端展示增加了無限的可能。
是不是也要增加一個tag形狀的欄位呢？
俗話說，過猶不及。tag形狀這種東西真的很少變更，欄位太多無疑會增加開發的時間成本，而且會讓人有一種捨本逐末之感。
前端獲取到後端數據後，如果前端不主動刷新重新請求數據的話，這個頁面的數據在該頁面銷毀前會一直保持不變。
如何理解？
首先，第一次進入一個頁面，該頁面數據為空或默認數據。此時前端會鏈接api請求數據。數據請求完成後，填充進頁面。那麼本次聯網請求就完成了，在前端不進行二次數據請求之前，該頁面會一直保持本次請求的數據。也就是說，就算服務端修改了數據，前端此時是不能事實的進行更新的，因為我前端不知道你數據更新了。
那麼在這個需要實時更新頁面數據的時候和前端講這種需求會被前端直接回絕：「做不了」。這個時候產品咋辦，怪怪妥協？最後背鍋的還是自己，而且自己也不知道是真做不了還是假做不了。
實時刷新也不是不能做，只是做的成本略高，需要和後端進行配合，像微信聊天一樣和後端進行長連接(socket)，這樣服務端數據變更前端就知道數據變更了。
當然如果稍懂頁面刷新機制的話，可以要求前端在適當的時機進行頁面刷新，如在頁面可見的時候進行刷新，這樣用戶每次看到的都是最新的數據。也可以讓用戶主動刷新，如新增刷新功能。
產品懂技術這件事情，不僅會降低和開發同學溝通時的難度和被歧視風險，還會提升在面對開發同學意見時的判斷力，會降低被技術團隊忽悠的幾率。同時，在需要向上級解釋技術原因導致變更的情況下，也會有助於說服老闆。
「聞道有先後，術業有專攻」，要相信自己所接觸的開發團隊是專業的，靠譜的，相信開發團隊為實現需求所做出的技術方案是合理的，最優的。如果有質疑，可以加深溝通，以合適的方式提出自己的質疑。這里要補充一句的是，這個信任過程是需要建立的，也是會根據團隊的表現不斷變化的；同理，其實團隊對於產品經理的信任度也是一樣的情況。
吐槽是沒有意義的，關鍵還是要解決問題。如果覺得產品經理不靠譜，那麼有沒有進行過深入的溝通？如果覺得開發不好溝通，那麼有沒有進行過了解，不好溝通的原因在哪裡？如果當事人本身確實不可溝通，那麼有沒有考慮和對方的老闆溝通，或者通過自己的老闆如實反映情況？吐槽是最容易的，解決問題反而會很難。