產品經理需不需要懂技術？大多數同行可能都認為需要，因為可以和開發平等對話，但真的懂技術之后會是這樣嗎？不懂技術就沒有優勢嗎？本文根據我的經驗和遇到的問題進行整理，感謝閱讀。

月初和一位產品朋友聊天，提到了產品崗是否需要懂技術的問題，網上也有很多觀點，有的極端、有的中庸。

因為我大學專業是軟件工程，雖然掛了很多科，但實習的時候也正兒八經混了兩個小項目經驗。之后無論是做測試，還是做售前，也一直在技術圈子的邊緣游離。所以我應該屬于在產品同行中略懂一點技術的。

懂技術給我的日常工作中帶來了很多幫助，但也造成了我后續（包括現在）的一些瓶頸與精神內耗。

今天根據自己的理解和日常工作經驗談談看法，希望能對各位產品同仁有點幫助。

01 為什么會有這個疑問？

也許是因為多年前一句“人人都是產品經理”的影響，也許是很多人感覺產品崗的入行門檻低，于是乎很多跨行業轉型的產品人層出不窮，然而至今都很少有大學專門設立產品課。

即便市場上出現了很多產品培訓、知識星球等等，但更多也都是從底層思維、行業知識、產品方法論等方面展開。

所以對于大部分產品人來說，技術、軟件工程等相關的理論，不好學、也沒機會學。

但在實際工作中，打交道最多的應該就是技術同學了（某些特定行業、特定崗位不在討論范圍內），無論前端、后端，無論公司的架構、開發語言是哪種，只要我們想把產品設計推進落地，終究離不開與技術同學對接。

尤其是當我們提的需求，技術同學說做不了的時候，或者和他們討論方案的時候，亦或是出現了一些奇怪的bug來分析問題的時候，不懂技術的我們只能一臉茫然的聽著，或佯裝疑惑、或佯裝點頭。

所以大家很自然的會想到一個問題：我要不要學一下技術，起碼能和開發平等對話呢。

02 幾個小伙伴的統一訴求

包括在我身邊，團隊中的四位產品小伙伴。

• 一位英語專業轉型
• 一位UI轉型
• 一位化學農藥啥啥的專業轉型
• 還有一位是企業管理專業轉型

七月份我們新制定了個人中短期成長規劃，他們也都把“了解技術、能和開發正常對接”之類的能力提升，作為下半年的學習目標。

團隊四人中，英語專業轉型的小姐姐已經被“磨煉”到懂技術的行列了。來公司前就已經在之前的工作中掌握了數據庫基本操作，在公司這幾年，整日與開發battle，討論方案、評審設計，已經能在技術評審時指出很多流程與結構方面的問題。

03 技術那么多，從何下手？

如果要了解技術，我的個人建議是從這幾個方面來入手（以下建議僅針對自己的認知，偏向常規系統，很多新興行業的系統與技術，或技術專業性較強的業務，就需要大家自己學習啦）。

之前我買過一本《給產品經理講技術》的入門書，看了目錄，然后針對性看了幾個章節。也許是當時自己沒有良好的讀書習慣，也許是之后工作中沒有應用的場景，所以沒過多久也都忘了。不過當自己偶爾遇到一些技術問題時，還會再翻出來學習一下。

這也是我想和大家說的，我們如果想了解技術，一定要“用哪里、學哪里”，盡量不要體系化學習。因為體系化學習過程中，很多知識點在工作中運用不到，遲早會忘，而且也不一定有那么多時間體系化學習。

比如現在有些向產品推薦的數據分析課程，通過Python或其他語言進行編寫，如果自己只是感興趣，工作中并沒有實際應用，學習一段時間后，大概率會因為實操難度而“從入門到放棄”，奇奇怪怪的失敗經驗又一次+1。

本身產品底層能力成長和行業知識成長就已經需要我們花費大量的精力了。

其次我們可以學一些基礎的，或者幾乎各個系統/產品都會涉及的技術工具。比如我給團隊小伙伴的建議是：先學會基礎的sql語句，然后學會看服務器日志。

這樣起碼我們能通過工具查看業務處理邏輯是否合理，或者后續在迭代中，針對復雜的業務場景，和開發一起進行流程設計。就像我在之前提升測試效率的推文中提到的，我們日常接觸的系統問題，很多都是業務處理不合理導致的功能性問題。而非因為性能、技術平臺選型所導致的技術難題。

當我們能夠通過系統日志，把主流程的處理邏輯轉化成流程圖時，就已經很夠用了，再通過不斷地實踐、練習，讓自己熟悉。不出半年，和開發的溝通討論就會順暢很多。下面這張圖就是我們一位測試小姐姐在剛入職時通過查日志并結合數據庫梳理出的平臺業務流程及處理邏輯，一共40頁，太贊了！

另一方面，我們需要了解一些基礎的概念。比如【接口】、【加密】、【數據字典】、【定時任務】、【前后端分離】，以及常見的架構概念。

以當下流行的微服務架構為例，注冊中心、配置中心、通訊網關、日志歸集、協議轉換等等之類的概念，可以在網上一搜一大把的文章中做個了解。前提是，公司的產品用哪套技術架構，我們去搜哪套。

第三步，如果產品涉及到第三方系統的對接合作，則可以了解第三方的API文檔，基于前期的技術理解，分析產品各個模塊與第三方合作系統的關聯關系及相互影響策略，最終產出業務架構圖、或系統間業務流程圖、數據流圖，基本就超出業內很多產品同仁了。

當然很多中后臺的產品經理，或者網絡層、數據層、硬件相關行業的產品人，在入行之后跟隨產品的迭代，也能夠或多或少掌握很多專業技術知識，有些可能還會轉型為架構師。但是這些專業性較強，也有很多高效但不通用的方法，在此不再展開討論（當然這些我也不會）。

其實我也很想看到有產品同仁總結分享，自己是如何在工作中從0技術一步步學習成長的。很遺憾這種經歷我沒有，也寫不出來。

04 懂技術，然后呢？

當我們真的了解基本的技術，理解開發人員之后，緊接著我們將面臨一個嚴重的問題：用技術思維設計產品，或因為技術思維而影響產品設計。

因為我本身在這兩年的產品工作中一直在面臨這個問題，也陷入了“掙扎”與“精神內耗”。

當我們在功能設計完成后，與研發進行評審或日常溝通時，會不自覺的被技術同事代入“這個功能很難做”、“這個功能花的時間會很長”的思維怪圈。最后可能自己因為同理心等原因，主動就把功能簡化了，尤其是在進度計劃已經確定的條件下。

一來二去，后續迭代過程中，便會自覺把一些技術難題，或者邏輯變更大的需求砍掉，逐漸讓迭代方案從功能層面越來越弱。

原本懂技術是件好事，我們可以甄別出設計風險，和技術一起想出更優解決方案，或者在技術同事“敷衍”、“夸大難度”時進行合理識別。但久而久之，我們原本很重要的產品思維、對設計體驗的極致要求，占比會持續走低。

當我發現這個問題之后，在后續的設計中雖然還會考慮方案的難度，但會刻意提醒自己：我要對用戶負責，要對產品的體驗與價值負責。

這也是很多技術轉型產品的過程中必將遇到的問題，當我們對產品有更高的要求時，技術思維也會讓我們陷入瓶頸。

于是出現了現階段的辯證關系：城外的人想進來，城里的人想出去。

05 不懂技術有優勢嗎？

其實我挺羨慕交互設計和UI設計的，但也可能是因為自己不了解。其實他們在推進新規范與新體驗時，也勢必會遇到技術上的障礙。

但是真正的靈感，或者真正好的功能與體驗，更可能由這些不懂技術的產品人提出來。因為他們是更專注的，目標更清晰的。

在現如今這個創新乏力的環境下，只有真正的觀察用戶、觀察競品、體驗自己的產品，才能真正想出一些能夠擊中用戶痛點的【微創新】功能，才能在現有版本的基礎上創造出更極致的交互，設計出更有溫度的功能。而這些，需要花時間探索，且不使用技術思維探索。

當我們真正有了創新的想法，更愿意讓想法落地，去堅持和技術battle，堅持實現自己的方案，且不打折扣。當然這個過程很難，當我們真正懂技術又不精通技術時，可能自己就。。。

放棄了~

所以我一直在刻意鍛煉自己，在思考時不去想落地。但這，也挺難的。就像“明知故犯”一樣，我知道這個設計做不出來，或者沒時間做，那我還要繼續想嗎？

06 到底應該怎樣？

說了這么多，總結一下我的觀點：

1. 剛入行的產品人，不要把技術當做首要目標，更重要的依然是產品的設計能力、邏輯能力、協作能力、行業知識等。
2. 工作中遇到技術問題或想和研發平等對話時，選擇可以“即學即用”的知識點快速突破，同時可采用我的建議，從數據庫和日志層面快速上手。
3. 但是無論何時，不要丟掉產品的核心思維和對用戶體驗的追求。
4. 當我們能力達到較高水平時，或者擁有較高話語權時，還是要做一個“偏執”的產品人，畢竟——產品經理可以改變世界【手動狗頭】

07 寫在最后

真正一款好的產品問世，既要有良好的產品設計，又要有嚴謹的技術支撐，本身兩者應通力合作，一起為了目標而努力。產品和技術不應該被對立，我們理應合力采用十八般武藝讓理想逐漸照進現實。

學習技術，是為了更好的工作；不學習技術，也可以更好的工作；吵架與爭執，一定不會更好的工作。

堅守設計理念與愿景，路要一步一個腳印地走。