上一篇《
訂定產品策略的難點,拆解團隊分歧點|EP2》提到在決定產品方向時,常遇到的內部爭執點,接著我將會以一個產品專員的角色,來記錄收到產品需求時,決定開發與否的思考環節,這篇會包含 (1) 產品需求彙整、(2) 產品願景梳理、(3) 產品開發排序。
以下產品需求的舉例,會使用我服務的群眾集資平台為例。
誰適合看這篇文章?
✔ 對於產品開發、產品規劃、產品管理、產品策略有興趣的朋友。
一、產品需求彙整
- 客戶需求:客戶因為使用過其他平台,因此也希望我們平台有相似功能。
- 內部需求:公司內部成員因為對於平台的期待、願景,因此希望平台領先發展的功能。
這兩種需求大約 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 的運作,也還在摸索產品經理的角色,因此產品管理這系列的文章會寫的偏初階一些。
另外,因為公司內滿多功能都在開發階段,公開文章不太能直接打出具體是什麼功能,因此文章主要都是紀錄心路歷程以及思考脈絡,也期望越寫越順手!
如對這系列有興趣,也可以觀看: