MH - 作者系列文章
MH
MH

做過公關、數位行銷,2020 年轉職成為產品經理,2021 年跑到新加坡繼續當 PM。歡迎來信交流:travelmisky@gmail.com 

產品經理的使用手冊:一個好 PM 要做些什麼?會為團隊帶來哪些價值?

自從轉職當產品經理後,陸續聽到不少周圍的朋友抱怨他們公司的 PM 有多雷、多廢、多會扯後腿:設計師朋友覺得 PM 只會丟需求,連個 user story 和商業目標都講不清楚;工程師朋友抱怨 PM 不懂技術,每次客戶有問題,都還是得由工程人員出面解釋。就連自己先前待過的幾家公司換了新 PM,至今仍能透過各種管道耳聞新 PM 多不會寫 PRD、不懂得判斷優先序,只會透過頭銜壓時程。到底是雷 PM 太多,還是上述這些純屬特例,又或者是好 PM 真的太難當?

想在新加坡網路業當產品經理,英文要多好才夠用?

正文開始前,先說明一下我的工作性質與情境:- 在新加坡網路產業工作近 2 年的 PM (Product Manager) - 最密切共事的同事主要來自東南亞和中國,而公司的「官方」工作語言是英文,但如果同個專案裡都是會講中文的同事(如台灣、中國、新加坡、馬來西亞等),那就會是中文。會用到英文的場合:- 聽 / 說:大型會議,比如公司全員會議、部門月會、專案的 weekly stand-up。另外身為 PM 還會參與各種專案的 Kick-off、retro、UI & UX review 等。我所處的部門還有讀書會和分享會,主講人也需要以英文報告。

如何舉辦一場產品回顧 / 檢討會 (retrospective)?

如果是有在跑 scrum 的團隊,應該對於 retro 這個詞並不陌生。在 scrum 這套方法中,每一個 sprint 結束後,團隊都會開一個回顧會議(也就是 retro,全名是 retrospective),讓大家一起討論有哪些做得好或不好的地方。此外,網路上也已經有很多 retro 相關資訊,甚至包含 retro 需要用的的模版都有了,可參考下面 2 篇文章:

為什麼要做這個產品功能?使用者想要的到底是什麼?論 User story 的重要性

在介紹 user story 之前,先簡單聊一下產品開發 / 迭代的過程。先前寫過一系列的〈如何改善產品?功能優化怎麼做?〉,其中的 step 1 & 2 分別是「收集意見」和「定義問題與目標」,但收集意見後,這些「意見」應該要長什麼樣子呢?定義問題與目標後,這些「問題」與「目標」又應該要怎麼展示呢?

成為內部產品 PM 的兩週年工作心得

陰錯陽差加入現職公司、成為內部產品的 PM 已滿兩年,但在網路上似乎看不到太多關於 internal product manager 的分享,所以這篇想聊聊 2C vs. 2B vs. internal PM 的差別。另外,之前已有寫過一篇文章介紹內部產品 PM 在幹嘛,現在回過頭看,覺得依然頗符合現狀,有興趣的人可以先看這篇〈負責內部產品(Internal Product)的 PM 都在幹嘛?跟 to B/C 端產品有什麼不同?〉,對「內部產品」會更有概念。

被死線追到快瘋掉?專案規模太大?切階段的幾種方法

這篇文章在草稿躺了好久,好幾個月前想到這個主題,是因為自己手上剛好有幾個正準備大改版的產品,由於資源和時間有限,當初規劃時就有和主管討論到,是否可以不要一次到位,而是改用分批交付的方式實現這些需求。如今過了一段時間,手上的產品陸續完成改版,總算有些實例和過程中學到的眉眉角角可以寫出來分享。不過,以下經驗僅限於網路產業(如網站、app 等形式的產品),硬體產品或其他產業就不一定那麼適用了。

產品大改版血淚史:為什麼要大改版&相關準備

我在每間公司聽到大家對於「產品大改版」的稱呼都不一樣,雖然 chatgpt 說可以用 “revamp”(或者 ”rebuild”)、雖然現職公司的大家都是用 “revamp” 稱呼大改版,但在網路上沒有查到很多文章會用 “revamp”,所以標題與接下來的內文就先用比較白話的「大改版」來統稱「畫面重新設計+程式碼重構」的大專案。