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

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

【菜鳥主管成長日記】我的下屬比我還強勢？性子軟的主管怎麼推動不配合的同事？

許多年前，在我剛被提拔成主管時，我發現原本自己做的游刃有餘的工作，在有了一群「小幫手」後，我反而不知道該怎麼做了？我不希望用主管的身分去指揮他們，可是有時候該嚴肅的時候，反而覺得彆扭，太嚴肅的糾正他們鬆散的行為，還反被擺臉色。相信許多性格比較溫和，做事認真負責的主管，在管理團隊上，若遇到比較強勢的員工，心中多少也會和我有一樣矛盾的感覺。那麼，這個分寸要怎麼拿捏才不會變成進退兩難呢？既能融入團隊，又不至於管不動他們？

導入敏捷方法，就可以不用寫文件！？

「老師，我們的供應商說，他們已經改用敏捷方法來開發我們的產品了，而且現在是在做 Prototype，所以不需要、也沒有文件可以給我們了，跟他們說這些文件是最後結案一定要的，他們還是不交，這樣對嗎？我該怎麼辦？」這是一位學員在我敏捷課程結束後的提問，這個問題其實可以分為兩個層面，一個是供應商的這種說法到底正不正確？另外一個則是更為深層的問題，為何這家供應商膽敢用這樣的態度來頂撞客戶？我們就先來談談「文件」這檔事好了。

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

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

「一個要領」調整表達結構，讓人願意聽、專案順利推進

當你開始具備多項的職場技能，越來越能夠掌握市場的狀態，以及團隊方向與規劃時，會發現需要講話的時間，變得更多了，變得更需要去做水平溝通或承上啟下的工作。尤其體制越來越需要你的觀點與專業時，提案的能力與表達闡述的方式，就會成為專案推展順利的關鍵，尤其職位越高，越需要將專業的內容，轉化為大家都聽得懂的方式。