身為團隊第一個 PM 好難！我的辛酸血淚史與生存之道
前前後後在好幾間不同的軟體/網路公司做產品工作，在過去的文章中有提到，我的職稱橫跨了產品經理（Product Manager）、專案經理（Project Manager）、產品行銷（Product Marketing），雖然工作內容與主要目標略有不同，但唯一相同的是，我在加入時都是團隊內第一個/唯一的全職產品負責人。
我的第一份產品工作是從擔任產品副理（APM, Associate Product Manager）開始，加入團隊時有其他市場的產品經理，但台灣的技術團隊與產品在地化沒人管理。在加入八個月後才有穩定的產品主管帶我，以及明確的團隊分工；再八個月後我才升職為能夠獨立作業的產品經理。
而也許是因為這份經歷的關係，我往後容易接觸到的工作機會，很多都是要找「第一個產品經理/專案經理」來幫忙解救混亂的團隊工作流程與調整產品體質 — — 一言以敝之就是萬用打雜工！這是一篇經驗分享的警・世・文，希望可以讓有興趣加入小團隊做第一位 PM 的人了解可能會遇到的困難與挑戰！
【文章內容】
- 讓我們從頭開始理解：沒有 PM 的公司如何存活？
- 為什麼公司突然覺得需要 PM 了？
- 擔任團隊內第一位產品經理會遇到的挑戰
- 講了一堆缺點跟挑戰，那優點呢？
- 結語：誰適合擔任第一位 PM 的角色？▍讓我們從頭開始理解：沒有 PM 的公司如何存活？
我待過的這幾間公司，要不是新創、不然就是大公司裡面負責獨立產品的團隊，在我加入時團隊總人數都不超過 30 人、產品團隊（工程師、設計師、QA）人數不超過 15 人。
那在我還沒加入之前，誰在負責 PM 的工作呢？
如果簡單拆解產品經理的工作內容，大概可以分為以下三個方向（擷取自【PM 總動員】如何成為合格的產品經理？必須理解的三大核心與案例）
- 問題探索： 探索市場與顧客的問題，聚焦在關鍵的需求
- 策略假設： 面對尚未滿足的需求，假設解決問題的路徑，成為決策判斷的依據
- 方案交付： 交付產品方案到顧客手中，推到市場上獲取商業價值
在一間公司、或是一個新產品團隊創立之初，老闆、 創辦人、CEO 通常就是產品經理本人，負責理解市場、客戶、使用者需求，建立第一個版本的 beta 產品，找到第一批使用者進行測試與推廣，進而找到 PMF（Product-Market Fit）。
這個時候團隊內可能只有老闆、業務/客服、工程師，所有工作都是大家分攤著做，還沒有明確的工作流程與分工。
當產品已經達到 PMF（Product-Market Fit）、團隊也漸漸擴張後，自然而然就會有模糊的分工方式出現。舉例來說，在還沒有 PM 加入之前，問題探索、方案交付（策略假設很多團隊可能沒心思處理）可能會有以下幾種不同的模糊分工模式：
問題探索 (Problem Discovery)
- 依舊由第一線接觸客戶、使用者的「老闆」負責
- 由第一線接觸客戶、使用者的「業務、客服」負責提出大部分需求
- 由「設計師」經由使用者研究、市場研究來提出
方案交付 (Solution Delivery)
- 由「工程主管」負責專案管理與上線
- 由負責上線前最後一哩路的「QA 測試主管」負責後期的專案管理與上線
- 由「設計師」負責專案管理、進行 design QA 與上線管理
原則上就是看公司內部的團隊配置是怎麼樣，從那一群人裡面找出最適合那份工作內容的人來佔代，也因此可能在同一個團隊內，是由許多不同的人分擔一般 PM 的工作；或是也有可能是由工程師、設計師抓一個人當作專案負責人來做 PM 的工作。
【問題與討論】
1. 如果你是老闆，你認為第一批創始團隊成員應該包含哪些職能的人？
2. 承上，當公司有第一批團隊成員之後，你的下一步會想要招什麼人進來呢？是更多的工程師？還是找設計師、PM 或是 QA 呢？▍為什麼公司突然覺得需要 PM 了？
既然上面的方法都還算可行，為何公司突然覺得需要 PM 了？我聽過的原因如下：
- 老闆（執行長）本人做產品工作，但隨著團隊擴張有更多重要的工作要做（募資、招募團隊、營運管理）因此需要一位全職的產品經理來分擔工作
- 團隊原本是由工程師/設計師/某個團隊成員負責專案管理，但他做得很不開心/做得很糟，所以我們想要找一個專人來負責專案管理
- 今年招募了很多工程師，沒想到整體效率下降，需要好的分工方式與資源管理
- 所有團隊成員每天都很忙、隕石很多、產品規格很亂、成果卻不如預期，想要有系統性的工作方法
- 現在客戶/使用者變多了，因此新的需求大增，對於要怎麼排序優先級跟拆進開發流程開始有困難
- 現有產品已經達到 PMF 且團隊維護順利，現在想開發新產品、開發新型態客戶，因此需要專人負責新產品（舊產品的維運跟成長就由原本的團隊成員負責）
- ……
這個問題的答案因團隊而異，但非常重要，因為決定了身為 PM 的我加入後的主要工作內容。
PM 在每個團隊中的工作內容可能會差很多，當你只有一個人又是新加入時，前三個月有可能都是在做一些很屎的事情——幫忙救火、補文件，並且努力滿足原有團隊成員的期待。如果想要找到舞台發揮長才，還得等到把團隊原先有的問題都處理完才行。
從老闆或團隊的角度，到底何時是雇用第一位 PM 的好時機呢？可以參考 Google Ventures 合夥人 Ken Norton 這篇《Product Manager Zero - When should you hire your first PM?》以下節錄 -Usually I discourage them from hiring until they've found product/market fit. But even when you're hitting your growth phase, the danger of having too many cooks in the kitchen exceeds the cost of being overworked.裡面也提到當身為老闆你聽到團隊成員跟你說 "You're slowing us down." "You're detached from the details." "The rest of our business needs you." 時，可能就要開始考慮是否需要找 PM 小幫手來支援了！另外也可以參考這些文章《When and How to Make Your First Product Hire》、《When they hired their first PM》。
▍擔任團隊內第一位產品經理會遇到的挑戰
1. 團隊不知道你的工作是什麼、大家對你的期待不同
儘管團隊內有些人過去的工作經驗會跟 PM 合作過，但對於你的期待可能還是會有很大的落差，尤其很多公司的 JD 都寫得超模糊 … — — 可能有人覺得你該負責畫 wireframe 出 spec、有人覺得你的工作就是定時程跟追進度、有人覺得你該主持所有的會議跟做會議紀錄。
這些工作內容可能對也可能不對，但如果沒有講清楚，很容易有模糊地帶與衝突發生。
[ 我的建議 ] 事先對齊團隊期待
工作內容與期待沒有對錯，只要雙方都能接受就沒問題，因此了解團隊「這時候想找 PM 進來的原因」非常重要！
至少招募你的人（主管/老闆）需要很清楚的說明他希望你第一個月、前三個月完成什麼事情、幫助他們達成什麼目標；而我自己在面試階段通常都還會另外要求跟工程師（或設計師、QA）也先聊過，確認他們也希望團隊有 PM 加入、了解他們目前遇到的問題、以及希望未來加入的 PM 可以幫助到他們什麼。
2. 一條龍之外，還要處理預期之外的工作內容
承上題，大家的期待不同，又因為團隊很小、分工模糊，要能夠協助團隊截長補短。舉例來說：
- 某團隊的設計師是從平面設計師轉過來，對 UX 跟解法發想非常不在行，所以從定義問題、釐清需求、市場與產品研究，到提出解法、畫出 User Flow & Wireframe 都是我負責，設計師只負責畫美美的介面出來給工程師刻前端
- 某團隊沒有 QA，所以我還要負責測試
- 某團隊的客服與營運單位人力不夠，所以我還要負責對外溝通（就是半個客服啦）、撰寫 FAQ、處理公關與行銷事務
- 一些跟產品本品無關的「專案管理案子」也可能落到我身上來
最後的情況就是自己時間不夠用，每天都在想這個到底是不是我的工作？我今天最重要的事情到底是什麼？打雜人生何時才能結束？而且剛開始絕對是需要「執行面」的事情最多，上軌道後才會有機會花時間處理「規劃面」的工作內容。
[ 我的建議 ] 補齊資源＆聰明運用自己的時間
如果問題是出在人力資不足或團隊成員能力不足，最重要的當然是建議公司趕快找合適的人加入團隊之外（缺漏的職位或是新 PM）。
除此之外要好好安排自己待辦事項的輕重緩急，如果事情真的不合理的太多，就要溝通工作量、或重新安排手上事情的優先級。
最後就是要懂的變通、幫自己省時間。舉例來說，為了方便工程師開發與我自己測試（沒 QA 的情況下），我最一開始就直接寫 test cases 來當作 spec，或是把會議紀錄當成 PRD 來寫，畢竟在某些時候形式不是重點，產品/功能能夠是快速、安全的上線才是最重要的。
3. 找不到人討論你覺得重要的事情，難以成長又很孤獨
公司在這個階段可能正在衝刺短期目標（賺錢、開發新產品）等等，其實無論往哪邊衝刺都會有成效，但也因此長期的產品發展通常會被忽略、甚至有可能沒有資源跟時間來做比較發散性的研究，因此每天就是在身兼多職的救火中度過。
因為講求速度，產品研究無法做得很深入、工作流程不會太細緻、沒有時間規劃長期願景，有些在完整配置的產品團隊會在乎的東西，在小團隊內根本做不到。沒有人在乎你在乎的事！
除此之外，因為你是唯一的 PM，很多時候大家就是相信你的解法、讓你來決定事情，有決策權感覺好棒棒！但從自己的角度來看，我本人資歷尚淺，還是會希望有資深的產品經理可以一起討論解法、檢查盲點、互相成長。不然自己一個人空想、看書、找公司外的人討論的成長幅度與學習曲線真的很平緩。
[ 我的建議 ] 從市場與使用者回饋來驗證與成長
當然，市場與使用者永遠是我們最好的老師。透過市場回饋來驗證自己的策略與判斷也是一條路，但很多小公司還沒有完善的數據基礎建設，所以這條路有時候也不存在。說服公司建立好基本建設是第一步（沒有盟友的時候其實很難達成），就算說服成功了，但如果自己沒有相關經驗，可能也不知道要怎麼定義數據、讀數據、做驗證甚至是進行後續的產品決策。
4. 有時候其他人想繼續緊握做決策的權力，產品專業難以發揮
不過關於決策權，我也曾經在另外一個團隊遇過跟上述完全相反的案例。
該團隊面試與招募我進團隊的是 CEO、COO，兩位對我的期待稍微有點不同已經讓我有些煩心之外，最難處理的是沒有面試過我的 CTO。他認為讓我決定產品走向是越界，因為這部分過去是由他負責的，因此有些會議他故意不邀請我參加，自己做決策，當有天 CEO、COO 問起，我才知道他自己在開發我不知道的功能。這也是「預期不同」造成的結果，整個團隊如果沒有共識，PM 這個職位本身就很容易踩到線或樹立敵人。
我也在另外一個團隊遇到類似但沒那麼極端的狀況。
在做跨國產品時，過去每個市場/國家的負責人都可以提出他們自己市場想要開發的新功能，並直接指派工程師開發；我加入後就開始執行一個「統一功能清理」的減法專案，盡量讓每個市場的產品功能趨於一致，改善與統一整個產品動線，差異的部分只留下必要的地化功能，不但會更方便產品團隊維護，也重新審視整個 UX 體驗與功能來符合大部分使用者的需求，砍掉那些當初開得天花亂墜疊床架屋的冗餘功能。這一開始也是讓各個市場的負責人非常感冒，我一來搶走了他們直接開需求給工程師的權利，二來我還預計要刪減他們的部分功能，最後花了非常多時間溝通、以及我主管的旁敲側擊協助，才讓他們理解我是來幫助他們與產品本身，而不是故意來搗亂的。
[ 我的建議 ] 聊聊其他團隊成員與產品的分工期待
加入前/剛加入後，多跟幾個不同部門的人聊聊，確認他們對於 PM 工作內容的認知、目前是誰負責與瓜分了一般 PM 的工作內容，以及他們想像未來這部分會如何跟新的 PM 合作（或交接） 。
舉例來說，在沒有 PM 的時候，可能是由業務團隊來規劃 roadmap、QA 主管負責專案管理與決定上線功能的時程與順序 … 等等，那如果有新的 PM 加入，他們希望 PM 完全接手嗎？還是他們想繼續負責？或是他們有希望的合作方式？老話一句，還是跟期待管理有關。
當然大老闆夠挺的話，一聲令下全權交給 PM 主理，那當然是最簡單暴力的啦！
5. 團隊沒有產品文化，建立理想的產品工作方法是條漫漫長路
除了三、四外，另外一種常見的狀況，就是老闆本身不是產品出身，但是自己有很明確的做產品的想法。這個我在《【產品團隊甘苦談】如何處理各種「隕石開發」的緊急要求？》中也提過，老闆身經百戰，最初的產品也是從他手上慢慢成長的，他認為他是最了解市場、客戶、產品的人，所以他深信他的想法肯定是對的。
很多時候關在房間裡討論很難說誰對誰錯，我自己信奉的概念是快速釋出 beta 功能去讓市場與使用者測試，但從老闆角度來看，如果不確定產品功能最終會長怎樣，會很難跟投資人或客戶交代；有時候他也不能接受看起來比較陽春、簡單的版本先被釋出（這部分有些設計師也不太接受）。
除此之外，說服公司付費使用一些有利於產品管理、專案管理、數據分析的工具有時候也是一大難題，他們很難透過想像來理解工具會如何運作、成效如何，再來就是全公司可能只有 PM 我本人有強烈慾望使用，所以通常的做法會是先使用免費版試用給團隊看，再來慢慢說服公司花錢買更進階的服務。
總之從頭開始解釋自己做產品的價值觀是一件非常困難又累的事情，尤其當你才剛加入團隊，大家對你沒信任感，也還沒看到你做出的成績時，就是一陣孤軍奮戰。
[ 我的建議 ] 培養團隊信任＆從低成本的方法開始嘗試
趕快建立戰功，爭取團隊對你的信任與依賴，未來才有機會好好推動自己的想法！對於想推動的事情，可以先找到輕量化、低成本的方式嘗試，例如使用者研究可以參考這篇文章。
當然，如果能夠找到有產品概念的團隊、創辦人，這段路會走得順利許多，老闆有心很重要啊啊啊啊！！！老闆本身是商業、技術、產品等不同背景出生，會對於公司內部決策方式與工作文化造成巨大的差異。加入團隊前可以做的研究、判別好團隊的方法可以參考這篇文章。
而產業與產品本身也會對於剛起步時整個團隊最重視的價值、最優先安排資源的部門有非常大的影響。若是「產品驅動」的商業模式，PM 能發揮的舞台當然最大；若是運營或商業驅動，PM 的工作很可能是以支援其他部門為主，「接其他部門的需求」與「專案管理」可能會成為工作內容的最大宗。
▍講了一堆缺點跟挑戰，那優點呢？
這些優點其實跟缺點是相對的，如果你能從另外一個角度來看事情，也許會認為這些都是很值得一試的團隊經驗！
1. 有機會接觸產品管理的不同面向 — — 現有產品優化、新產品實驗、開發新市場
我的第一份工作是在做現有產品的優化，這也是我目前最擅長的類型。但後來加入其他團隊後，他們多多少少都有開發新產品、或用現有產品開發新市場的想法，而這是我過去沒有嘗試過的。
雖然不會一開始就讓新任的 PM 全權負責新產品的概念、目標，但一定會需要我從旁協助專案管理、功能發想與實作、第一個版本的驗證等等，因此有機會參與一個新產品從零到一的建立過程。反正全公司就你一個 PM，所有專案可能都有你的份。
2. 如果你很怕無聊、喜歡多元工作內容，那每天都會覺得有新的挑戰
如果你是團隊裡唯一的 PM，很多人會來問你問題，不知道誰負責的事情可能就得由你來做（或至少由你找人來做），昨天可能是在討論使用者、設計的議題，今天又變成討論技術問題和上線測試，明天緊接著要交出一份數據報告討論接下來的產品方向，然後每天可能都要花時間救火。
狀況好的時候會覺得每天都很好玩、有不同的挑戰、幾乎做產品的所有工作項目與技能都可以碰到；狀況差的時候會不知道自己東做一點西學一點到底有沒有累積、流程亂成一團沒有專責的人負責很煩，就看個人喜歡的工作內容與工作方式。
3. 會有很多接觸第一線使用者、團隊成員的工作機會
一樣是分工的問題，若有多個 PM 的大型團隊，大家分工明確，會接觸到的人就很固定，第一線使用者、客戶也有專人負責維護或做使用者研究。但在小型團隊、資源不夠、分工不明時，會有很多機會接觸第一線使用者。
我某份工作是做電商 B2B SaaS 產品，早期曾經跟著 Sales、BD、COO 等商業團隊一起去拜訪客戶，參觀他們的辦公室與倉儲，現場了解老闆在意的面向、第一線員工每天的工作內容、物流方面如何揀貨與貼標籤，並面對面做使用者訪談與搜集客戶的意見，是非常好的學習經驗。後來隨著團隊成員變多（我也變忙後），就由 AM 去負責做第一線的拜訪與訪談工作，我則在辦公室等待他們整理好的客戶回饋與洞見；而為了效率與便利性，往後很多的使用者研究也都是線上遠端進行，就不再有到現場拜訪的機會了。
當然，在某些分工明確的公司中，PM 依然常常到第一線是探訪使用者、客戶，因此也不一定跟團隊大小或產品階段有關，這一點就給大家參考參考～
4. 在小型社會中訓練「跨部門溝通」、「利害關係人管理」的技能
呈上，因為工作流程與分工還沒那麼完善，所以非常需要頻繁的跨部門溝通、跟利害關係人溝通。我相信這些技能在大公司也會需要，但在人數還少的時候有很多機會去測試與驗證怎樣的溝通流程是比較有效的。
這部分也包含使用的溝通工具、內部工作流程的優化，小團隊的彈性更能接受頻繁的改動，大家可以一起討論什麼才是最適合團隊的工作方式與工具。
5. 有機會把產品團隊捏成自己喜歡的形狀＆升官發財
這一點應該會吸引很多想要一展長才的資深產品經理！早期加入的優點就是有機會把自己喜歡的產品文化導入公司，早期加入也容易談到比較好的薪水與條件。
畢竟如果能創造出一個自己喜歡的工作環境，那肯定是最幸福的事了！
▍結語：誰適合擔任第一位 PM 的角色？
上面講了這麼多優缺點跟會遇到的問題，如果自己可以接受、看完也覺得好像很好玩很有趣很有挑戰性，那你可能就是適合的那一位啦！（但不覺得感覺就是一個超級大雷缺、大屎缺嗎！！！）
執行力強、抗壓性高、能夠妥善運用有限資源是最基本的。
我想分享的唯一一點是，新手非常不適合擔任這個角色。一來無法有系統地學習，在這個階段的團隊中工作，如果你沒有自己的中心思想，很容易學到一些短視近利的壞習慣；二來這個舞台你撐不起來，畢竟還沒建立自己的工具庫與工作方法資料庫，也沒遇過夠多需要大量溝通與抗壓的情況，很難做好這份工作。當你還沒看過什麼是「好」的工作方法，是很難自己憑空想像出來，而這個階段的團隊正是要仰賴你帶入這些好的產品工作方法的。
從公司角度看，他敢錄取你，感覺也很不合理，所以如果你真的被錄取了，也請好好思考他招募的其他團隊成員的背景與能力大概在哪邊。在此也分享一篇 PTT 舊文《Re: [心得] 為什麼我非常鼓勵年輕人去參與startup？》裡面提到新創招募人時「謹慎」的重要性。
理想的狀況是自己已經有幾年的產品工作經驗，因為看過好的、糟的產品工作方式而有喜歡、想嘗試的工作方法，同時對於要做的產品領域、產業也熟悉，並且不排斥有可能會雜亂無章的技能樹生長，那你很可能就會是適合加入還沒有 PM 的團隊，成為打頭陣第一人！
相反的，如果你看完這篇文章覺得自己不適合這個角色、這個階段的公司，推薦《Stage of company, not name of company》這篇文章，他將公司的成長過程分為 (1) pre-product fit, (2) post-product fit, (3) growth, (4) scale 四個階段，文中也分享了在這些階段的公司中工作應有的期待。
最後，祝福大家都找到適合自己的團隊！
謝謝你的閱讀！如果有任何回饋或有興趣的主題，歡迎留言給我們 📒如果單純想給我一點鼓勵，請給我 1–10 個拍手；
如果覺得文章對你有點幫助，請給我 11-30 個拍手；
如果想看更多團隊合作與職涯相關文章，請盡情長按拍手（max 50）讓我們知道 👏🏻想要持續追蹤我們的最新文章和 Podcast，記得追蹤「產品三眼怪實驗室」的粉專(◉◉◉)！
我們每週都會認真更新唷！千萬別錯過了～
