為什麼不懂技術的人可以做產品經理？

01-09

如題。知乎上程序員們各種吐槽產品經理，這讓我對產品經理這個職位產生了很大疑惑…一個理想中的PM應該是個通才（儘管比較稀有…）。如果PM在知識面上有所欠缺的話，為什麼那麼多PM要欠缺在技術知識上呢…（或者說連技術都不懂怎麼當PM）…
難道很多公司更看重PM在其他方面的才能？

這問題下面這麼多回復，搞笑的實在有點多。你們是覺得產品經理就是專門跟程序員說，這裡我要這樣的效果，那裡我要圓角的，這裡顏色不好，那裡字體不對的職位？

整個產品流程，從前期的市場調研，競品分析，需求評審，項目提案，到中間的產品實體化，設計，交互體驗考量，公司內資源協調，公司外資源需求整合，項目考量，落實規划到後期的運營規劃，市場推廣，程序開發，用戶反饋，產品迭代，需求評審等等一系列的工作內容中。你們覺得涉及到真正需要能跟你勾通這裡代碼如何處理，這個存儲流程如何涉及，這個演算法如何調整的環節有多少？占他們多少的時間和工作強度？

沒錯，產品經理需要通才，懂得越多越好，但絕對不是需要他們在技術方面懂的越多越好，而是知識擴展，行業深度的方面通才。程序員能夠和產品經理在工作中接觸的無非是產品落實開發的那一小部分，就因為他們不能夠理解一個看起來簡單的需求為何需要較大的工時，於是就質疑這個行業的普遍勝任力，這有點誇張了吧？

我不否認現在產品經理這個行當有很多渾水，許多產品經理不僅不懂技術，在該懂的地方也一知半解，但個人認為不懂技術根本不應該成為產品開發過程中會經常出現問題的地方。真正讓產品經理和程序員之間出現障礙的只是勾通而已，這兩個職位真的不在一個次元的世界中。

產品經理始終覺得跟程序員勾通怎麼這麼費勁，解釋個東西都解釋不明白。

程序員也覺得產品經理怎麼屁都不懂，除了指手畫腳就是提一堆滑稽之談。

雙方有著絕對的信任能夠解決很多不需要浪費時間去讓對方明白的問題。

我現在和程序員勾通的時候經常是這樣的對話：

猿：這地方有個問題

狗：啥

猿：這裡要展示的數據沒辦法從結果表中取，但是從原始表直接取數據的話，經過演算法處理完以後展示出來和其他地方的數據有偏差，後期管理也沒辦法同時管理兩個表，另外你看，從%#%￥￥%……表裡返回的這個%$##$%%^$$%值，我們還得演算法處理一下，這中間浪費很多處理能力………………

狗：（什麼玩意兒沒一句聽懂的）啥玩意兒你說我聽得懂的那到底是能實現不

猿：能倒是能……就是……

狗：有啥影響沒

猿：那肯定有，運算速度要慢，前台的載入速度要慢不少

狗：實際響應一下，前台載入要多久

猿：多1.1秒

狗：沒事兒就這麼做吧

完

產品經理不需要懂你具體的數據存儲流程，方式，演算法，他只關係最後的影響結果，是影響前台，影響體驗，還是影響運營，影響實現。當然還有需求不能實現的時候，我往往會問確認做不了嗎，其他地方我允許損失的情況下？如果確認做不了，我會問那如果改成什麼樣就可以實現，並且自己評估方案改過以後的損失和需要調整的地方。這中間的過程，我不需要明白具體是哪裡出現問題了，為什麼出現這個問題了，為什麼這個問題解決不了。

多點仁愛之心,這個世界會變得更美好。珍惜產品狗，他們也很苦逼_(:з」∠)_ 。

產品經理與程序員的矛盾部分時候其實是承擔責任與產品規劃的問題，但是一個普遍現象。

產品經理不懂技術（或者是需求的不明確）導致後期新提出的很多需求會讓技術人員前期的技術實現（甚至是架構）需要重新調整，甚至重構，而很多時候，不懂技術的產品經理是不知道的，苦逼的程序員當然憤怒。這時候，產品經理的技術就能夠用上，他知道合理的調整新的規劃，而不「XX時間必須完成」。如果這種矛盾不能調和，會上升到人與人之間的矛盾。

私以為99%的產品經理提出的需求都是可以實現的，只是，給我時間，而不懂技術的產品經理，會不知道這個時間的長短。而不懂技術的產品經理在規劃時間時不科學，會讓開發找偷懶的機會，久而久之會讓產品經理懷疑技術人員的。

當項目成員之間不再信任，互相指責，互相規避責任的話，會讓項目打折扣，這種負面能量會讓情況越來越糟糕。

勇於承擔負責，多一點信任與寬容，多一份溝通與交流。

那些技術對產品經理的經典無力吐槽

頂尖的互聯網產品經理的額外硬性指標

最近跟很多非技術工種想轉產品的同事聊起來這個問題，基於之前的回答有了一些新的想法，補充一下。

開發人員的思維模式，偏重於結構化思維；相對來說，測試人員也是很接近的狀況。

銷售、市場、商務、UI等工種同學的思維偏重於非結構化思維。

那麼產品經理，我們不考慮具體的技能、業務方向和職能，所要完成的工作內容，大多數的情況下，是面向非結構化/半結構化的信息（需求、調研結論等等），以結構化的思維方式進行抽象歸納總結整理成結構化的數據，分別輸出給研發相關團隊（需求規格說明書）和管理層（產品規劃文檔），並能夠基於基礎數據形成自己風格的非結構化數據輸出給商務相關團隊。

技術出身，或者理工科院校相關專業（計算機、數學等）畢業的產品經理，如果同時具備比較好的非結構化思維基礎，相對來說就更容易適應產品工作。

有可能說的很拗口，這是因為答主高考語文剛及格的緣故。非心理學相關專業出身，因此上文中用詞可能不是很準確，請閱讀者不要介意。

以下是修改前的原答案。

————————————————————————————————————————

看了很多回復，有些說的確實很中肯，但是仍然有些不吐不快的想法，於是就回答一下。

非理論派，因此下面的內容很有可能跟教科書有很大的差異，覺得合適就看看，覺得有問題的話請忽略，不喜勿噴，謝謝。

首先說一下產品經理的主要構成：畢業就做產品或轉自其他工種。

畢業就做產品的，除了計算機系的大多也不懂技術；轉自其他工種的，我了解的，有來自開發、運維、運營、設計、銷售、售前、業務等各個領域的，其中必然有大量懂或者不懂技術的。如果一定要按照這個維度來分，那麼就只有技術背景、非技術背景兩類。

在我的八年產品經理生涯中，見到過相當多的優秀的產品經理，也有更多剛及格的產品經理，當然，有更多的產品經理尸位素餐，完全不及格。所以我認為其實是人人都能做產品經理，但不是人人都能做好產品經理，大家都盯著產品經理噴，無非就是這個職業的批評難度最低。其實這麼多年我見過的開發也必然是三六九等，優秀的、及格的或者是不及格的，不一而足，但是批評技術同學的很少，因為有些開發會用一句話來回答：你懂技術么？不懂勿噴。這個世界就清靜了。

這里我沒有任何攻擊或者侮辱其他任何人的意圖，我只是想說，產品經理的工作是工作難度相對入行門檻差距最大的一個工種，尤其是人人都能做產品經理這個概念廣為流傳之後，很多人會故意曲解這句話（這裡必須舉個栗子：成功=99%的汗水+1%的靈感這句話廣為人知，但是真正重要的後半句卻有意無意間被宣傳者忽略）。

接下來我說說我對產品經理這個工種的理解。

從上到下看，一個合格的產品經理需要達到以下標準：

1、理解公司發展戰略，能夠帶領所負責產品和公司戰略有效結合，使得產品規劃符合公司的發展需要

2、了解行業動態和市場趨勢，能夠制定和規劃產品方向，並根據變動適時調整

3、把握產品的定位、目標用戶群，以及目標用戶群的實際需要，使得產品能夠切合用戶需要，對用戶有價值

4、能夠綜合用戶的實際需要、競品和市場狀況，制定產品的路線圖和各版本實際需求，形成有效的產品描述和設計文檔(文檔類型並不重要，能夠清晰描述即可)

5、能夠把產品需求如實有效地傳遞給開發以及團隊中所有的相關方，使其在團隊內部形成共識，能夠認可並完成共同確認的目標；協同技術團隊確定技術實施方案。

6、根據項目情況，組織和協調所需資源，尤其是跨團隊跨部門的人力資源資源

7、根據資源情況，合理安排項目管理粒度和項目周期。

8、帶領虛擬團隊，按照既定的產品規劃(包括CR)完成設計、開發、測試、上線和迭代，即常規的項目管理過程。當然，項目管理過程可以根據實際需要簡化或者精細化，不再贅述。

從上面的情況看，其實所謂的「懂技術」在產品經理的技能樹上所佔的比重並不是很大，我不否認其重要性，但是不了解市場和戰略的PM，對一個產品線來說，其危害遠比不了解技術要高。

那么問題來了，為什麼那麼開發同學吐槽產品經理不懂技術？嗯，同理，還有很多設計吐槽產品經理不懂設計。我的理解有兩點：

1、產品經理對於開發、設計師來說是任務輸出方，在某種程度上代表著勞資雙方的對立，很多時候產品經理需要向團隊內部輸出公司戰略或者領導意圖，當這個業務線面對著一個想法複雜而多變的老闆的時候，那麼把老闆想法轉換成具體任務的過程就會變得無比悲催。

2、技術、設計是開發同學和設計師的職業壁壘，是工程師和設計師批評產品經理的最直接有效最難以反駁的武器，並且很容易在同工種之間獲得共鳴。這就好像日韓只有在批評中國的時候才達成共識，中韓只有在批評日本的時候在合作無間、中日也只有在批評韓國的時候才最容易同仇敵愾。

產品經理需要怎麼改變才能從根本上解決這個問題？嗯，怎麼做都不可能完全解決，因為這是一個「我們來做這個」和「我們為什麼要做這個」的根本對立問題。但是還是有一些辦法可以緩解一下。

同理心問題，產品經理必須站在工程師和設計師的立場上思考問題，因為PM才是虛擬團隊的leader，而其他工種不是。然後才是技能問題。

項目管理是產品經理的必備技能，無論任何背景出身，都需要基本的項目管理能力，如果從事了產品經理工作，就必須了解學習相關的知識，並在實際環境中加以應用，而不能只是拘泥於教科書的條條框框。

產品經理的背景不同，可以懂技術，也可以不懂技術，這個因人而異。但是入行之後，完全不懂技術就不夠用了，根據所負責的產品形態不同，對技術的深入程度需求也有較大差異，至少需要了解所負責產品所涉及到的技術點，需要有能力把用戶需求儘可能保真地轉化成開發同學能實現的描述。

懂技術這件事情，不僅會降低和開發同學溝通時的難度和被歧視風險，還會提升在面對開發同學意見時的判斷力，會降低被技術團隊忽悠的幾率（這幾種情況我都遇到過，不舉栗子了）。同時，在需要向上級解釋技術原因導致變更的情況下，也會有助於說服老闆。（什麼？我一個學心理學出身的產品經理為什麼要花時間去了解技術？Emm，個人覺得這樣回答的產品經理可以考慮專門做業務或者轉崗）。

我之前在另一個類似問題的回答里說過「術業有專攻」，要相信自己所接觸的開發團隊是專業的，靠譜的，相信開發團隊為實現需求所做出的技術方案是合理的，最優的。如果有質疑，可以加深溝通，以合適的方式提出自己的質疑。這裡要補充一句的是，這個信任過程是需要建立的，也是會根據團隊的表現不斷變化的；同理，其實團隊對於產品經理的信任度也是一樣的情況。

吐槽是沒有意義的，關鍵還是要解決問題。如果覺得產品經理不靠譜，那麼有沒有進行過深入的溝通？如果覺得開發不好溝通，那麼有沒有進行過了解，不好溝通的原因在哪裡？如果當事人本身確實不可溝通，那麼有沒有考慮和對方的老闆溝通，或者通過自己的老闆如實反映情況？吐槽是最容易的，解決問題反而會很難。

這里必須要說一句，無論任何工種，都有不可溝通的一小撮人存在，就是無論任何溝通方式都會完敗於對方的情況，如果對方人品還過得去，那麼就加強線下接觸，吃飯喝酒小禮物不一而足；如果人品實在不行，先考慮是否能完成當前的任務目標，結果為導向是任何公司都在意的事情。

我很討厭上面自己的回答，貌似站在道德的制高處指指點點，充滿了說教意味。我也不能說自己很多地方都做得好，面對上一段提到的奇葩合作方的情況，我也不止一次暴走。及格就是我對自己的評價，僅此而已。

以上。

利益相關：5年RD，8年PM，天賦和努力程度都有限的及格線產品經理

看到這個題目，我感覺膝蓋碎了一地。。。。

作為一名實打實的文科出身的初級還未入門的遊戲pm，請允許我先談一下我個人對產品經理的理解：產品經理是一個問題解決者。從用戶那邊把真正的需求轉化為可用語言表述（技術團隊能夠理解的語言）的內容輸入給團隊，結合各方面的資源用最低的成本把這個內容轉化為產品去解決用戶問題滿足用戶需求。

在和其他的pm交流的過程中，我發現這種理論是站得住腳的。在正確（退一步說假設正確）的前提下，我們來看看這裡面的描述：很多關鍵的步驟是可以不用技術去理解的。我為什麼這麼說？因為產品的本質是什麼？是服務。服務的關鍵在於理解服務對象的需求，這說回到產品就是常說的sense，技術是要實現某一個過程的手段，而且這個手段不需要一定要pm來做，而pm要做的是告訴正確的人在合適的地方採取正確的手段來實現目標，這個人可以是pm本身，因為他自己對這個需求理解最透徹，如果他能把相關的理解高精度地傳遞給技術，是不是同樣的效果呢？

以上是我覺得產品經理不需要技術的原因。

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

目前在公司負責微信相關業務，算是正式第一次和程序員打交道。剛開始前端各種不配合，做出來的東西完全不按照原來的設計來，效果真是和預期差了十萬八千里。我過去和他交流時，我覺得他滿臉寫著「你懂什麼哦」；現在他為了我的項目，測試一個鏈接，在自己的朋友圈發了一個遊戲大概有50遍，後來他家人打電話問他來確認他是不是出事了（其實我提醒過他可以設置分組測試的，畢竟不拘小節。。），他們技術那邊有問題也會跑過來我這邊，（以前都我屁顛屁顛跑過去的），手頭的項目算是按照預期完成了，雖然我沒有打一句代碼。我在工作和他們交流的時候，極盡所能用程序員能夠舒服理解的表達方式和語言，另外我經常在知乎上看到有程序員抱怨說他們的產品經理（大部分是從產品角度）無端改需求，這樣的pm如果能拿出他修改的理由和理論還有預期的效果，是合理的，更多是出於自己之前思考的欠缺和腦瓜一拍的傑作，這無非更加增加了程序員和pm的溝通成本。溝通，是保證工作效率的關鍵要素。

在上面的描述中，我用了極盡所能這一個詞，其實也包含了我的態度，或者說是個人的發展方向：我想學點技術。我學技術是為了更好的與技術人員溝通；我學技術是為了遇到一些問題我可以自己去解決而不用再經歷一個溝通的過程；我學技術是為了多一種手段去解決問題；我學技術是為了追尋一種酷的感覺，我一直覺得那些會技術的人自己用一台電腦好像就能操控整個世界的感覺，目前正在和拖延症鬥爭中。

所以會技術的pm，不要以為會技術就能解決所有問題，至少一個人的技術能解決所有問題的大神不多；不會技術的pm，不要放棄自己的更多的可能性。

與君共勉。

你覺得懂技術是什麼？會自己寫代碼么？

看一個網站，你就能分析出一個功能是如何通過其後台系統實現的，信息是如何在系統間傳遞和讀取的，限制和判斷邏輯如何等等！

然後把你的邏輯思路和流程告訴rd，rd給你系統的解決方案，最終完成項目！

不然rd是幹什麼的？純實現部門？

rd是根據設計邏輯給出系統層面的解決方案的角色！

難道rd會問pm這個代碼怎麼寫么？

再者，即使是rd轉pm，那麼設計這個環節，你難道有得保證開發能有藝術眼光？

就算開發也有藝術眼光了，那麼運營這邊的需求溝通、老闆那邊的kpi、roi彙報，這些呢？

產品經理又不是只對接rd，需要的素質多著呢！

因為大多數是做不了技術的才去做產品經理的嘛。。。。而且工資為毛那麼高

產品經理本來就是一個有技術含量的非技術性職位。

這樣來看就對了。

懂技術更好~~

不是只有開發技術才被成為技術。產品經理應該了解他所在行業的實現技術。

遇到過很多代碼寫得比工程師好的產品經理，也遇到過很多 html 也不懂的產品經理。

如果產品經理自己就能把代碼搞定，那壓根就不需要只懂技術的人了。花1.5個人的錢，招能幹2個人活的人，自己設計自己實現，節省扯皮時間，效率多高！老闆好嗨皮！

術業有專攻嘛，總有的人擅長這個不擅長那個，做技術的人也不是人人懂產品懂市場懂審美的啊。所以需要各個環節的人齊心協力去合作，誰也別鄙視誰，這其中產品經理還擔任了項目管理的職責。

現實中，PM懂技術確實是有優勢的。只是這些年互聯網行業爆發，在高校教育與實際應用脫節的情況下，不要說又懂產品又懂技術的PM，就是靠譜的程序員都人才緊缺，因此產品經理隊伍難免良莠不齊，有的新人連Excel都玩不轉，這是客觀現實。隨著人才和行業的成熟，情況會有所改觀。

我們公司的產品經理貌似是最多的（不說也該猜出來了）。。。結果就是不少產品經理每天無所事事，做一些沒有用的東西。我們部門的開發人員測試人員業務都比他們更懂業務。但是畢竟我們用戶大，需要有人不厭其煩地去做需求（雖然很多需求他們自己也沒搞懂），然後畫畫原形界面（畫的都像砣屎），但是產品最終怎麼做，需求評審的時候全是老闆說了算，但是他們有點很好，第一他們為了產品不怕折騰，想法被老闆否定了還會想更好的，第二願意學習，也願意學習一些開發相關的知識，並且尊重開發人員，一起討論想方案。。。廠子太大，我說的僅限於我所在部門我所能見到的。還有說道溝通能力，不要覺得程序員就愣，大家都一樣，比程序員愣的產品經理也不少，不要憑藉職業對具體的人主觀臆斷。

產品經理完全可以不懂技術，但是要對軟體的實現過程有基本的了解。最重要的是要懂業務或者懂交互，不然沒什麼存在的價值了。的確是有很多什麼都不會的轉來做這個職位，身邊也有一些這樣的，但是只要謙虛上進肯學習總是好的。就怕什麼都不會，自己那塊基本業務都理不清，還自己覺得很牛逼，動不動就說要設計個產品替代微信，用戶要上多少億，只能讓人覺得像個煞筆。最後，我所說的僅限於我見到的。ps:我廠有好的產品經理，業務、技術、交互、市場樣樣精通，無所不能，膜拜到底。

我一直不反對抖機靈的答案到第一位，我是看不慣，專門用來黑人的回答都到了第一位。

什麼叫做不了技術的才做了產品經理。那我可以明確的告訴你，我見過一個開發轉了產品，然後3個月沒到，又轉回去的。

對於開發而言，他要面對的可能僅僅只是其他開發以及產品，測試。

但對於產品經理而言。

從用戶側（客服，用研），提煉出用戶需求場景，然後輸出需求list，確認需求優先順序。

到UED（交互，設計），把需求用圖展示出來，這個階段，除了交互，產品自己也要有足夠的知識的積累。

然後到前端，後端的開發溝通，各種需求PK。如果遇到不靠譜的開發團隊，自己還要想到需求可能影響的模塊，找到對應的團隊進行解決。

最後還要涉及到設計用例的評審。

還有包括和老闆的溝通。老闆只會和你說我要這個，那個。但產品經理要根據現實的產品情況，用需求的方式實現老闆的想法。

如果你覺得你能隨便拉一個開發同學出來，就能把產品經理事情做好的話，豈不是不會出現我說的，開發轉產品，然後又轉回去的事情。

不懂技術不代表不理解技術。

作為產品經理這個職位來說，我們得先問一下為什麼產品經理會存在。可以查看這個問題產品經理為什麼會存在？

產品經理本質上就是一種分工而已，術業有專攻，每個人把自己的責任做到，這就是最基礎的要求。

那麼產品經理的責任是什麼？我認為是這樣幾點;

管理：管理上級和無授權管理團隊相關人等
溝通：通過任何方式獲取想要的資源，把問題解決
執行：把想法落地，並保證這個想法是可運行，符合戰略方向的
商業思維：這個大部分產品經理不一定有機會做。

//當然因為不同團隊，風格不同，可能會有不同的分工。

從職能劃分來看，需要懂技術的責任模塊只是一小塊，主要是在執行。就算不懂技術，其實不影響成為產品經理，但影響他後續的成長和提升。我見識過很多不懂技術，但是團隊影響力非常強的產品經理，也見過很懂技術，但不懂溝通的產品經理。

作為產品經理，你的技能點如何點是一個很重要的問題，也是形成個人風格的很大因素之一。當然，不懂技術不代表可以不理解技術，這是至關重要的一點。

最後，還是那句話：術業有專攻。

程序員為毛永遠不明白你的用戶基本上都是不懂技術的。

說技術不善於溝通的大部分都是產品炒出來的吧，不然他們都失業了。

因為pm有比實現技術更重大的任務。問這種問題可以先檢索，或者嘗試實踐去了解。在這裡得不到好的回答。

產品經理應該是懂技術懂用戶的。

我們的產品經理全是懂技術的。我認為產品經理一定是某方面有技術優勢的。

至於為什麼某些公司會有不懂技術的產品經理。這個問題不好理解，也許只是因為同一個名稱所代表的實質性職位在不同公司並不完全相同吧。所以鑒於我不太清楚那些不懂技術的產品經理實際擔當的是什麼指責，所以我不作評價，謝謝。

其實不懂技術沒關係，別老說:「技術我不懂，反正你在xx時間前做出來就行」