每隔一段時間，PM 社群就會掀起一場論戰：
「PM 到底要不要懂技術？」 「不懂 coding 的 PM，工程師會尊重你嗎？」 「現在都 AI 時代了，PM 不會 coding 是不是快被淘汰了？」
這些問題我看過太多次了。每次看到，我都有點想翻白眼，不是因為問題無聊，而是因為這個問題本身就問錯了方向。1.先說一個真實情況
我認識一個 PM，從來沒寫過 code，連 Git 是什麼都說不清楚。但他帶的產品，工程師搶著要跟他合作。
我也認識另一個 PM，本科系，GitHub 上有自己的 side project，偶爾還能幫團隊 debug。但每次開完需求會議，工程師出來都是一臉「又要搞什麼飛機」的表情。
所以問題從來不是「懂不懂 coding」，而是「你有沒有辦法跟工程師好好合作、做出對的東西」。
這是兩件完全不同的事。
2.「技術焦慮」從哪裡來？
很多 PM 的技術焦慮，本質上是一種被淘汰的恐懼，不是真的對技術有興趣。
他們去學 Python，不是因為想理解資料，而是怕被說「不懂技術」。他們去考 AWS 認證，不是因為雲端架構跟他們的產品有關，而是簡歷上要填點什麼。
這種學法學不出什麼東西，因為動機是錯的。你在焦慮的驅動下學技術，學到的只是「我學過這個」的安全感，不是真正能用上的判斷力。
更根本的問題是：你真正需要的，根本不是 coding 能力。
3.PM 需要的是「技術溝通力」，不是「技術執行力」
把這兩件事分清楚，焦慮會少一半。
技術執行力是：自己能寫 code、能實作功能、能做技術決策。
技術溝通力是：聽得懂工程師在說什麼、知道一個需求大概會踩到什麼坑、能判斷「這需求合不合理」、不會問出讓工程師沉默三秒的問題。
PM 需要的是後者，不是前者。
技術執行力是工程師的本業，PM 去搶這塊，要嘛搶不贏，要嘛搶贏了也沒用。但技術溝通力是 PM 的核心，沒有這個，你跟工程師的對話就是雞同鴨講。
4.那 PM 要懂哪些技術？
我的版本不是什麼都要懂，而是跟你的產品有關的要懂、跟你的決策有關的要懂，其他的不用浪費時間。
一定要有感的幾件事：
1. 理解「為什麼這個功能需要這麼久」 不是要你自己估時程，而是聽得懂工程師說「這邊有 API 依賴」、「要動到資料庫 schema」、「這功能牽涉到三個 service」的時候，你知道這代表什麼意思、複雜度在哪裡。
2. 理解「trade-off」的存在 做軟體沒有完美解，只有取捨。當工程師說「這樣做快，但之後擴展會有問題」，你要能判斷：在你的產品現階段，這個取捨值不值得，而不是說「那就兩個都要啊」。
3. 知道「這個需求能不能做」的直覺 不用精準，但要有感。當你提出一個需求，你大概知道這是改個 UI 設定還是要重新設計整個資料模型。這個直覺能讓你在提需求之前，先自己過濾一遍明顯不合理的想法。
4. 讀得懂（不用寫得出）基本的技術文件 API 文件、系統架構圖、ERD，不用自己畫，但要能看懂別人畫的。這樣你在跟工程師溝通的時候，有共同的語言。
5.什麼時候「要會 coding」才真的重要？
有幾種情況，coding 能力確實有明顯加分：
- 你做的是 developer tools 或 API 產品：你的用戶就是工程師，你要有辦法感同身受他們的使用情境。
- 你在早期新創，PM 要身兼多職：可能真的需要自己跑 script 撈資料、自己改個小功能。
- 你的產品跟 AI 深度整合：需要對模型能做什麼、不能做什麼有基本的感知。
但如果你做的是企業 SaaS、電商平台、B2B 產品，老實說，你去把 LeetCode 練到 Medium，不如把你的用戶研究做得更深。
6.些因為「不懂技術」而被嗆的 PM，問題通常不在技術
回頭看那些被工程師嗆「你不懂技術怎麼當 PM」的情況，真正的問題幾乎從來不是技術知識不足，而是：
- 需求說不清楚，讓工程師做完才發現方向錯了
- 不理解技術限制，一直提做不到或代價很高的需求
- 不信任工程師的判斷，卻又說不出自己的理由
- 把工程師當工具，而不是合作夥伴
這些問題，去學 coding 都解決不了。
7.最後
技術焦慮的本質，是不確定自己夠不夠格。
但「夠格」這件事，從來不是靠證照或技能清單來定義的，而是你有沒有辦法帶著團隊做出對的東西。
去學技術沒有不好，但動機要對。不是因為焦慮，而是因為你真的需要它來做更好的判斷。
你現在的技術焦慮，有多少是真的想學，又有多少只是在跑「感覺應該要懂」的安全感？
這個問題值得你認真想一想。
