Program Management on 施星宇

Product、Program、Project Manager比較

Mon, 05 May 2025 14:52:00 +0800

前言

PM大概是科技業中最容易讓人搞不懂的職稱之一，Product Manager叫PM、Project Manager也叫PM，後來又冒出一個Program Manager還是叫PM，三個職稱看起來差不多，實際工作卻可能差了十萬八千里。更麻煩的是每間公司對PM的定義都不太一樣，有些公司的Product Manager做的其實很像Project Manager，也有些職缺乾脆只寫一個「PM」，等進去面試後才發現工作內容跟想像中完全不同。

我以前也很直覺地認為Product、Program與Project是從策略一路排到執行，Program Manager大概就是一次管理很多Project、職級也比較高的人，然而自己實際做過Technical Program Manager（TPM）後，才發現事情沒有這麼簡單。這三種角色並不是一條由上到下的指揮鏈，比較像是站在不同角度處理同一件事情，而在公司規模不大或分工沒有那麼細的地方，更常是一個人把三份工作全部包走。

因此這篇並不是要給三種PM下一個放諸四海皆準的定義，畢竟這種定義大概也不存在，而是希望用比較接近實際工作的方式，解釋三者通常在意什麼、每天都在處理哪些問題，以及新人看職缺時到底該看哪裡。

Product Manager｜產品經理

Product Manager最重要的問題是：「這個東西到底該不該做？」

假設一間影音平台想推出家庭訂閱方案，Product Manager不能只是收到老闆一句「Netflix有家庭方案，我們也來做一個」，接著就把需求丟給工程師。他得先弄清楚究竟是哪一群使用者有這個需求、他們現在遇到什麼問題、願意付多少錢，以及這個方案對公司的生意是不是真的有幫助。要是辛苦做了半年，結果沒人想用，就算準時上線、程式也沒有Bug，仍舊很難說是一個成功的產品。

為了回答這些問題，Product Manager可能會訪談使用者、看產品數據、研究競品，跟設計師討論操作流程，再找工程、法務、行銷與客服確認各種限制。由於想做的東西通常永遠比工程資源多，他還得決定第一版要先做什麼、哪些需求可以晚一點、哪些看起來很酷但其實先不要浪費時間。

而且產品上線並不是下班的時候，反而只是另一個階段的開始。多少人真的開通家庭方案、有多少人用過一次就不再使用、訂閱收入有沒有增加、客服又收到了什麼奇怪的抱怨，這些都會影響下一步的產品方向，因此Product Manager通常會關注使用率、轉換率、留存率、營收或使用者滿意度等結果。

Product Manager經常被稱為「產品的CEO」，這句話聽起來很威風，但老實說也很容易誤導新人。多數Product Manager並不是任何人的主管，沒有辦法命令工程師一定要做什麼，也不能無視成本與技術限制亂開支票；他真正需要的能力，是在資料永遠不完整的情況下做出還算合理的判斷，再想辦法說服一群不歸他管的人一起把產品做出來。

Project Manager｜專案經理

如果公司已經決定家庭訂閱方案非做不可，Project Manager接下來關心的就是：「要怎麼在有限的時間與資源內把它做完？」

一個看似簡單的功能，背後可能牽涉會員系統、付款、App、網站、客服工具、法務條款與行銷素材，其中只要一個環節慢下來，上線時間就可能整個往後延。Project Manager需要把事情拆成可以執行的任務，找出負責人與前後依賴關係，排出Milestone，再持續確認專案是不是還走在原本的計畫上。

當然，現實中的計畫幾乎沒有照表操課這回事，工程師可能突然發現原本的設計做不出來、法務審核比預期多了兩週、老闆在上線前又多塞了三個需求，甚至原本答應支援的人直接被別的專案搶走。Project Manager的價值就是在這些事情真的把專案炸掉以前先看見風險，把影響攤開來讓大家知道，再協調出可以接受的做法。

所以Project Manager確實會排時程、追進度與開會，但如果只把這個角色理解成每天問「好了沒」的人就太可惜了。好的Project Manager會讓每個人知道現在的目標、決策與責任是什麼，問題出現時也知道該找誰處理；催進度只是表面，減少意外與混亂才是這份工作的核心。

Project Manager通常會在意專案能不能準時完成、預算是否超支、需求範圍有沒有失控，以及最後交付的品質是否符合標準。不過這些結果也不是他一個人能控制的，專案管理做得再好，碰到需求每天改三次或資源根本不足的組織，一樣只能努力不要讓場面變得太難看。

Program Manager｜計畫經理

Program Manager應該是三者中最難只用一句中文解釋的角色，因為Program究竟有多大、包含什麼，在不同公司中的差異非常大。

回到家庭訂閱的例子，如果公司的真正目標是「拓展全球付費會員」，那麼家庭方案可能只是其中一小塊，整個Program還包含新的付款系統、跨國定價、家長控制、隱私與法規、客服流程和上市行銷，而這些工作分散在不同國家與團隊，各自又有自己的目標與時程。Program Manager要處理的就是這些工作之間沒有人單獨負責、但不處理又一定會出事的空隙。

例如付款系統什麼時候可以支援新的方案？各國法規不同，要不要分批上線？兩個團隊同時需要同一批工程資源時，哪一邊應該先做？一個團隊延遲會影響到多少下游工作？這些問題通常不是多開幾場進度會議就會自己消失，Program Manager得先建立大家共同理解的目標與Roadmap，再整理跨團隊的Dependency、風險與決策，必要時把Trade-off帶到更高的層級解掉。

因此Program Manager不一定是一次管很多Project Manager的人，更不代表他必然比Project Manager高一階。Program描述的是問題的範圍與複雜度，而不是組織圖上的上下關係。有些Program是一項有明確終點的大型產品上市，有些則是雲端遷移、隱私合規、開發流程或營運效率這種持續多年的能力建設，兩者都可能由Program Manager負責。

至於Technical Program Manager，簡單來說就是處理的Program具有相當程度的技術複雜度，因此除了Program Management能力外，也需要理解系統架構、技術限制與工程團隊的語言。這不代表TPM每天都要下去寫Code，但至少不能在工程師講到API、Database、Latency或System Design時立刻進入放空狀態，不然很難判斷風險，更不用說協助團隊做選擇。關於TPM實際面試會遇到什麼，我之前也寫過一篇Google Technical Program Manager面試經驗。

所以三種PM到底差在哪？

說了這麼多，可以先很粗略地記成下面三句：

Product Manager在意的是「為什麼做、替誰做，以及該做什麼」
Project Manager在意的是「由誰來做、什麼時候做完，以及如何順利交付」
Program Manager在意的是「多個團隊與專案要如何合作，才能達成更大的共同目標」

這個分法雖然不可能涵蓋每間公司的情況，但至少比「Product負責策略、Project負責執行、Program負責管理很多Project」來得接近現實。因為Product Manager一樣需要處理大量執行問題，Project Manager也不可能完全不參與策略，而Program Manager更不是只要把幾張專案進度表疊在一起就算完成工作。

在小型新創公司，一位Product Manager可能從使用者訪談一路做到排時程與追進度，實際上同時兼了Product與Project Manager；到了分工細的大公司，三種角色可能一起出現在同一個Program中，甚至還有Product Operations、Delivery Manager、Engineering Program Manager等更多令人眼花撩亂的名字。台灣的情況又更有趣，軟體公司的PM可能偏產品，系統整合公司的PM可能主要面對客戶交付，硬體公司的PM則可能每天處理供應鏈、試產、認證與量產時程，光看兩個英文字母實在很難知道他到底在幹嘛。

新人該怎麼看PM職缺？

比起研究職稱，最有用的方法還是把Job Description打開來看，而且不要只看那些「善於溝通、積極主動、可以在快速變動的環境工作」之類每間公司都能複製貼上的句子，可以特別找下面幾件事：

這個角色最後要對什麼結果負責，是產品成長、單一專案交付，還是跨部門的整體成果？
平常最常合作的對象是使用者、設計與工程，客戶與供應商，還是公司內的多個團隊？
工作中有多少產品與需求的決策權，又有多少時間是在執行別人已經決定的方案？
公司用什麼方式判斷這個PM做得好，是營收與留存、時程與預算，還是效率、成本與組織能力？
這個職位上一個人一週通常怎麼過？這題在面試中問下去，通常比職稱本身更容易挖出真實的工作內容。

如果你喜歡理解使用者與商業問題，願意在模糊的資訊中做取捨，Product Manager可能比較適合；如果你擅長把一團混亂整理成可以執行的計畫，對細節、風險與時間很敏感，Project Manager可能比較對味；如果你喜歡處理跨團隊的複雜問題，能在沒有直接管理權的情況下推動一群人往前，而且看到一堆Dependency不會先頭痛，那Program Manager也許是可以嘗試的方向。

不過Program Manager，尤其TPM，通常比較需要既有的產業或專案經驗，原因也很直接：如果自己還沒有看過幾個專案是怎麼成功、又是怎麼爆炸的，就很難提早看出一個大型Program究竟會在哪裡出問題。

結語

Product、Project與Program Manager並不是三條完全分開的路，也不是固定的升遷順序。實際工作中大家都會碰到產品判斷、專案執行與跨團隊協調，只是每個角色花費的比例不同，而這個比例還會隨著公司、產業與團隊一直改變。

如果真的只能用一句話總結，我會說Product Manager確認問題值不值得解決，Project Manager想辦法讓解法順利交付，而Program Manager則確保一群彼此牽連的團隊最後真的能產生結果。

所以下次看到PM職缺，先不要急著被職稱騙進去，問清楚每天到底在解決什麼問題比較實在。

2023 Google Technical Program Manager 面試經驗

Fri, 07 Jul 2023 12:00:18 +0800

Google Technical Program Manager 面試經驗

前言

一直有許多Google SWE的面試經驗分享，然而Technical Program Manager(TPM)的面試經驗則幾乎沒有，其實不光是Dcard國外各大網站TPM的面試經驗分享也很少，因此來分享一下，雖然沒有拿到Offer，但有面到最後，經驗應該可以參考一下。

過去學經歷是112電資相關學碩，今年當完兵之後在比Google略大一點的公司當TPM。以前就有想進去Google，去年也投了Google SWE的面試，面完過HC等Team match時就遇到Hiring Freeze，詳細經歷可以參考：Google SWE 面試心路歷程，直到今年景氣變好才又開始Fit talk，結果連match了三個team都沒中，心灰意冷之際就收到另一個HR寄來TPM的面試邀請，抱著打聽情報的心態就跟HR排了個1:1，其實本來是對Google TPM缺沒什麼興趣，但在會議中被HR一波洗腦後，抱著那就試試的心態就接下面試邀請了。

時間

5/12 - 收到HR的TPM面試邀請
5/23 - 跟HR約1:1了解職缺
6/13 - VO:Technical Judgement*2
6/20 - VO:PgM + GCA
6/30 - 跟HR1:1通知面試結果: not move forward

面試

Google TPM的VO面試總共有五關，每關45分鐘:

兩關的Technical Judgement面試
一關Program Management related(PgM)面試
一關General Cognitive Ability(GCA)面試
一關Googleyness面試

可能因為之前已經面過Googleyness，所以這關就直接跳過了，實際上只面了四關，考慮到我技術能力可能比PM能力好一點，HR先幫我排了兩場Technical Judgement面試，結果不錯的話再排PgM和GCA，後來也證明這是正確的策略。

根據網路上的情報跟HR提供的文件，我認為Technical Judgement面試可能像是技術面試，可能會問Codeing，也可能會問System design，為此還翻出leetcode刷了幾題暖身；PgM可能會問跟經驗相關的問題；GCA則可能問解決問題的邏輯，但這部分當下也想不到有什麼準備方向，所以我只把HR給的參考資料看完，再多回想幾個小故事，由於實在想不到要怎麼準備，我也想辦法跟HR要些Hint，不過HR看起來已經給我全部能給的東西了，那就硬著頭皮上吧，學習嘛…。

順帶一提，TPM的面試是全英文的，四關差不多兩小時都在不停的說英文，這樣的要求也是可以理解，在Google這種公司Cross-function的溝通是極度仰賴英文的，這點也跟SWE面試很不一樣，SWE只有兩關英文，而且不會一直講話。

Technical Judgement 老實說聽到第一個問題時就開始懷疑人生了，我原本已經擺好寫Code的姿勢了，結果第一個問題是：「你最成功的專案什麼？」(詳細題目記不得了，反正是類似這的問題)，是那種我以為應該在PgM或GCA面試會問的問題，還好之前已經準備了不少小故事，姿勢一換搬出從大學、研究所到工作時做的還算有技術深度的案子，講解要解決的問題、我在團隊扮演的腳色、技術的選擇、克服的問題等，過程有來有回，面試官聽也還算滿意，不過一連的幾個問題也都是差不多這種類型，讓我有種我是不是走錯棚的錯覺，結束時還問了一下：「請問這個是Technical Judgement Interview嘛？」面試官愣了一下回：「是阿」，「Ok…」瞬間好像懂了甚麼又覺得甚麼都不懂，第二場Technical Judgement也是差不多的情況，總之自認表現還行，後來HR的feedback也是說Positive。
Program Management Related Knowledge(PgM) 有鑒於Technical Judgement面試問題實在出乎意料，因此再次問HR有關PgM面試的細節，HR還是回說他給的文件已經有資訊了，那就只能自行腦補了，既然名字叫Program Management那應該就是問PM相關能力吧，那應該多往PM的腳色去回答就行，果然不其然，面試的題目跟Technical Judgement幾乎一樣，而我就搬出之前做專案時怎麼定Scope、怎麼寫Spec、怎麼drive project、怎麼溝通協調，面試官看起來還算滿意我的回答，結束面試前小聊了一下這個position的情報，面試官覺得跟我目前的經驗差距頗大，不過還是祝我Good luck。
General Cognitive Ability(GCA) 到了GCA，我是真的想不到要怎麼準備了，如果是問解決問題的邏輯好像也很難準備。果然這關又問了跟前三關差不多的問題，然後我先從執行面去回答，但感覺面試官不太滿意，因此我又換一條路從技術面切入回答，面試官還是不太滿意，並建議我應該先從更High level的架構回答，因此我再給出了一個這方向的答案，不過沒有想得很透徹，應該是Bug滿滿，自己覺得答的超級爛，有感自己答的很爛，結束前後臉皮的跟面試官請教了一回，他也人很好跟我解釋了每一個問題的回答重點，大方向的概念是要先想出一個解決問題的框架，再將這個框架套入回答問題的框架去依序回答才有辦法打到得分點。

結果

後來再跟HR約了一次1:1，結果跟想像的差不多，前面表現都還不錯，主要掛在GCA，沒辦法再move forward，只能回去等還有沒有team match的機會了。

後來想了一下這次的面試確實有很多可以改進的點，除了現在真的菜，能講的經驗還太少外，就是對TPM面試回答的框架還不夠熟，這邊指的框架像是: 面對PgM的問題可以依序從以下幾點下手:

專案範疇與組織
專案執行
溝通與影響力
釐清模糊不清的情況

面對GCA的問題可以依序從以下幾點下手:

理解問題
蒐集資訊
找出解決方案
支持解決方案的證據
良好的溝通

下次要再嘗試Google TPM的面試時，應該要多花點時間打磨手上的案例，想辦法塞進這些框架組織，然後熟練使用這些框架回答問題，某種程度上也算是刷題吧。

結語

個人覺得TPM的面試比SWE面試還要難而且複雜，即便如此Google似乎很想找有EECS背景且有PM能力的人進去當TPM，只是這類人不多又或者沒興趣所以一直找不到人，如果有相關背景的人有興趣可以去嘗試看看。

如果有看完這篇對你有幫助，就順便祝福我早日拿到Google Offer啦。

附一張今年去101蹭飯的照片，好想進Google呀。