產品經理的日常－需求判斷與執行

2025/07/06 更新2025/07/06 發佈閱讀 5 分鐘

十分火急的需求判斷

在放長假時，Slack 與 Asana 跳出各種通知與任務指派。

我心想，應該又是各種「需求」需要 PM 確認吧？

「需求」是指用戶或利害關係人，希望產品具備的功能或想解決的問題，比如：
業務需要新的模組功能。
行銷想優化活動流程。
客服希望解決用戶反饋的某些問題。
老闆天馬行空的產品點子。

PM 理應處理需求，但不應全盤接收，為什麼？

資源是有限的

小公司的人力資源往往是不夠充沛的，工程師數量是固定的，且一天工作只有 8 小時。

想做的事往往很多，但能開發的資源與時間，卻也只有這麼多。

若 PM 是名 Yes Man，將每個需求都接下來。

那原本排定的項目，就會受到延期或排擠。

需求是需要被討論與選擇的。

在討論需求的過程中，PM 理應扮演引導者和決策者的角色。

情境 1：
業務 A：KJ，用戶反應希望在 XX 功能上增加 XX 功能，否則操作上很不方便。
我：有幾位用戶也有反應希望增加這個功能？能的話，我也想知道他們的反饋。

情境 2：
客服 B：KJ，我希望後台 XX 功能的用戶身份篩選能為多選，否則計算上很不方便。
我：那目前不是多選，你們是如何計算解析？

接收到需求的當下，要先問「為什麼」，才能知道：

有了這些資訊，才能判斷該需求的優先級，以及需不需投資源執行。

我常用該框架，幫助我做需求執行的第一道判斷，該矩陣維度分別是：

第一象限－重要 + 緊急
要立刻處理，感到壓力最大的任務，比如：
- 系統 Crash，導致用戶完全無法使用。
- 用戶無法執行產品重要流程（如：訂閱付款、提領、製圖等等）。
第二象限－重要 + 不緊急
不用馬上處理，但需有時間排程的長期目標任務，比如：
- 某功能流程優化（目前流程沒 Bug，且用戶依舊能操作，只是阻力較大）。
- 某個想做的新功能，但不急著馬上要做。
第三象限－不重要 + 緊急
對長期目標沒價值，但現在有人希望你立刻協助，比如：
- 老闆：我希望能有這項功能（所謂的隕石）。
- 業務 A：該按鈕要改文案與樣式，才會較吸引用戶點擊。
- 業務 A：Demo 時畫面卡住，請 PM 幫忙（但不是系統 Bug）。
- 其它瑣碎的臨時協助請求（有些能用 No-Code 方式處理）。
第四象限－不重要 + 不緊急
沒明顯的用戶價值與商業價值，不做也沒差的任務，比如：
- 需求偏客製化（少數用戶提出），無法吸引更多用戶使用，能造成的影響力不大。
- 業務 A：希望能替某「特定客戶」更改標題
- 優化一個核心用戶使用率超低的頁面 UI 細節與功能。

「緊急性」與「重要性」是主觀判斷，有時還是演變成「重不重要誰說了算」的情況。
比如：
PM 認為某事「不重要 + 不緊急」，但老闆一聲令下後，事情就變成「重要 + 緊急」。
該框架只能作為需求執行的第一道判斷，因為沒考量資源成本。
若需求處於第一象限或第三象限，基本上就是要插單做。
若這件事開發要投入的資源與成本很高，就會造成其他開發功能的時程遞延。
「第一象限－重要 + 緊急」的任務若太多，是個警訊需好好檢討。
需思考與討論，是當初測試沒測完全，還是測試案例寫的不完整，又或是其他原因導致。
「第二象限－重要 + 不緊急」通常會累積許多待開發項目。
這些項目會根據公司設立的目標，或使用其他框架去重新排序優先級。