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

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

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

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

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

01 為什麼會有這個疑問？

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

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

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

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

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

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

02 幾個小夥伴的統一訴求

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

04 懂技術，然後呢？

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

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

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

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

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

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

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

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

05 不懂技術有優勢嗎？

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

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

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

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

放棄了~

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

06 到底應該怎樣？

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

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

07 寫在最後

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

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

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

作者：不想延期，公衆号：不想延期

本文由 @不想延期 原創發布于人人都是産品經理，未經許可，禁止轉載

題圖來自 Unsplash，基于 CC0 協議。

該文觀點僅代表作者本人，人人都是産品經理平台僅提供信息存儲空間服務。

,

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!

查看全部