職涯路上對產品與專案的歷練與反思
其實這幾年碰到的專案環境比產品還要多，原本想要條列式來表達產品和專案兩者的差異，但這樣不免有些枯燥和乏味，所以想說用比較故事性的表達：以自身在這裡面的思緒上的轉變來做陳述，而看文章的大家就當故事看看就好，因為現在的數位環境實在太多元，而有時產品和專案的分野也著實模糊不清，再加上每個人都是獨立的個體，所以有時可能都是比較主觀的描述。
這邊先落下我對產品經理、專案經理的定義，方便大家在後面看內容時的定錨：
產品經理
它是一個探索模糊的角色，而且要能夠去感知或猜測用戶的場景、心情，並且把這些素材轉化為可運作的服務模式(商業模式)，然後在這些基礎上，能夠定義出產品路線圖去帶領團隊打造有層次的數位服務機制或是還沒人插旗的藍海市場。
產品經理的個性特質會更偏向喜歡探索、能接受大量未知情況、有強烈的自我主張、勇敢等等，而擁有這些特性的產品經理基本上是天生狂野，不是太容易被拘束的，所以產品經理除了要滋長天生適合產品的敏銳度、同時也要被社會框架磨練，才有機會懂得在組織中如何與他人合作。
專案經理
它是一個收斂模糊的角色，針對老闆派下來的需求，可以有層次的解析專案要怎麼有效的被歸納、定義，連動的資源與時程都要盡量被明確定義，同時還去考量政治、 人情，也要能夠完整的針對橫向或縱向的溝通，怎麼讓專案有脈絡且按時交付的持續推進，是專案最首要的目標。
專案經理的個性特質會更偏向於嚴謹、分類整體情況、注重資訊的傳達與表達、為專案劃出界線，如何妥善安排整體專案的細節(如政治、時程、資源)會是專案經理最首要的目標，好的專案經理通常會很有脈絡的定義和說明整體專案要如何進行，將所有的已知彙整邏輯化說明、告知未知在哪，讓組織充分理解專案的效益與情況。
— —
這邊比較有趣的矛盾點會是：
產品經理做專案，會有那種"事情時間到了就可以執行了"的心態，然後藍圖只在他心中，有些主管會很不爽為什麼事情都沒有彙報，然後在專案中對政治和組織管理的敏感度相對低，如果跟到不友善的主管，真的是死路一條。
專案經理做產品，會有整體時程和邏輯都說得很明確，但是那種邏輯都是歸納後的概念，會變成在組織中事情看起來都很順利地推進，但做出來卻發現根本沒人要用，或是產品易用性極差。
那…接下來就先從一開始說起…
最初的階段 : 我以為我是一個還不錯的產品人，但其實只是一個廢廢的碰產品的專案經理
那時候的背景是剛進入互聯網產業，做了一年多的PC產品，推動了一些產品上線、負責產品有幾千萬的業績，那時候心裡還有點驕傲，覺得娃~我好棒棒，但那時候真正厲害的是大老闆，因為他構築了公司產品的護城河，同時因為產品是和KOL合作，所以KOL的粉絲信仰值都非常充足，有些產品還沒上線推廣就有用戶買了欸XD!!!或是產品的活躍數裡面，有1/4是已經訂閱產品的用戶。
那時候既沒有產品的戰略思維、立體看待互聯網流量的眼光、用數據架構合理產品路線圖的能力、也不知道該如何去探索用戶的場景和需求。基本上就只是整天跟KOL討論功能怎麼做，然後畫wireframe，跟內部討論完需求，東西就上架了。產品可以做的這麼爽，我還錯把KOL跟大老闆的厲害沾光在自己身上，哈哈哈。
其實那時候自己以為在做產品，公司也都喊著用戶體驗，但大部份也都只是從邏輯上去推導用戶可能覺得怎麼樣，但邏輯總是可以有很多面向，所以有時候在有邏輯都只是主觀，而老闆的主觀就是一種合理客觀(無誤)。
整體來說，大部份都還是以專案方式在歸納跟推動，就是一開始匡列好範圍，做好後大部份就不再迭代，但因為老闆的想法還是偏向於把產品做完整，而不是把專案劃定界線、資源來定時上線這樣。
而且公司裡面確實也有很多面向C端的產品，所以即使是專案，大環境的背景下，整體的專案運作還是會以偏向產品的思維來做進行。
那時候確實也開始覺得工作無聊，因為公司裡面沒有更厲害的人在帶我，自己也不知道該如何前進，後來一年半左右就離開了。
第二階段 : 遭遇產品與專案能力不足的雙向痛擊
後來有一段時間，在各個新創公司中流連打轉，在那個階段中主要是兩個點在痛擊：產品環境的選擇、專案職務的界線劃分，現在回頭看雖然還是很慘痛XD，但那些經驗確實也教會我很多東西。
產品環境的選擇
那時候在9個月內換了三家新創公司，薪水還越換越低XDDDDDD。從一開始離開上一個階段的公司意氣風發，覺得我好棒棒一定有很好的未來在等我，到後來變得更謹慎的思考，下一步到底怎麼踩會比較合適。
對於新創環境有興趣了解的朋友，可以參考我這一篇
>>>新創公司給人的綺麗幻想與殘酷現實
當時還沒有具備做一個產品該有的戰略觀、方向、資源、組織運作模式、公司利基點之類的架構，所以面試時也都和面試官非常淺薄的在討論曾經做過什麼東西，思考的層次也不深，所以當初讓我面試入職的，爛鍋配爛蓋剛好(誤)，但其實也是靠著進去這些公司的懷疑人生讓我重新組裝自己對於產品的架構，因為從原來有能獲利的商業模式的公司到毫無章法的地方，才會意識到原來運作產品需要章法，而這些章法反思後，也會內化進思考邏輯裡，有時候做不了產品其實也可以增進產品能力(這句真的不是幹話)。
專案職務的界線劃分
在其中一家新創公司時，和一個資深UI有了非常大的衝突，後來也因為這件事情離開了。
UI覺得我很菜，她也是很帶刺的人，我那時對於產品的推動運作確實也沒有足夠的經驗來判斷到底什麼事情是她做、什麼事情是我做，例如她從大公司來，之前很多PM交付給她的會是很完整很細緻的wireframe，產品文件也要非常詳盡，她也認為PM提出一個產品規劃，背後要有一定人物誌、user journey等等的框架做基礎。
產品運作上這邊概念都沒錯，但這些基本上是看情況由PM與UI協作，新創環境下的UI沒那個福分當純粹的GUI，PM和UI一定也要跳下來做UX的部份。但那時候可能自己也有一部份的自卑覺得對產品還不夠熟，另一部份是真的對於產品運作只有一家公司的經驗，並不真的知道在業界內怎麼做才是合理的，比較多都是被打壓也不知道怎麼回擊。
但很有趣的是，當在這個階段如果是專案管理的處理手法就會非常有趣，基本上會比較積極的跟主管和UI溝通，大家想要用怎樣的方式來讓專案進行，需要定義出什麼樣的職責和運作模式，當這件案子被這樣用框架劃分時，事情即使不完善，大家至少會有個基本共識來進行專案(或產品)。
只是那時候真的太菜，天生也沒有專案管理的sense，那時候真的弄得很難看，不過不經一事也就不長一智啦，但那事情之後專案管理還是沒有多大長進就是了XD。
在經歷了這個階段後，手上握著回前公司(最初階段那家)和全聯Px pay的offer，當時想著在前公司比較熟悉，業務也比較多元，所以回鍋了前東家。
回到前東家後，則是讓我對於產品和專案的思考再往前一個檔次了，但在專案管理上依然被痛擊，哈哈哈哈哈。
第三階段：做產品時不是只有做產品
那時候回去的環境情況，整體是非常適合優秀的產品人存在的環境，因為由PM主導整體數位產品的推動情況，而且是根據組別、產品別來劃分資源，所以只要產品人有合理的數據脈絡、邏輯足夠嚴謹的主觀推論，基本上就能夠讓產品往前進，即使錯誤也能夠快速迭代修正。
(題外話：但很可惜的是，當時公司試行這個政策時，大多PM都是Jr.PM，沒辦法有戰略、產品路線圖的概念來推動，大部分都只是針對現有的產品UI縫縫補補，整體幾乎沒什麼效益，所以PM的權力就被緊縮。那時候，大老闆便派了另一個做十幾年的專案經理來當產品教練，造成的災爛又是另外一回事了…)
在那個資源豐沛的環境，而我也有基本的產品運作概念加上KOL確實也很能夠吸金，我回去過了兩季後，那個組的產品成績在我推動下進行的很不錯。
而上面看到我的表現之後，決定交派給我一個大型產品的規劃。
我以為大型產品的推動，也是思考用戶要什麼、進而安排架構，卻完全沒思考到…大老闆在處理這樣的任務時，不會以產品的角度來切，而是以專案的眼光來追著案子上線，我以為在做產品卻沒想到其實是需要滿滿的專案管理技能。
一直以來所訓練到的用戶體驗、用戶思維、用戶旅程、人物誌、產品路線圖、數據分析、產品戰略族繁不及備載等等全部都派不上用場，這真的需要一定程度對長官、對組織要有足夠的敏銳度，才能知道下一步該怎麼進行。
我交代一下當時的背景，
1.老闆對這件事情根本不想動什麼用戶思維的腦筋：
因為老闆對這件事情的期待是盡快上線，所以他根本沒想管什麼用戶要怎樣，你先上線就對了。
2.多頭馬車進行：
這件事是老闆持股的子公司的產品，所以我在彙報的方向上會對到非常多角色，而這件事會讓整個案子變得非常混亂和繁複，我會對到的角色：
a.子公司PM(他背後也代表著子公司總經理的意見)
b.產品教練，當時公司在進行一個產品教練制度(那個很雷的十幾年專案經 理)
c.自己專案內的主管，他不承擔責任、經手過的專案都雷爆
d.母公司的老闆，想到也會跳進來對wireframe的細節有意見
3.我一直以來都是以產品探索和迭代為主，我完全不知道該如何管控這樣的局面，結果都想著該如何說服和回應他們的主觀。
4.這個專案內有一些內容是TPM比較容易做的(對我來說很困難)，因為用到IT在使用的use case diagram、sequence diagram，要去跟後端IT說明有哪些token可能要怎麼取、哪些機制要怎麼運作，那對我來說也頗吃力
所以在那個時空背景下，我一個人要對老闆、子公司PM、產品教練、主管，而他們都會對產品出意見，這些意見或建議要回應都需要相當程度的時間，同時老闆就覺得PM哪有分什麼專案、產品、TPM，你PM做就對了。
所以在這樣的情況下，我既無法有效歸納需求、對於產品上的技術規格也處理得很吃力、橫向也難以溝通，這些情況進而導致專案延誤，而那時候只懂得用我認為合理的邏輯(但他們只覺得是我的主觀)且帶著情緒去說哪裡不合理，所以被認為難以合作、專案時程延宕，後來還被開了一張績效改善單XDDDD，上面就隨便寫著規劃能力與數據分析能力不佳。
這件事情回頭看，雖然那個公司有頗大的問題，但我自己確實也有能力不足的地方，但都不是我所以為的產品能力，過了很久之後回頭看，才發現是專案管理的範疇，當時產品做得太心高氣傲，一點點都沒意識到，而這些技能我一一描述出來大概是下面這幾項：
- 評斷專案狀況的眼光
- 建立專案的共識
- 匡列專案的範圍
- 積極地向上管理與溝通
- 劃好專案的界線
這邊就只先概念提出這些面向，因為之前寫過一篇關於大型專案的內容，在這邊就不細節贅述，有興趣可參考這篇文章>> 大型專案是升遷的美夢還是多災的雷坑
這次的挫折就漸漸意識到，只有產品能力不是一切，如果真的有純以產品脈絡在運作的公司，當然能夠很開心的運作，但如果不總是這個情況呢？總不能抱著好的產品實力，但卻被束之高閣吧。
後來在市場上打轉了一圈，發現能純以產品思維運作的環境仍然非常少，不確定是台灣淺碟市場產品無法好好延伸發展，還是整體數位環境的管理層級還停留在過去純做專案的思維。
總之這時候對於產品、專案的視角就又更進一步的轉換了…
但即使這樣，我還是可以踩到雷，那時候一直在想，如果女生有渣男體質，我想我一定也有遇到渣公司的體質(?)
當時也一直在反思，為什麼一段時間的產品路都走的這麼坎坷，到底是我的問題、還是環境的問題，後來發現這些情況的本質是兩個問題都有XD
一部分是當產品人走到一定的階段之後，你不會只是在一個小地方做產品功能規劃而已，而是會接觸到更大的局面、更多的資源，而在這樣的情境下勢必會遇到更多的人，更多的人也代表著更多需求與期待，而有這些資源的人大多數會是在公司待得久的人，而…這邊要引用另一句話：「核心團隊是給待得久的人，而不是厲害的人。」
如果我也不是老闆，卻也不轉換產品人的堅持，那在公司的組織體系下絕對是沒辦法生存，有時候對產品人其實很殘酷，我們拿著合理的邏輯與數據支撐的證據想推動我們的規劃，卻敗給主管的"我覺得這樣比較好"，這種公司的取捨留存就還是回歸到各位心中那把尺。
第四階段 : 向上溝通與劃分界線不足而爆掉
那時候漸漸了解到"做產品"和"在組織內做產品"的差異，但還沒有充分理解到要怎麼用專案管理的技能來保護自己，我換到了另一家公司，這家公司算是給專案管理的技能再上了一次震撼教育的課XD。
那時候其實一到職就覺得很不對勁了，那時候的產品總監不是做產品上來的，聽說是做產品行銷然後跳到這個位置來的，但是一個行銷卻又不了解AARRR的概念…現在回頭想應該就要怕豹!!!
另外一個背景是 : 執行長的位置被架空，都是技術長在數位產品上說了算，而技術長只是享有權利卻沒有對應的能力。
技術長整天口口聲聲說用戶思維，在擋大家的規劃，卻不知道用戶思維推動的規劃背後，還是要有高層背後的策略當背景，然後產品總監沒有推動產品策略的能力，也只會一直巴結技術長。
結果就是技術長一直在賣弄官威說大家規劃沒有產品思維，然後整整三個月幾乎沒有任一個toC的產品功能被推動，真正不得不動的就是toB的合作案。
而這次又是我擔任苦主啦~噠啦!!!那時候因為IT開發量能不足，又處在官威體系底下，技術長出來硬壓一個時間，但產品總監和技術總監又都不敢出聲，結果後來時間真的壓得太緊，產品有正式上線，但測試過程有一點小出包(但無傷大雅)，所以技術長出來質疑這件事情，產品和技術總監都不敢出聲，我這個負責的PM就出去被指責了。
然後產品總監後來怕這件事會損耗他在上面的信任度，那時候在試用期附近，他打算直接開除我，後來還是人資出來擋說延期三個月，因為那個產品總監之前已經惡行多端了，也知道技術長擺弄官威的情況，但事態演變成這樣我也覺得荒謬至極不用待著了。
以下說到的專案管理技能，是為了在這種情況下純粹是能讓自己舒坦嗆他們一場的，這也是當時自己沒做到，在當時的場景莫名其妙挨揍，心裡留了一些陰影。
如果有機會再遇到這種情況(希望不要QQ)，最簡單的方式就是當時開會指責測試過程出問題的時候，直接回懟說 : 當時產品總監和技術總監都清楚這樣的情況，但他們沒有回覆你不行，這代表他們認為目前的資源是足夠運作的，所以這些情況應該還是要請教他們為什麼出了這些錯。
能這樣嗆出來，就代表在專案上，你已經盡了向上溝通與資源確認的責任，最好的情況要留溝通的底，但一般正常的公司是不用做到這麼極端啦，會到這種情形，通常公司運作的日常拉扯張力已經很大了，而這種情況下，真有非待著不可的理由就只能這樣剽悍的保護自己。
不管在做專案或是產品，想要補充的心態是，這些都只是工作，而工作是為了成就感存在，大家可能會覺得PM就是常常被罵，我做久了之後，覺得沒有這回事，誰他媽的在亂罵我就會嗆回去，劃分好界線、明確定義分工，該是我們承擔責任的就擔，但很多都是模糊不清的時候找PM來墊背，PM可以是幫你們把模糊情況定義出來的人，但不是該死事情都往你身上堆的人。
PM要能夠守護自己的工作空間，才會有足夠的心力在這條職涯上走的長久。
這也是這幾年我在包含產品、專案、整個工作路上不斷在調整心態的地方。
產品人如何看待專案思維
我曾經有一段時間很自以為的覺得專案思維不好，後來發現絆住我的確也是這種思考。
因為產品是探索、架構比較抽象的策略、生成可落地的規劃。如果要純粹的用這些思維來做事，以我的經驗這樣的運作模式只能在兩種情況下：
1. 由你負責且做大的產品
這樣你可以有充足的話語權，底氣也夠。
2. 公司真正在為用戶思考，產品思維貫徹到底的公司
這類的企業，我在台灣真的沒看過幾家，有看到的我好像進不去(誤)，大部份企業在運作時，都還是掐揉著管理層不願改變的偏執與自戀，或是用過去習慣的專案思維在進行。
扣除掉上述兩種情況，在運作產品的過程中，你就是會遇到滿滿的人，碰到滿滿的人基本上你就是要用到專案管理中劃好界線、框架定義完整、溝通期待、政治敏感度、向上管理等等各面向，來確保事情可以在組織中順利運行，當產品人走到一定的位階之後，必然會碰到這些事情，更大的產品也代表對組織內的資源有更大的挪用，要往上生長的產品人，專案管理是躲不掉修練。
其實對於專案經理狀況也是類似，專案經理在初期打磨的都是對人的軟實力，但是到後期越往管理層前進後，他們越需要對用戶的洞察進而生成有意義的策略，但這是在專案管理的時間比較難具備的技能。
不過現在的情況是，專案經理絕對、超級容易比產品人好升遷，因為他們對於有既定範圍的案子的掌握度，那細心程度、對人、對管理，都比產品人好一萬倍XD。因為產品人就是在探索抽象未知的人，細心、政治、管理在這個地方幫助不太大。但是升遷到高階管理者時所需要定義策略的能力，當專案經理沒有培養起來這技能時，企業就很容易在原地繞圈。
因為現在的時代是需要管理者不斷的突破框架，帶著企業前進。但容易升遷上來的角色在初期無法建立這種能力，但在初期有這種能力的角色，特質上可能又不容易走到那個位置，兩難啊兩難。
結論 : 產品與專案在這條路上的相愛相殺
產品做到最後仍然要向上管理和運作組織資源，專案管理的技能也許點不到最好，但產品的策略與用戶探索仍然是很稀缺的資源，職位越高越重要
專案也許前期吃香，但職位越高越需要創造力，這會是專案管理要重新修煉的地方。
而且這兩個技能在某些情況下，其實是相衝突的，專案是在一個範圍內將資源效益做到最好，但產品常常是在框架外探詢無限可能。
人在不同組織、不同時空背景要應用的比例大不相同，真的也只能根據所在的位置調整當下最適合的可能性，而不該一味的追著夢幻的產品環境或要求專案在運作時各種資源一次到位。
共勉之，願我們都能很好的探尋外部可能性與對內的運作效益最大化！
