1. 不懂就問，切勿裝懂
PM = Product Manager 產品經理，有些公司可能是 Project Manager 專案經理，其實從英文來看應該比較清楚，就看是管產品的還是管專案的。
這篇文章所稱的 PM 是前者，所以顧名思義，該人的職責就是 manage the product (and manage it well)。這表示：PM 必須掌控產品的需求和時程，再往回推，如果要做到這些事，代表這位 PM 也必須知道一個產品的目的是什麼，並確認相對應的需求是否合理，最後才把實作進度分配下去。
所以流程是這樣的：
(1) 了解需求端的目的
→ (2) 確認需求是否合理或是否可實做（如果不合理或有部分需求不適合直接實做，可以怎樣調整？應該怎樣調整，才能使用最小資源就完成需求端的目的？）
→(3) 確認要進實做後，就開始安排相關時程
當然這個流程是把一切簡單化了，每個人都知道這個流程不會這麼流暢地跑下去，身為一個 PM，如果有哪個環節搞不懂，就去搞懂，否則很容易淪為各部門之間的傳聲筒。
2. 找平衡
舉個例子：身為公司主要的需求端（行銷部門），我們每個月都會至少做一次線上活動，比如抽獎、打折、異業搭售等。我每次都會先把活動目的、主題名稱、希望的主視覺風格、活動方式、活動時間給寫成 MRD（Marketing Requirement Document），PM 就可以依此確認需求，並且自己去找工程師和設計師討論可行性。
這個時候， PM 通常會有很多問題，比如工程師會跟說：目前系統機制沒有「打折」這個機制欸；設計師會說：目前案子太多，沒時間做出一整個獨立活動頁。
但身為一個（有 sense 的）PM，不該只是把這些工程師或設計師等實做端來的問題丟回給需求端，而是應該先經過自己的推敲、整理和思考，然後在實做與需求兩方找到平衡。
系統沒有打折，但有折價機制啊！原本行銷想要活動可以打 9 折，如果 PM 知道產品的客單價大約 3,000 元，打 9 折後等於 2,700 元，那不如就試試看全站折價 300 元，這樣有沒有符合行銷原本的意思呢？
設計師太忙了，但這次行銷活動也不複雜，訊息沒有多到一定要放在一個活動頁裡，用彈窗就可以做到這件事了吧！
總之，身為 PM，要做的不是順應所有需求端的需求（要是都順應，實做端也會殺了你），也不是被實做端壓得死死的（要是被壓死，需求端也會來逼迫你）。
PM 要做的是找尋替代方案——一個讓實做與需求端都能接受的最大公約數方案。
3. 練習溝通，達到雙向交流，而非單向施壓
我的朋友在電商平台工作，他曾短暫跟一個新進 PM 交手過，每當他提出需求（MRD 都還沒寫呢，只是開口問說：「我下個月想做一個特價專案是……」），PM 就會先來一句：「工程師沒空，他們在修 bug，你是要 user 可以在我們平台上看到特價，但產品有一堆 bug，還是產品可以正常使用，而他們下下個月也照樣可以看到特價活動？」
通常聽到這種話，心中的白眼會先翻個 2,580 圈（對，我沒膽，我朋友也沒膽，我們的白眼只敢在心中翻）。
因為，說真的，這干我們屁事呢？產品本來就會有所謂的開發跟維運，PM 要做的就是調配兩者進度，不可能永遠讓工程師在修 bug，也不可能工程師只需永無止盡開發新功能，兩者一定需要交錯進行的，不然公司還要不要賺錢？
就算 PM 知道工程師真的很忙，為了公司的商業目標（通常是賺錢）考量，就不該聽到任何需求就先 say no，應該先去聆聽，然後吸收並理解，再進行評估，最後做出決定，並且告知相關單位，自己是基於什麼原因做出這樣的決定。
同樣身為企業中的需求端（通常也會是幫公司賺錢的主力單位之一），我也非常不喜歡 PM 直接拒絕（或直接答應）一個需求。
直接拒絕，會讓人覺得 PM 根本沒有在聽我說話——如果有在聽，並且有聽進去，那就應該會在拒絕之餘，先解釋原因並建議其他解決方案。
直接答應，會讓人覺得 PM 沒有認真思考這件事的可行性。通常一個專案的龐雜程度不是 PM 點頭即可，還需要跟實做端討論可行性與時程，如果 PM 可以把持這一切，要嗎是這個 PM 真的非～～～常猛（那我當然心服口服），要嗎就是這個 PM 擅自幫實做端決定他們的生死（與加班的命運）。
說服是一種技巧，更是一種藝術，要如何說服行銷單位縮小需求，以便工程師準時完工？要如何說服工程師這個專案應該先做哪個部分、價值在哪裡，以便工程師心服口服全力投入？
壓時程、搬出老闆、搬出公司誰都會，但這就是人人都會的「放大絕」而已，大家服的是你搬出的藉口，不是你作為 PM 的專業。
4. 理解
PM 是一般民眾（通常是銷售、行銷、客服等需求端）與實做端（通常有工程師和設計師）之間的橋樑，當工程師用技術語言講解某個需求為何不能被實現時，PM 必須經過理解和消化後，轉達給民眾。
當一般民眾開出需求後，PM 也必須將其翻譯為工程師看得懂的文件（如 PRD）。如果作為 PM，卻只會複誦而非內化再表達，那只是個取代性非常高的傳聲筒。
總之，PM 既要懂管理（也就是一些難以被量化的 soft skills），也要懂技術（不管是寫 code 還是設計 UI，都算是 hard skills），如果還處於菜鳥 PM 階段，建議可以先思考該怎麼分配這兩個比例。
如果自認善於多工與溝通，可以考慮多培養一點人際交流、時間管理的軟技能，確保產品能跟著時程走，也確保各單位都滿足你的行事風格與最終決策，這樣一來，大家都能聽從你的建議、與你和平共事。
如果有技術背景，或者至少對於技術有興趣、能稍微理解，那你可以多鑽研技術面的東西，這樣子當需求端提出需求時，你會比較有相關經驗去判斷這樣的需求是否合理、需求端給的時間夠不夠實做，實做端大約會怎麼處理這個需求，而不是直接把需求轉貼給實做端，這樣就又把自己當傳聲筒來使用了。
講了這麼多，很多人都覺得 PM 就是屎缺，每天被需求端壓時間、被實做端嫌東嫌西。一個好的 PM 很難找也很難做，因為他被期許為是一個懂得技術層面的專案／產品管理者，但這既是困難處，也是讓人有價值的重點。
PM 在團隊可以是非常重要的核心角色，如果說需求端給的東西是草圖，工程師與設計師的產出是磚塊，PM 扮演的角色其實是磚塊之間的黏合劑，多則讓整個建築顯得拖泥帶水，少則讓基底不穩；如何拿捏多寡，靠能力、更靠經驗。
