這堂課會學到什麼
還記得 第四堂課 : 產品分析步驟 (下)，帶你掌握兩大實用工具——影響地圖和使用者故事對照，如何使用幫助我們描繪了「誰」需要什麼，以及「為什麼需要」的場景，並將 Epic 拆解成眾多 Ready Stories。
這些 Story 就像是一群參加馬拉松的跑者——每個人都有自己的特點和步伐，但比賽資源有限，賽道也不可能讓所有人同時衝刺，因此我們需要決定：誰先跑？誰在中間？誰暫時留在替補席？
而這，正是今天要聊的重點——如何給這些 Story 排優先順序。
我們將介紹三種方法來幫助你更有系統地評估和進行排序：
- MOSCOW 法：快速分類必須做、應該做、可以做和不做的項目，讓你在資源有限時能清楚取捨。
- Kano 模型：用戶體驗導向的利器，從用戶的角度出發，找出「超出期待的驚喜功能」。
- RICE 模型：數據驅動的量化工具，從觸及（Reach）、影響力（Impact）、信心（Confidence）、工作量（Effort）出發，計算每個任務的優先分數。
接下來，我們就來看看這三種方法的核心邏輯、應用場景，如何幫助 PM 在一片任務清單中理清重點方向，讓產品邁向成功！
排定產品優先順序方法一 : MoSCoW 優先級排序法
MoSCoW 優先級排序法的由來其實有點像取名遊戲。它是由英國專案管理顧問 Dai Clegg 在 1994 年提出的，最早用於動態系統開發法（DSDM）的框架中。這個方法的核心目的是幫助專案團隊在面對有限資源和時間時，快速且清晰地判斷「什麼最重要」。
MoSCoW 是什麼呢 ?
- M 是 Must Have（必須擁有）
這是專案成功的基石，沒有它專案根本無法完成，就像開車卻沒有方向盤一樣荒謬。如果這些需求無法滿足，那專案基本可以直接打包回家了。 舉例：如果你的專案是建一個電商平台，那支付功能就是 Must Have，沒得商量！ - S 是 Should Have（應該擁有）
它們雖然不像 Must Have 那樣致命，但也非常重要，像是最佳搭檔。如果時間和資源允許，這些需求就該優先安排上，否則可以適當調整到下一個階段完成。 舉例：在電商平台中，能夠多語言切換可能是 Should Have，能顯著提升用戶體驗，但不是非有不可。 - C 是 Could Have（可以擁有）
這些是專案的「錦上添花」功能，有了更好，沒有也不至於毀了專案的整體效果。它們常常是額外的附加值，等主要需求完成後再考慮。 舉例：在電商平台裡，有一個 AR 試衣功能，這就屬於 Could Have，用戶會覺得很炫酷，但它並不是成功的必要條件。 - W 是 Won’t Have（不會擁有）
這是專案的「界外球」，也就是明確不在當前範圍內的需求。這些需求可能未來有實現的可能，但現在，它們被分類到「以後再說」的區塊。 舉例：在電商平台中，開放用戶自訂商店頁面設計可能是 Won’t Have，因為這對初期專案沒有太大影響且需要更多資源投入。
為什麼 MoSCoW 好用？
舉個例子來說：
當團隊需要決定下一步工作優先級時，MoSCoW 幫助我們冷靜分析哪些需求一定要先做，哪些可以等一等，哪些甚至可以不做。這樣，大家就不會被無窮無盡的需求搞得分不清輕重緩急，從而有效避免「每個需求都是老大」的窘境。
這個方法特別適合在專案初期或需求分解的時候使用。還記得我們之前提到的 使用者故事對照 User Story Mapping 嗎？將眾多的 User Story 按照「最小可行產品」（MVP）的概念分成三類：Must、Should、Could，這就是 MoSCoW 在實務中的應用！其實就是利用 MosCoW 方法，快速分類出 Must、Should、Could 優先順序 :
若無法清楚看到圖片文字，請點擊下方連結預覽 or 下載查看清晰版本 :
注意要點
MoSCoW 的 Won’t Have 其實並不是真的「完全不要」，而是「當下不做」。這也提醒我們，作為產品經理或專案管理者，重要的不是說「不」，而是要善於說「暫時不」。
所以，無論是規劃產品還是執行專案，記得帶上 MoSCoW 這個優先排序的利器，它會讓你的團隊更聚焦、更高效，也更有條理！
排定產品優先順序方法二 : Kano Model 優先級排序法
Kano 模型，也被稱為「二維品質模型」，是東京工業大學教授 Noriaki Kano 在 1980 年代提出的一套創新的需求分析方法。這個模型的靈感很有趣：用戶在看似冷靜的外表下，可能暗藏一顆對產品「又愛又恨」的心。Kano 認為，用戶需求並非單純的「有功能」或「無功能」，而是有層次可循。
模型的核心是二維品質，也就是從兩個維度看需求：
- 滿意度——來自用戶主觀感受，反映需求被滿足的程度。
- 實現程度——功能提供、產品品質的客觀表現，描述需求是否被具體實現。
這個二維的視角拓展了傳統的一維品質觀念——即「品質越好，滿意度越高」的線性關係。Kano 模型告訴我們：有些功能，即使再怎麼提升，也只是讓用戶覺得「應該如此」；而某些出乎意料的魅力需求設計，卻能讓用戶瞬間心花怒放。
通過這個模型，你能更清晰地識別需求的影響力，從而設計出真正打動人心的產品——不只是滿足用戶，還能驚喜他們！
Kano 模型是什麼？
Kano 將需求分成了五種類型，各自代表著不同的用戶心理和滿意度，下圖水平軸代表功能實現程度，垂直軸則是滿意度：
- M : 基本需求（Must-be Needs）：
這些是產品的基礎功能，用戶不會特別感謝你有它，但沒有它，他們一定會生氣。就像你去餐廳，菜沒有熟，沒得談！ 舉例：手機可以打電話、收發訊息，這是基本需求。沒這功能，用戶直接換牌子。 - O : 期望需求（One-Dimensional / Performance Needs）：
一維品質要素，可以看到圖裡面只有期望需求是直線而非曲線，該屬性與用戶滿意度呈線性關係，越多越好、越快越棒，這些需求是用戶會直接感受到的價值，滿足得越多，越能提升用戶的滿意度。 舉例：手機的續航能力，用戶肯定希望能用得越久越好，這些是直接體現性能的需求。 - A : 魅力需求（Attractive / Delightful Needs）：
這類需求是產品的驚喜功能，當你提供時，會讓用戶眼睛一亮；但即便沒有，它們也不會特別抱怨。這是製造「哇！」效果的秘密武器。 舉例：手機的夜景拍照功能，一拍效果極好就是大片，直接刷爆朋友圈！ - I : 無差異需求（Indifferent Needs）：
中性的需求，有它沒感覺，沒有也沒差。這些需求對用戶來說幾乎毫無影響，但對開發團隊來說，可能是浪費資源的地雷區。 舉例：手機的內建鬧鐘有 20 種聲音選擇，除了少數人會在意，多數用戶根本不在乎。 - R : 反向需求（Reverse Needs）：
這些需求非常主觀，對某些用戶來說是優點，對另一些人卻是負擔。這時候產品就需要靈活應對，甚至提供自訂選項。 舉例：手機上預裝一堆無法刪除的 APP，這可能讓部分用戶覺得方便，但大多數人只想刪到空蕩蕩。 - Q : 疑問需求（Questionable Needs）：
疑問需求的線段沒有出現在圖上，因為這些需求通常出現於問卷設計不合理、受測者無法正確理解問題，或者填寫時出現錯誤，導致回收結果不具參考價值。這類需求的存在提醒產品團隊需檢討問卷的設計，確保問題表述清晰並符合受測者背景。 舉例：問卷中詢問「如果咖啡機有內建洗碗功能，您會喜歡嗎？」有些受測者可能因為誤解，對正反向問題給出矛盾答案，這就屬於疑問需求。
為什麼 MoSCoW 好用？
在需求分析時，Kano 模型提醒我們，並非所有需求都值得花一樣的精力對待。有時候滿足用戶的「基本需求」只能達到及格線，而多一點「魅力需求」，卻能讓你的產品一戰成名。
注意要點
最有趣的是「魅力需求」這一類。它們是用戶未曾期待卻深深喜愛的功能，而這也帶出 Kano 模型的精髓——用戶說想要的，未必是真的想要；用戶沒說的，可能才是打動他們的關鍵。舉個例子：誰能想到早年的智慧型手機，第一次讓人用指紋解鎖時，竟然能讓那麼多人「心動」到直接掏錢？
所以，下一次你在分析需求時，不妨帶著 Kano 模型一起上場，從用戶的情緒出發，打造超乎期待的產品體驗！
Kano 模型怎麼計算？
我們用簡單易懂的方式，一起來看看 Kano 模型怎麼運作吧！
Step 1 : 問卷調查。 這份問卷分為兩個部分，針對某個功能，會問兩個問題：
1. 正向問題：如果這個功能存在，你會有什麼感覺？（選項：很滿意、滿意、沒感覺、不滿意、非常不滿意）
2. 反向問題：如果這個功能不存在，你會有什麼感覺？（選項同上，選項：很滿意、滿意、沒感覺、不滿意、非常不滿意）範例：假設你在開發一款咖啡外送 App，問卷可能會設計下面兩種問題
正向問題：如果你可以自訂咖啡豆的烘焙程度，你會怎麼想？
反向問題：如果你無法自訂咖啡豆的烘焙程度，你會怎麼想？小提醒：為了確保結果有意義，至少要收集 30 份以上的有效問卷。太少的樣本可能會讓結果不夠準確喔！
Step 2 整理數據 : 收集完問卷後，下一步就是整理數據，根據用戶的回答，我們會回收問卷對於每個功能的回答進行歸類（其中隸屬於 Q 一類「疑問需求」需要篩掉）。
假設收到問卷的選項 (下圖一)，就可以交叉對照對照問題分類表 (下圖二)，判斷這個 (下圖一)問卷是歸類哪個屬性。
例如下圖一收回的問卷回答，問卷填寫人在 正向問題選擇 「很喜歡」+ 反向問題則是選擇「無所謂」，對照下圖二得到可以 歸類為 A 屬性魅力需求。範例： 假設問卷對於 咖啡準時送到 的功能，數據回收結果如下：
有 10 位用戶認為某功能是「A : 魅力需求（Attractive / Delightful Needs）」
有 28 位用戶認為是「O : 期望需求（One-Dimensional / Performance Needs）」
有 42 位用戶認為是「M : 基本需求（Must-be Needs）」
有 7 位用戶認為是「I : 無差異需求（Indifferent Needs）」
有 3 位用戶認為是「R : 反向需求（Reverse Needs）」
有 10 位用戶認為是「Q : 疑問需求（Questionable Needs）」我們可以計算這個功能的代表屬性： M: 基本需求的數量最多，有 42 個樣本，這個功能的屬性就被分類到 A 屬性了！
若無法清楚看到圖片文字，請點擊下方連結預覽 or 下載查看清晰版本 :
Step 3 : 列出產品功能改善順序並搭配敏感度公式。 當你分析出每項功能的屬性後，恭喜你！接下來就能像組裝拼圖一樣，排列出改善優先順序，讓你的產品功能一步步走向完美。依照經典法則，改善順序大致如下：
M : 基本需求→ O : 期望需求→ A : 魅力需求→ I : 無差異需求
在這條產品優化之旅上，目標很清楚：
- 先降不滿！ 移除令人抓狂的「R : 反向需求」& 改善無法缺少的「M : 基本需求」。
- 再添驚喜！ 聚焦提升讓人愛不釋手的「O : 期望需求」和「A : 魅力需求」。
可是，當手上有一大堆功能需要分析時，難免有點眼花撩亂，怎麼選擇先做什麼？這時候，Mike Timko 的 Better-worse 敏感度公式就像你的產品指南針，幫你找到最佳的優化順序。因為在功能屬性看似「撞衫」的情況下，敏感度公式可以幫你 清晰判斷每個功能對用戶滿意度的影響力。透過計算滿意度（SI）和不滿意度（DSI）的影響值，我們可以畫出一張「哪個功能值得優先關注」的地圖 (下圖四)。
公式如下：
- 滿意度影響 (SI) = (A + O) / (A + O + M + I)
- 不滿意度影響 (DSI) = (O + M) / (A + O + M + I) × -1
當 SI 和 DSI 的絕對值越大，它們對用戶的「心情波動」就越強，這就意味著這個功能的優化潛力越高！
範例： 假設問卷對於 咖啡準時送到 的功能，數據回收結果如下：
- 有 10 位用戶認為某功能是「A : 魅力需求（Attractive / Delightful Needs）」。
- 有 28 位用戶認為是「O : 期望需求（One-Dimensional / Performance Needs）」。
- 有 42 位用戶認為是「M : 基本需求（Must-be Needs）」。
- 有 7 位用戶認為是「I : 無差異需求（Indifferent Needs）」。
- 有 3 位用戶認為是「R : 反向需求（Reverse Needs）」。
- 有 10 位用戶認為是「Q : 疑問需求（Questionable Needs）」。
若無法清楚看到圖片文字，請點擊下方連結預覽 or 下載查看清晰版本 :
小結 :
| 順序 | 需求類型 | 優先度 | 解釋 | 優先考量原因 |
|---|---|---|---|---|
| 1 | 基本需求 (Must-be Needs) | 最高 | 產品的「底線」，必須先滿足，否則用戶會直接不滿意甚至放棄產品。 | 這些功能是不可或缺的基礎，關係到產品能否在市場上生存。 |
| 2 | 期望需求 (Performance Needs) | 高 | 直接提高用戶滿意度，是核心競爭力的一部分。 | 滿足期望需求能提升用戶的「感知價值」，通常是與競品競爭的關鍵點。 |
| 3 | 魅力需求 (Delightful Needs) | 中 | 非必需，但會帶來驚喜感，有助於產品脫穎而出。 | 資源允許的情況下，加入一兩個「魅力需求」可提升產品吸引力和差異化。 |
| 4 | 無差異需求 (Indifferent Needs) | 低 | 有無皆可，用戶無感，開發這類需求需謹慎。 | 避免浪費開發資源，重點放在更能影響用戶滿意度的需求上。 |
| 5 | 反向需求 (Reverse Needs) | 依情況而定 | 需求因用戶偏好而異，應靈活應對，甚至提供自訂選項。 | 根據用戶群體的特性與市場需求來判斷，避免讓功能成為「雙刃劍」。 |
RICE 優先級排序法
RICE 優先排序模型 是一種專門為產品經理設計的需求評估方法，由 Intercom 團隊提出。RICE 模型解決了產品團隊常見的頭痛問題：在資源有限的情況下，如何客觀地決定哪些功能應該優先實現？畢竟每個功能看起來都「很重要」，但真到了分資源的時候，總得有個說得過去的理由。
RICE 是什麼呢？
RICE 是四個指標的縮寫，分別是 Reach（影響範圍）、Impact（影響力）、Confidence（信心指數）和 Effort（實現成本）。透過這四個指標的加權計算，你可以得出每個需求的「優先分數」，然後用科學數據，幫團隊避開「只靠直覺決策」的危險地帶。
1. R：Reach（觸及）— 影響到多少人？
「觸及」是指這項需求會在特定時間內影響多少人，通常以「人數」為單位。它可以根據產品的性質和目標，靈活定義不同的時間範圍，例如：2 個月內的活躍用戶人數、30 天內試用版的註冊人數。
舉例：一項功能預計在未來 3 個月內，將改善 5,000 名用戶的購物體驗，那麼其 Reach 就是 5,000。
小提醒： 注意不要過於樂觀估計觸及範圍，數據需具備參考價值。 定義好「時間範圍」非常重要，別讓模糊的數字讓大家一頭霧水。
2. I：Impact（影響力）— 帶來的效果有多大？
影響力指的是這項需求完成後，對 單一用戶 帶來的 體驗改善程度。雖然「感覺」難以量化，但 RICE 模型追求的是「相對排序」，因此團隊只需要統一一套標準即可。
計算方式：影響力分為五個等級，從「巨大的改變」到「幾乎無感」。Intercom 提供的影響力評分標準如下：
3 = Massive impact（超高影響力）
2 = High impact（高影響力）
1 = Medium impact（中等影響力）
0.5 = Low impact（低影響力）
0.25 = Minimal impact（幾乎無影響）
舉例：一個功能可以大幅提升用戶購物轉化率，這樣的影響力就可以打 2 分 或以上。
小提醒： 評估時，別讓「觸及」和「信心程度」混入影響力的分數，專注於它對單一用戶的影響就好。對業務目標的影響通常難以量化，但需盡量與關鍵指標 (如轉化率、留存率) 對應。 記住這是主觀預測，和團隊討論時應保持一致標準。
3. C：Confidence（信心程度）— 你有多大把握？ 信心程度就是我們對 Reach 和 Impact 估算的信心值。根據可用的數據、用戶研究結果來評估，信心程度自然高；如果只是猜測，分數就得保守一點。
計算方式：Intercom 給出了三個常用標準
100% = High confidence（高信心）
80% = Medium confidence（中度信心）
50% = Low confidence（低信心）舉例：用戶調查和 A/B 測試數據支撐，信心程度可以達到 100% 。反之，如果只是根據直覺猜測或是少量樣本做推斷，信心可能只有 30%~40%。
小提醒： 避免「拍腦袋決策」的重要關鍵，評估數據的來源是否可靠。 若無具體數據支撐，信心指數應適當降低，避免影響判斷。
4. E：Effort（工作量）— 需要多少時間和人力？ 前三項都在討論「效益」，而 Effort 是分母，代表「成本」。它衡量的是完成這個需求所需要的人力和時間，通常以 人月（Person-months） 為單位計算。實現這個需求需要花多少時間和資源？這部分要估算進去，從 設計到開發，再到測試都得計算在內。
計算方式： 人數 × 時間 = 工作量
舉例：一項需求需要 4 名工程師花費 2 週完成，則工作量為 4 × 2 = 8 個人週
小提醒 : 工作量評估不僅是工程開發，也需考慮設計、測試和部署的成本。用人天數量化工作量時，需要與負責團隊確認預估的合理性。
如何計算 RICE 分數？
計算公式其實超簡單：
RICE 分數 = (Reach × Impact × Confidence) ÷ Effort
得到 RICE 高分功能 = 高影響範圍、高影響力、高信心、低實現成本。
分數越高，優先級越高。這個公式的核心精神就是權衡：資源有限的情況下，我們當然要先做「最小代價換最大價值」的事。
以下範例表格透過 RICE 模型分析多個功能，計算分數並進行排名。
| 功能 | Reach 觸及 | Impact 影響力 | Confidence 信心程度 | Effort 工作量 | RICE 分數 | 計算方式 |
| A 功能 | 500 | 3（中等影響力） | 80%（0.8） | 20 | 60 | (500 × 3 × 0.8) ÷ 20 = 60 |
| B 功能 | 1000 | 2（高影響力） | 70%（0.7） | 50 | 28 | (1000 × 2 × 0.7) ÷ 50 = 28 |
| C 功能 | 200 | 0.5（低影響力） | 90%（0.9） | 10 | 9 | (200 × 0.5 × 0.9) ÷ 10 = 9 |
排序結果：
- A 功能（RICE 分數：60）
- B 功能（RICE 分數：28）
- C 功能（RICE 分數：9）
優先開發 A 功能，再來為 B 功能，最後才是分數最低的 C 功能。
RICE 為什麼實用？
跟其他優先級模型相比，RICE 有趣的地方在於它數據化的評分過程，幫助團隊擺脫「主管說了算」或「哪個最吵做哪個」的情境。這也讓它成為 User Story Mapping 的好夥伴——當你把故事分成 Must、Should、Could 之後，RICE 模型能進一步幫你「量化任務價值分數」，選出真正值得投資的需求。
所以，下次當你面對一堆需求無從下手時，不妨拉出 RICE 模型，把每個需求都放進去算一算。讓數據來告訴你，究竟該先動哪塊任務！
問題：如果 RICE 模型在實際操作中，遇到需求執行後發現 Effort 更高、Confidence 更低，該怎麼辦？
回答：
這就像點了一碗看似清爽的牛肉湯，結果一喝發現是麻辣燙——入口有驚喜，壓力有點大，但肚子餓，現在也只有這碗湯，還是想吃一下墊個肚子 ? 還是就此停下，再另外去買其他食物 ? 。當你在開發過程中發現 Effort 比預期更高，或者 Confidence 隨著執行而下降，以下幾個方法可以幫你應對：
1. 重新評估 RICE 分數
別硬著頭皮往下開發，這時候最好的辦法就是「停下來重算」。拿最新的資訊重新計算 RICE 分數，看看這個需求在新條件下是否還值得繼續。
- 如果分數依然高，說明它的價值足以支撐高成本，接著做。
- 如果分數掉到谷底，那就果斷優化需求，甚至考慮停掉。
2. 拆分需求，降低 Effort
Effort 飆高的時候，可能是因為需求太大塊，讓人消化不良。試著把它拆成幾個小任務，針對每塊任務重新計算 RICE 分數，挑優先級高的先做。
- 舉例：假如你發現新增功能「自動化推薦」的開發比預期複雜，可以拆成「推薦系統基本框架」和「進階演算法調整」，分開進行。
3. 檢討 Confidence，補足數據
如果 Confidence 降低，通常是因為假設不夠穩。這時候就需要冷靜下來，看看是否有數據或用戶回饋可以補足信心。例如：
- 發起一次快速的用戶訪談，確認這個需求是否真的對他們有價值。
- 分析 A/B 測試數據，看看預期效益是否有眉目。
4. 啟用最小可行版本（MVP）策略
當 Effort 和 Confidence 出現波動時，一個穩妥的做法是先做一個 MVP（Minimum Viable Product）——簡化版本，快速驗證需求的價值。如果 MVP 證明了它的價值，後續再逐步優化。
5. 團隊同步，調整優先級
別忘了，RICE 是一個「相對排序」工具，而非絕對答案。當需求的 Effort 和 Confidence 變化時，記得及時和團隊同步，讓大家清楚這些變動對整體優先級的影響，並共同決定接下來的方向。
小結：
在實際操作中，需求的狀態變動很正常，RICE 不是一把鐵律，而是一個動態的指南針。遇到變數時，與其硬撐，不如靈活應對。畢竟產品開發就像登山，路線是可以調整的，但目標——到達頂峰，始終如一。
問題：MOSCOW、Kano Model 和 RICE 這三種優先排序法，要怎麼判斷使用的時機？各自的利弊又是什麼？
回答：
這個問題就像問：「咖啡、美式和拿鐵，哪個場合適合喝？」——得看你的需求和場景來決定！讓我們逐一拆解這三位排序大咖的出場場合和使用心得 :
| 優先排序法 | 適合時機 | 優點 | 缺點 |
| MOSCOW | 1. 資源有限、時間緊迫 時快速決定「做什麼」與「不做什麼」。 2. 需求範圍已大致確定，需要初步分類時。 | 1. 簡單直接，四種分類（Must、Should、Could、Won’t）一目了然。2. 適合跨部門溝通，容易讓所有人理解需求的輕重緩急。 | 1. 太籠統，無法細緻衡量需求的影響力或工作量。2. 適合初步篩選，不適合精細排序。 |
| Kano Model | 1. 想以 用戶為中心 判斷「基本必須」與「驚喜功能」。 2. 新產品規劃初期或需引入用戶研究結果時。 | 1. 強調用戶情緒，幫助設計超出用戶期待的功能。 2. 適合產品設計初期，打造符合用戶需求的功能組合。 | 1. 偏向質化評估，需用戶調研，過程可能耗時耗力。 2. 無法直接考慮開發成本，需搭配其他模型使用。 |
| RICE | 1. 當需求堆積如山但資源有限，需要量化效益、風險與成本進行排序時。 2. 迭代期產品需求管理，精準分配資源 時。 | 1. 精細量化，幫助優先處理高效益、低成本需求。2. 適合在資源有限情況下，最大化價值。 | 1. 依賴數據，數據不足或估算不準易導致錯誤排序。 2. Effort 評估可能隨執行深入而變動，需靈活調整。 |
那麼該怎麼選？
- 如果只需要快速篩掉低優先級需求，MOSCOW 是你的首選。
- 想打造讓用戶拍手叫好的產品？ 選擇 Kano Model，傾聽用戶心聲。
- 想做一個 精算師，幫需求排隊，資源花得超值？非 RICE 莫屬。
總結一句話：
需求管理沒有單一真理，視情況靈活搭配這些方法，才能在「需求無窮無盡」的世界裡，優雅地搞定優先級。
書籍推薦
資深PM的十堂產品煉金術：從面試到AI應用的全方位指南，外商思維 x 台企實戰教你從0到1打造爆款產品。
在 第三章「有效管理產品需求的藝術」 中，書中詳細介紹 MoSCoW 法則、RICE 評分法、Kano 模型 等經典方法，幫助你理性排序功能開發優先級，不再讓需求管理變成一場混亂的拉鋸戰。與本文精選的三種經典排序方法剛好完全命中 !! 有興趣往下鑽研的人可以來看看這本書。
除此之外，這本書還涵蓋 產品策略、用戶增長、定價決策、履歷面試攻略、PM職涯發展，甚至探討 AI 時代的產品經理挑戰，內容超實用，適合新手 PM 入門，也能幫助資深 PM 優化決策流程，值得一讀！
結論 Recap
本篇文章我們學習了三種幫助產品經理能在複雜任務中，如何理清優先順序的工具：
- MoSCoW 法
- 將需求分為 Must Have（必須做）、Should Have（應該做）、Could Have（可以做）、Won’t Have（不做）四類，幫助你在有限資源中快速決定「什麼最重要」。
- 應用技巧： 將 User Story Mapping 與 MoSCoW 法結合，清晰定義 MVP（最小可行產品）範圍。
- Kano 模型
- 從用戶滿意度和實現程度的雙維度出發，將需求分為 基本需求、期望需求、魅力需求、無差異需求 和 反向需求，幫助你設計出既滿足又驚喜的產品體驗。
- 應用技巧： 深入洞察用戶情緒，特別關注「魅力需求」，提升產品的獨特性與用戶滿意度。
- RICE 模型
- 以 Reach（觸及）、Impact（影響力）、Confidence（信心） 和 Effort（工作量） 為核心，量化每項任務的優先分數，幫助你從數據出發制定最理性的決策。
- 應用技巧：故事分成 Must、Should、Could 之後，RICE 模型能進一步幫你「量化任務價值分數」，使用簡單公式計算優先級，確保有限資源下每個決策都有清晰數據依據。
行動建議：
- 下一次面對需求或任務列表時，不妨試著使用其中一種方法進行優先級排序。無論是快速分組、用戶導向，還是數據排序驅動，這些工具都能幫助你做出更高效、更有條理的決策。
接下來，我們將進入一個非常實務且重要的環節——第七堂課 : 產品需求文件 PRD 製作管理 與 UX 工作產出。這不僅僅是交付給開發團隊的溝通橋樑，更是一份能夠協調設計、開發、測試團隊的核心指南。在這堂課中，我們會聚焦以下幾個問題：
- PRD 的核心內容是什麼？
- 怎樣的 UX 工作產出能在 PRD 中發揮關鍵作用？
接下來看看下一堂課的文章吧 !!
📩 歡迎交流！看完文章後，若有任何想法、建議或想一起討論的話，隨時歡迎來信交流！
Miss 六月奶茶聯絡信箱 : junemilktea6@gmail.com
