身為一個 PM,你基本上要具備的技能有...

身為一個長期跟 pm 打交道的倒楣行銷(好啦,公平點,或許 pm 也覺得他遇到我很倒楣),我從這兩年內交手過的 5 個 pm 身上學到不少事。

我知道說的永遠比做得容易,但我還是要說哈哈哈,並且決定在此分享我心中 pm 的 do’s and don’ts.

如果你是 pm,你可以參考看看,在一個外行人眼中,這些外行人對於你的工作職責有沒有什麼誤解或過度簡化;如果你不是 pm,那你也可以跟我分享你眼中的 pm 又是怎樣的角色 & 有怎樣的技能。


1. 不懂就問,切勿裝懂

pm = product manager 產品經理,有些公司可能是 project manager 專案經理,其實從英文來看應該比較清楚,就看你是管產品的還是管專案的。

我在這篇文章所稱的 pm 是前者,所以顧名思義他的職責就是 manage the product (and manage it well)。這表示:他必須掌控產品的需求和時程,再往回推,如果他要做到這些事,代表必須知道一個產品的目的是什麼,才能確認相對應的需求是否合理,並且把實作進度分配下去。

所以流程是這樣的:(1) 了解需求端的目的→ (2) 確認需求是否合理或是否可實做(如果不合理或有部分需求不適合直接實做,可以怎樣調整?應該怎樣調整,才能使用最小資源就完成需求端的目的?)→(3) 確認要進實做後,就開始安排相關時程

當然這個流程是把一切簡單化了,但我想說的是:每個人都知道這個流程不會這麼流暢地跑下去,身為一個 pm,如果你有哪個環節搞不懂,就去搞懂,否則你只會淪為各部門之間的傳聲筒

2. 找平衡

我直接舉個例,身為公司主要的需求端(行銷部門),我們每個月都會至少做一次線上活動,比如抽獎、打折、異業搭售等。我每次都會先把我的活動目的、主題名稱、希望的主視覺風格、活動方式、活動時間給寫成 MRD(Marketing Requirement Document),pm 就可以依此確認我的需求,並且自己去找工程師和設計師討論可行性。

這個時候, pm 通常會有很多問題,比如工程師會跟你說:目前系統機制沒有「打折」這個機制欸;設計師跟你說:我目前案子太多,沒辦法做出一整個獨立活動頁。

但身為一個(有 sense 的)pm,你不該只是把這些工程師或設計師等實做端來的問題丟回給需求端,你應該先經過自己的推敲、整理和思考,然後在實做與需求兩方找到平衡

系統沒有打折,但有折價機制啊!經過你一算,原本行銷想要活動可以打 9 折,你知道產品的客單價大約 3,000 元,打 9 折後等於 2,700 元,那不如就試試看全站折價 300 元,這樣有沒有符合行銷原本的意思呢?

設計師太忙了,但這次行銷活動也不複雜,訊息沒有多到一定要放在一個活動頁裡,我們用彈窗就可以做到這件事了吧!

總之,我的意思是,身為一個 pm,你要做的不是順應所有需求端的需求(要是都順應,實做端也會殺了你),也不是被實做端壓得死死的(要是被壓死,需求端也會來逼迫你),你要做的是找尋替代方案,一個讓實做與需求端都能接受的最大公約數方案

3. 練習溝通,達到雙向交流,而非單向施壓

我以前曾碰過一個 pm,每當我提出需求(MRD 都還沒寫呢,只是開口問說:「我下個月想做一個特價專案是……」),pm 就會先來一句:「工程師沒空,他們在修 bug,你是要 user 可以在我們平台上看到特價,但產品有一堆 bug,還是產品可以正常使用,而他們下下個月也照樣可以看到特價活動?」

我通常聽到這種話,心中的白眼會先翻個 2,580 圈(對,我沒膽,我的白眼只敢在心中翻)。因為,說真的,這干我屁事呢?產品本來就會有所謂的開發跟維運,pm 要做的就是調配兩者進度,你不可能永遠讓工程師在修 bug,也不可能工程師只需永無止盡開發新功能,兩者一定需要交錯進行的,不然你公司還要不要賺錢?

就算你 pm 知道工程師真的很忙,為了公司的商業目標(通常是賺錢)考量,你不該聽到任何需求就先 say no,你應該先去聆聽,然後吸收並理解,再進行評估,最後做出決定,並且告知相關單位你基於什麼原因做出這樣的決定。

身為需求端(通常也會是幫公司賺錢的主力單位之一),我非常不喜歡 pm 直接拒絕(或直接答應)一個需求。直接拒絕,會讓我覺得你根本沒有在聽我說話--如果你有在聽,並且有聽進去,你應該會在拒絕我之餘,告訴我原因以及其他解決方案。直接答應,會讓我覺得你沒有認真思考這件事的可行性。通常一個專案的龐雜程度不是 pm 點頭即可,還需要跟實做端討論可行性與時程,如果 pm 可以把持這一切,要嗎是這個 pm 真的非~~~常猛(那我當然心服口服),要嗎就是這個 pm 擅自幫實做端決定他們的生死(與加班的命運)。

說服是一種技巧,更是一種藝術,你要如何說服行銷單位縮小他的需求,以便工程師準時完工?你要如何說服工程師這個專案應該先做哪個部分,價值在哪裡,以便工程師心服口服全力投入?

壓時程、搬出老闆、搬出公司誰都會,但這就是人人都會的「放大絕」而已,大家服的是你搬出的藉口,不是你這個人的專業

4. 理解

pm 是一般民眾(通常是銷售、行銷、客服等需求端)與實做端(通常有工程師和設計師)之間的橋樑,當工程師用技術語言講解某個需求為何不能被實現時,pm 必須經過理解和消化後,轉達給民眾。

當一般民眾開出需求後,pm 也必須將其翻譯為工程師看得懂的文件(如 PRD)。again,如果你只會複誦而非內化再表達,那你只是個取代性非常高的傳聲筒


總之,pm 既要懂管理(也就是一些難以被量化的 soft skills),也要懂技術(不管是寫扣還是設計,都算是 hard skills),在我看來,如果你還是個菜鳥 pm,可以先思考你想要怎麼分配這兩個比例。

如果你自認善於多工與溝通,你可以考慮多培養一點人際交流、時間管理的軟技能,確保產品能跟著時程走,也確保各單位都滿足你的行事風格與最終決策,這樣一來,大家都能聽從你的建議、與你和平共事。

如果你有技術背景,或者至少對於技術有興趣、能稍微理解,那你可以多鑽研技術面的東西,這樣子當需求端提出需求時,你會比較有相關經驗去判斷這樣的需求是否合理、需求端給的時間夠不夠實做,實做端大約會怎麼處理這個需求,而不是直接把需求 copy & paste 給實做端,這樣你就又把自己當傳聲筒來使用了。

講了這麼多,很多人都覺得 pm 就是屎缺,每天被需求端壓時間、被實做端嫌東嫌西。我也知道,一個好的 pm 很難找也很難做,因為他被期許為是一個懂得技術層面的專案/產品管理者,但這既是困難處,也是讓人有價值的重點。pm 在團隊可以是非常重要的核心角色,如果說需求端給的東西是草圖,工程師與設計師的產出是磚塊,pm 扮演的角色其實是磚塊之間的黏合劑,多則讓整個建築顯得拖泥帶水,少則讓基底不穩;如何拿捏多寡,靠能力、更靠經驗。

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.