上一篇《訂定產品策略的難點，拆解團隊分歧點｜EP2》提到在決定產品方向時，常遇到的內部爭執點，接著我將會以一個產品專員的角色，來記錄收到產品需求時，決定開發與否的思考環節，這篇會包含 (1) 產品需求彙整、(2) 產品願景梳理、(3) 產品開發排序。
誰適合看這篇文章？
✔ 對於產品開發、產品規劃、產品管理、產品策略有興趣的朋友。一、產品需求彙整
接續本系列第一篇《產品管理的首要任務，重視每位利害關係人｜EP1》列舉的產品需求，最主要來自於兩個來源：
- 客戶需求：客戶因為使用過其他平台，因此也希望我們平台有相似功能。
- 內部需求：公司內部成員因為對於平台的期待、願景，因此希望平台領先發展的功能。
這兩種需求大約 80% 是相似的，因為客戶通常會先跟我們公司的專案窗口抱怨功能不齊全，接著公司內部的夥伴就會轉達客戶需求給產品研發部門。
在把這個表面需求吃下來之前，會需要先盤點「真實的應用需求」，到底客戶想要用這個功能解決什麼問題，例如：
- 客戶 A：希望集資頁面，可以增加「直接私訊」的按鈕，讓贊助者遇到問題就可以透過站內私訊，聯繫到原專案團隊，像是蝦皮的聊聊功能。
- 後續拆解：接收到這個需求時，我會先確認
a. 此需求是 must to have 還是 nice to have？
b. 此痛點有沒有現有功能可以暫時代替？是否有相反情境的客戶？
c. 若不開發，影響層面多大？
d. 若開發，是否有助於業務去獲客？ - 思考脈絡：針對上面這五題，我分別在思考的關鍵因素是
a. 到底是單純許願？還是真的需要新功能不可？
b. 會不會有些客戶其實不想要這個功能？變成開發完還需要設定 on/off 機制，讓想要的開啟、不想要的關閉。
c. 若不開發，會讓專案無法執行嗎？會讓客戶對我們失去信心嗎？
d. 若開發，這個功能可以符合多數客戶需求嗎？會不會只是少數客戶需要？ - 優先順序：上面思考完一輪、也跟產品團隊討論完之後，就會決定這個需求我們應該列為 P1 緊急插件、P2 一般排程、P3 次要排程、P4 單純許願、或 P5 直接婉拒。
二、產品願景梳理
接續第一大點需求彙整，接下來就會進到 Roadmap 討論，如果該產品需求要接，那應該要放在 Roadmap 的哪一個時程。
以我參與到的 Scrum 產品開發經驗，在 Roadmap 階段會需要：
- 先抓出大方向 Epic：這一季、或這一個月要開發的最大功能或方向是什麼。
- 再抓出中目標 Feature：根據 epic 大方向底下，要完成的目標功能各是什麼。
- 最後拆解成小功能 issue：每一個 Feature，要先完成哪幾項 issue 才會開發完成。
Roadmap 每季都會梳理一次，時時確認產品團隊的方向是否有依照 Roadmap 規劃，同時也才能向業務單位回報我們現在開發到哪、下一階段要開發什麼。
上述排好一輪之後，先決定舊的 Roadmap 是否要更動，再把新需求列入評估，看這個新功能是否可以包進哪個 Feature 一起做掉，或是它是一個全新的功能，要直接當成 epic 來看待。
三、產品開發排序
接續 Roadmap 願景梳理，那過程中到底如何拍板決定誰先誰後呢？
最常使用的依舊是「重要 vs 不重要／緊急 vs 不緊急」這個四象限，通常被排在 P1 插件的，一定是「重要且緊急」，接下來 P2 是「重要但不緊急」。
這裡重要的定義我會判定「對於大客戶很重要」，若功能沒有做完，可能會影響到大客戶的專案。
而「不重要但緊急」會被我排在 P3 的原因是，他通常是來自小客戶的需求，雖然也很緊急沒錯、也會影響到他的專案，但盤點了現有資源以及功能開發完的狀態，判定先做這個功能並沒有辦法有效的增進多數專案的成績。
四、總結
很幸運的是現在工作有 1/4 的時間在接觸產品管理，與產品團隊一起規劃產品方向、討論產品需求，現階段我還在一步步了解 Scrum Team 的運作，也還在摸索產品經理的角色，因此產品管理這系列的文章會寫的偏初階一些。
另外，因為公司內滿多功能都在開發階段，公開文章不太能直接打出具體是什麼功能，因此文章主要都是紀錄心路歷程以及思考脈絡，也期望越寫越順手！
如對這系列有興趣，也可以觀看：
