產品經理每天都在立場的抉擇，像是哪個功能先做？哪個畫面比較重要？重要版面要留給誰？從高層主管到行銷業務，從 APP 評論到使用者訪談，收集了產品意見後要怎麼改？這篇想記錄我近期的產品職場日記。
誰適合看這篇文章？
✔ 對產品經理、產品企劃、產品策略、產品規劃、職場日記有興趣的朋友一、面對各方許願的產品立場
近期待過的產品團隊，都會遇到「資源有限、慾望無窮」的情況，像是：
- 行銷部：近期有活動要宣傳，希望首頁除了 A 版位，再加 B 版位。
- 業務部：最近業績掉很多，請設定一個喚回機制。
- 使用者們：編輯履歷欄位很多，能不能減少必填欄位。
而該如何堅定地拿出「產品路線圖 Product Roadmap」，很委婉地告訴對方「這個功能不在近期的排程內，但我們會列入考慮」是我最近的課題。
通常被拒絕後，對方會有幾種反應：
- 「這是 OO 高層指定的功能，你不幫我就是不支持，你自己跟 OO 說」
- 「為什麼 OO 的功能可以做，我的就不行，那個功能明明也沒啥用」
- 「不做可以，請給我一個替代方案」
- 「別的競品都能做，就我們沒有」
- 「改一下而已不會很久吧？就格式調一下有什麼困難？」
▍需求人的立場
需求人往往會帶著情緒來爭執，他們立場我也能理解，因為他們沒辦法向他們的主管交代，必須要爭一口氣、證明有討價還價的過程，避免被主管認為是自己不夠力。
▍產品團隊的立場
這個需求看起來不是調整一下這麼簡單，要改到介面、API 等，而且發生情境似乎是個案的操作習慣，但現階段還有其他重要的功能，若現在讓他破格插隊，就會有其他個案需求湧入。
二、產品團隊的堅持與妥協
每天的工作都是「堅持」和「妥協」在拉扯，也不斷進行多方溝通，當有人提需求時，我目前會：
- 先詢問此需求的來源：高層的隕石需求終究順位會高一些，很常都要優先處理。
- 確認此需求發生的情境：是個案的操作習慣導致的問題？還是機制本身就有錯誤？
- 確認此需求的嚴重程度：確認該問題會影響多大，是 APP 評論都在洗一顆星？還是只是一通客訴電話？
- 確認修改的複雜程度：和工程主管先確認要改動多大，以及大約要多少工作天。
- 確認此需求的期望時程：確認需求人期望的時程，並比對產品路線圖可以安排的時間。
上面這段流程就是不斷「妥協」的過程，例如時程、改動範圍，都是產品經理要跟需求人不斷討價還價的，究竟對方要解決什麼問題、這樣改能不能解決、能不能用改少一點的方式等等，都確認完一輪後，才會決定要不要排入開發。
但進到開發，也會有需要「妥協」的過程，像是：
- 工程師抱怨設計師的圖稿太過複雜，不想在那個流程上花太多 Coding 時間，希望做比較簡易的流程。
- 設計師抱怨工程師能力不夠，明明其他平台都做得到。
我目前的處理方式是：
- 想解決的問題：若因為工程師或設計師的抱怨，而減少流程，能不能達到最初的功能目標？如果可以我就會妥協，並承認最早規劃有可能不夠好。
- 心中堅持的畫面：若是競品做過的畫面經過評估後，就是我們理想中的 MVP 畫面，可以直接拿著競品去爭取我要做到的目標，只要工程師說不行，我就會堅持說對方研究如何做到。
三、產品的學習心得總結
另外這篇剛好先總結我近期的產品心得，期望自己能持續突破：
- 產品思維：核心就是對現實的了解，對產品現實理解的越正確，就越能對所有模型融會貫通，形成自己的原則，下更精準的判斷。
- 產品願景：我們要帶使用者去哪？產品要長成什麼樣子？制定好目標，每天傳遞、推進目標，才能讓產品團隊的大家都有一致的前進方向。
- 產品優勢：更精準的場景創新、更完善的內容體系、更貼心的服務、更完整閉環的解決方案，都是其中一種優勢，小產品堅持精準的有效創新，大產品堅持更完善的內容體系。
- 產品需求：不要一個個小需求分開做，而是一個個大場景一起想，面對一個需求，背後其實是一個使用場景，用戶提的需求只能解決單一問題，試著從產品總目標回推這題要怎麼解。
- 產品管理：當一個推動者、賦能者，不要只寫需求文件，要說到多數人都能接受、認同，並且執行、繳出成果、收集數據，這個功能才算完成。
四、總結
這篇是近期的產品經理學習心得，若對這系列有興趣也可以持續觀看：
