Takumi她骷咪進化日記

作者 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 feedback 1


• 分析器 user feedback 2


• 分析器 user feedback 3

產品是有機的生命體

所謂產品，就是一個隨時都有真實 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