產品管理vs 專案管理 Product Management vs Project Management 有何不同?

從矇矇懂懂以Product Manager 的角色,進入第一間在台灣的七十人網通公司到四年後後飛往位於台灣東北方的東京擔任R社的產品經理 (日本當地EC)、再轉職到有熊有兔子的L總部做內部開發流程改善顧問,在韓國,泰國,台灣舉辦開發流程研討會,負責Product management 範圍的「宣導」(請大家用一個高視角來規劃產品)、最後又回到Rakuten 相關企業(他們投資的科技公司)當PM。
這九年,太多的同事跟朋友問我:「產品管理是什麼?」「Project Management, Product Management到底有什麼不同?」

剛開始我也不知道Project 和Product,究竟有何不同。而台灣公司的PM通常包含Product & Project兩種角色(但部分責任被管理層掌握)。所謂「出色」PM,大部分是技術背景很好,可以精確回答業務端一個需求難在哪裡及需要多少時間。不過(請不要被我以下的言論嚇到):

我沒有遇過太多優秀Product PM,不是太會說不會做,就是其實他們是管專案的。
是的,管理一個專案的開始與結束十分重要;理解技術限制、磨練自己的跨團隊協調能力也是優秀PM不可或缺的技能。

但請容我提議,PM分兩種,product (PDM) or project management (PJM)。而若是你被稱為是 ‘product manager’,請你思考一下你是否真的在做「產品管理」,還是你大多是接到上頭來的需求後,就開始規劃時程,執行需求?

Project Management? Product Management?

一言以蔽之,專案管理(project management)就是管理一個有始有終的案子的COST, TIME(schedule), SCOPE。
舉一個簡單的例子,一個「案子」可以是「今年年初將某產品量產」。案子就像是「任務」,是有明確的目標,資源,與預計完成時間。

而管理「產品」(product management) ,則是管理產品的樣貌、策略、走向、功能、甚至行銷語言。

專案管理的技巧跟方法論,因廣為產品經理所用,所以大家又更混亂了。
例如project management 課程裡常常提及的利害關係人管理,product 人也需要有一套方法管理與說服上層與團隊該如何投資產品開發,只是需要說服的內容不同。專案人管理大家對專案的期待,產品人管理大家對產品未來的想像。

產品管理的人注重在 why (為什麼要做這件事?)
而專案管理的人專注在how(怎麼要最有效率的執行出計劃來?)
至於What,product manager 專注在產品的走向與功能,
而project manager 則是在乎啟動一個案子所需要的各種細節:人、風險、功能細節。
當然,兩種PM都需要知道為何要做,要做什麼。但是前者PM的責任是產品本身,後者PM的責任則為執行的成敗。通常product manager 與各式有主導權的哥哥姊姊叔叔阿姨們大致決定的產品開發範疇後,
project manager 於是加入,將所有的規格,資源,人力,時間,全部仔細的梳理一遍,隨之開始產品開發。
兩種職位可以由同一人擔當,但時間有限,兩個都做的PM,很有可能兩個都只做到OK的狀態。

PDM 存在的意義

對我來說PDM的存在只有一個目的,就是做出對用戶有無可取代(好吧!也可以妥協成「對客戶有用」)的產品,又可以「順道」幫公司賺錢。

所以Product Manager 所最需要專注的地方,尋找用戶最頭痛的地方,又是你的公司可以幫忙解決的,就在那接點服務他們。

舉一個非常簡單好懂的例子:信用卡公司往往想的是要怎麼讓客戶分期付款或是累積更多卡費。不過聽說某間金融科技公司他們為了解決他們的用戶因為刷卡方便而伴隨而來的,無法掌控個人金流的無力感,做了一個設定預算的功能,讓用戶每個月都可以決定自己最多可消費的額度。
表面上看起來,該公司似乎限縮了自己的營業額,但是換來的是客戶對於該公司的良好印象。

那要怎麼找痛點?
其實真的沒有想像中難:請先開始跟團隊或同事閒聊你的產品🗣,然後刻意卻又看似悠哉的問他們產品相關問題🗣,聆聽他們說的👂。

更完整一點,請去找幾位用戶(我相信你可以找到的!),事先想好你想問的問題(至於要怎麼問,我改天再提提我的想法。),繼續找他們閒聊🗣你的產品:你都什麼時候用?為什麼會用我們的服務?可以用給我看看嗎?PDM 需要有一個讓人放鬆的氛圍,當氣氛越輕鬆的時,受訪者會越來月沒有禮貌地貴司很無趣的甚至很差的功能跟流程。那就是PDM需要尋找的真誠的建議。
請不要受傷,請不要辯解,而是詢問,並且理解。

找到用戶很想改善的事情,然後呢?

還有很多可以談的,但這裡我先從結論說起:做實驗。
請自己把想法畫起來,找開發跟設計討論,產生更多想法。再來,花最短的時間把你們(不是只有你的意見)覺得最不錯的幾個想法,反映在最簡單的模型Prototype裡(一張圖也是可以),再去找客戶閒聊

以上聽起來容易,只要當過PM的人都知道,那是有多難。不過,PM就是被請來幫公司創造有價值的產品的,即便上述的流程完全沒有發生在你的公司裡,你還是可以東看看,西敲敲,想辦法挖出一點客戶給過的寶貴建議。

那喬伊斯你自己做過了什麼?

我說一個我初來乍到R公司時所做的一個非常非常小,身為讀者的你也一定做得到的改變。
我負責的產品是一個電子點數卡app,上面有一個很簡單的Barcode,供店員掃描,幫用戶累積點數用。
那時我不會說日文,也不知道去找誰,請他幫我們做用戶訪談。
但感謝app store和日本人習慣長篇大道的分享自己使用心得的文化,我得以在每次發行新版本時,到app 後台看看他們的使用心得。

建議中的其中一個反覆出現的關鍵字是:「我頭暈」。
這句話出現的頻率之高,以及這些用戶如何各式描述barcode讓他們有多暈, 都是非常不可思議的。
原來,我們的公司為了要增加Barcode的掃描成功率,在用戶打開app時,會自動將用戶的螢幕亮度調成100%。更不巧的是,Barcode 的畫面又是我們主畫面。
所以用戶每開必眩,即便他們只是單純想要看一下自己得到的點數,還是都得先被一道超強藍光擊中雙眼。

於是我找了團隊中的工程師,行銷,與設計同事,一起想了非常多解決方案
1. 我們要不要解決他?
→ 要,因為這個困擾出現在評論許多次,用戶也一直給我們負評。
2. 我們要怎麼調整這個亮度?

方案❶ 用戶將手機做往他的反方向「平行移動」的時候,我們假設他們就是要使用Barcode。當Andriod偵測到 這件事,我們就調整亮度到最大?
→ iOS 工程師皺眉說到「這啥?iOS是要怎麼做」;另外,我們無法保證每台手機都會成功,還有我們假設過度自動是嚇人的(這產品壞了嗎?)

 方案❷不要管亮度。我們要不要把barcode 頁面從主頁換掉? 
→ 不好。因為數據發現,八成的用戶打開我們的app ,只停留在Barcode 頁面。我們假設他們大部分是打開app來獲得點數,所以不想增加他們出示Barcode所需的準備時間。再者,Barcode掃描率是我們的獲利來源,我們不想增加大家掃描的難度。

 方案❸OOXX? @#$%?

最後我們決定採用方案N:

每次用戶打開Barcode頁面時,我們讓app 保持原本手機的亮度。當使用者用手指點擊Barcode的部分的時候(手機用戶總是喜歡點東點西),我們將整個頁面調成全亮。當他們再次輕觸Barcode時,app則會將頁面亮度調回整成原本亮度。

這個半手動的小小功能,讓我們的app 漸漸地回到App Store 4.0以上評等,且再也沒有用戶說:「我暈」,我們也沒有收到用戶抱怨Barcode掃碼不過的事情。

產品管理者的下一步

選對痛點進行改善是產品成功的第一步。但,你若在科技公司待過幾年,最常聽見團隊中別人(絕對不是你自己)的抱怨之一,就是「我們的產品目標是什麼?」。相信我,他們絕對不是想要聽到「賺三百萬」或是「成為亞洲最大的OOXX平台」。

大家想知道的是未來的產品走向。這就是產品管理者的下一步。

優秀的PDM有一套自己蒐集產品回饋的方式,廣納建言。
她能清楚規劃並表達達成目標所需的產品策略,
並且謙卑地認知到,她所計畫的未來是建立在各式各樣的假設上,
因為沒有人知道未來。

在此,容我先賣個關子。
寫太久文章,也是會累的。

發表迴響

在下方填入你的資料或按右方圖示以社群網站登入:

WordPress.com 標誌

您的留言將使用 WordPress.com 帳號。 登出 /  變更 )

Twitter picture

您的留言將使用 Twitter 帳號。 登出 /  變更 )

Facebook照片

您的留言將使用 Facebook 帳號。 登出 /  變更 )

連結到 %s