PM 有兩種,「專案經理」跟「產品經理」到底有什麼不同?

作者 Benson,大學畢業後因緣際會下,第一份工作是與朋友和開的公司。熱血地為了理想做過產品、也辛勤地為了現實接過案子。四年後在公司最賺錢的當下,選擇離開舒適圈、加入了 MY83 保險網,希望透過網路資訊的力量,解決消費者與保險業者之間長期以來的資訊不對稱。本文原載於此

說到 PM 有兩種,我想大部份很多人直覺會說:有腦和沒腦的,後者佔 90%。恩… 或許在某些工程師眼中,或許是如此吧。

但今天我們要討論的是另外真正的兩種 PM:Project Manager 和 Product Manager。因為我剛好本身都有經歷、又剛好都在是新創公司裡,或許可以和大家分享一下這兩種 PM的差異。

畢業後,因為莽撞不懂事,自己和朋友開了公司,後來因為沒錢了,大約三年的時間,花了不少時間在幫客戶架網站 (對,就是接案子啦)。很幸運的,在我這三年的 Project Manager 過程中 ,我們未曾因為我們的關係而讓專案 delay (就是排除類似客戶素材不給我們,時程當然 delay 的情況);很感恩的,我們每筆款項都有收齊 (當然催款也是要有技巧的啦)。因此我想我還算是個合格的 Project Manager 吧。

爾後,因為我突然驚覺工作真的不能只有這樣賺錢自己過爽爽而已,似乎還應該追尋一些更高層次的價值與使命,因緣際會下,我就這樣加入了我心目中很厲害的 startup、負責 MY83 保險網,開始了我 Product Manager 的旅程。

來到 MY83 才真正的體會到:哇靠,平平是 PM,Project Manager / Product Manager,我的媽呀!這兩種也差太多!

這邊和大家簡單分享一下,平平是 PM 到底哪裡不一樣?

Project Manager(專案經理)

以 Project Manager 而言,若撇開開發客戶、維護客戶關係的層次不說,大多情況,身為一個 Project Manager 最大的任務就是將 Project 如期、如規格「正確」的執行,而這過程中,我想分為兩種層面的技能:技術與溝通。

技術層面上,Project Manager 就是把上司 / 業主 / 老闆心中想要的功能「翻譯」成工程師可以開發的 SPEC、確認功能可行性、與上司 / 業主 / 老闆確認 SPEC 細節、估時、排時程、確認優先順序、掌握開發進度、測試、驗收。

另外溝通層面上,一個有經驗的 Project Manager 都知道 Project 過程中一定會遇到很多狀況:

  • 可能原先說好的 SPEC 大改,但資源與時程不變…崩潰(最常見的 QQ)
  • 可能因此工程師不爽而罷工
  • 可能工程師開發上踩到沒有預期的地雷
  • 可能設計師素材 delay
  • 可能原先確認的資源沒有到位
  • 可能這個…
  • 可能那個…

這時,Project Manager 所需要的就不再單單只有技術層面的技能了,而為了 Project 一樣可以順利完成,這時 Project Manager 還需要另外必備技能 – 「溝通」,如何在問題發生時,精準地搶時間、有效搶資源、適時地妥協時間、適當地妥協資源,這絕對是 Project Manager 經常需要面對也學習的。

當然每個 Project 的資源、時間、Scale 都不同,Project Manager 所需有的技能等級也不會完全一樣。但整題而言,在 Project Manager 的角色中,你必須是個「負責任、懂技術、有溝通能力」的角色,我認為這些是足以身任一個的 Project Manager 基本條件。

不過我自己觀察 Project Manager 通常比較容易感覺到「專案的成敗」,而較難去感受到「產品的成敗」與「真實使用者的回饋」。

Product Manager(產品經理)

User First, Always!

說到 Product Manager 我想到的第一句話是:「好的 Product Manager 就是一個產品的 CEO」這句話,重點不是 Title,而是好的 Product Manager 需要的是全面性的思維。

而這時,你可能會聽過很多很像很潮的名字:大數據分析、Growth Hack、A/B Testing、SEO、使用者訪談、Monetization(如何賺錢)、Content Marketing、Funnel Analysis、跨領域合作、AARRR 等等等等。

但我認為,身為一個 Product Manager 這些思考或方法的原點都是以「使用者」出發、產品是否解決使用者的痛點、是否真正滿足使用者需求。你要討好的對象不是老闆、不是團隊成員、不是投資者、不是合作廠商、而是「使用者」。

舉些實際的例子好了,MY83 宗旨是希望透過網路資訊的力量,解決保險的資訊不對稱,幫助消費者保險買對不買貴!

因此,前些時間,我們推出了「MY83 實支實付推薦分析器」,在製作這產品時,我們唯一思考的問題、就是如何解決普遍大眾 (我們的使用者) 都會遇到的問題:「保險合約書每個國字我都看得懂,但是整份合約我就是看不懂;我想買保險,我又不想被當冤大頭,我要怎麼辦」

因此從產品 idea 的發想、討論、規劃、製作、到 go to market 的整個過程中,我們當然也運用了上面那些很潮名詞的方法和概念。但我們心中也始終把使用者放在第一順位,在新創公司時間與資源有限的情況下,雖然不敢說是個完美的產品,但最後似乎有了不算太差的成果。

產品是有機的生命體

所謂產品,就是一個隨時都有真實 user 在使用的東西。

所以做一個 Product Manager、或者待在一個做產品的團隊都可以深刻的感覺到,壞的情況是,當產品出問題或斷線,客服電話馬上進來、客服信箱馬上開始被罵;好的情況是,你也會收到使用者溫馨的回饋與感謝。

對我而言,產品就像個有機的生命體,他會哭、會鬧、也會讓你崩潰;但同時,只要發展的順利,它也會有讓你感到使命感與驕傲。

不過只要方向對了,產品真實的有解決了使用者的問題,我想成就感大多是大於挫折的。甚至有時你會幸福地感覺到這世界似乎因你的努力,而有了一點點的不一樣 (當然,這也可能是自己腦補的啦…)

產品策略 / 方向 / Growth Hack

在新創公司裡,Product Manager 通常會兼著 Project Manager 地在做,而在每天十萬火急、槍林彈雨的戰場上,勤奮的你,有時一不小心會失了準心,會讓自己變成一個天天解票、卻沒有解決問題的 Project Manager。

之前聽過一個令我敬佩的大大說過「premature optimization is the root of all evil」,在產品的開發過程中,這句話有時也是相當有道理的,在你的產品尚未有太好的 traction 之前,而卻這時期就開始了大量的 A/B Testing 調教一堆的功能。那何不如多約訪幾位你的使用者、聽聽他們怎麼說,不要害怕失敗地、大膽嘗試產品方向上大幅度的修正,努力找到適合自己產品的成長模式。而不是將資源放在一些小打小鬧的微調與無關緊要的細節上。

身為一個 Product Manager,沒有把寶貴的資源放在最需要的地方,這件事影響層面可大可小,失了準心可能讓團隊成員沒有成就感而提早離開、也可能一擲千金不小心把資源與時間提早燒完而提早退場。

因此身為 Product Manager 也記得不忘提醒自己抽離每日戰戰兢兢的工作,讓頭腦放空一下,多聽聽 user 怎麼說、看看別人怎麼做,千萬別忘了思考產品大方向與策略,身為一個 Product Manager 這真的非常非常重要。

第三方套件或工具使用的不同

身為一個新創團隊的 Project Manager 腦袋裡裝的常是,這樣的 Project 以哪種工具,會是有比較好的產出。通常以下這些會是 Project Manager 出現的工具:

AWS / Linode / React.js / Angular.js / Twitter Bootstrap / Sendgrid / New Relic / Asana / Redmine / Trello

而身為一個 Product Manager,最在乎的就是如何理解 user 的行為,而當你使用者不再是小貓兩三隻的時候,或許以下工具,會是你有用的助手

Google Analytics / Mailchimp / Uservoice / Google Web Master / Amplitude or Mixpanel / Custom.io / segment.io / facebook karma / Optimizely

與工程師、設計師溝通

如上所說,在新創公司裡,Product Manager 通常會兼著 Project Manager 做,所以 Product Manager 常常也需要制定產品 SPEC

當你描述完一個超屌的功能後,工程師會冷冷地問你一句:「怎麼寫」、「你知道這要花多少時間嗎」,第一次,你可能會被問倒;但第二、第三次之後,你最好可以馬上說出解法(ex: 你可以在 DB 開個欄位當作 flag、再以 cronjob 定期去檢查… blah blah blah,這時間上應該還好吧!?)

這目的不只是讓工程師知道你也懂技術,也是為了讓工程師知道這功能你有為他們思考過,更為了避免… 你變成工程師口中的「無腦 PM」、讓你們的關係惡化

當然你也會需要與設計師合作,而你也一定要知道設計師的地雷為何、並且尊重他們的專業,讓他們的天賦自由地發揮。

最酷最潮、真的對產品是最好的嗎?

但與工程師與設計師合作時,Product Manager 也一定要注意:

有些工程師志在使用最酷最潮的技術,但你需要思考的是,最酷最潮的技術與投入的時間成本、真的可以對產品與使用者是好的嗎?ex: 假如工程師希望網站後端的 php 改用 RoR 寫,但 RoR vs php 使用者真的看得出來、真的有需要整個打掉重來嗎?

設計師也一樣,有些設計師也會志在做出最屌的設計,但你需要思考的是,最屌的設計真的可以對產品與使用者是好的嗎?ex: 設計師希望網站整個採用了 Material Design 的方式設計,但對使用者來說有沒有 Material Design 真的有差這麼多嗎?

當然,這種情況有時也會出現在你自己身上,你會想用最酷最屌最潮的東西方式,但你需要思考的是,這些最酷最潮的東西,真的可以對產品與使用者是好的嗎?

工具、技術、設計,都是為了解決使用者問題、滿足使用者需求。別忘了,User First, Always !

PM 一定要資工背景嗎?

我本身是清大資工系畢業的,但是說真的,現在工作上所用,除了對於程式基本運作原理的了解外,自己是認為與我學校所學沒有絕對大的關聯,但這也可能是我們系雖然是偏硬體的資工系吧。不過在畢業後,我倒是有全心全意認真的寫過 web 一年,那年對我目前的工作、工程師的溝通以及思考產品時,所運用的產品思維上,自認為是有不小幫助的。

據 ex-googler Alice 說法 google/facebook 的 PM(Product Manager) 與 APM(Associate Product Manager) CS或是相關的技術背景是必備的 (似乎因為 google 工程師都是萬中之選,PM 不是 CS 背景可能太容易被電爆 XD );但是 Airbnb 的 founder Brian Chesky 也是設計師出身。

而在這什麼都可以在網路上學到的時代,我個人是認為身為一個 Product Manager 只要在討論產品時,可以與工程師與設計師溝通、可以一起討論貢獻出有效的解法,再加上面對問題時具有一定的軟體思維,我倒認為 CS 是個 nice-to-have 而非絕對的 must-have

如何培養自己成為一個好的 Product Manager 呢?

說了這麼多,或許你會想知道,怎樣才可以成為一個好的 Product Manager。其實我也還在學,但走過了一些路之後,或許可以和你稍稍分享一些方式(有些也是我們面試時,常常問面試者的題目):

多聽多看多用:

多追這領域相關的新創部落格與時事、多追美國與中國的強大新創公司,他們背後做事的邏輯與方式。

你平常看 Facebook 時,除了朋友動態,你都在注意或學習哪些資訊呢?那些你平常最喜歡的產品中,你從這些產品內你觀察或學到些什麼?

Think as a CEO :

如剛剛所說,「好的 Product Manager 就是一個產品的 CEO」,如果你愛 Facebook 但覺得 Facebook 哪邊不好用,如果你是 Facebook 的 Mark Zuckerberg 你會可以怎樣把它改得更好;如果你愛 Airbnb 但覺得 Airbnb 哪邊不好用,如果你是 Airbnb CEO 你會怎樣把它改得更好。

如果你是一個你是 facebook / Airbnb 的 CEO 你希望你的產品解決什麼樣的問題、為用戶帶來怎樣價值、進而應該去改善或開發哪些功能、這些功能的 UI / UX 會長怎樣、背後的可能演算法以及 DB schema 又大概會長什麼樣子、技術可行性與開發時程大約是如何?

找一間優質的新創公司,勇敢的把履歷投過去吧:

是的,或許你會覺得我有點屁,畢竟你還不是 Mark Zuckerberg 或 Brian Chesky,就算你身懷絕技,也不一定有實戰的場所。

而 Learning by doing 一直是我認為最棒的方式!找一家優質的公司,你也認同、感興趣的產品,勇敢地讓他們看見你的熱情與淺力、爭取加入他們!我想會是讓你成長最快的方式。

如果剛好你想做好產品、想要給使用者好的服務與價值,

 

http://www.inside.com.tw/2015/09/30/what-are-the-differencies-between-project-manager-and-product-manager

 

 

arrow
arrow
    全站熱搜
    創作者介紹
    創作者 她骷咪 的頭像
    她骷咪

    Takumi她骷咪進化日記

    她骷咪 發表在 痞客邦 留言(0) 人氣()


    留言列表 留言列表

    發表留言