[討論] 產品經理(PM)需要懂技術嗎？ - 看板Soft_Job - 批踢踢 ...

想要轉職，不知道技術知識到什麼程度才能找到產品經理的工作機會2. 已在職中，身為PM 不確定自己技術知識夠不夠，還能朝哪些方面加強將問題拆解後， ... 批踢踢實業坊 › 看板Soft_Job 關於我們 聯絡資訊 返回看板 作者annedoo(安安)看板Soft_Job標題[討論]產品經理(PM)需要懂技術嗎？時間MonJul518:39:112021 月經文來著。

我兩年前曾經在板上問過這個問題， 偶爾也會有人站內信找我討論， 所以就寫了一篇文章分享自己的想法、跟大家交流交流～～～ Medium有圖有參考連結好讀版： https://pse.is/3hk2n9 懂技術當然比不懂技術好，上知天文下知地理當然比什麼都不懂好。

而會有人不斷討論這個問題的原因大概分為兩個層面： 1.想要轉職，不知道技術知識到什麼程度才能找到產品經理的工作機會 2.已在職中，身為PM不確定自己技術知識夠不夠，還能朝哪些方面加強 將問題拆解後，我們背後真正想問的是： -若要成為一個及格的產品經理，對技術的了解要有多少？ -產品經理有那麼多種技能要點，技術在這所有技能中有多重要？ -為了轉職/為了職涯發展/為了讓工作與溝通更順暢，我應該優先補足技術知識、還是精進其他技能？ 【文章目錄】 -產品經理什麼時候會用到技術知識？ -所謂的「懂技術」是什麼意思？溝通技術的不同層次 -怎樣才算是夠懂技術了？ -如何跟工程師合作？ -結語：產品經理技能樹 這邊先長話短說、下個小結，一般來說： PM對技術的理解，要足夠跟工程師溝通、安排資源、解決問題。

也跟工程師們喊話下： 你的PM亂答應需求、亂訂時程不一定是因為他不懂技術， 有可能只是因為他不懂得溝通與拒絕的藝術。

▍產品經理什麼時候會用到技術知識？ 目標：加速產品開發、確保團隊在往對的方向前進 有技術知識的PM能夠： -了解產品的核心技術競爭力，對於在做的產品有正確的認識 -分辨市場上其他競品強不強，是強在技術還是其他地方 -在做產品決策、優先級排序、規劃與協調資源時更順利 -跟工程師與技術單位溝通時更順暢 擁有技術知識，讓PM在以下工作階段更順利 -研究問題、討論解法、優先級排序（需求方、使用者、客戶） -資源安排＆實作（設計師、工程師） -處理緊急issues（整個團隊） 寫程式不是PM的工作！ 有些人會有個迷思，好像PM必須要會寫程式才能做好自己的工作。

問了一些工程師朋友和同事，PM的技術能力要到什麼程度？他們的答案是「可以跟工程師溝通就OK」「了解技術限制、複雜度、成本之類的就很棒了」「不會寫程式沒什麼關係啊」「寫程式是我們的工作吧！」 如果你覺得學會寫程式就能成為一個好的產品經理，那我會說你只是在偷懶而已。

擁有技術知識、懂產品背後的邏輯，並不代表你自己需要會寫程式。

會寫程式當然很好，能更懂行話、也對跟工程師溝通有幫助，但與其自己實際練習寫程式，我會寧願花時間在其他地方。

▍懂技術是什麼意思？懂技術的不同層次 PM不用知道如何寫程式，但要知道產品背後的邏輯與技術限制。

技術知識要能輸出成為「理解能力」與「溝通能力」兩個方面才有用：聽得懂是第一步，能夠參與討論是第二步，有能力做出合理的判斷是終極目標。

我將技術知識含量多寡以及能達到的成果分成以下幾種類別。

【高】技術知識作為決策的一環 -跟需求方討論時，可以判斷做不做得到、難易度如何、可能遇到的問題 -排序產品與問題優先級時，能精準的將技術複雜度作為一個維度來參考 -能夠將核心技術轉化成產品的核心競爭力之一 -能夠從頭參與新產品、新服務的討論，包含選擇什麼技術來實作、資料庫架構的欄位與內容、是否要找第三方的服務來串接 -了解技術團隊使用的外部服務（AWS、Sentry、CircleCI）的成本 -了解什麼是正確的時機refactor、解決技術債（TechDebt）、LegacyCode的問題 【中】良好的溝通媒介 -接收需求時，能清楚釐清問題內容，以利後續跟技術團隊討論實作可行性跟時程 -接收需求時，能判斷是否跟目前邏輯相違背、有沒有dependencies等 -接收需求時，能描繪出改動的範圍大小，並向需求方建立正確的期待 -討論產品解法時，能顧慮到技術限制、技術可行性 -與技術團隊討論時，知道該問哪些問題、聽得懂對方的解釋、參與討論 -遇到issues時，知道怎麼回報、怎麼重現bug並提出可能的原因 -若需要跟第三方服務或客戶串接，要看得懂技術文件，或至少知道哪一部分需要跟技術團隊確認 -在寫產品文件時，能將部分技術規格也納入其中，並搭配工程師的TechicalSpec 【初】基礎中的基礎 -了解最基本的網路產品如何運作 -DailyStandup時聽得懂工程師說明他在做的事、遇到的困難 -遇到問題時不會問錯人！前端、後端、DataTeam的工作範圍都不同；就算都是後端，他們負責跟維護的部分可能也不同，要能判斷這塊需求或問題要問誰才對 -能夠和工程師一起處理issues&bugs 【零分】能力不足 -聽不懂工程師說的技術名詞卻也不會問 -不懂得釐清需求方的問題，要來來回回問工程師很多次 -工程師回覆之後也無法好好解釋給需求方，讓需求方了解技術限制或bug發生的原因 -規劃產品時沒考慮到技術問題，也沒諮詢過技術團隊 【哎呀扣分】懂技術不是讓你用來不尊重專業意見的 最忌諱的就是PM覺得自己懂點技術，所以就不尊重工程師的專業意見，因此自己壓時程、亂答應、質疑工程師的判斷。

有時候一個乍看很簡單的東西，可能會因為自家產品背後混亂的codebase而變得難以實作，或是需要先進行refactoring才有辦法開始開發。

每一間公司、每一個產品都會有不一樣的狀況，因此不要輕視彼此的專業、不要幫對方做決定，大家在能力上應該是互補的關係，而懂對方的語言的目的只是為了讓內部溝通更順暢。

另一種狀況是PM太過關注技術複雜性。

我曾經因為覺得某個東西技術上應該很難實作，所以就自作主張推掉需求，但後來才發現其實工程師能夠想到其他很好的技術解法，這就是自以為懂技術的糟糕心態。

應該說，每個人各司其職、為自己的位置與角色發聲才是最好的平衡。

我不應該過度幫工程師擔心技術的事情，而是應該帶著我身為PM的想法與立場去溝通與搜集專業意見，同時設定好雙方的期待。

PM很常需要在中間當協調人或決策者，勢必要能夠聽懂別人說的話、了解別人在意的事情，但不是取代其他專業同事應該要做的事。

【翻譯蒟蒻】除了跟行內的人溝通，還要能夠解釋給外行人聽 當老闆、業務、客服問PM為什麼這個做不到、為什麼會發生這些issues，你能不能用很簡單的邏輯與案例解釋給他聽？ 當一個產品需求會被拒絕，有時候是需求本身不合理、有時候是設計上的難題、有時候是技術上的限制，PM在接收需求的時候心中就要做簡單的分析，知道這些問題該問誰、問完之後有哪些因素影響團隊做決定（做或不做、優先級如何），跟產品團隊討論完後再回去找需求方溝通。

遇到issues的時候也一樣，PM就像一台翻譯機，客服回報問題，PM整理好問題影響範圍、重現方式並翻譯成技術語言給工程師聽；工程師找到問題後告訴PM背後的根本原因和可能的解決方案、PM再翻譯回去給客服聽，討論該如何跟客戶或使用者溝通。

最後是關於一些常見的技術問題，團隊應該要建立起共同的知識資料庫，避免一樣的問答不斷重複發生。

PM總是幫忙工程師回答問題也不是辦法，文件化並分享知識給同事才是最有效率的作法。

▍怎樣才算是夠懂技術了？ 標準答案：看公司！看團隊！ 1.最基本的技術知識 延續上面提到的技術與溝通等級，對新手PM來說，有【初】基礎中的基礎就不錯了，其中的了解網路產品如何運作包含理解以下名詞： Backend、Frontend Server、Client、Cloud、DNS Database、SQL FTP、API Cache、Cookies、Session Container、Docker、GitHub、CI/CD、Deployment 會使用BrowserDevTools並大概知道每個區塊的作用 2.技能對應到工作需求 有些公司裡面會有TechnicalPM(TPM)、SystemArchitect(SA)、DeliveryManager(DM)的角色，在這些團隊內他們會吃下很多技術相關的工作，一般PM對於技術知識的理解與溝通可以透過他們來協助。

但另外一些公司則可能會希望PM擁有一定的技術知識與背景，所以真正的問題是，我需要多少的技術知識，才能支撐我做好在這間公司、這個產品的產品工作。

在面試前可以先： -了解這間公司的技術架構，在使用的服務等等 -找該公司的工程師或其他職位的JD來看，是否懂裡面所有的專有名詞 -搜尋該公司的PM面試題目，看看是否有技術相關題目 Ref:IGotAnOffer—Productmanagerinterviewquestions(theultimatelist) 如果面試的時候有跟工程師對到，在問問題階段也可以反問他們對於PM的技術能力的要求與期待是什麼。

如果你想進去的產業跟公司的產品技術含量高，技術背景就會是標準配備。

而每間公司、每個產品的程式架構都不一樣，使用的服務、背後的邏輯也不盡相同，到了新的團隊或換新產品的時候都需要重新學習跟理解。

在《產品經理就職手冊：抓住四大學習重點，讓你快速進入狀況》中有提到，剛入職時可以請工程師帶著PM了解目前產品的技術架構和TechRoadmap。

若產品經理了解技術架構與限制，也會多少對判斷Dependency與了解可能的技術坑有幫助。

針對這點可以請工程師跟你說明目前是使用什麼Techstack、前後端如何互相呼叫、有哪些主要的API/Service/Database，以及我們是否跟其他團隊在技術層面會有高度合作關係等等。

3.基本的撈資料、分析能力 一樣根據工作所需，有些基本的撈資料、分析是PM會自己做的： -用SQL撈資料（知道資料庫裡有哪些欄位、怎麼存資料、關聯性為何） -用Crawler爬資料 -埋點、分析Events、A/BTesting ▍如何跟工程師合作？ 有的時候技術問題很複雜、或是程式過去是很多人共同在維護，技術知識學海無涯，工程師本人也不一定隨時都知道技術問題的答案，可能會需要先花時間去看一下、研究一下才能跟你討論。

因此問問題與合作時先做功課、虛心請教、給對方足夠的時間研究也是很重要的。

執行細節歡迎參考我們過去的文章： 【PM夥伴攻略】如何跟工程師合作？ 【PM夥伴攻略】番外篇：工程師雷區幹話大全 【PM夥伴攻略】如何與工程主管EngineerManager合作？ ▍結語：產品經理技能樹 在《從入門到卓越，產品經理技能檢核表與職涯發展路徑》中提到的「TechnicalSense—對技術理解的能力」主要集中在SeniorPM的職涯階段。

不過在這個產業工作，多瞭解點技術相關知識總還是非常有幫助的。

做產品就是在商業價值、使用者體驗、技術之間取得平衡，三種技能一定都會點到，但每個PM的興趣和專長都不同，長遠的職涯發展朝向不同方向，相對應所需的知識和技能就會有所不同。

最重要的是，PM跟商業團隊、技術團隊、設計團隊其實合起來是一個全方位的產品團隊，大家做好份內的專業外，自己的能力能夠跟團隊成員互補、並持續進行知識交流是很重要的，大家要一起成長，才會變成更棒的產品團隊！ 以上，歡迎PM、工程師們一起來交流， 擁有什麼樣的技術知識才足夠成為及格的產品經理。

-- ※發信站:批踢踢實業坊(ptt.cc),來自:1.162.152.200(臺灣) ※文章網址:https://www.ptt.cc/bbs/Soft_Job/M.1625481555.A.131.html ※編輯:annedoo(1.162.152.200臺灣),07/05/202118:40:36 ※編輯:annedoo(1.162.152.200臺灣),07/05/202118:42:00 →wellkom:不懂沒關係，不要把前工作一堆process無腦導入就好07/0519:27 →MoonCode:我覺得產品經理只要懂產品在幹嘛就好07/0521:31 →MoonCode:但我覺得光這樣就很難了07/0521:32 推jack0204:最重要的是知道公司目標，訂里程碑，引導團隊前進07/0523:04 推steven11329:我覺得工程師反而不適合當PM。

懂6、7成比完全懂07/0523:13 →steven11329:要好。

不會被自己的專業知識給限制。

有時候我也會被07/0523:13 →steven11329:非工程師的新ideal感到驚喜。

07/0523:13 推taipoo:謝謝分享07/0601:12 推lee457088:推分享07/0601:33 推taikobo:推,很多PM只是當傳聲筒而已,把壓力轉嫁給工程師...07/0607:39 →lspci:這篇怎麼好像把PJM跟PDM混在一起了07/0612:01 →wellkom:大公司分的比較細，以小公司來說本質上就是沒人願意幹的07/0612:13 →wellkom:雜事統稱PM.把雜事理出頭緒大家開心就好PM07/0612:14 →HKCs:會擋需求擋子彈的PM就是好PM07/0615:13 推DCTmaybe:推推，能夠把需求講清楚就好了我要求不高07/0622:31 →superpandal:按照這樣沒見過合格的...有時候問題都要工程師自己07/0800:09 →superpandal:反映07/0800:10 推ma5300408:這篇不錯07/0913:00 推MDay56:謝謝分享07/2510:23