產品經理可以不會寫程式碼，懂程式碼最好

產品經理重要的是能懂使用者和使用者需求，並能將需求轉化成程式碼可以實現的產品開發需求

產品經理是否要懂程式碼，我認為是沒有必要的，當然懂程式碼，懂程式碼邏輯更好。

百度查詢到的產品定義是這樣的：“產品經理（Product Manager）是企業中專門負責產品管理的職位，產品經理負責市場調查並根據產品、市場及使用者等的需求，確定開發何種產品，選擇何種業務模式、商業模式等。並推動相應產品的開發組織，他還要根據產品的生命週期，協調研發、營銷、運營等，確定和組織實施相應的產品策略，以及其他一系列相關的產品管理活動。”

用人話說產品經理就是工地的專案經理，協調各個部門，確保建築材料充足、完工質量、商業價值的核心角色。

用形象的話說就是一個萬能膠的角色，能把幾方面都粘住，組在一塊搗鼓出一個有商業價值的東西。這個東西就是企業可以盈利的依靠。

所以一個產品經理他的角色使他更偏向與組織，設計，而不是開發。

一個好的產品經理，他只需要具備三個條件：1.情商高會溝通，

2.有主動學習的能力，

3.有將想法落地的能力。

所以一個產品經理並不需要懂程式碼，懂開發。只要懂業務，懂輸出需求，懂跟進專案就行。如果懂開發，有開發得思維就行。

產品經理究竟要不要會程式設計？這是個老生常談的問題，我們先把它放下來，看另外一個問題：「一個咖啡師，要不要會種咖啡」。

上週朋友介紹我去一家藏在寫字樓裡的專業咖啡館，咖啡師像做科學研究一樣稱重、磨豆、量溫度、看時間、衝咖啡。我隨口問道，弄這麼複雜，跟樓下星巴克有什麼區別。沒想到讓咖啡師打開了話匣子，從咖啡聊到咖啡豆，再聊到咖啡的產地，雙眼閃光，如數家珍。

我當時腦子裡就閃過一個念頭，假如我抄下他的操作步驟，鉅細無靡地照做，應該也可以做出一杯還不錯的咖啡。要是我能懂得怎樣控制和調整其中一些關鍵步驟的引數，加以練習，或許還能成為一個及格見習咖啡師。

但倘若想要遊刃有餘，成為專業的咖啡師，我恐怕也要像他一樣，知道咖啡的產地、種植方式、處理工藝和貯存條件。除此之外，可能還要弄清楚不同咖啡機的構造和原理。

– 2 –

從某種角度來說，我認為這就是「產品經理究竟要不要會程式設計」的答案。

不會程式設計，不知道支撐一個產品背後的軟硬體邏輯，只是照葫蘆畫瓢地交出原型，寫出 PRD，當然也可以做產品設計。但若想成為卓越的產品經理，我們應當像咖啡師瞭解咖啡豆一樣，去了解技術。知道它們的運轉邏輯，實現路徑，以及邊界和可能性。

我們要弄明白資料在哪裡，怎樣儲存，它們如何在控制語句的描述下流轉，表達在螢幕上；使用者又透過什麼方式將意圖透過螢幕傳遞給程式，然後被程式碼所捕獲和處理。我們要理解程式語言如何用數值條件理解邏輯，又如何透過呼叫和迴圈來分發和控制流程，等等。

我一直認為，產品經理能瞭解程式解決問題的方式，能看懂淺顯的技術文章，瞭解一點框架性和概念性的技術嘗試，可以大致理解工程師的語言和方案就足夠了。在此基礎之上，如果還能寫出五臟俱全的程式片段，或看得懂核心業務邏輯的程式碼表達，就能算是超出期望了。

我們不必真的像程式設計師一樣，具備工程能力和工程素養，做出完整的功能模組甚至產品實現，這不該是產品經理的戰場。

回到最初的問題，產品經理要不要會程式設計。我的答案有點繞：要會，但又不需要會 —— 因為當你「學會了」程式設計之後，對技術的理解和意識會內化成你的思維習慣，這時，是不是真的能寫程式本身，可能也就不那麼重要了。

– 3 –

怎麼學呢？

對於產品經理，或者其他需要了解技術的泛網際網路崗位，我一般會推薦去學 JavaScript 或 Python。

JavaScript 的環境簡單，上手門檻低，而且相對比較直觀，但總覺得門派眾多，風格也比較自由。Python 則更加嚴謹，有各種三方庫加持，並且Python 對資料和文字處理有著天然優勢，日常工作中寫一段小東西處理一下電子表格或文字材料都非常實用。

我用 Python 拉過 Google Analytics 的資料，也用它處理過業務資料和語料，還起過 TensorFlow，跑過 scikit-learn。

如果你沒有幹過這些事情，或許看起來會覺得有點厲害。但其實這幾個事情可以算是完全沒有技術含量的。真的不是裝大尾巴狼，它們都有完備的庫和文件和簡明易懂的示例程式。我們只要知道一點點基本的語法和邏輯，照著文件改幾個引數，就能跑起來了。

哪怕你只是個出納，花幾個週末學一點基本語法，照著示例，可能只需要抄十幾二十行程式碼，就可以在 Excel 表格中馳騁，把一系列的機械操作簡化為一個全自動的指令碼，那種神秘的操控感，你值得擁有。

我多年以前學 Python 是靠看書和文件，其實挺苦的，希望大家能找到一些比較不錯的學習方式。我自己會看影片學習，比較不那麼無趣，而且老師講的也比較詳細。比如前些日子，我就訂閱了極客時間的《零基礎學 Python 》影片課，我試看了一下覺得不錯，影片的教學形式，學習過程應該會相對輕鬆很多，而且還可以跟老師互動，有作業需要完成，還是蠻能督促你學習的。

當然大家也可以看文章自學，網上自學的文章還挺多，但我總覺得影片更好。

產品人，多個技能，多條路。

作為一個不會程式碼的產品經理，給予我自身的經驗：

1.入行不一定要懂程式碼，但一定會有非常好的邏輯能力，你的原型要有閉環，要讓開發能夠理解，並且找不到毛病。

2.你可以不懂程式碼，但一定要清楚哪些功能開發能夠實現，實現過程中的難度等級，實現上要花大約多長時間。不懂程式碼，就要靠經驗以及多溝通來彌補，不能異想天開瞎提需求，需求的適當合理性也很關鍵。

3.懂程式碼是加分項，很多公司的招聘要求會有這方面的限制，比如要會查個數據庫之類的。

4.現在不會，不代表一直不會，有時間就去好好學習吧。

其實吧，目前我敢說90%以上的“產品經理”，其實都不能說是一個合格的產品經理。我們總是說產品經理是離CEO最近的人，沒錯，實際上早期沒有產品經理這個角色的時候，公司的老闆自己就是產品。為什麼我要說其實很多人都算不上是一個產品經理呢？因為真的不是畫畫原型圖那麼簡單的事情。

上週和上海某211大學的設計工作室老師燙火鍋，他聊到一個很有意思的話題叫做：技術負債。也就是說在一家公司早期的時候，如果沒有一個系統的規劃，如果沒有一個優秀的架構，如果只是單純為了實現功能而在程式碼上做了很多臨時性的東西，那麼總有一天這些潛在的威脅就會成為大面積的BUG出現，每天什麼都不用幹，修BUG就可以了。這就是“出來混的總是要還的”。

其實產品也是一樣的，產品沒有負債嗎？有。公司早期的產品規劃，同樣因為各種原因，人手不夠啊，著急上線啊，經驗有限啊等等，在產品上只顧著功能的實現，卻並沒有一個整體的規劃，甚至是完整的開發流程和規範化的文件。最終導致的結果，新人來了沒有資料接手學習，產品邏輯上漏洞百出。我見過最嚴重的錯誤，是一家小電商平臺，使用者購買產品時用了抵扣券，結果退款的時候商品按照原價推回去，這個BUG持續了一個月沒人發現......還好抵扣券金額不大。

所以很多人動不動就在問產品要不要懂技術......搞得產品本身的事情做得很好了一樣......迫不及待要去跟技術搶飯碗裡哈？我只能說：產品在懂技術前，麻煩先把本身的業務能力提上去。什麼是本身業務呢？

UI設計和UX互動要不要懂？我相信光憑這一項，90%產品經理是不合格的吧？有多少產品專門去學習了IOS和Material Design的設計邏輯？有多少產品閱讀了《互動設計精髓》這種基礎入門書籍？有多少產品能夠畫高保真的設計稿？......嗯，產品為啥要懂UI和UX？因為你是產品啊，是負責整個應用的人啊，不懂這些，你的產品需求怎麼辦？

產品調研和使用者調研要不要懂？是不是可以做一份詳細的調研報告？知不知道哪些地方可以查詢相關資料？了不瞭解那些埋點工具的使用？能否在調研資料中查找出問題？除了競品，自己家本身的產品是不是完全瞭解？整體的產品是否有明確的規劃？調研這種東西或許並不會常做，但是不會是絕對不可能的。

再配合上一些基礎的技能知識，個人的特質潛力，良好的工作態度。如果能夠做到這些，恭喜你成為了產品設計師，嗯，不是產品經理，還不夠資格。

等到了產品經理，又需要什麼東西呢？就是計劃的全域性觀。

首先來說，核心是“責任”，你要明白一個產品，要對自己的產品負責。無論產品出現任何問題，不管是技術還是其它人的失誤，核心都是產品經理自己的失誤，反思的是自己做錯了哪些事，沒有做好哪些事。如果你自己沒有一個良好的“背鍋”心態，不要做產品，真的。

透過資料探勘需求，這個是產品設計師到產品經理階段躍升最核心的一個技能，這裡的資料指的就不是那些第三方的調研資料了，而是你目前產品運營的真實資料，這些資料怎麼打點，需要哪些資料，怎樣反映問題，如何解決這些問題，是產品經理需要去思考的問題。

透過產品規劃來落實到專案管理，這個考驗的是產品的宏觀思維。你是不是對自己產品所處的行業有非常熟悉的瞭解（這不僅僅是運營的事情）？你是不是非常瞭解CEO制定的公司戰略，並且有明確的方向，知道產品應該在哪個節點往哪個方向走？是不是可以在運營砸過來上百條需求裡面，合理分出優先順序融入產品的迭代中？還有最關心的一點：如何做到專案的不延期？（坦率的講，大多數人都沒辦法確保產品準時上線吧？）

等到這些東西都會了，你又要開始學習管理，學習戰略思考，學習運營和市場方面的知識，你覺得這些東西都會了麼？這樣看下來，作為產品經理，程式設計這件事情，佔幾成？

不會寫程式碼的產品不是好產品，不會寫程式碼的產品不是好產品，不會寫程式碼的產品不是好產品——三遍完畢。 很多產品經理都認為，產品經理不一定要會寫程式碼，只要大概瞭解一下程式設計就可以了。於是我帶著這個問題從我的產品經理生涯開始就一直探索。經過一段時間，總結出來以下幾點思考：

1. 溝通——產品經理與程式設計師產生矛盾的根本原因是什麼？難道是程式設計師就是不願意配合嗎？亦或者是程式設計師天生就腦子木很難溝通。我個人認為一旦產生問題，不要把責任都往別人身上丟，就如產品經理的產品做不好不考慮自己的設計問題卻要怪使用者奇葩是一個道理。假設產品經理真的懂技術，能看清某些看似簡單實則很難實現，某些看似複雜實則很腦殘的技術的話，與程式設計師的溝通成本就會大大降低，更不會產生產品經理覺得程式設計師木，程式設計師覺得產品經理智障，大家相互you can you up的情況 。記住產品經理永遠都是一個專案的主導，如果自己協調不好關係，那麼整個專案就會自上而下的產生越來越大的時間成本，溝通成本和人力成本。

2. 設計——很少有產品能在一上架就大賣的，都是需要一段時間的積累。如果設計出現問題，在新團隊中會產生爭執，在老團隊中會出現產品上架後各種奇奇怪怪的問題。因為新團隊磨合程度不夠，不能心照不宣的避開一些問題，而老團隊磨合的程度雖然高，但是程式設計師會自行判斷設計出一套東西出來，最後的結果就是產品失敗，導致加班，改bug等一系列的頭疼問題。這一切產生的原因歸咎於產品經理對技術的把控能力不到位，假設從程式設計之初就考慮到各種可能出現的技術問題，第一步先考慮產品邏輯是否正確，第二步以一個程式架構師的角度考慮程式邏輯是否正確，那麼產品經理就不會再抱怨——為什麼程式實現出來以後總是跟我的設計的不一樣呢？（ps：當然有部分問題是連自己真正需求什麼都搞不清楚人）

3. 專案管理——在這個高速發展的時代，網際網路公司的競爭中，誰贏得了時間就贏得了市場。在小型網際網路公司中，產品經理往往擔任了一部分專案經理的角色。不管產品經理對專案成本管理，專案風險管理等理論知識運用的多好，亦或者對敏捷開發、瀑布開發把控得多牛逼。只要不懂技術，那些各種理論都是空談，技術的啟動和實現整個專案的基礎，連這個基礎都不懂還談什麼專案管理。因為一個專案從一開始的時間評估就是錯誤的，產品經理沒有能力以技術角度去跟領導談時間週期和專案技術實現方案，僅僅是依靠對市場的分析和使用者的分析得出來的專案是進行不下去的。這也是導致專案延期的最直接原因。很多時候專案延期了失信於使用者，亦或者為了趕工期而草草了事，最終只會造成使用者的流失。 最後總結一下，一個專案出現問題，不應該去怪做具體事情的兄弟們。而是應該站在一個管理者的角度去思考問題： 專案設計是否合理，做具體事情的同事是否能在有限時間內保質保量的完成任務，如果不能，是否有更好的途徑是實現它； 中層管理者是否有能力能在一線同事出現難解決的問題時第一時間幫其解決問題，而不是一味的責怪和推責任。 在一個專案中，產品經理是對產品最直接的負責人，對產品負責就是對自己負責，從現在開始，在業餘時間擼一擼程式碼吧，一個懂程式碼的產品經理才能走得高走得遠。

產品經理不一定需要懂程式碼，但一定要能和研發人員順暢溝通，能評估最基本的研發可行性和工作量。

所有的產品招聘中都會提到誇職能的溝通，這些溝通中包括研發。如果產品懂程式碼有一定的程式碼功底，和研發溝通起來會更順暢。如果不懂也可以，但最基本的一定要有所瞭解，提出的需求要保證最基本的可行性。之前產品和程式設計師大打出手，就是因為缺乏最基本的研發邏輯，根本做不到的事，找程式設計師正事提需求，肯定會遭白眼。

其次，產品如果不懂研發工作量，不要對外排期，一定要和研發溝通好後，在確定排期。很多時候看似邏輯簡單的一個小需求，後面的工作量不一定小，還要考慮資料量，效能等各方面。

有很多研發轉產品的，沒聽說有產品轉研發的。兩個角色，看公司組織結構了。有的可能兩個角色同屬於一個體系，溝通順暢。有的可能就會互相套路，產品會欺負程式設計師只懂技術，邀功時沒有程式設計師，甩鍋時想起程式設計師。兩者沒有基本真誠的話，那只有互相套路了...

產品經理會不會寫程式碼不重要，重要的是要知道自己該幹什麼？知道該幹什麼的產品經理而他的老闆不知道產品經理應該有什麼樣的許可權。這就是為什麼小公司老闆就是產品經理，把產品弄的好好的。

作為一名曾經的產品經理，從不懂程式碼到自學技術後，懂得了程式碼，這期間的感受是非常明顯的。可以非常明確的告訴你，作為產品經理，不一定要懂程式碼，但是你想要往更高級別的產品經理走，懂一些程式碼是必須具備的條件。

經常都是說，產品跟技術是兩對冤家，這也不是沒道理的。很多不懂技術的產品，都是憑空想出一些功能，覺得這些功能使用者會喜歡。

但是，在考慮功能的時候，沒考慮到技術的可行性，這就導致方案到技術部門的時候，容易產生分歧，進而影響到整個產品的進度。

做過產品設計的人都知道，產品反覆修改是很正常的事情，但是在產品設計的時候，不懂技術的產品經理，往往低估了修復的技術難度。

然後隨意修改，不考慮技術的感受，結果必然會讓技術反對的。如果是懂技術的產品經理，在產品設計的時候，就會考慮到這個問題，懂得提前告知技術這些問題，讓對方有所準備。

所以，懂得技術的產品經理，不管是從產品推進的效率上，還是跟技術溝通的效率上，都比不懂技術的產品經理來得高。

懂技術的產品經理，從產品立項開始，就能評估技術的可行性，這比不懂技術的產品經理把產品做到一半後，才發現技術實現不了。

很多產品一開始都是缺人手的，這個時候懂技術的產品經理，往往會比不懂技術的產品經理更容易被重用，因為他們本身就能自己解決一些實際的問題。

那些整天只會寫寫原型，寫寫PPT的產品經理，理論上只能說是產品專員。所以，想要在產品經理這個崗位上，有所建樹的話，建議還是自學點技術，對自己絕對是有好處的。

感謝邀約，隨著網際網路的發展，人工智慧、物聯網、區塊鏈領域的興起，對人才的要求層次也越來越高，自然對產品經理的要求也越來越高，不再是簡單的梳理需求 ，畫畫原型而已，我的回答是產品經理一定需要懂程式碼，如果是從寫程式碼的開發人員轉行產品經理更具優勢。以下是我對這個問題的看法，僅供參考：

網際網路產品經理在網際網路公司中一般處於核心位置，需要非常強的溝通能力、協調能力、市場洞察能力和商業敏感度。毫不誇張的說，一個關鍵崗位的產品經理決定了一個網際網路產品的成敗。

1、產品經理具體做什麼呢？

一個合格的產品經理要做的事情非常多，整個產品的生命週期都要參與，比如產品的調研，需求文件的輸出、設計原型、視覺設計協調、開發進度跟蹤、產品測試跟蹤、產品釋出準備及相關的準備工作、產品資料分析、產品迭代等等... 由此可見，各個環節都有產品經理的身影，如下圖所示：

2.產品經理具體的職責

接下來我們來看看產品經理的具體職責，如下圖所示，主要負責產品的調研，產品的定義，專案管理、產品生命週期的管理、產品營銷的支援、產品宣講等具體的工作，可見當一個產品經理是多麼的不容易。

3、什麼樣的產品經理才是一個好的產品經理呢？

人人都可以做產品經理，但是並非人人都可以做一個好的產品經理，作為一個好的產品經理，應該有成本意識、銷售意識、團隊意識、全域性意識。產品涉及的內容方方面面，因此要考慮的東西十分全面，研發這個環節當然是整個生命週期的重中之重，出於對整個產品的把控，產品經理最好能夠懂一些開發技術，要不設計的產品，在好的需求，技術實現不了也是白搭，如果技術實現方案太難，技術成本控制不住，那麼就很難推動這個產品的進展。如果不被技術嘲諷為門外漢，瞎指揮，作為產品經理不得不懂一些技術，要不被開發牽著鼻子走的感覺是很難受的。

不知道大家發現沒，現在越來越多的網際網路公司，尤其那些技術性專業性要求強的公司，越來越強調產品經理懂技術，最好是技術出身，如下圖所示：

由此可見，或多或少，對於產品經理這個崗位，你需要懂後端或前端相關的技術內容。

隨著時代的發展，人工智慧、物聯網、區塊鏈也慢慢走入我們生活，我們可以預見，在未來幾年會發展十分迅速，這些前沿方向都是技術專業性很強的方向，比如你不瞭解什麼是AI，機器學習實現的原理，監督學習和半監督學習，資料標註和資料清洗這些關鍵概念，你是很難理解和設計好這些技術專業性很強的產品，意味著無法進入這未來的新興領域。如果你想持續保持競爭力，不寫程式碼可以，如果會寫自然更好，但是你不能不懂技術，不懂技術，你就無法和做研發的同事做到平等的溝通，別人會認為你不專業，瞎指揮，自然你設計的產品就很難推動。

今天的內容就和大家分享下，隨著時代的發展，各行各業對人才的定義也發展這變化，只會越來越高，複合型人才在未來會很吃香，因此作為產品經理，也要不斷拓展知識的領域，懂技術會更具有優勢。