產品經理的使用手冊：一個好 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”，所以標題與接下來的內文就先用比較白話的「大改版」來統稱「畫面重新設計+程式碼重構」的大專案。