Managertoday 經理人

「PM 只會出張嘴、改需求...」從 RD 的抱怨,談產品經理該做的事

2019-11-18 22:42:30
Managertoday
https://bnextmedia.s3.hicloud.net.tw/image/album/2019-05/img-1558928861-99258@900.jpg
前陣子批踢踢科技業版上有一篇文章:「PM 到底要做啥」,引起了一些討論(和工程師的酸酸與抱怨),其實內容蠻常看到的,都是工程師(後面簡稱 RD)常常會嘴 PM 的幾個點。以下整理前三名 RD 最喜歡抱怨 PM 的點,想要來釐清一下迷思,還有討論 PM 應該如何思考與自我定位:

前陣子批踢踢科技業版上有一篇文章:「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」完全不一樣的結果(不過誤解還是不可避免,這只是盡量減少「人禍」的可能性)。

「客戶心中的 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」)