產品經理需要懂技術嗎？
🚨✨這篇文章中的 PM 指的是網路軟體產業的產品經理，可能也會不小心涵蓋到我身兼專案經理的經驗，抱歉一人身兼多職，小公司就是一條龍嘛！大家就當參考🙂
PM 需要懂技術嗎？需要或不需要，目的是什麼？所謂的「懂技術」又是什麼意思？
懂技術當然比不懂技術好，上知天文下知地理當然比什麼都不懂好。而會有人不斷討論這個問題的原因大概分為兩個層面：
- 想要轉職，不知道技術知識到什麼程度才能找到產品經理的工作機會
- 已在職中，身為 PM 不確定自己技術知識夠不夠，還能朝哪些方面加強
將問題拆解後，我們背後真正想問的是：
- 若要成為一個及格的產品經理，對技術的了解要有多少？
- 產品經理有那麼多種技能要點，技術在這所有技能中有多重要？
- 為了轉職/為了職涯發展/為了讓工作與溝通更順暢，我應該優先補足技術知識、還是精進其他技能？
【文章目錄】
- 產品經理什麼時候會用到技術知識？
- 所謂的「懂技術」是什麼意思？溝通技術的不同層次
- 怎樣才算是夠懂技術了？
- 如何跟工程師合作？
- 結語：產品經理技能樹這邊先長話短說、下個小結，一般來說：
PM 對技術的理解，要足夠跟工程師溝通、安排資源、解決問題。
也跟工程師們喊話下：
你的 PM 亂答應需求、亂訂時程不一定是因為他不懂技術，有可能只是因為他不懂得溝通與拒絕的藝術。
🚨✨ 這篇文章中的 PM 指的是網路軟體產業的產品經理，可能也會不小心涵蓋到我身兼專案經理的經驗，抱歉一人身兼多職，小公司就是一條龍嘛！大家就當參考 🙂
另外補充：我做 B2B 產品的經驗比做 B2C 多非常多，所以工作內容也許會有些偏頗；我待的都是產品跟團隊都還在早期階段的小團隊，不熟悉大公司運作，大公司內也許會有更多熟悉技術的角色協助 PM，歡迎分享。也歡迎工程師們一起來加入討論～～～
▍產品經理什麼時候會用到技術知識？
▧ 目標：加速產品開發、確保團隊在往對的方向前進
有技術知識的 PM 能夠：
- 了解產品的核心技術競爭力，對於在做的產品有正確的認識
- 分辨市場上其他競品強不強，是強在技術還是其他地方
- 在做產品決策、優先級排序、規劃與協調資源時更順利
- 跟工程師與技術單位溝通時更順暢
▧ 擁有技術知識，讓 PM 在以下工作階段更順利
- 研究問題、討論解法、優先級排序（需求方、使用者、客戶）
- 資源安排＆實作（設計師、工程師）
- 處理緊急 issues（整個團隊）
▧ 寫程式不是 PM 的工作！
有些人會有個迷思，好像 PM 必須要會寫程式才能做好自己的工作。
問了一些工程師朋友和同事，PM 的技術能力要到什麼程度？他們的答案是「可以跟工程師溝通就 OK」「了解技術限制、複雜度、成本之類的就很棒了」「不會寫程式沒什麼關係啊」「寫程式是我們的工作吧！」
如果你覺得學會寫程式就能成為一個好的產品經理，那我會說你只是在偷懶而已。
擁有技術知識、懂產品背後的邏輯，並不代表你自己需要會寫程式。會寫程式當然很好，能更懂行話、也對跟工程師溝通有幫助，但與其自己實際練習寫程式，我會寧願花時間在其他地方。
▍懂技術是什麼意思？懂技術的不同層次
PM 不用知道如何寫程式，但要知道產品背後的邏輯與技術限制。工程師擅長提出解決方案，PM 則要能夠問對問題、定義好目標。
技術知識要能輸出成為「理解能力」與「溝通能力」兩個方面才有用：聽得懂是第一步，能夠參與討論是第二步，有能力做出合理的判斷是終極目標。
我將技術知識含量多寡以及能達到的成果分成以下幾種類別。其中提到的「需求方」可能是使用者、客戶、老闆、業務、客服、工程師、設計師、甚至是 PM 本人。
【高】技術知識作為決策的一環
- 跟需求方討論時，可以判斷做不做得到、難易度如何、可能遇到的問題
- 排序產品與問題優先級時，能精準的將技術複雜度作為一個維度來參考
- 能夠將核心技術轉化成產品的核心競爭力之一
- 能夠從頭參與新產品、新服務的討論，包含選擇什麼技術來實作、資料庫架構的欄位與內容、是否要找第三方的服務來串接
- 了解技術團隊使用的外部服務（AWS、Sentry、CircleCI）的成本
- 了解什麼是正確的時機 refactor、解決技術債（Tech Debt）、Legacy Code 的問題
【中】良好的溝通媒介
- 討論問題與需求時，能清楚釐清問題內容，以利後續跟技術團隊討論實作可行性跟時程
- 討論問題與需求時，能判斷是否跟目前邏輯相違背、有沒有 dependencies 等
- 討論問題與需求時，能描繪出改動的範圍大小，並向需求方建立正確的期待
- 討論產品解法時，能顧慮到技術限制、技術可行性
- 與技術團隊討論時，知道該問哪些問題、聽得懂對方的解釋、參與討論
- 遇到 issues 時，知道怎麼回報、怎麼重現 bug 並提出可能的原因
- 若需要跟第三方服務或客戶串接，要看得懂技術文件，或至少知道哪一部分需要跟技術團隊確認
- 在寫產品文件時，能將部分技術規格也納入其中，並搭配工程師的 Techical Spec
【初】基礎中的基礎
- 了解最基本的網路產品如何運作
- Daily Standup 時聽得懂工程師說明他在做的事、遇到的困難
- 遇到問題時不會問錯人！前端、後端、Data Team 的工作範圍都不同；就算都是後端，他們負責跟維護的部分可能也不同，要能判斷這塊需求或問題要問誰才對
- 能夠和工程師一起處理 issues & bugs
最基本的網路產品技術知識後面會提到。
【零分】能力不足
- 聽不懂工程師說的技術名詞卻也不會問
- 不懂得釐清需求方的問題，要來來回回問工程師很多次
- 工程師回覆之後也無法好好解釋給需求方，讓需求方了解技術限制或 bug 發生的原因
- 規劃產品時沒考慮到技術問題，也沒諮詢過技術團隊
【哎呀扣分】懂技術不是讓你用來不尊重專業意見的
最忌諱的就是 PM 覺得自己懂點技術，所以就不尊重工程師的專業意見，因此自己壓時程、亂答應、質疑工程師的判斷。
有時候一個乍看很簡單的東西，可能會因為自家產品背後混亂的 codebase 而變得難以實作，或是需要先進行 refactoring 才有辦法開始開發。
每一間公司、每一個產品都會有不一樣的狀況，因此不要輕視彼此的專業、不要幫對方做決定，大家在能力上應該是互補的關係，而懂對方的語言的目的只是為了讓內部溝通更順暢。
另一種狀況是 PM 太過關注技術複雜性。我曾經因為覺得某個東西技術上應該很難實作，所以就自作主張推掉需求，但後來才發現其實工程師能夠想到其他很好的技術解法，這就是自以為懂技術的糟糕心態。
應該說，每個人各司其職、為自己的位置與角色發聲才是最好的平衡。我不應該過度幫工程師擔心技術的事情，而是應該帶著我身為 PM 的想法與立場去溝通與搜集專業意見，同時設定好雙方的期待。
PM 很常需要在中間當協調人或決策者，勢必要能夠聽懂別人說的話、了解別人在意的事情，但不是取代其他專業同事應該要做的事。
【翻譯蒟蒻】除了跟行內的人溝通，還要能夠解釋給外行人聽
當老闆、業務、客服問 PM 為什麼這個做不到、為什麼會發生這些 issues，你能不能用很簡單的邏輯與案例解釋給他聽？
當一個產品需求會被拒絕，有時候是需求本身不合理、有時候是設計上的難題、有時候是技術上的限制，PM 在接收需求的時候心中就要做簡單的分析，知道這些問題該問誰、問完之後有哪些因素影響團隊做決定（做或不做、優先級如何），跟產品團隊討論完後再回去找需求方溝通。
遇到 issues 的時候也一樣，PM 就像一台翻譯機，客服回報問題，PM 整理好問題影響範圍、重現方式並翻譯成技術語言給工程師聽；工程師找到問題後告訴 PM 背後的根本原因和可能的解決方案、PM 再翻譯回去給客服聽，討論該如何跟客戶或使用者溝通。
最後是關於一些常見的技術問題，團隊應該要建立起共同的知識資料庫，避免一樣的問答不斷重複發生。PM 總是幫忙工程師回答問題也不是辦法，文件化並分享知識給同事才是最有效率的作法。
要怎麼用簡單的方式解釋技術給同事聽呢？可以看看一些工程師寫的技術科普文章，例如《Decoding (REST)APIs for Product Managers》《從拉麵店的販賣機理解什麼是 API》、《白話 Session 與 Cookie：從經營雜貨店開始》。
▍怎樣才算是夠懂技術了？
標準答案：看公司！看團隊！
1. 最基本的技術知識
延續上面提到的技術與溝通等級，對新手 PM 來說，有【初】基礎中的基礎就不錯了，其中的了解網路產品如何運作包含理解以下名詞：
- Backend、Frontend
- Server、Client、Cloud、DNS
- Database、SQL
- FTP、API
- Cache、Cookies、Session
- Container、Docker、GitHub、CI/CD、Deployment
- 會使用 Browser DevTools 並大概知道每個區塊的作用
更多技術名詞介紹，請參考《探索網路產品背後的技術與架構：沒有技術背景也能看穿一切的實用小工具！》中「網站技術的百科全書目錄」段落。
Deployment 名詞介紹，請參考《產品上線管理：寫給 PM 的基本名詞解釋與工作流程》中「相關技術名詞概述」段落。API 介紹、如何分辨前後端，請參考《【Podcast EP08】產品經理到底要不要懂技術？feat. 旅英資深軟體工程師 Even 》20 分左右開始。2. 技能對應到工作需求
有些公司裡面會有 Technical PM (TPM)、System Architect (SA)、Delivery Manager (DM) 的角色，在這些團隊內他們會吃下很多技術相關的工作，一般 PM 對於技術知識的理解與溝通可以透過他們來協助。
但另外一些公司則可能會希望 PM 擁有一定的技術知識與背景，所以真正的問題是，我需要多少的技術知識，才能支撐我做好在這間公司、這個產品的產品工作。在面試前可以先：
- 了解這間公司的技術架構，在使用的服務等等
- 找該公司的工程師或其他職位的 JD 來看，是否懂裡面所有的專有名詞
- 搜尋該公司的 PM 面試題目，看看是否有技術相關題目
如果面試的時候有跟工程師對到，在問問題階段也可以反問他們對於 PM 的技術能力的要求與期待是什麼。如果你想進去的產業跟公司的產品技術含量高，技術背景就會是標準配備。
而每間公司、每個產品的程式架構都不一樣，使用的服務、背後的邏輯也不盡相同，到了新的團隊或換新產品的時候都需要重新學習跟理解。
在 Nana Chiang《產品經理就職手冊：抓住四大學習重點，讓你快速進入狀況》中有提到，剛入職時可以請工程師帶著 PM 了解目前產品的技術架構和 Tech Roadmap。
若產品經理了解技術架構與限制，也會多少對判斷 Dependency 與了解可能的技術坑有幫助。針對這點可以請工程師跟你說明目前是使用什麼 Tech stack、前後端如何互相呼叫、有哪些主要的 API / Service / Database，以及我們是否跟其他團隊在技術層面會有高度合作關係等等。
3. 基本的撈資料、分析能力
一樣根據工作所需，有些基本的撈資料、分析是 PM 會自己做的：
- 用 SQL 撈資料（知道資料庫裡有哪些欄位、怎麼存資料、關聯性為何）
- 用 Crawler 爬資料
- 埋點、分析 Events、A/B Testing
▍如何跟工程師合作？
有的時候技術問題很複雜、或是程式過去是很多人共同在維護，技術知識學海無涯，工程師本人也不一定隨時都知道技術問題的答案，可能會需要先花時間去看一下、研究一下才能跟你討論。因此問問題與合作時先做功課、虛心請教、給對方足夠的時間研究也是很重要的。
執行細節歡迎參考我們過去的文章：
▍結語：產品經理技能樹
在 Lucas Hsieh《從入門到卓越，產品經理技能檢核表與職涯發展路徑》中提到的「Technical Sense — 對技術理解的能力」主要集中在 Senior PM 的職涯階段。不過在這個產業工作，多瞭解點技術相關知識總還是非常有幫助的。
做產品就是在商業價值、使用者體驗、技術之間取得平衡，三種技能一定都會點到，但每個 PM 的興趣和專長都不同，長遠的職涯發展朝向不同方向，相對應所需的知識和技能就會有所不同。
選對戰場，找到適合自己的產業、產品與團隊，才能加速學習並得到大展長才的機會。
最重要的是，PM 跟商業團隊、技術團隊、設計團隊其實合起來是一個全方位的產品團隊，大家顧好份內的專業外，自己的能力能夠跟團隊成員互補、並持續進行知識交流是很重要的，大家要一起成長，才會變成更棒的產品團隊！
最後應觀眾要求放上我們愛的技術迷因：
謝謝你的閱讀！如果有任何回饋或有興趣的主題，歡迎留言給我們 📒
如果單純想給我一點鼓勵，請給我 1–10 個拍手；
如果覺得文章對你有點幫助，請給我 11-30 個拍手；
如果想看更多產品經理職涯相關文章，請盡情長按拍手（max 50）讓我們知道 👏🏻想要持續追蹤我們的最新文章和 Podcast，記得追蹤「產品三眼怪實驗室」的粉專(◉◉◉)！
想看我們所有的文章與分類，歡迎參考「文章列表」並善用標籤來搜尋與篩選！我們每週都會認真更新唷！千萬別錯過了～