大家好，小弟分享在不同地方當產品PM的差異與省思
Medium好讀連結 : https://reurl.cc/ykAZbO
--
PM這個詞，廣義的PM就有各式各樣的職務內容，即使把範圍限縮到產品管理(Product
Management)之後，會發現每個公司對PM的想像，還是有巨大的差異，而如果心中沒有定
義自己要是一個什麼樣的PM，或是想要長成什麼樣的PM，那很容易隨波逐流不知道飄到哪
去，也沒辦法對於想加強的專業做有目的性的加強。
以下我會分享在產品這條路上，曾經見識過的PM型態，然後試著解釋，形成這些PM職務內
容的可能因素，也提供給看文章的大家一些借鏡或延伸思考。
曾經見識過的不同PM型態
Account管理產品型態
這個型態概念上像是經紀公司，但是變成互聯網型態的運作，概念上就是找一個偶像合作
，利用KOL的IP來創造產品。
而在這樣的型態之下，產品能否持續迭代取決於這個KOL紅不紅，如果對方的聲勢如日中
天，在公司內就較有說服力去提案產品的功能推動。因為投入比較有增長機會的回報。
但在這樣的型態內，就要負責很多AM(Account Manager)的角色，好的KOL如果拿翹，你會
痛苦萬分，因為很多溝通協調跟利益拉扯，PM在公司與KOL(外部公司)之間，要拿捏好溝
通的平衡。
另外一部份是不紅的KOL，公司會自然而然的排擠掉對方的需求，想迭代什麼產品功能，
永遠只能對對方說最近開發排程比較滿，時間未定，久了之後這種冷釘子對方也知道，就
會淡化跟公司的合作了。
而在這樣的型態之下，如果有機會經營到夠紅的KOL，在產品活躍的情況下，也可以在產
品與用戶的互動過程中，也能夠去發掘到一些洞見，進而增強自己在產品微觀上的能力與
經驗。
但有也有很多時候，是必須放棄自我堅持的，因為要聽強勢的KOL堅持做某些功能出來，
甚至還會替你定義流程，有時是必須吞下的無奈。
功能型團隊型態
這種團隊型態我遇過兩種情況：
一種是源於組織高度分工後而拆解出來的部門，他們需要出縝密的需求文件，對於產品的
邏輯和流程可能都要細緻而嚴謹，這樣團隊的好處是在思考產品功能流程的時候，在思考
上可能邏輯會變很快很好，
但這樣的部門通常離用戶會比較遠，當功能變的只是一個功能而不是一個服務用戶的模式
時，對於產品的思考會變得比較單向跟侷限。
之前面試類似這樣的團隊，和他們在討論產品的商業模式或是服務模式的重新定義，他們
露出了”哩爹功煞”的表情，這令人覺得很可惜，產品人的能力不該只是當一個繪圖和
word的工具人。
另一種則是源於管理者的偏執，在討論的時候他就要建好產品高仿真的原型，那個原型是
為了討論的一個初稿，嗯…就只是要一個初稿，然後一天工作12個小時就只是一直在改
wireframe，用戶的需求其實也沒有定義清楚，但PM就只能接需求然後畫圖做原型，才能
跟管理者討論。
拜那家公司所賜，我在短短時間就練就還不錯的Axure能力，也多了解了新一種瞎忙型式
。
產品在規劃的過程中，需要有層次的討論和開展，從需求模糊到逐漸釐清，到後續安排與
運作組織資源，每個情況都需要思考跟評估要消耗的成本，這樣的運作模式是很奢華的，
而且那還是一家新創。
一個好的產品人也盡量要有好好運用資源的能力，那關乎到在組織的信用，而組織知道你
是能很好運用資源的人，自然會投給你更多資源，前提是…組織對這件事情有意識。這件
事可以在一個階段內正向循環，然後，你就會遇到下一個坎了(笑)。
toB型態
toB型態可以再粗分成接專案的形式、或是面向B端的產品。
接專案的形式簡單來說，就是面向B端公司，完全客製化的需求，有時是做一個landing
page再延伸一些內頁，或是做APP裡面要有菜單、支付功能等等，但就是一次交付完整的
規劃，接下來動工執行。基本上就是一個打工仔的概念，有那種別人說什麼，我們就得做
什麼的意味。
面向B端的產品，舉例來說Salesforce、91APP等等，當你產品大到大家來找你時，你就可
以脫離打工仔的困境，更能以整個市場面交集較多的功能來考量roadmap，而不只是你說
我做的概念。
而在這兩條路上的技能點通常不太一樣，接專案的型式很容易把溝通(或是甩鍋技能)點滿
，因為產品功能如果沒有做的很制式化和熟悉，文件與時程控管通常不能如願，而當客戶
不理性的壓你時程，老闆唯唯諾諾去接受這種欺壓，通常死的就是PM。舉例：一個篩選功
能你覺得規劃加IT估工要三週，當客戶或老闆說一週半，你要不就好好舉證說這件事情為
什麼做不到，有些更保護自己的，就會推說其他部門沒做好，然後專案很容易就開始烏煙
瘴氣了。
即使專案環境的是好的，在迭代的面向上也不容易，當你的規劃與推動無法經由用戶反饋
來更新認知，在產品思維上則很難進步，雖然案子接越多你歸納整合的能力可能會變很強
，可能對不同產業的了解也可以更豐富，但基本上這種情況是深耕於公司而不是深耕於自
己技能，天花板大概就在那裡。
面向B端的產品，則要看公司推動產品的策略。如果產品只是草創，PM這個角色會比較容
易成為被使喚的角色，即使你有策略或是視角，但資源、時間有限的情況下，通常還是會
以老闆說的為主。但是當B端產品市場佔有率高了之後，上面的使用者與可看到的用戶場
景就會豐富起來，而這樣的豐富對PM來說才有更多著墨的點去思考與開展。
混和型態
當組織比較大，事業體或範圍更大時，在用PM的方式不一定會特別去定義產品經理或是專
案經理，他們會希望處理案子的人，可以交付明確的邏輯然後提出可以推動的方向。
處理的面向可能很多元，有可能從會員政策如何制定、到驅動事業體的業績、或是維運組
織內工具等等，在這樣的場景之下好處是可以增加宏觀的視角，去看待不同的專案和整體
組織的運作模式到底會怎麼變動。
這在台灣這種職位並不多，而且這樣的位置也不是太容易，因為你每次接觸新的專案都無
前例可循，可是組織內的案子如果推動好，你就能更好知道如何調整與調度組織資源。
在產品的面向上，你會知道拉到更高的格局在運作產品時，會有怎樣的困難，會卡在什麼
地方，你會增進打大仗的能力，也能夠更多的以管理層的思維在想整體架構的運作。
通常這樣的角色，要有政治敏感度、對事情大方向的思考、擷取重點給高階主管的能力、
對事情重新拆解再組成的思維，如果Jr.PM在這樣的場景中，很可能會迷失方向或是無法
掌握到一些比較模糊、難定義的專案狀態該如何去推進，但如果產品能力有一定資歷，遇
到這樣的情況，把每件事情都當作做一個新的服務模式，那會很有趣…吧。
數位轉型型態
這只會發生在大型的組織，而且對於一直在互聯網尖端的我們，相比之下會驚訝於自己在
數位上走的很前面，但有時也會反思，因為很多公司規模小，所以很多事情可以銳利、快
速解決，但卻無法克服資源層的貧瘠。
大組織資源非常豐富，但要如何從中去產生改變並且引導用更有效率的方式做事，這樣的
思維反而是我現在正在建立的。
有些概念在互聯網公司，可能一講就可以直接執行，但是在大組織中，我們要先找出某些
機會證明這件事可行，再找種子學員開研討會，接著再用種子學員去影響單位的事業體。
很有趣的點是，小公司或是一般互聯網推一個事情極快，但是可能只影響2萬人，但大公
司事情很難推動，但是當對組織有正面影響時，可能影響到的是30萬人。
而且當思維塞進去一個更大的地方時，它如果是有效益的，很可能會變成一個慣性去執行
，這是傳統公司在推動時難動的缺點，但推成功就變成是一個優點了(笑)。
在大組織內做事，好處是當你更有credit之後，你能思考的面向更廣、動用的資源也更多
，但事情通常動的相對於小公司慢，因為一個專案、一個服務模式，你可能要考量的面向
很多，溝通或是釐清細節通常也要更多時間。
另外一點是，如果組織文化不是比較活絡的、而是官僚跟傳統的，那麼你會遇到很多很多
的政治惡鬥，這種組織通常數位轉型只會失敗，這並不是我詛咒，而是人性只要一安逸或
怠惰，在組織裡變成常態，通常在做事就是對人不對事，而數位轉型通常就是在改變舊組
織的型態，這是來挑事的，那就更容易出事。
toC型態
對於這個型態太理所當然，差點忘記寫。toC這型態其實我覺得一路走來，Jobs神話了這
個角色，但是不是怪他，而是他真的是神。但我覺得有太多的人誤會了產品經理這個角色
。一堆人心中只有著美好的夢，覺得要有多極緻的用戶體驗，卻忘了現下的思考規劃應該
要符合現狀，甚至只是有這個態度，但是產品本身沒有策略、也沒有去思考用戶的點、一
切的出發都只是一個不切實際的感覺，這對於產品人來說是最諷刺的一個情況。
murmur完還是要說一句實在的，很多大PM可能都是從這種傻傻的產品夢開始的，在產品、
專案，從點到線，再到面應該都是個必經之路吧。
toC的型態是現在最廣為人知的產品經理，但是現在的產品論也都發展的五花八門，不過
我是覺得大部份都還沒有形成一個很明確的體系。畢竟牽扯的因素太多，從商業戰略、環
境、文化、服務環節、客群等等的，有時候一個環節錯掉，可能產品就掉鏈了。反而是大
家用熟自己習慣的，團隊喜歡的，能夠激發出創意的，然後可以持續推進專案就好。
toC的PM在台灣其實相對不好生存，因為台灣是淺碟市場2000萬人，從產品面向和定位，
篩選下來，你可能每個產品的客群是數千人到數萬人，而這樣的基底不一定能夠營利。不
能營利的話，很多的想法可能就無法付諸實現，而很多更棒的服務模式卻是從小想法開始
延伸的。這有時候變成一個雞生蛋蛋生雞的問題，不過最近都沒有雞蛋所以不用擔心了(
誤)。
如果要真的接觸到幾十萬以上用戶的PM，通常要到跨國公司或像是電商這樣，在生活中可
以高頻出現的場景。
所以我自己一路走來覺得有趣的是，我們看著國外的一些產品思維其實是奠基在產品環境
人數相對大的基礎上，但淺碟市場應該是另一種產品運作法。有時候感覺像是拿大砲在打
巷弄戰(笑)。
而且有時候雖然都是toC的公司，但是每家公司文化不同，對於PM的定義也不同，會發現
同樣都是做產品，那種運作的過程可以天差地遠，並不會有制式的套路可以追尋，最後總
是回歸到”對人”和”直面事情的本質”是最核心的唯一解。
面對PM在不同定位的心態
互聯網的產品PM這個職業在台灣、甚至全世界都還算是一個新興的位置，而很多新萌生的
企業也會圍繞著這個概念而生，所以這個職位也不會被明確定義具體到底該做什麼，但這
個位置又牽涉非常廣的層面。而在這樣的情況下換句話說就是充滿非常多的機會，但風險
也伴隨著機會而來。
風險可能是：
你沒有對的眼光，選到好的公司
你沒有足夠的運氣，去選到和你氣味相投的公司
你對自己沒有充足的了解，走在錯誤的路上
你沒有足夠的能力，卻對自己有太好的想像
你沒有足夠的視野，踩過一次雷再回頭踩一次
機會可能是：
你能力雖不出眾，但卡對位置公司站在風口上，你變成了核心團隊
你選小公司，但那小公司正好是車庫裡的微軟或google
你的能力隨著公司發展，提供了很多一般人歷練不到的視野或技能，你變成一個超稀缺的
人才
你選擇到正確的部門，可以讓你安心的推動專案且增進自己的視野
上面的機會我踩中的不多，但風險絕對都是我踩過的，然後字字血淚的概括出來的XD。
對於遇到不同的PM定位，該用什麼心態來面對大概分成以下四個概念來看：
產品運作模式是否認可
有些公司會注重單打獨鬥，把所有重責大任都單壓在PM身上，會以你提出的邏輯縝密度來
決定規劃，這樣的角色任務吃重，但團隊的聲音會相對弱化，這就看產品人的眼光是否毒
辣，或是反思自己規劃的能力夠不夠強、運用資源的創造力是否豐富，進而決定一個產品
的天花板。
有些公司則會注重團隊合作，PM在裡面更多是扮演穿針引線的角色，有時候部門一多，其
實產品規劃的重點反而在協調資源做最大的輸出，在這種角色下，如果沒有夠清晰的視野
或是用數據說話的能力，很容易在部門的漩渦中迷失，但如果協調能力夠強，也能知道產
品想往哪走，那產品的迭代方向相對會更有機更寬廣。
有些公司則是讓PM當成探索小隊，我遇過兩種情況:
一種是資源貧瘠的新創公司，招了一堆PM，但RD很少，但就是找PM一直生想法。但產品沒
有接觸到用戶、沒有迭代，說實在這種作法應該是蠻辛苦，就我所知那公司應該快倒了…
。
一種是大公司，處於集團層，在各個事業體裡面尋找業績突破機會，或是優化公司產品的
機會。這種運作模式，其實需要時也、運也、命也，因為沒能伸手進事業體輔助，有時候
在營運模式外面看也看不出什麼，但伸手進去也不一定能做出成績，但大公司有資源，整
體來說我覺得應該還是有可以切入的角度來進行。
在各種不同的產品運作架構下，我想還是找認同的做起來才能最自在。
我的看法是，做產品到後來，其實那個提出想法的我越來越不重要，但你怎麼引導團隊，
或是架構出一個想法，讓產品可以前進，在某些數據或是很明確質化的用戶場景，再反饋
給團隊，讓團隊、產品有自己的生命力和探索性反而對我來說是比較有趣的。
所以相反來說，那種單壓一個PM在做功能、或是純粹功能型工具人PM的部門，對我來說就
像地獄一樣。因為要那樣接需求然後去做wireframe，我不如當RD，薪水還比較高(無誤)
。
目前職位可以修練的方向
在你接觸產品一段時間後，半年到一年多不等，你會對產品的路有一條模糊的概念，但還
不太有清晰的架構。可能還會開開心心的以為眼前的wireframe就是一切，也可能還傻傻
的看著數據孤島一個一個建立還很開心自己的公司有在做數據，但如果有一些契機讓你摔
了個跤，你會開始意識到，原來產品重要的從來不是眼前所看到的框架，而是這一小角海
底的冰山，它有可能是人、有可能是政治、有可能是對於用戶體驗的洞見。
我曾經被一個資深設計師欺負，嫌我wireframe很爛，嫌我不懂很多東西。但我卻不能夠
很有力的反駁，就這樣被欺壓了一陣子。但也因為摔了這個跤，我也開始反思，在
wireframe的繪製上，原來都還亂截圖在拼貼，後來才發現拼貼也不是不行，只是
wireframe有時是一個重在快速說明概念，有時要進開發，你可以把它刻的很細緻，它是
搭配著你產品討論的一個運作模式，不是像當初那樣亂拼貼，也不是像那個資深設計師說
要刻到多細、互動要多好。
而在不懂很多東西上，在做產品時可以有很多套路，user journey、persona、design
thinking、定義Roadmap等等等的運作架構，但我那時候對這些東西，毫無概念，連回嘴
都不知道怎麼回XD。
說實在這些套路可用可不用，有時使用是想訓練團隊的產品思維，有時是真的用來探索用
戶的習性，所在的環境和場景不同，就可參考不同的方式來運作。我認為可以更貼近當下
企業有的資源與運作模式來推動產品，才是最重要的。
所以回歸到可以修練的方向，梁寧有提出產品人的三個構面：宏觀、中觀、微觀，簡單解
釋：宏觀就是戰略觀，打大仗的能力；中觀就是套路，上一段的那些方法皆是套路；微觀
就是你在產品上細節的規劃、對於用戶體驗、服務模式的感知與直覺。
通常新手也不知道自己在幹嘛，背後有多少資源，就可以藉著套路慢慢建立自己的思維模
式。
再資深了一些之後，會對於規畫上、面對的用戶上有更深一層思考的延續。
當你對於產品這件事有更深入琢磨後，你會知道在看待和討論一件事情的時候，絕對是從
背後的因素和情況來了解起，而絕對不會是眼前所見的框架。
而我們可以盤點一下，在目前的環境上你究竟能走到哪或是往哪走，有些公司可能不知道
自己會走到哪，但你可以從手上的規劃來發想，有時候即使沒有足夠的實戰經驗，只要你
多往那個方向涉獵，心中的知識架構會自然而然儲備起來，未來遇到你就能快速的有方向
的探索，而不會只是一頭霧水原地打轉了。
你所欠缺的能力
產品本身也可以有很多不同的路，粗分可以分成產品專業和產品管理，那麼對於自己來說
，想要成為的角色是什麼？
說實在，在這樣的路上有時也是需要機緣和運氣，可能你想要的路，不一定能碰的到。對
我來說，這一路產品走來，我知道自己缺什麼，缺的還不少XD，但我知道自己絕對不要什
麼，所以當我發現走錯路時，我會很毅然決然的停損，錯個幾次之後，方向就會明確了(
汗)。
向外的話，如果你不知道欠缺什麼能力，你整理好履歷之後開始投，慢慢投，慢慢面試，
當你遇到覺得厲害的面試官時，就在結尾問對方說，自己在產品面上還有什麼需要加強的
。一部分也會在接觸不同公司、不同業態的時候，他們提及的一些內容和反饋，都可以擴
充自己在產品上的思維。
向內的話，你可以反思自己在規劃上一些專案管理的能力、或是選議題規劃的能力、溝通
協調等，專案到你手上，它會是有條有理的、有憑有據向前進，還是很多事情不清楚，但
就莫名其妙完成了。
分享一個個人想法，如果你不知道自己的缺點在專案運作中是什麼，也大多不知道專案中
的困難可能會發生在哪、或是有什麼要注意的，那你通常就會是專案裡最大的問題XD。
組織信任感
有時候組織如果做的事情比較多且雜，我覺得也不是壞事。只是我們要能夠為這些事情釐
清重點，建議組織該做什麼、不做什麼，用產品思維來面對交派的事情，我有時覺得專案
經理可能也可以當成產品經理來做，只是你的客戶從C端變成組織內部了XD。
而組織有時在發展過程中，如果這個組織是你所信賴和喜歡的，現在對我來說做不做產品
其實隨緣，因為你總是會有做產品的機會，但好的組織不容易找到，在一個雷包地方做產
品和在一個開心的地方做專案，我想問問每一個產品人，你要選哪一個？
台灣的環境並不友善到，可以輕易找到好好toC做產品的地方。而且另外一個觀點是，當
產品做到後面，你會有更多的思考資源運作、還有溝通協調、同時思考公司態度是什麼，
有時會漸漸模糊化產品與專案的分野。
所以到後來，我覺得起頭的產品思維很重要，但有了一定水準的思維模式之後，隨著認同
的組織去推動很多事情，遠比"一定要做產品"這件事重要的多。
而在組織內部，你做事的credit越來越多和視野越來越廣的時候，發現機會後再以產品思
維來推，也是很有可能成就一番大事的。
總結
PM的路很彎且有很多方向，有時想要的也暫時拿不到，但你如果在一個確定拿不到的地方
待著，你就真的拿不到了。
在這些定位底下，真的能夠幫助你成長的是什麼？必要時借助各種產品框架來建構脈絡，
看懂你現在工作型態的total picture，它會有助於增長宏觀視野，也能夠帶你往更高一
層的產品視野邁進。
不同產品定位的拆分運作，都是由當初核心團隊在商模、組織運作、個人思想下，慢慢演
變而來，認清在體制內可運作與不可運作的情況，才可能讓你個人與產品有更大的發揮與
空間。
同時也好好審視自己過去的軌跡與未來的歷程。產品管理還是可以有很多面向，如果想在
這條路走，可以是Senior，Principle，也可以是管理職，組織內的credit跟產業未來的
路，這些都要納入考量，清楚現在的定位，就越能夠知道做什麼樣的提案或是產品規劃方
向可以更符合組織所需要的服務模式。
知道產品要往哪處之前，先知道自己身在何處，這樣才能在蜿蜒崎嶇的產品路上不迷失且
有方向的往前進。
--