前陣子批踢踢科技業版上有一篇文章：「PM 到底要做啥」，引起了一些討論（和工程師的酸酸與抱怨），其實內容蠻常看到的，都是工程師（後面簡稱 RD）常常會嘴 PM 的幾個點。
雖然我覺得這些批評常地圖炮，文中被炮轟的其實是「做不好的 PM」，而不是「PM 這個角色」本身，當然更不代表 PM 這個角色沒有價值。不過有這樣的評價，PM 當然自己也可以思考，是不是沒有找到自己的角色定位，沒有做自己該做的事情，或是在溝通上沒有控制多方的需求以及期待，才會導致雙方錯誤的認知。
以下整理前三名 RD 最喜歡抱怨 PM 的點，想要來釐清一下迷思，還有討論 PM 應該如何思考與自我定位：
抱怨一：出一張嘴不做事
要看「出一張嘴」是不是真的讓事情推進，或是解決了問題。如果有，其實「出一張嘴」也是一種做事，而且偏偏是許多 RD 很不喜歡做（或是很難做得好）的事。
許多人可能因為「本來就會說話」、「從小就會和其他人交流聊天」，而忽略「溝通能力」的價值，不認為這是一種專業，但是 PM 要做的事情，是「在不同時間點，戴上不同帽子，扮演不同角色，和不同的人溝通」。其實和 RD 的溝通，只佔 PM 日常溝通的一部分而已，而且愈高階的 PM，這部份占愈少，因為 PM 往往還要跟供應商、業務、行銷、老闆、代工廠、客戶、用戶……很多角色溝通，而且厲害 PM 和菜鳥 PM 能做到的結果差很多。
以和 RD 溝通為例，很多 RD 會抱怨「PM 只會跟 RD 壓 schedule，然後出一張嘴要你做」，很多 PM 其實會覺得很莫名，PM 問 RD 工時是一種尊重吧？不然要自己漫天亂估嗎？
差別可能在於 PM 的心態，以及溝通的方法。PM 在面對 RD 時，應該戴上「客戶代表」的帽子，而非「老闆的帽子」。
做為「客戶代表」，重要的目標是讓 RD 充分知道市場的需求長什麼樣子、為什麼有這樣的需求、背後帶有什麼商業價值，然後「你需要他們的協助，來實現這個商業價值」。
而不是像老闆一樣要求「畫押，然後做就對了」，甚至沒有畫押，直接押一個死線，必須完成任務。
這種思維的好處，除了讓 RD 感受到「參與感」，甚至是「英雄感」，而非「社畜感」，讓他們認知到自己的專業能力，才是實現這個願景的重要工具，也可以讓 RD 從他的角度，提出其他可行的解法。甚至一個團隊合作了一段時間，有了默契，並累積了一些對客戶的認知，有時 RD 會記得之前聽過的客戶需求，有機會就在程式裡加入一些優化（那時做為 PM 會超驚喜！），或是會主動與 PM 討論解法，這些都能讓整個團隊更進步，也更團結。
反過來講也有些 PM 會覺得，RD 為什麼總是一個口令一個動作，很多顯而易見的設計，沒有講就不做，遇到也不會主動問 PM，或是任何事情都要文件定義得清清楚楚才要開工，按表操課。其實，肯按表操課還是好的，慘的是文件最後寫得落落長，但根本沒人看。
其實我認為 PM 也可以思考，是不是雙方的溝通與合作模式，讓 PM 少了「為什麼要這麼做」的溝通，習慣讓 RD「做就對了」，一旦習慣了這種「接單生產」的合作模式，怎麼能期待對方有對產品的熱情與 ownership，主動「多做一步」呢？ 或是 RD 吃過虧，「有私下答應過」的功能沒做到，被 PM 拿出來 highlight 變羅生門，久而久之就會要求什麼都先更新文件以自保。
其實我覺得這種「公事公辦」，都是雙方合作缺乏互信以及默契的結果，帶來的結果其實是一種資源的浪費，這當然雙方都有責任，要公事公辦也不是不行，但這樣的結果 PM 一般會比較痛 XD，所以雖然初期的溝通與互信的建立很花時間，但我認為
PM 最重要的「做事」，應該就是在溝通中搞定多方，而這也跟 PM 的專業能力有關 ── 如何挖掘真正的「Why」，並傳遞價值、激發熱情，是要有深刻洞察才做得到的。
抱怨二：需求一直改一直改，schedule 卻沒變
其實我認為這個問題背後的問題，是資訊不透明，PM 沒真正搞懂需求是什麼，心中也沒有商業價值判斷，就很容易變成傳聲筒，擋不住客人或老闆的要求，不過反過來我也必須說， 奢望需求一旦確定下來都不會改的人，跟要求程式寫好測過就要沒 bug，是一樣的天真呀。
即使「改需求」難以避免，但 PM 還是有些能控制的方向，減少「人禍」造成的需求變更。從基本功開始，PM 至少要明白客戶或用戶這麼做的「目的」是什麼，因為一般而言，客戶開案的大目標不會有太大的改變，但是對「怎麼實現」會有很多意見，
如果雙方可以在目的，也就是「Why」方面先建立共識，其實在後續的「How」如何實現，會更容易聚焦。而且這也會扣回第一點 ── 你如何讓你的團隊真正了解需求，一起做出客戶需要的產品？
接著，盡量做到以可視化的方式溝通，例如提供相關範例，確保是不是客戶要的，或是畫出使用流程、大致的介面與行為，讓客戶更清楚做出來是什麼樣子。不然很容易變成「客戶心中的 xxx」、「PM 心中的 xxx」和「RD 心中的 xxx」完全不一樣的結果（不過誤解還是不可避免，這只是盡量減少「人禍」的可能性）。
當然， PM 也要想辦法讓客戶「畫押」 ，並讓對方知道修改可能需要負擔額外成本，或是增加工時，讓對方理解他們的修改，也是要付出對應的代價的，讓對方的利益和己方一致，往「盡量一開始就釐清需求，不要太多修改」前進。
更厲害的 PM 會「嗅得出來」哪些地方可能有風險，例如聽到客戶需求講得不太清楚，或是數據不太合理、動機不太合理，或者他是也是轉自第三方（or 老闆）的消息或說法，就會有很大的機會，後續有新的資訊跳出來而變動，根據 PM 嗅出來的「異味」，他會在問題還沒發生時就盡量避免 。例如，可以想辦法約到對方老闆，直接溝通需求，不要透過傳聲筒，或者是在討論初期，針對需求提出多種可能實現的 proposal，用結果去逼近對方的真正需求。
抱怨三：PM 都不懂技術
PM 其實會覺得不太公平，技術以及程式怎麼寫，一定是 RD 最會呀！不過我發現即使是懂技術的 PM，還是會被 RD 嘴不懂，所以我最後已經放寬心了，只要不是寫 code 的人，會需要 RD 解釋邏輯的，大概都會被嘴吧！（RD 不要戰我...）
不過我覺得 PM 還是有些基本的觀念與認知需要弄懂，不需要會寫程式，但是重點是關於產品設計的 know-how、哪邊可能有問題、導致問題的原因是什麼、釐清問題的步驟、不同模組之間的合作或介接關係是什麼……等觀念。
這可以協助 PM 和 RD 溝通、釐清問題，也可以讓你初步聽到需求時，能很快知道風險與難度在哪裡，快速與客戶做進一步溝通，因為
面對客戶時，PM 要戴上的就是「開發團隊代表」的帽子了，客戶對於可行性、風險、工期的初步判斷與期待，一般都是先對 PM 溝通，此時 PM 若心中有一個大的藍圖，就能很快釐清需求、建立期待。
拿到實體世界來講，假設你要蓋一間房子，PM 可能不必有土木師傅或是建築工程師的功力，也不用親自設計出建築設計圖或水電配置圖，但他要有個敏銳度，這邊的施工是不是已經偏離設計圖了，是不是少了防火梯（疑？），可能會造成什麼風險？為什麼會這樣？如果硬著頭皮不做會怎麼樣？延宕要花多少錢？要怎麼跟業主溝通？
這樣的 PM 算「懂技術」嗎？其實我覺得比較像是 「專案或產品的 know-how」 。PM 也應該要有認知，對於每一個專案細節，PM 一定無法比實際執行的人懂，但是對「全局」的綜觀與掌握，以及 A 事件若發生，有多大的可能觸發 B，PM 要怎麼執行 C，讓事件的影響變成 D，然後要如何、跟那些人溝通……等處理流程。
PM 的力量
總而言之，我認為 PM 是資訊的匯總角色，很像任意門，每天一睜開眼睛就是要對接老闆、業務、行銷、開發，甚至是客戶、用戶等等角色，心中有個藍圖，頭上戴著不同的帽子，滿足不同的期待，做著所謂「見人說人話，見鬼說鬼話」的人生（要精確判斷對方是人是鬼也是沒這麼簡單！），PM 需要找到自己的定位，發揮自己的價值，做起事來才會事半功倍。
不過說起來容易，做起來卻不簡單，實際上具體上遇到不同的情況要怎麼做呢？許多內容整理在我的新書：《打造360度行銷產品力：產品經理帶你直搗商業競爭核心》。
（本文經 Evonne Tsai 授權轉載自「Medium」）
