產品經理該怎麼處理灰色地帶、模糊不清或未定義的問題？

想寫這篇文章，是因為這幾年工作下來，被不少人問過各種產品問題 ： 怎麼寫 PRD、怎麼開始重新設計一個產品、怎麼跟需求端打交道，仔細回想後，發現這些問題看似難以歸類，但說到底，或許都是因為原本沒有一套規則或模板可以參考，當事人必須自己重新打造，所以才會有種無頭蒼蠅的無助感。

產品經理應該要怎麼點技能樹？

應該有許多上班族在某個職能上投入一段時間後，總會想著：「下一步還能幹嘛？」以我自己為例，做了一年多的公關後，終於被一些記者記得、寫的公關稿很少被客戶退了、辦記者會越來越上手，接著就會想說：「那之後還要做什麼呢？」又或者做了快三年的行銷後，每天淹沒在各種異業合作的提案書、填不完的數據追蹤表格、一檔接一檔的策展活動、無盡的臉書廣告貼文，當時也常想：「我還能做什麼呢？」

產品經理的使用手冊：一個好 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 端產品有什麼不同？〉，對「內部產品」會更有概念。