產品經理需要懂技術嗎？懂到什麼程度？

12-01

如果不需要，為什麼？如果需要，能不能簡單介紹一下對於沒有技術背景的人怎樣達到這個程度，有沒有好的方法？或者好的資源可以推薦。

最近七年，我都在做互聯網產品，其中前五年分別在創業公司和上市公司里，做別人的產品；近兩年在創業，做自己的產品。

我的體會是：產品經理需要懂技術，創業者尤其需要。但前提是你總覺得有股憋不住的想要做點兒什麼的衝動，如果打算混安穩日子，特別是在大公司，你什麼都不需要懂，反而要小心別「知道的太多了」，傻人一生平安。

做產品這幾年，和開發工程師打交道最多，和他們交流通常有兩大忌：

一. 忌不懂技術

更準確的說，是不能缺乏設計、開發一個互聯網產品基本的技術常識，比如至少要清楚一個網站從不存在到能被用戶訪問，需要哪些必須的環節；也要明白一個App從你的腦海走到用戶的手機里，需要經歷怎樣的過程。

有常識，當然不一定就能做出好產品，但沒常識，就很象在村裡呆了半輩子的人乍到城市，一舉一動即使小心翼翼，也沒法兒不透著突兀和不和諧。

很多公司都有完全不懂技術的產品人，大多年齡較長，也許是互聯網出現的時候，他們已經過了充滿好奇和渴望未知的年齡，不願意放低身段去學習新東西，喜歡只憑著想像和自己的生活經驗就開噴，間或以若干近期熱門關鍵詞作為點綴，以示自己尚蹲在潮流尖端。

這樣的人也許能忽悠某些領導，但一定不招工程師待見，他們可能什麼都不說，但心裡已經開始等著看笑話，交給他們的開發需求，自然也是能拖則拖、能蒙則蒙。

二. 忌懂技術

我遇到不少工程師喜歡說：「只要產品需求明確，技術上一切都能實現。」

這句話聽起來相當豪邁，也讓產品經理大為放心，覺得技術真是產品的堅強後盾。但其實傳遞了一個特別糟糕的信號。

當工程師這麼說的時候，潛台詞是：「你弄好你自己的事兒就行了，別來管我！」而且這種說法隱含著一個樂觀但顯然並不現實的假設：技術是無所不能的，他（掌握技術的人）也象燈神一樣，可以實現你的任何願望，只要你能明確的描述它。

我不知道阿拉丁說完願望之後，假如膽敢繼續追問燈神將具體採用何種技術方案來實現的話，會不會被塞到燈里，但我知道很多工程師在發現你關注技術層面過深的時候，都會有種領地被侵犯的感覺。

這就是工程師維護自己專業槽的本能，與行業中其它角色相比，工程師地位不是最高，待遇也不是最好，還經常加班加的要死要活的，唯一得天獨厚的優勢，就是專業槽比任何角色都深。關於產品、關於UI、甚至關於商業模式每個從業人員都能噴上幾句，要是說到用戶體驗，那更是連業外人士都敢大噴特噴而沒有任何心理負擔：反正我就是用戶嘛，越傻越光榮。而一旦涉及到代碼，大多數人就直接暈菜了。想想那些UI設計師的苦逼段子，工作時沒有噴子們指手劃腳的干擾，真是上帝賦予工程師獨有的恩賜。

所以當他們認為有外人正試圖跨越這條槽時，自然會有所警惕，甚至體現出抵制和敵意。當一個產品經理髮現工程師開始比較密集的使用術語或拚命把簡單問題往複雜了說，你應該知道，他們在槽邊開始向你射箭了。

從整個產品乃至公司的角度來說，各個專業角色之間的專業槽都是應該被填平的，產品經理不該對工程師玩挾天子以令諸侯，不要總假裝自己是用戶的三個代表，動不動就拿想像中的「用戶需求」當「奉天承運」來用；工程師也不必總裝燈神，假裝無所不能很累的，工程師之間必有能力高下之分，其實有時候功能做不了或做不好，純粹只是因為工程師能力所限。如果彼此坦誠一些，大可以提前有效溝通，儘可能避開那些投入產出比過低的部分，有不少工程師不願意拿出來討論的技術實現上的細節，都是值得產品經理參與進來的，在這些細節上如何取捨與抉擇，會對產品的開發進度、性能甚至功能帶來極大的影響，如果溝通到位，往往可以讓開發工程師少做大量無用功。在我開始自己動手寫代碼之後，對這一點有了越來越深的體會。

下面就說說我為什麼開始學寫代碼，算是回答問題的後半部分吧。

在我做互聯網產品的前五年里，我對技術的了解僅維持在常識範疇，能夠手寫的代碼只有html和css，連js都不會，更別提任何適用於Web開發的編程語言了。我一直認為自己無法完全親手寫一個哪怕是最簡單的動態網站，是作為互聯網產品人員，很大的缺陷和恥辱。

工程師們一般倒不這麼覺得，和他們聊天的時候，有時順嘴噴一些對技術架構或某些技術問題的看法，立刻遭到讚揚：「你很懂技術嘛！」這時馬上打著哈哈說：「懂個p啊，我連hello world都不會寫，完全是紙上談兵。」於是嬉笑聲中，一群人把手裡的箭收起來了。

但我壓根兒就TM不想只能紙上談兵，2009年，我不顧當時三十二歲的高齡，悍然決定要學Ruby，買了書、裝好環境開始看書，敲代碼，堅持了幾天，然後失敗了，考慮到也許Ruby對我來說太難，又嘗試了Python，結果還是失敗了。消沉幾天後不死心，又買了一本iPhone開發的書，還趁機決定買了台27寸的iMac，但悲劇是只翻了翻書，連Xcode都沒敢下就直接放棄了，這書上什麼都不講的啊！上來就是大段大段的代碼啊！而且obj-c的代碼都巨長，完全看不懂。

後來我想，這件事有兩個收穫：一. 發現了自己智商的邊界。二. 我有了一台iMac。

轉眼又過了一年多，想要自己動手做一個iPhone上的App的感覺越來越強烈，快壓抑不住了。於是在某一天，我好了傷疤忘了疼似的把那本幾乎沒有摺痕的iPhone開發基礎教程又翻出來，等待Xcode下載的過程中，暗下決心：看不懂我也把它背下來。

後來發現笨辦法至少對我來說，還挺管用的：照著書敲代碼，能正常運行的話，就合上書，再敲一遍。一般重複四五次就能記得很牢了。合著書，劈里啪啦熟練的敲著自己還不知道是什麼意思的代碼，加上Xcode的自動補全很給力，幾分鐘就可以折騰出一大屏花花綠綠的代碼，而且還能在iPhone上運行，這時會產生一種已經會寫iPhone App的錯覺，很奇妙。

人的大腦也很奇妙，你如果已經背下來了，本來不理解的就會慢慢自動理解，就這樣背了一段又一段代碼之後，突然發現：我明白是怎麼回事兒了。之後就開始給自己提出各種小的不能再小的功能需求，嘗試用這些代碼去實現，每實現一個，都欣喜若狂：我能顯示按鈕了！我能彈出對話框了！我能寫滾動列表了！我能發一條推送信息了！??

這些事兒在熟練之後，也許就像喝口水一樣平淡，但卻能給初學者帶來巨大的快樂，我一直覺得，能否始終保持如初學者般的熱情、專註，決定了在做某件事時能走多遠，能做多好。

由於書上所用的Xcode版本問題和我用的不同以及一些印刷錯誤，書上的代碼不會總是百分之百能運行，有時會報錯，只能上網用盡一切辦法搜，搜索的過程中，就會慢慢看到一些專門的技術論壇、Blog，最終不可避免的會發現Stack Overflow這個神奇的網站，你遇到的大部分問題，都能在上面找到答案。

當實現書上的功能已經不能帶來狂喜的時候，就會忍不住想把自己束縛了很久的各種idea放出來了，終於可以親手去做它，而不是局限在畫畫原型圖、寫寫需求說明最後還要虔誠的擦拭神燈，呼喚燈神們顯靈這樣隔靴搔癢的做產品。

開發的過程對我來說充滿了樂趣，因為寫代碼的時候，世界變的簡單而美好，某個做法對還是錯，你不需要自己反覆猜測，也不需要和任何人沒完沒了爭辯，編譯器就是神聖的裁判。你的每個操作都能得到及時、明確的反饋，而且擁有近乎奢侈的試錯機會，從這個角度來看，編程的樂趣倒是有點兒象玩遊戲。

當然也會遇到無數的問題，Stack Overflow、Github、Bitbucket、mailing list會慢慢成為你的朋友。

在能夠獨自寫出一個iPhone App並把它放到App Store上之後，我又發現還需要再學一門語言，用來開發網站以及需要在App中調用的RESTful Web Service，於是不顧三十五歲的高齡，再一次悍然打起了Python的主意，有了學obj-c的經驗，知道關鍵是要能狠得下心和靜得下心來，看什麼書，其實區別不是特別大，所以我就用了免費的Learn Python The Hard Way，用前面提到的方法，跟著做了一遍（前半部分比較簡單，可以每天做上十幾個exercise，後面速度可能會慢一點兒），了解了Python怎麼寫之後，馬上開始看Django Book 2.0，只看到第九章，就等不及用同樣的方法把Django Tutorial做了兩遍，接著驚喜的發現已經可以寫一個簡單但完整的網站了。然後很快試著用Django寫了一個特別小的針對某垂直領域的工具類網站，上線跑了一段時間，昨天晚上結束免費試用，開始收費，現在看到已有幾個付費用戶，我很欣慰。

至於技術需要懂到什麼程度，我覺得要是花幾個月學的東西就夠用一輩子，這買賣也太划算了，尤其是在技術領域，一定會需要持續學習，但對於我來說，已經沒有資格象十幾二十歲的年輕人那樣僅憑興趣廣泛的學，我目前對這件事的原則非常功利：馬上要用到的，能顯著提高效率或者公認是最佳實踐的就學，否則就先不學，盡量不折騰、嚴格控制投入的時間和精力。

比如寫好的代碼放到Server上，雖然只要能跑就算是部署成功了，但公認的最佳實踐是使用virtualenv隔離Python環境，這樣可以減少以後很多的麻煩，那就值得多花時間去了解，去應用；使用Fabric配合Git進行自動化部署可以大大提高效率，那就也值得花時間去學怎麼用。

我也知道可以用Memcached或Redis來做緩存，提高應用性能；或是用Rabbit Mq和Celery來做非同步隊列，可以改善同步執行耗時較久的任務給用戶帶來的不爽感；還有Node.js似乎比傳統的Web開發語言更適合做RESTful API ?? 不過這些都不是目前最緊迫的問題，所以雖然我還不會而且確定會有用，但先不去學。

一沒留神，噴了幾千字，還是打住吧，看來中年男人的啰嗦算是沒救了。

最後還是總結一下，就一句啊：

產品經理懂技術＝流氓會武術。你要是覺得幫派夠大，自己腦子又好用到可以當師爺，那不會武術也湊合；要不巧是個和我一樣沒什麼團隊精神，又老喜歡獨來獨往的流氓，還想只憑著腦子就能連點兒防身術都不練，恐怕很容易被人打成爬行動物。

比較嚴肅的總結是：產品經理懂技術，在沒資源的時候可以用最低成本把事兒辦了，有資源的時候可以把資源用的更有效率。

----------
廣告：

冷啟動是我和幾個朋友發起的產品經理培訓項目，可能是你能找到的類似課程中，最務實的。

http://mp.weixin.qq.com/s?__biz=MzIzODAyMDQxNA==mid=405012504idx=1sn=642ff95063e92ba2e92adf48107f8fd1#rd (二維碼自動識別)

【pm懂技術，看這篇就夠了！】

兩年前我入門的時候看這個問題就很困擾，

這個問題下的答案也沒啥乾貨，

我自己摸索了半年，

深感產品需要懂技術這點非常重要，

整理髮出來和大家交流學習～

下面詳細敘述下：

1.pm需要懂技術么？

要的，作為產品，懂技術可以和技術高效過需求，同時對自己產品／項目的把控度也更強。

舉幾個栗子：

1.不會因為不懂技術被嘲諷、被糊弄

我在做c端產品實習的時候，從來不管技術大哥如何實現，總是說：

-你怎麼實現我不管，我就要這個～

-這個功能不就是xxx么，你直接說要多久把～

-這次的需求很簡單，只要做xxx就行了，prd你看下哈～

搞得技術大哥很尷尬，而且在技術心中，這樣的pm地位很低，你啥都不懂，還特么想給我提需求？我自己也很虛，經常是跪舔著求實現需求的狀態，遇到case只能去找技術解決～

所以過需求的時候技術跟我說這個排期多久多久我就信了，導致有一次一個rd把我一個小需求拖了一個月，有時候直接跟我說這個需求做不了，我也就信了？

現在再也不會了，至少我會去追問「一個簡單的分頁為什麼要做這麼久？」

技術大哥會跟我解釋：因為一頁的數據來自不同的資料庫的不同表，做分頁就很麻煩～

那我覺得這樣的解釋ok啊，這時候說你排期吧才真的沒毛病！

2.寫需求更高效

你要知道你的產品的每一個塊都要落資料庫的，所以設計產品架構的時候模塊化很重要，有哪些欄位也很重要～

聽過一句話，你的產品架構，其實也是技術架構！一定不能亂（亂耦合）！

所以在寫需求的時候，一定要寫清楚產品結構圖，另一方面，知道別人怎麼工作的，寫需求才能按照他們的思路去寫，比如：

前端要做哪些？欄位、樣式、交互（操作前、操作中、操作後）、邊界條件（字數、圖片尺寸等等）

3.過需求更高效

我來點評之後第一次過大需求，拉著前端、後端、qa開需求會，我從頭到尾把需求說了一遍，自認說的很詳細了，結果大家還是一頭霧水，問題不斷，於是我又按照自己的邏輯說了一遍，還是一堆問題。

這時候，我mentor打住我，讓大家停一下，然後對著開發挨個說：

對前端說：我們這邊新增了哪幾個頁面，ui設計稿什麼樣的，交互是什麼樣的...前端done!

對後段說：我們這次的產品大邏輯什麼，新增了哪些欄位，最重要和複雜的邏輯是哪些，可能要哪邊的介面，那邊的技術已經幫你找好了....後端done!

對qa說：這次的迭代和之前有什麼不同，最重要的測試點是什麼，有哪些風險要測下，回頭上線的時候跟我說下我們一起看下...qa done!

最後強調了下項目的目標和重點，拉著大家過了下估時和排期，整個需求會done！

高效明了！！

所以啊，你要懂人家在做什麼，才能跟人家進行有效溝通～

4.對自己產品／項目的把控度也更強

實習時候的一個項目的時候，從b端招商-錄入系統-c端展示都是由不同的團隊負責具體的某一塊，只有我一個人知道整體的邏輯架構，當時出了一個case，目前的流程看似是無法走通的，但是其實如果了解底層是如何實現的，完全可以從技術角度去解決，這個case出現的時候我還請假在學校，打了幾個電話就解決了，就很踏實很放心。

這個時候，我才意識到，作為產品owner意味著什麼，意味著你特么是最了解整個產品所有細節的人！你要對整個產品負責！出了任何問題都會來找你！你是所有人的backup！你說你不懂技術不了解底層行么～

2.pm要懂哪些技術？

論技術，我只是個外行人，

自己結合工作中遇到的問題摸索了下，

了解到了一些皮毛，很多知識我都簡單化了，

和大家分享下，給大家提供點學習的思路～

下面從按照：前端、後端、app端開發三方面闡述

關於技術，你要先知道的是：

瀏覽器前呈現的內容基本是前端負責，瀏覽器後傳過來的數據和邏輯大部分是後端負責

為了加深印象，你可以先看看這篇文章：你剛才在淘寶上買了一件東西 - dunnice - 博客園

看完了我們接著看～

2.1 前端

前端=html+css+js=&>結構+欄位+樣式+交互

（我喜歡公式化拆解，這樣是為了便於理解，並沒有不尊重前端大哥們哈～）

對於前端的工作，了解以上問題，前端的大體工作基本就清楚了～

建議通過下面的渠道方法來進行學習：

a.w3school 在線教程

去看下html結構、標籤和css的內容，看一點懂就好了，不要求會敲！

HTML 全局屬性

HTML 事件屬性

第二個鏈接中的表都快成為我交互checklist了～

b.chrome 開發者工具：大殺器！直接讓你看看人家前端的代碼是怎麼寫的哈～

可以從這篇文章著手查看Chrome開發者工具不完全指南（一、基礎功能篇） - 賣燒烤夫斯基 - 博客園

c.慕課網 你可能要去了解下 ajax、json這些東西

JavaScript教程-JavaScript入門視頻教程-慕課網先看這節課

Ajax全接觸-慕課網再看這節課

這兩節課程非常短，一定要看完！！

看完之後，相信你對前端大哥的工作已經心中有數了～

d.其他

關於前後端如何進行數據傳輸：大部分是通過api介面的方式獲取，所以你需要了解的有：利用「介面」做產品時我們該如何思考？ | 人人都是產品經理

關於現在常用的h5：還請看下這篇答案：H5 是什麼？

2.後端

其實後端大哥寫代碼，所用到的不同編程語言，函數，編碼方式各有不同，我們完全不需要知道他們是如何實現的，業務層的邏輯我們只需要自己搞清楚就好了，只要你做到以下幾點，基本和技術大哥沒有隔閡：

1.需求目標想清楚，細節說清楚，原型畫清楚，邊界條件想清楚！

2.態度端莊，報以詢問尊重的語氣讓技術大哥給你評估需求，並排期，千萬不要說「不就是xxx么」

3.對需求負責，不要亂改需求，不要頻繁改需求，改需求時態度好點並帶上奶茶～

然後有空可以看看下面這個問題，不要提出一些傻逼嘻嘻的需求：

有哪些產品經理認為很簡單，實則開發很難的技術？

a.從技術理解一個產品，大概可以分為5層：

邏輯層——把產品需求翻譯成邏輯
實現層——具體的函數方法、寫代碼
介面層——各模塊交互的通道
數據層——程序執行的結果
架構層——技術的抽象、結構、調用關係、規範

此處參考@pm0238老哥的回答！

這裡面，pm一定要負責的是邏輯層，你在設計需求的時候，要有【模塊化】的概念，

說的簡單點，就是每一個業務就是一個模塊，那麼底層的技術那邊也是一個模塊！

模塊越清晰，每個模塊之間不要耦合在一起，這樣回頭迭代起來就越方便，

不然就會出現，你覺得加一個小功能很簡單，但對於底層但技術來說，完全就是兩套技術架構～

此處借用網上的一張圖，關於酒店業務的，每個業務都是一個模塊，迭代起來非常方便

ok，那剛剛說的，如何如了解後端技術呢？其實也有個公式

程序=演算法+數據結構

（我這樣說只是幫助理解，rd大哥們真的不要打死我啊...）

b.演算法

演算法這邊非常複雜，我的建議是，如果你不是專門的做演算法方面的產品，

了解演算法的邏輯就好，不要求知道怎麼實現的，有些比較有趣的演算法，比如

網易雲音樂的歌單推薦演算法是怎樣的？

大家如何看《今日頭條》的個性化推薦，如何實現的呢？

如何評價知乎的回答排序演算法？

這些有趣的演算法都可以了解下，對掌握技術都很有幫助的～

c.資料庫

只需要會一種技能：sql

真的，從周邊同行來看，感覺sql已經成為pm必備技能之一了，大家都在寫sql

為什麼呢？因為要關注數據！但是不可能一個小數據都要bi幫你寫，所以只有自己寫！

所以關鍵點在於 數據驅動產品的發展～

我曾經問過我的一個技術大哥，我怎樣才能走進開發大哥的心

老哥抽著煙看了我一眼，說：你先把底層的資料庫好好看看吧～

可謂是一語道破啊..

關於sql，只需要看一本書《sql必知必會》，鏈接見下

https://pan.baidu.com/share/link?shareid=2505662611uk=2987501288fid=1123158373539826

很多人看到group by 基本就放棄了，講真，這本書不是讓你單純看的，平日里自己去寫一寫sql看看自己產品底層的表結構，神特么有意思好伐！而且寫sql這種事情真的超有成就感！

3.app端開發

其實這塊的只是我不是很熟悉，我自己因為做web端產品比較多，其他的產品也是在app上用h5頁面做的，所以基本上很少接觸，所這塊大家有興趣可以自己查看下哈，我能提供的就是說，注意下大家都會遇到的

1.不同系統的兼容性問題

2.不同版本的兼容性問題

3.不同屏幕尺寸的兼容性問題

4.android 和 ios 系統的規範（這個直接百度能查到很多～）

5.android 和 ios 打包發布流程

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

最後說一些別的吧

1.產品懂技術，為了是提高溝通協作的效率，而不是為了流氓會武術，絕對不能報著學會了點技術皮毛，看你以後還敢不敢糊弄老子的心態，這樣永遠沒法協作好～

2.提高效率最好方法是和rd大哥搞好關係，提需求改需求，認真負責，態度端莊，私下相處和睦～多技術都很有自己的想法，有時候一些老員工，他們對於業務的理解比我們還要深刻，多溝通，多交流，多學習，ok的～

3.關於技術知識，我提供的只是通用的很少很少的一部分，建議大家根據自己的產品或業務實際情況來學習，不要悶頭去鑽研如何寫代碼！技術大哥嘴裡蹦出來不懂的技術名詞還請百度去查看，一定要厚著臉皮把自己產品的底層邏輯問清楚了～

4.作為產品，需求靠不靠譜才是關鍵，懂點技術只是提升效率，如果你需求不靠譜，方向錯了那麼提高效率也只是加速了走向墳墓的時間罷了～所以大家不要鑽到技術眼裡去了，滿奶子都是技術，有個leader曾跟我說：低頭做事，抬頭看天～共勉

以上，就是我這半年來摸索出來【產品經理懂技術】的一些感悟～

已同步到專欄，歡迎關注哈猜花星の產品路

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

胸弟，我寫的有點辛苦，點個贊or關注下唄～

Ps : 收藏量是點贊的2倍，傷心了...

歡迎關注個人專欄，只寫產品乾貨

http://zhuanlan.zhihu.com/caihuaxing

不一定。
不同業務的成功關鍵可能是技術/產品/運營/銷售/投資等不同點；
一個業務的不同發展階段，上述關鍵點的重要性也可能變化；
作為一個創業小團隊，團隊成員對「產品經理」的定位和期望，很重要但也會影響答案。
所以，要結合你創業的領域和團隊尋找答案。
當然，即使非技術出身，做上產品經理後，該領域的技術你也應該是越來越熟悉，避免在做產品決策時拖後腿。

我的觀點是：產品經理要比開發人員更懂技術。

懂技術，不意味著寫代碼比工程師更好，而是明白技術能用來做什麼。這個非常重要。

懂技術，也會理解開發人員，一起做事情更會得心應手。

懂技術，在針對一些功能實現的可行性上，才會有所取捨。

依我看，產品經理需要懂技術，而且還要寫代碼，寫過代碼和看過書完全是兩回事。
但是不需要水平有多高。
哥這麼多年七七八八學了點技術，雖然至今還是菜鳥，但是比完全不懂技術的，還是感覺踏實很多。
不過我從一開始就是最簡單最實用的VBA、VBS、JS入手，目的就是操作EXCEL操作電腦里的文件，跟DOS批處理似的，生產出來的代碼直接就是簡化自己日常工作的。到後來我做的東西給全公司人用了，直接提高了大家的生產效率，以至於有人要求技術也開發一個專業的產品來，可惜產品出來大家還是寧可用我的腳本，不用專業技術做的EXE程序，雖然我的腳本程序幾乎沒有界面，但操作簡單夠智能。
我建議所有文科生想學技術的，不要跟風開發什麼蘋果APP，先學點對自己工作直接有用的腳本語言，簡單歸簡單，其實沒啥可恥的。
做出來的東西自己就是第一個用戶，每一次的改進對自己都有好處。這感覺是非常的爽。
一上來就學一些特高級特潮流的語言，或者特低級特底層的語言，我覺得都沒什麼好處。你要是問專業程序員，他肯定推薦你學C、C++什麼的，理由是學了之後基礎紮實，啥也不懼，我擦，他自己對外宣稱要花一輩子吐血去學的東西，再讓你去學，你說這算怎麼回事？
你懂得if else，懂得循環，懂得資料庫怎麼回事，懂得面向對象是啥意思，這就夠了。你說你要學會用指針有什麼意義，你會操作內存又有什麼意義，你理解什麼是多態又有什麼意義？

學技術的目的是為了用，而不是做屠龍高手，華山論劍。
（其實有很多技術人員，貌似屠龍術不少，一張嘴就是沒有啥實現不了的，真到了開發的時候，複雜點的業務邏輯都能把他給圈糊塗了。）

依我看最好的學習辦法不是看書，而是直接COPY幫助文檔里的示例代碼，改，調試。
還有，不要被IDE折騰死了，IDE固然方便高效，但是新手裝個IDE真是挺煩的。

所以建議學技術還是先從腳本開始（但不建議學rubby和python），開發產品先從網頁開始。
你寫PHPjs代碼，根本不需要什麼IDE，乾淨利落editplus直接就上了，調試直接就瀏覽器。你搞什麼安卓開發，你裝java裝eclipse完了還要下載一大堆android的東西，速度慢得跟牛一樣，一大堆版本問題，還有模擬器。你搞IOS，你還要有MAC，還要註冊神馬的。
搞完這些你都吐了，往電腦里裝了N多亂七八糟的玩意，卻連一句代碼都不懂，你說你是何必？你搞網站，網上有現成的三件套，apache+mysql+php，一次性全裝好，放個只有一句echo的頁面到指定文件夾，當時就可以看到「網站」效果。至於VBA，直接在wordexcelppt里就帶了，錄個宏，你改一改就是你的第一個可運行有用的程序！批量處理一些EXCEL上的工作，瞬間解放生產力。
神馬hello world，關你屁事啊？！
花幾天時間，跨過最初的障礙，很快你就可以理解工程師的爽和痛了。
再往後，你要學C學JAVA，做個windows下的EXE，做個安卓APP，那都是看你的毅力了，起碼你不會被唬住了。什麼代碼之美，各種程序員們爭執的牛B問題，你都可以逐步理解。
以後技術再跟你說什麼，你哪怕不懂，上網搜搜也能明白。
如果你非要選擇買個什麼很吊的書在那裡狂看，十有八九你永遠跨不過障礙。到頭來你還是啥也不明白。
如果你連VBA和JS都害怕。你可以學HTML+CSS，這些雖然不算編程，但至少學了有收穫有用，沒事弄個博客，自己還可以改改界面，比你啃完一本破書還是啥也不懂要強多了。

不過懂了技術，不代表就能和程序員和諧相處。

如果不懂人情事故，就是程序員轉產品，也未必能和程序員打好交道。

產品經理相關問題答案：

磨牙行者：面試一個產品經理（PM），如何考察他在交互與用戶體驗方面的能力？

磨牙行者：做產品經理是不是要很聰明？

磨牙行者：什麼是「定義」？

磨牙行者：不懂技術的產品經理想學習技術要從哪裡開始？

磨牙行者：為什麼知乎上很多人喜歡把一個很簡單就能說明白的答案寫成長篇大論？

磨牙行者：在蘋果都把屏幕改為4.0吋的今天，如何看待羅永浩依舊要做3.5吋的手機？

個人認為可以分階段看。

一、pm的成長本質上是不斷假設，不斷驗證的過程。大概是7個階段：
入門階段p4，
練習階段p5，
熟練執行p6，
創造價值p7，
權衡決策p8，
變遷階段（產品架構師）p9，
封神階段（上帝視角）p10.

二、技術理解大概可以分為5層：
邏輯層（把產品需求翻譯成邏輯），
實現層（具體的函數方法、寫代碼），
介面層（各模塊交互的通道），
數據層（程序執行的結果），
架構層（技術的結構、調用關係、規範）.

三、不同階段pm有不同的使命和技能要求

-p4階段的pm：是打底子的階段，這個時候你去研究技術是沒有意義的，這個時候的使命是產品入門，熟悉業務、練習工具，掌握產品設計基本功。
-p5階段的pm：是不斷訓練自我的階段，這個時候必須注重邏輯層的訓練，例如畫流程圖，窮舉從0到n每一種情況的解。
-p6階段的pm：之所以叫熟練的執行者，因為他是公司戰略落地的中堅力量，要求每一個解法都是最優解，因此這個階段的pm最需要加深對技術的理解。
訓練方法是同理心代入，即換位思考，站在rd的角度思考邏輯是否有漏洞，函數是否可復用（開發成本），介面如何定義，涉及哪些欄位，數據如何流轉，日誌能否順利入庫。
pm同理心代入rd的對象，越是高階、架構能力越完美，對pm的成長越有好處。

因為技術架構和產品架構本就是相通的。

當然也不能沉迷於技術，即，可以只了解但不掌握技術實現層的能力。而邏輯層、介面層、數據層、架構層是必須深入理解的，這樣pm才能不斷給出最優解，掃除需求中的隱患（掃雷）。

#為什麼不能沉迷實現層？——因為pm要做的是傾聽並認同rd，而不是指導rd，過於沉迷實現層，你就完全變成了rd，會冒出一堆這句代碼應該這麼寫，這裡應該這麼實現的想法，反而會讓rd反感。#

-p7階段的pm核心使命是創造，由於這種創造往往涉及到新技術、新解法，因此更注重架構層。
這裡有人可能會說，我見過很多高階的pm不懂技術架構，也沒見他們畫過架構圖，但是他也做的很好。

我的看法是這樣的：技術架構、產品架構、組織結構，本就是相通的。p7以上的pm，他們能夠在日常的組織溝通中，潤物細無聲的掌握組織架構，進而理解技術架構。

不信可以隨便找一個p7的pm問他們技術團隊是怎麼分工的，他一定能給你講清楚：我司的rd有*個組，分別叫abcde，他們分別負責***，其中e組是我創造了**業務/服務後專門組建的。

還會覺得他不懂技術架構嗎？

不可能不懂的，只是沒有專門去梳理畫圖而已。

p8以上的能力都是已經被驗證過無數次的，他們要麼同理心極強可以看人知事，要麼經歷了無數的權衡，其決策的複雜性早就超出了架構本身。

也許你的老闆當年就是在和rd聊天的時候掌握了組織架構，進而在心中投射出技術架構，並hold產品架構。

四、p5p6階段的pm如何訓練技術理解
1.邏輯層必須精通：畫圖，流程圖、邏輯圖。但要注意別亂畫，一定要先有主幹，再有分支，脈絡清晰。不要畫整體的邏輯圖，判斷的主體不要一直在變，每一個技術模塊的判斷要解藕，不然rd會很難受。另外必須精通所負責業務的訂單狀態機，不然很難獲得rd發自內心的認同。——精通的標準是獲rd認同點贊

2.實現層了解即可：掌握基本的概念，mvc、面向對象（封裝、多態和繼承）類、方法（函數）、調用，可以看懂簡單的代碼，了解常用函數，不了解的可百度自查。如感興趣，可自學python，寫幾個函數。——了解的標準是和rd聊天暢通無阻

3.介面層也必須精通：因為往往涉及到多個模塊，多個團隊，60%的問題都是欄位理解不一致導致的。p6階段的pm必須掌握每一個核心介面，尤其是後端與前端的介面，準確記住核心欄位的定義、類型、返回值，否則在我看來都是會出問題的。——精通的標準是介面文檔心中留

4.數據層要做到熟練掌握：因為p6的pm往往是團隊的中流砥柱，是一切的兜底，比如數據分析師生病了，難道昨天的數據就不看了嗎？我認為現在pm的競爭比前些年要激烈的多，標準也嚴格的多，除非極少數天賦極高工作不久就突破p7的pm，95%以上的p6同學都必須熟練掌握sql.當然這個要求也和業務相關，不同的業務對pm的要求不太一樣。對於滴滴、美團這類的強業務產品，熟練掌握數據工具是必要的。——熟練掌握的標準是在數據獲取和分析方面能為團隊兜底

5.架構層：p6階段也應該熟練掌握，訓練方法有三種，一種是同理心代入，對於滴滴、百度這樣的公司，pm每天能接觸到高階的技術架構師，在日常聊天交往的過程中，代入對方去理解他們的思想，理解他們創造的架構。
第二種是組織架構代入，就是通過熟練理解rd的分工，理解人與人之間的關係，映射到技術模塊，進而理解技術架構。
第三種是畫圖，在前兩種方法的基礎上，畫架構圖，如遇困難可翻閱rd的文檔甚至當面請教。——熟練掌握的標準是瞭然於心

總結：對大多數天賦正常的pm，除了實現層可以理解即可，其它的（邏輯、介面、數據、架構）都要熟練掌握甚至精通。

（註：p8的以上部分也是我自己同理心代入老闆的視角體會的，未必正確，大家自行感受。）

最後，#我所說的，都是錯的。#

先說結論：產品經理需要懂技術。

1比自己團隊的程序員更「懂技術」。
這裡說的技術是指當前行業的XX技術到了哪一步，競爭對手的技術有什麼創新。產品決策其實是商業決策，商業本質之一是「開源節流」，「懂技術」就能夠更清晰地把握系統的現狀。
產品經理要比程序員更懂行業，行業的業務知識對產品經理是很重要的，有助於設計出一個滿足用戶需求的體系結構。要比程序員更懂行業里的那個領域。能夠「給」出自家產品所在的領域，業務領域的架構，只有技術架構和業務架構緊密結合才有可能真正創造出一個好的系統!（好的系統就是一切）
這樣的好處就是：
1知道一個東西實現的基本原理，以及目前的技術能力能否實現。
2可以方便你協調好「產品」和「開發任務」之間的關係。

2需要懂技術。
這裡說的懂技術是指：要知道自己團隊每一個程序員哥哥的真實水平，他們什麼性格，相處方式。

3要懂技術。
這裡說的就是：你得學點計算機語言。那就從「python」入手吧，這是我的小建議。

更重要的是：比起「能坐下去敲代碼」，產品經理更重要的是「綜合能力」——最起碼的邏輯能力、資源整合能力、溝通能力、協調能力、項目進度掌控能力、立足於市場、產品和行業的直覺和想像力—這一切都將表達在你的產品里，有道行的人，一眼看出來。

產品穩定以後，要能在：開發語言、設計模式和開發平台不斷地升級，同時還需要吸收這些新技術新知識，並將它們用於開發工作中（雖然只是分配工作給別人）——這個技術叫大技術，主要是技術實現的邏輯層面，而不是技術細節，什麼叫技術邏輯層面什麼叫技術細節了，討論什麼語言更好叫技術細節。

當然，產品經理最重要的還是「產品思維」，學習技術只是為了走得更穩，千萬不要舍主求次。你可以懂技術，但千萬不要有「程序化思維」。

洗澡前手機不到一個小時的快碼，邏輯有點亂，將就著看吧。

某位辯論界的前輩教導我們說，要先定義問題，再回答問題。

「產品經理需要懂技術嗎？」

首先，產品經理需要懂技術嗎？

大家通常提到的產品經理，更多的是產品設計師，或者用戶體驗產品經理。除此之外，還有後台產品經理、需求分析師等很多種。

從行業角度，也可以分做技術型產品的 PM、設計型產品的 PM、運營導向產品的 PM。再細點，更可以分出電商產品的 PM、社交產品的 PM 或者搜索產品的 PM 等。

某招聘網站上，產品經理的常見分類就有很多：

顯然，每種產品對應的產品經理，所需的技術知識都不會相同。

大致上說，做的產品技術實現比較難、邏輯複雜的情況下，產品經理應該多少有些了解。百度搜索的產品經理，不可能對搜索演算法不敏感。而產品實現並不困難的情況下，或者說非技術因素更重的產品，可能就不太需要了解太多技術背景。

其次，產品經理需要懂技術嗎？

我們在寫簡歷的時候都知道有一種寫法，是把技能描述成「精通」、「掌握」、「了解」什麼的，我其實覺得很沒意義，因為根本解釋不清楚。

有的甚至還能畫出經驗值的橫條，這是在玩 RPG 嗎：

如果說精通 PS，到底是精通到可以手繪出蒙娜麗莎，還是精通到可以給女朋友修個不跪鍵盤的照片而已？我們需要的是實際的描述。

同理，「懂」這個詞也可以解釋成很多行為。我知道 Java 和 C++ 的區別算不算懂？我可以設計數據結構和一些演算法，算不算懂？我能夠自己上馬實現所有代碼，算不算懂？

最淺層次的「懂」，我覺得任何產品經理都要達到的。很多產品經理居然都不知道自己產品的後台用什麼語言寫的，也不知道 API 是什麼概念，更不知道產品包含的所有數據是怎樣流通的，這算是不及格。

而比較高層次的「懂」，到底是不是需要懂得讀代碼、需要懂得寫代碼，都是要看實際情況了。

再者，產品經理需要懂技術嗎？

技術到底是什麼呢？

大多數人只會把技術理解成代碼，是在編輯器里一行一行蹦出來的東西，蹦得越快代表寫的越好。比如，很多人看《戰狼》時到這裡覺得好有逼格，但程序員會覺得為毛在作戰的時候要列印日期：

除此之外，其實還有很多純技術的工作，並不是單純地實現軟體。有很多技術型公司里，會有演算法設計師，還有各種各樣的架構師。大公司里，技術顯然不是單純的安卓或者 iOS 開發。比如我查到很多 BAT 在招聘的崗位就有很多無關直接代碼實現的：

過程改進
安全專家
數據挖掘/機器學習
廣告投放策略
搜索演算法
資料庫專家
自動化測試
...

現在大數據這麼火，很多公司都有數據部門，他們的技術細節跟開發部門的一樣重要啊，他們的技術算不算問題里的技術呢？

我的理解是，任何產品工作中接觸到的技術，都應該算作產品經理「有可能」需要了解和學習的技術。包括演算法、技術邏輯、數據結構、架構、整體框架等等，只說代碼實現反而是比較次要的。

好了，說了這麼多，就應該回答問題了。

其實問題里有個詞，就是很好的解答：看是不是真的「需要」。

我們總結下剛才提到的所有信息。

先把這些縷清楚，然後做幾件事：

定義產品崗位在公司中的職責（是不是需要參與項目管理？是不是需要完成邏輯設計？），然後看自己在產品部門中的位置（是實習生還是總監？）
反思或者預測自己產品工作中可能接觸到的技術（很多情況下會是數據結構、演算法和實現邏輯，而非代碼語言），然後跟相關的同事做一些溝通了解。
做出最後的判斷，究竟該搞懂到什麼程度，會對工作有極大幫助。

之前在鎚子的時候，做安卓系統，我們會對原生提供的一些可復用的模塊很熟悉，這樣我們會設計出成本更低的方案；在做上門美甲以及現在的眾包物流時，我們會跟開發的同事一起設計訂單邏輯和數據結構，因為這些既跟具體實現的方法有關係，也跟用戶對產品的使用效率有關係。

這些可以算作技術，卻並不是日常生活里理解的「用 C 語言寫一個排序」那樣的技術。比較讓人頭疼的是，很多人問出產品經理是不是需要懂技術的問題，腦海里想的是下個星期要不要報個 Java 學習班或者買本《7 天學會安卓開發》，這是很荒謬的。

所以，定義清楚了問題，你也許很快就知道自己該做什麼了。

作為一位工程師，和一位在不斷追求更好產品的設計人員。個人認為，產品經理最好是這樣的：

一、精通技術。技術很容易框住人的思想，要不特別精通，能隨時跳出技術的束縛，帶給產品真正的提升。一般這種產品經理會出現在像 Facebook 和 Google 這種工程師能主導產品的公司，或者一些技術型創業公司。

二、不懂技術，喜歡天馬行空，又能聽得過工程師的建議。精於產品的設計，生命周期管理。

如果只是略懂點技術，可能（注意，是「可能」）會帶來思想上的限制。一個人永遠不能管得了那麼多，精通得了那麼多。有時候我們更需要的不是會技術又會懂產品的產品經理，而是相信夥伴能做得好，並鼓勵其一起去做得更好的產品經理。

我覺得產品經理不需要懂技術，至少不需要自己懂編程，會寫代碼。產品經理非逼著自己學習編程實在沒有必要。但是，產品經理有一項素質非常非常重要，就是邏輯思維能力和抽象能力必須非常強。

在現實環境中，產品經理被研發人員鄙視或者消極配合，很大程度上是因為產品經理設計的產品功能、流程存在邏輯上的硬傷。研發是負責具體執行的，一旦落實到細節，這些問題就會暴露。研發是很強調邏輯思維能力和抽象能力的，但是產品經理必須具有更好的邏輯思維能力和抽象能力，這樣才能指導好研發做產品。

我招聘產品人員，培養產品人員，非常注重邏輯思維能力的訓練。現實中邏輯性好的產品經理和研發配合都不錯。

產品經理其實不需要懂代碼里的細節，但最好知道實現這個功能的技術模型是什麼樣的，理解一些術語。有一定的開發經驗最好了，不懂也可以工作後補一點（我看到我同事就買了本JAVA編程思想，嘖嘖），主要是為了與技術順暢溝通，少提出讓技術覺得不可行的產品設計。但要注意不要讓技術束縛了你活躍的思維。

觀點：產品經理什麼都懂一些最好，懂技術更好，但不要求，了解即可。
產品經理核心技能1、溝通能力
2、無授權領導能力
3、學習能力
4、商業敏感度
5、熱愛產品
6、注重細節，追求完美
7、日常產品管理能力

除了產品經理必會的技術比如Axure, Photoshop, Visio等，其他技術盡量多了解，像Javascript, Html5, Css,SQL，以及其他數據分析技術。總之如果想做一名優秀的產品經理，就要不斷學習，學習各種知識技能，知識面越廣越好，從各種渠道汲取最新的有營養價值的內容。

雖然大部分公司不嚴格要求產品經理一定要會寫代碼或懂很多技術。但是由於產品經理需要和各個部門溝通，當你和其他部門溝通時經常會遇到一些比較專業的代名詞和技術，如果你一點都沒接觸過那你會覺得他們都是在說天書，開會的時候也會覺得無法快速融入。但你了解一些技術之後，遇到產品設計時或需要決定產品發展方向時，對於產品開發實施的可能性也會自己有一定的把握。所以能多會的技術就多學習，畢竟技多不壓身。

除了技術以外，產品經理還需要對產品所在的行業進行深入了解，包括競品分析，產品需求分許，用戶需求分析。同時還要時時關注行業最新資訊，包括行業最新技術，競品最新發展動態，國內外行業發展情況，多關注熱點新聞。

見過一些不懂技術的產品經理，做得比較出色。也見過一些技術出身的，做得相當出色。
感覺產品經理做得好不好，與是否懂技術無關，技術也是把雙刃劍。
採訪過的一個技術總監兼產品經理說，懂技術可以讓你知道哪些東西是肯定做不了的，避免浪費資源，但同時也會制約你的想像（也算是一些條條框框）。

抱歉，我來晚了！

我相信絕大部分想從事產品經理工作或剛入行的產品經理都會問這樣的問題：做產品經理要不要懂技術？需要懂到什麼程度？怎麼著手學習技術？
一直想寫點什麼，剛好遇到這個問題，現分享下個人的理解，核心觀點就是我的簽名。

到底要不要懂技術？
產品經理也分多種類型，不同類型的產品經理對技術的要求也不盡相同。總的來說，產品經理懂一定技術是有利於其工作的。原因請往下看。

為什麼要懂技術？
產品經理學點技術知識，無外乎以下3點：
1、實現與技術無障礙溝通。非同步通知、回調、ajax等總得知道吧。
2、更深層的考慮產品的實現。以技術的角度簡單判斷方案是否可行，而不至於方案總是被推翻，總是在改需求。
3、提高工作效率。如會資料庫查詢就不需要麻煩開發大哥了，如果會簡單的編程可以處理特定的文件而不需要人工處理。更高級點，做個定時任務把你每天需要看的數據獲取到然後發送到你的郵箱，每天在上班路上就可以看這些數據。

需要懂到什麼程度？
知道為什麼要懂技術也就知道了需要懂到什麼程度了。
一般而言，個人覺得
最低要求：能和技術無障礙溝通，有那麼一點點不懂得也沒關係，多問。
基本合格：能夠想想技術上大概的實現過程，各個介面之間是怎麼調用的，數據是怎麼存取的。
優良水平：會一門編程語言，夠用即可；熟練MySQL語句。

建議學習哪些
1、資料庫相關知識：主要了解關係型資料庫與非關係型資料庫的區別，熟練掌握MySQL查詢語句。
掌握資料庫的查詢操作還是能給工作帶來不少的方便的，比如在技術忙的時候就不需要勞煩技術大哥了，也免得被嫌棄。如果有些數據是需要定期分析的（比如每天都要看或者每周看的），那可以實現定時任務將所需數據跑出來。
之前有一篇關於資料庫的回答，可以參考下
產品經理如何學習資料庫以便進行數據分析？ - 互聯網
2、掌握一門編程語言，目前使用廣泛的java，寫爬蟲程序較多的python，還有前後端通吃的node.js
可以寫寫小程序或者介面啥的，比如我的知乎專欄中有關於身份證號碼及銀行卡號規則的文章，你是否能按照這樣的規則寫個小腳本，自動判斷是否符合演算法。再如給你卡BIN資料庫，你是否能寫個卡信息讀取介面？
以上涉及的部分內容，可能需要到本人專欄查看支付結算雜談 - 知乎專欄
3、有時抓個包也可以是產品經理的一項技能，雖然不要求一定會，但是學習比較簡單，還是可以學下，抓包工具推薦Charles

有哪些學習技術的途徑？
1、傳統的書籍，也可以藉助互聯網學習及提問，這塊不過多介紹
2、作為產品經理，自學能力怎麼能不好呢，知乎上這塊的熱門回答很多，也可以參考
給技術基礎較差產品經理推薦的技術相關書籍有哪些？ - 產品經理
3、微信訂閱號中有個叫【給產品經理講技術】的訂閱號，還不錯，每天一篇文章，一點一點積累
4、別忘了身邊那麼多開發，都是你的老師，多問沒關係，大眾場合不方便問可以一起吃飯的時候問，姿態很重要，多請教
5、爬蟲式的學習方法，即在學習查找某個知識的過程中，其實還會有其他相關的技術，可以順藤摸瓜進行學習，這樣學習速度會非常快。

需強調的是，學習這些技能是以掌握產品經理核心能力（需求挖掘、邏輯思維等）為前提的，千萬不要舍主求次，更不要被技術束縛了產品思維。

申明：本人並不是技術出身，且產品分多類，以上觀點僅代表個人認知，無法使用所有的產品崗。

========================
會點贊的同學是個好同學
========================

如對支付結算感興趣，請移步支付結算雜談知乎專欄

這要看你想做怎樣的產品經理，是【現代的】還是【古代的】？
前者代表的是互聯網浪潮下滋生的一大批互聯網產品經理，後者是一批在科技界披荊斬棘活下來並自稱產品經理的人。

現代的：Web技術革命、移動互聯網的發展使得互聯網產品這一細分職業得到發展，有些順勢而上的產品經理們不需要懂技術，他們需要懂用戶心理，拿捏市場和用戶需求，他們需要準確的判斷和執行，他們是互聯網浪潮的策劃人與核心。

古代的：或者是從古代開始到現在的。他們把握時機，積極發現，無論是技術阻礙還是商業敏感，他們都能發現並抓住。他們必須了解技術，因為他們就在這個科技領域裡耕耘和探索，他們有的享受著互聯網浪潮的紅利、有的帶領著技術革命踏上新的浪潮，他們不僅僅是弄潮兒還是潮汐的引領者。

技術不是代碼

需要懂點技術，但不需要具體到coding這種層面
懂點技術最根本的作用就是容易跟開發同事溝通，能理解對方說的，能把自己想的翻譯給對方。同事也可以關注最新的技術，輔助產品設計和規劃。

我認為產品經理就是要把自己磨練成一個通才，因為產品經理要面臨的工作很多，所需的技能和知識也很多，一個產品經理不可能把這些技能都精通的，一個技術轉型的產品經理經過鍛煉可以具有一定的營銷知識，但是永遠不會超過一個每天工作在一線的銷售人員，我記得以前我做產品助理的時候，每次和市場討論產品，都是心驚膽戰的，因為市場方面的知識畢竟不如人家，經常是被對方頂的一愣一愣的。因此，無論是從職位要求，個人能力還是工作特點來看，產品經理都應該是一個通才.

首先，我非常明確地說：
作為項目的推進者，產品經理必須了解整個項目涉及到的所有領域，這包括市場、管理、美術等等，這其中也包括代碼編程
一個產品經理如果不懂得美術出的圖是像素還是矢量，不知道客戶端和服務端，那是對自己項目的不負責任。
另外對這些領域，只要用心，勤奮，好問，智商足夠，一個產品經理完全是能夠了解的，而產品經理了解的內容，也完全是夠用的！
當然對每個領域的深入程度，卻是要根據自己的職業規劃，規劃考慮的。
+++++++++++++++++++++++++++++++++++++++++++++++++++++++
技術是很廣泛的概念，首先你得明確技術是什麼
比如在遊戲行業
玩法設計、數值設計、消費點設計、遊戲推廣、遊戲運營、活動設計，這些都是非常非常專業的技術，對於一個遊戲公司而已，能編程的程序員好找，但擁有將整個遊戲設計出來，並開發完成，上線盈利的產品經理（或者稱為策劃、運營）才是整個項目的核心。
一般而言，產品類、用戶類的技術（管理暫且不定義為技術）是產品經理價值的根本，代碼類技術在以上技術面前，並不具有很高的優先順序！
++++++++++++++++++++++++++++++++++++++++++++++++++++++
產品經理也是很廣泛的概念，首先你得明確你是什麼類型的產品經理
很多的論壇斑竹也叫產品經理，產品經理是一個爛街頭的概念，可以泛泛地分為
1、偏設計型
這個圖標要藍色的，這個button再放大點拉
2、偏市場型
我們的產品在市場的佔有率是x%，男性用戶多少，女性用戶多少，我們該怎麼推廣
3、偏程序型
這類產品經理往往是程序員出身。
第三類的產品經理，肯定是要會程序的，而且往往是程序員出身。
而對於前面兩類產品經理而言，用戶體驗，市場分析是其最根本的技術，而程序技術並不具有很高的優先順序。
++++++++++++++++++++++++++++++++++++++++++++++++++++++++
為什麼產品經理會有學不學技術的困惑？
人的精力是有限的，一個人可能掌握所有領域的技術，一個理想的團隊應該是，每個專註自己的領域。
而產品經理除了專註自身核心技術（市場、運營等）外，也需要了解項目所涉及其他領域，以達到溝通和項目把控的目的。
而這些了解，並不困難，而且也不需要非常深入。
那為什麼產品經理會有技術的困惑呢？
答：團隊本身或產品經理出現了問題！
1、無負責任的主程，無程序員管理制度，產品經理對整個項目負責，而技術無明顯責任，而這時候，產品就成了技術的評估者！
遇到好的程序員還好，若是遇到差的，出了問題，程序員可以無限誇大技術難度（反正你也不懂）。產品無法抓到技術的錯誤，而程序員卻可以記住產品的修改！這時候，出了問題，往往是產品經理擔責！
2、產品經理受質疑，缺乏威信
在IT團隊中，威信並不是由職位決定的，特別是在產品經理和程序員地位本來就平行的條件下，別人對你的信賴，來源於你職業的專業程度。
美術能用他的作品來證明他的專業，程序員用他完成的功能證明他的專業，而艱澀的代碼，又讓外人難以評價。
而產品經理，他的威信，來源於他過往項目成功的經歷。
但互聯網是失敗率極高的行業，大部分產品經理沒有牛逼產品，而是靠嘴、靠忽悠來向團隊成員以為他是牛逼的、專業的
但這種專業性往往很容易受到質疑，雖然你研究了幾年的用戶體驗、市場狀況，但一個沒認真研究過的人也可以發表自己的觀點，而只要他敢說，會說，他得到的支持，也許比你認真研究的成果更受老闆歡迎。
3、對自身的待遇的不滿
一般而言，相對於技術，產品經理的工資是很低的（牛逼的產品經理是少數）。
剛從學校出來的畢業生，做產品經理，和做程序員的同學一對比，落差之大，是很多產品經理新人想學技術的原因。
你想依靠產品一舉成名，但在這競爭激烈的市場，獲得成功的產品是極少極少的，更多的是失敗的產品經理，
往往，你工作了五六年，突然發現自己的待遇還比不上一個剛畢業的毛小子程序員，心理的不平衡可想而知，這也使你重新審視自己的職業規劃。
++++++++++++++++++++++++++++++++++++++++++++++++++++++
總結
1、產品經理是個入門門檻很低，但前途極其艱難的職業，牛逼的產品經理總是少數，而大多數產品經理終身不會有太好的產品。
剛出校門，你還能忍受比同學要低一倍的工資，夢想著有遭一日一飛衝天，但5，6年後，你做程序的同學已經小富。而你依然拿著低廉的工資，同時，一幫比你更能吹牛逼的年輕人已經進入了市場。大城市壓力太大，想回老家，卻發現，老家不需要你的職位，而當年考公務員的同學已經結婚生子。
2、所以建議所有的產品經理，入行前，認真審視一下自己的性格適不適合這個職業，自己有沒有足夠的魅力。別只想著一飛衝天，要考慮一下失敗的後果，給自己留條後路。對於軟體專業的學生，建議先做技術，在技術的視角學習你的產品經理。
3、如果你真的適合做產品，那就別在技術上浪費太多時間，你需要分析市場，你需要的是人脈，你需要更高的職位，你需要更牛逼的團隊，你需要更捨得投入的老闆，投資人。如果你團隊的技術和你不對眼，馬上讓他退出，或者你自己退出，產品經理的職業生涯很短暫，沒必要為必然要失敗的項目付出幾個月的時間。
4、如果是創業，你必須懂得技術，或者你有個做技術的老闆，否則你會死得很慘。
++++++++++++++++++++++++++++++++++++++++++++++++++++++++
註：答主不是產品經理，但答主為產品經理代言。

這取決於做什麼產品，以及做產品的哪部分，還有「懂技術」也有各種程度，總之這個問題不能一概而論。

如果是做監控寶（http://www.jiankongbao.com），我們要求產品經理必須懂技術，因為這本來就是技術型產品。
如果是做一個非技術型的產品，懂技術的產品經理可以更好的在合理設計、實現難度、性能三者之間做好權衡，如果網站沒啥流量，那性能就算了。
你可能說產品經理不用管實現和性能，理論上是這樣，但是前提是你得有一個比你這個產品經理更懂產品的程序員來幫你預見未來可能會讓你抓狂的問題。
那產品經理到底要懂多少技術？這是個世界難題，或許可以寫本《給產品經理看得技術書》哈哈。