[討論] 產品經理(PM)需要懂技術嗎?

作者: annedoo (蕭安)   2021-07-05 18:39:11
月經文來著。
我兩年前曾經在板上問過這個問題,
偶爾也會有人站內信找我討論,
所以就寫了一篇文章分享自己的想法、跟大家交流交流~~~
Medium 有圖有參考連結好讀版:
https://pse.is/3hk2n9
懂技術當然比不懂技術好,上知天文下知地理當然比什麼都不懂好。而會有人不斷討論這個問題的原因大概分為兩個層面:
1. 想要轉職,不知道技術知識到什麼程度才能找到產品經理的工作機會
2. 已在職中,身為 PM 不確定自己技術知識夠不夠,還能朝哪些方面加強
將問題拆解後,我們背後真正想問的是:
- 若要成為一個及格的產品經理,對技術的了解要有多少?
- 產品經理有那麼多種技能要點,技術在這所有技能中有多重要?
- 為了轉職/為了職涯發展/為了讓工作與溝通更順暢,我應該優先補足技術知識、還是精進其他技能?
【文章目錄】
- 產品經理什麼時候會用到技術知識?
- 所謂的「懂技術」是什麼意思?溝通技術的不同層次
- 怎樣才算是夠懂技術了?
- 如何跟工程師合作?
- 結語:產品經理技能樹
這邊先長話短說、下個小結,一般來說:
PM 對技術的理解,要足夠跟工程師溝通、安排資源、解決問題。
也跟工程師們喊話下:
你的 PM 亂答應需求、亂訂時程不一定是因為他不懂技術,
有可能只是因為他不懂得溝通與拒絕的藝術。
▍產品經理什麼時候會用到技術知識?
目標:加速產品開發、確保團隊在往對的方向前進
有技術知識的 PM 能夠:
- 了解產品的核心技術競爭力,對於在做的產品有正確的認識
- 分辨市場上其他競品強不強,是強在技術還是其他地方
- 在做產品決策、優先級排序、規劃與協調資源時更順利
- 跟工程師與技術單位溝通時更順暢
擁有技術知識,讓 PM 在以下工作階段更順利
- 研究問題、討論解法、優先級排序(需求方、使用者、客戶)
- 資源安排&實作(設計師、工程師)
- 處理緊急 issues(整個團隊)
寫程式不是 PM 的工作!
有些人會有個迷思,好像 PM 必須要會寫程式才能做好自己的工作。
問了一些工程師朋友和同事,PM 的技術能力要到什麼程度?他們的答案是「可以跟工程師溝通就 OK」「了解技術限制、複雜度、成本之類的就很棒了」「不會寫程式沒什麼關係啊」「寫程式是我們的工作吧!」
如果你覺得學會寫程式就能成為一個好的產品經理,那我會說你只是在偷懶而已。
擁有技術知識、懂產品背後的邏輯,並不代表你自己需要會寫程式。會寫程式當然很好,能更懂行話、也對跟工程師溝通有幫助,但與其自己實際練習寫程式,我會寧願花時間在其他地方。
▍懂技術是什麼意思?懂技術的不同層次
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 總是幫忙工程師回答問題也不是辦法,文件化並分享知識給同事才是最有效率的作法。
▍怎樣才算是夠懂技術了?
標準答案:看公司!看團隊!
1. 最基本的技術知識
延續上面提到的技術與溝通等級,對新手 PM 來說,有【初】基礎中的基礎就不錯了,其中的了解網路產品如何運作包含理解以下名詞:
Backend、Frontend
Server、Client、Cloud、DNS
Database、SQL
FTP、API
Cache、Cookies、Session
Container、Docker、GitHub、CI/CD、Deployment
會使用 Browser DevTools 並大概知道每個區塊的作用
2. 技能對應到工作需求
有些公司裡面會有 Technical PM (TPM)、System Architect (SA)、Delivery Manager (DM) 的角色,在這些團隊內他們會吃下很多技術相關的工作,一般 PM 對於技術知識的理解與溝通可以透過他們來協助。
但另外一些公司則可能會希望 PM 擁有一定的技術知識與背景,所以真正的問題是,我需要多少的技術知識,才能支撐我做好在這間公司、這個產品的產品工作。在面試前可以先:
- 了解這間公司的技術架構,在使用的服務等等
- 找該公司的工程師或其他職位的 JD 來看,是否懂裡面所有的專有名詞
- 搜尋該公司的 PM 面試題目,看看是否有技術相關題目
Ref: IGotAnOffer — Product manager interview questions (the ultimate list)
如果面試的時候有跟工程師對到,在問問題階段也可以反問他們對於 PM 的技術能力的要求與期待是什麼。如果你想進去的產業跟公司的產品技術含量高,技術背景就會是標準配備。
而每間公司、每個產品的程式架構都不一樣,使用的服務、背後的邏輯也不盡相同,到了新的團隊或換新產品的時候都需要重新學習跟理解。
在《產品經理就職手冊:抓住四大學習重點,讓你快速進入狀況》中有提到,剛入職時可以請工程師帶著 PM 了解目前產品的技術架構和 Tech Roadmap。
若產品經理了解技術架構與限制,也會多少對判斷 Dependency 與了解可能的技術坑有幫助。針對這點可以請工程師跟你說明目前是使用什麼 Tech stack、前後端如何互相呼叫、有哪些主要的 API / Service / Database,以及我們是否跟其他團隊在技術層面會有高度合作關係等等。
3. 基本的撈資料、分析能力
一樣根據工作所需,有些基本的撈資料、分析是 PM 會自己做的:
- 用 SQL 撈資料(知道資料庫裡有哪些欄位、怎麼存資料、關聯性為何)
- 用 Crawler 爬資料
- 埋點、分析 Events、A/B Testing
▍如何跟工程師合作?
有的時候技術問題很複雜、或是程式過去是很多人共同在維護,技術知識學海無涯,工程師本人也不一定隨時都知道技術問題的答案,可能會需要先花時間去看一下、研究一下才能跟你討論。因此問問題與合作時先做功課、虛心請教、給對方足夠的時間研究也是很重要的。
執行細節歡迎參考我們過去的文章:
【PM夥伴攻略】如何跟工程師合作?
【PM夥伴攻略】番外篇:工程師雷區幹話大全
【PM夥伴攻略】如何與工程主管 Engineer Manager 合作?
▍結語:產品經理技能樹
在 《從入門到卓越,產品經理技能檢核表與職涯發展路徑》中提到的「Technical Sense — 對技術理解的能力」主要集中在 Senior PM 的職涯階段。不過在這個產業工作,多瞭解點技術相關知識總還是非常有幫助的。
做產品就是在商業價值、使用者體驗、技術之間取得平衡,三種技能一定都會點到,但每個 PM 的興趣和專長都不同,長遠的職涯發展朝向不同方向,相對應所需的知識和技能就會有所不同。
最重要的是,PM 跟商業團隊、技術團隊、設計團隊其實合起來是一個全方位的產品團隊,大家做好份內的專業外,自己的能力能夠跟團隊成員互補、並持續進行知識交流是很重要的,大家要一起成長,才會變成更棒的產品團隊!
以上,歡迎 PM、工程師們一起來交流,
擁有什麼樣的技術知識才足夠成為及格的產品經理。
作者: wellkom (wellkom)   2021-07-05 19:27:00
不懂沒關係,不要把前工作一堆process無腦導入就好
作者: MoonCode (MoonCode)   2021-07-05 21:31:00
我覺得產品經理只要懂產品在幹嘛就好但我覺得光這樣就很難了
作者: jack0204 (Jarbar王朝)   2021-07-05 23:04:00
最重要的是知道公司目標,訂里程碑,引導團隊前進
作者: steven11329 (清新柳橙)   2021-07-05 23:13:00
我覺得工程師反而不適合當PM。懂 6、 7 成比完全懂要好。不會被自己的專業知識給限制。有時候我也會被非工程師的新 ideal 感到驚喜。
作者: taipoo (要成功要積極)   2021-07-06 01:12:00
謝謝分享
作者: lee457088   2021-07-06 01:33:00
推分享
作者: taikobo (勉強になるなぁ...)   2021-07-06 07:39:00
推,很多PM只是當傳聲筒而已,把壓力轉嫁給工程師...
作者: lspci (awk sed echo)   2021-07-06 12:01:00
這篇怎麼好像把PJM跟PDM混在一起了
作者: wellkom (wellkom)   2021-07-06 12:13:00
大公司分的比較細,以小公司來說本質上就是沒人願意幹的雜事統稱PM. 把雜事理出頭緒大家開心就好PM
作者: HKCs (路人)   2021-07-06 15:13:00
會擋需求 擋子彈的PM就是好PM
作者: DCTmaybe (竹竹人)   2021-07-06 22:31:00
推推,能夠把需求講清楚就好了我要求不高
作者: superpandal   2021-07-08 00:09:00
按照這樣沒見過合格的... 有時候問題都要工程師自己反映
作者: ma5300408 (skyskystillsky)   2021-07-09 13:00:00
這篇不錯
作者: MDay56 (他媽媽衝擊波)   2021-07-25 10:23:00
謝謝分享

Links booklink

Contact Us: admin [ a t ] ucptt.com