最近七年，我都在做網際網路產品，其中前五年分別在創業公司和上市公司裡，做別人的產品；近兩年在創業，做自己的產品。
我的體會是：產品經理需要懂技術，創業者尤其需要。但前提是你總覺得有股憋不住的想要做點兒什麼的衝動，如果打算混安穩日子，特別是在大公司，你什麼都不需要懂，反而要小心別「知道的太多了」，傻人一生平安。
做產品這幾年，和開發工程師打交道最多，和他們交流通常有兩大忌：
一. 忌不懂技術
有常識，當然不一定就能做出好產品，但沒常識，就很象在村里呆了半輩子的人乍到城市，一舉一動即使小心翼翼，也沒法兒不透著突兀和不和諧。
這樣的人也許能忽悠某些領導，但一定不招工程師待見，他們可能什麼都不說，但心裡已經開始等著看笑話，交給他們的開發需求，自然也是能拖則拖、能蒙則蒙。
二. 忌懂技術
這句話聽起來相當豪邁，也讓產品經理大為放心，覺得技術真是產品的堅強後盾。但其實傳遞了乙個特別糟糕的訊號。
當工程師這麼說的時候，潛台詞是：「你弄好你自己的事兒就行了，別來管我！」而且這種說法隱含著乙個樂觀但顯然並不現實的假設：技術是無所不能的，他（掌握技術的人）也象燈神一樣，可以實現你的任何願望，只要你能明確的描述它。
我不知道阿拉丁說完願望之後，假如膽敢繼續追問燈神將具體採用何種技術方案來實現的話，會不會被塞到燈裡，但我知道很多任務程師在發現你關注技術層面過深的時候，都會有種領地被侵犯的感覺。
這就是工程師維護自己專業槽的本能，與行業中其它角色相比，工程師地位不是最高，待遇也不是最好，還經常加班加的要死要活的，唯一得天獨厚的優勢， 就是專業槽比任何角色都深。關於產品、關於ui、甚至關於商業模式每個從業人員都能噴上幾句，要是說到使用者體驗，那更是連業外人士都敢大噴特噴而沒有任何 心理負擔：反正我就是使用者嘛，越傻越光榮。而一旦涉及到**，大多數人就直接暈菜了。想想那些ui設計師的苦逼段子，工作時沒有噴子們指手劃腳的干擾，真 是上帝賦予工程師獨有的恩賜。
所以當他們認為有外人正試圖跨越這條槽時，自然會有所警惕，甚至體現出抵制和敵意。當乙個產品經理發現工程師開始比較密集的使用術語或拼命把簡單問題往複雜了說，你應該知道，他們在槽邊開始向你射箭了。
從整個產品乃至公司的角度來說，各個專業角色之間的專業槽都是應該被填平的，產品經理不該對工程師玩挾天子以令諸侯，不要總假裝自己是使用者的三個代 表，動不動就拿想象中的「使用者需求」當「奉天承運」來用；工程師也不必**燈神，假裝無所不能很累的，工程師之間必有能力高下之分，其實有時候功能做不了 或做不好，純粹只是因為工程師能力所限。如果彼此坦誠一些，大可以提前有效溝通，盡可能避開那些投入產出比過低的部分，有不少工程師不願意拿出來討論的技 術實現上的細節，都是值得產品經理參與進來的，在這些細節上如何取捨與抉擇，會對產品的開發進度、效能甚至功能帶來極大的影響，如果溝通到位，往往可以讓 開發工程師少做大量無用功。在我開始自己動手寫**之後，對這一點有了越來越深的體會。
下面就說說我為什麼開始學寫**，算是回答問題的後半部分吧。
在我做網際網路產品的前五年裡，我對技術的了解僅維持在常識範疇，能夠手寫的**只有html和css，連js都不會，更別提任何適用於web開發的程式語言了。我一直認為自己無法完全親手寫乙個哪怕是最簡單的動態**，是作為網際網路產品人員，很大的缺陷和恥辱。
工程師們一般倒不這麼覺得，和他們聊天的時候，有時順嘴噴一些對技術架構或某些技術問題的看法，立刻遭到讚揚：「你很懂技術嘛！」這時馬上打著哈哈說：「懂個p啊，我連hello world都不會寫，完全是紙上談兵。」於是嬉笑聲中，一群人把手裡的箭收起來了。
但我壓根兒就tm不想只能紙上談兵，2023年，我不顧當時三十二歲的高齡，悍然決定要學ruby，買了書、裝好環境開始看書，敲**，堅持了幾 天，然後失敗了，考慮到也許ruby對我來說太難，又嘗試了python，結果還是失敗了。消沉幾天後不死心，又買了一本iphone開發的書，還趁機決 定買了臺27寸的imac，但悲劇是只翻了翻書，連xcode都沒敢下就直接放棄了，這書上什麼都不講的啊！上來就是大段大段的**啊！而且obj-c的 **都巨長，完全看不懂。
後來我想，這件事有兩個收穫：一. 發現了自己智商的邊界。二. 我有了一台imac。
人的大腦也很奇妙，你如果已經背下來了，本來不理解的就會慢慢自動理解，就這樣背了一段又一段**之後，突然發現：我明白是怎麼回事兒了。之後就開 始給自己提出各種小的不能再小的功能需求，嘗試用這些**去實現，每實現乙個，都欣喜若狂：我能顯示按鈕了！我能彈出對話方塊了！我能寫滾動列表了！我能發 一條推送資訊了！
這些事兒在熟練之後，也許就像喝口水一樣平淡，但卻能給初學者帶來巨大的快樂，我一直覺得，能否始終保持如初學者般的熱情、專注，決定了在做某件事時能走多遠，能做多好。
由於書上所用的xcode版本問題和我用的不同以及一些印刷錯誤，書上的**不會總是百分之百能執行，有時會報錯，只能上網用盡一切辦法搜，搜尋的 過程中，就會慢慢看到一些專門的技術論壇、blog，最終不可避免的會發現stack overflow這個神奇的**，你遇到的大部分問題，都能在上面找到答案。
當實現書上的功能已經不能帶來狂喜的時候，就會忍不住想把自己束縛了很久的各種idea放出來了，終於可以親手去做它，而不是侷限在畫畫原型圖、寫寫需求說明最後還要虔誠的擦拭神燈，呼喚燈神們顯靈這樣隔靴搔癢的做產品。
開發的過程對我來說充滿了樂趣，因為寫**的時候，世界變的簡單而美好，某個做法對還是錯，你不需要自己反覆猜測，也不需要和任何人沒完沒了爭辯， 編譯器就是神聖的裁判。你的每個操作都能得到及時、明確的反饋，而且擁有近乎奢侈的試錯機會，從這個角度來看，程式設計的樂趣倒是有點兒象玩遊戲。
當然也會遇到無數的問題，stack overflow、github、bitbucket、mailing list會慢慢成為你的朋友。
至於技術需要懂到什麼程度，我覺得要是花幾個月學的東西就夠用一輩子，這買賣也太划算了，尤其是在技術領域，一定會需要持續學習，但對於我來說，已 經沒有資格象十幾二十歲的年輕人那樣僅憑興趣廣泛的學，我目前對這件事的原則非常功利：馬上要用到的，能顯著提高效率或者公認是最佳實踐的就學，否則就先 不學，盡量不折騰、嚴格控制投入的時間和精力。
比如寫好的**放到server上，雖然只要能跑就算是部署成功了，但公認的最佳實踐是使用virtualenv隔離python環境，這樣可以減 少以後很多的麻煩，那就值得多花時間去了解，去應用；使用fabric配合git進行自動化部署可以大大提高效率，那就也值得花時間去學怎麼用。
我也知道可以用memcached或redis來做快取，提高應用效能；或是用rabbit mq和celery來做非同步佇列，可以改善同步執行耗時較久的任務給使用者帶來的不爽感；還有node.js似乎比傳統的web開發語言更適合做 restful api ⋯⋯ 不過這些都不是目前最緊迫的問題，所以雖然我還不會而且確定會有用，但先不去學。
一沒留神，噴了幾千字，還是打住吧，看來中年男人的囉嗦算是沒救了。
最後還是總結一下，就一句啊：
產品經理懂技術 ＝ 流氓會武術。你要是覺得幫派夠大，自己腦子又好用到可以當師爺，那不會武術也湊合；要不巧是個和我一樣沒什麼團隊精神，又老喜歡獨來獨往的流氓，還想只憑著腦子就能連點兒防身術都不練，恐怕很容易被人打成爬行動物。
比較嚴肅的總結是：產品經理懂技術，在沒資源的時候可以用最低成本把事兒辦了，有資源的時候可以把資源用的更有效率。
產品經理要懂多少技術
產品經理是個辛苦的工作，除了要最熱愛產品，練功坐禪研究使用者體驗外，還要和一大堆人打交道 寫 的，做設計的，搞運營的，做市場的。前兩類人算是藝術家，自然會帶點藝術家特有的奇葩氣質，第一類人又是和產品經理打交道的人裡面最聰明的，乙個不小心，沒準就被程式猿們劃入 白痴 族群，作為茶餘飯後鄙視的物件。那麼...
人工智慧產品經理是否需要懂技術
對於產品經理是否需要懂技術，在網際網路時代一直是乙個非常有爭議的話題。在人工智慧時代的，或許我們可以有乙個準確的答案。個人覺得在人工智慧時代我們需要懂技術 而且是需要在自己所在的領域中掌握前沿急速的實現原理，諳熟每種技術實現手段的優劣勢，對技術的發展方向和技術如何融合產品經理自己的獨到認知。對於 懂...
產品經理需要懂技術到什麼程度呢？
很多想入行的新人都會想問 產品經理需要懂技術嘛？如果懂的話，又需要懂到什麼程度呢？我覺得產品經理對技術方面還是需要懂一點，但是精通就沒必要了，產品經理的主要職能又不是去寫程式。但是如果想成為一名優秀的產品經理，技術這塊必須持續學習，要跟隨時代的步伐了解技術，但是並不要求精通。其實很容易理解，假設某產...