此文章經由 sofasoda 團隊翻譯 Product School 原文 3 Prioritization Techniques All Product Managers Should Know
身為產品經理最大的課題之一就是——功能/服務開發的優先級。
大家對於安排優先級可能多少都有一些概念，例如，你會根據不同事情的重要性和時間期限決定要先處理哪件事情，或是先回誰的訊息和 email。但是產品開發的優先級就這麼簡單嗎？
產品經理經常要面對的是一堆還未排序的產品功能和服務，但同時也會接受到來自四面八方的想法和意見，可能工程師跟你說如果可以開發功能 A 的話，可以讓整體產品體驗有所提升，然後另一位同事私訊你建議功能 B 應該要安排在接下來的排程中，過沒多久資料分析師就帶著數據來跟你說他覺得功能 B 的影響力應該不大，所以不應該開發，但是功能 C 才是使用者真的想要的。
聽到這些來自各方利益關係者的建議，身為產品經理的你，會如何決定優先開發哪些功能？這個就是產品經理要面對的挑戰。安排產品開發的優先級真的不是件容易的事，但是如果想要成功推出一個產品、一項新的功能或服務，就必須把這件事情做好。
在這篇文章中，我們會分享產品經理必會的三大 Priortization 方法
- The MoSCoW Method （莫斯科法則）
- RICE Score（RICE 分數）
- Kano Model（Kano 模型）
莫斯科法則 The MoSCoW Method
對於想要加強利害關係人（Stakeholder）之間溝通的產品經理，可以考慮使用這個方法，同時也可以幫助產品經理釐清哪些功能/服務是重要的，哪些是相對比較不重要的，透過這個方法，產品經理可以更有效的溝通正在開發中的功能或服務以及優先開發的原因。
MoSCow 所代表的四種產品功能或服務的分類是：
Must have（一定要有）：不能沒有的產品功能
這種類別的產品功能有可以是跟法律、安全或商業相關的，或著是你已經向使用者保證會有。你可以透過列出如果沒有功能 A，最好和最糟的情況，如果沒有功能 A 會很糟的話，那就是屬於「一定要有」的！
Should have（應該要有）：有了會比較好，但沒有也不會很糟
Could have（可以有）：如果有足夠資源的話，有也不錯，但是沒有不會失敗
一個產品功能該被歸類在「應該要有」還是「可以有」只有一線之隔，想要知道究竟應該被歸類在哪個，你可以問問自己「有或沒有這個功能，對使用者體驗的影響多大」，影響越小的應該被往下排！
Won't have（一定不會有）：現在不開發不見得是永遠不開發，只是不是現在會被分類到這個的產品功能可能是因為缺乏時間或資源或是時候未到，因此不會被安排到近期的開發時程。
RICE 分數
RICE 分數則是用比較數學化的方式去衡量產品功能或服務是否優先開發。RICE 所代表的四個英文單字是：Reach（觸及人數）、Impact（影響力）、Confidence（信心程度） 和 Effort（工作量）
RICE 分數的公式是：Reach x Impact x Confidence / Effort
Reach 觸及人數
預估這項新的功能或是服務會觸及到多少人，你可以從歷史資料中抓出實際使用者的數字佐證，例如：用 MAU 估算出新的功能會影響到多少使用者這次的新功能或是發佈會影響以及觸及到多少人，可以從過去的資料中抓出實際使用者的數字去佐證，例如：「用 MAU 去估算出這樣的新功能會影響到多少使用者」
將這個數字填入公式中 Reach 的位置
Impact 影響力
根據這項新的功能或是服務量化能為產品帶來的影響力（好處），這個 Impact 通常就會是你設定的成功指標。但這個數字不好估算，所以可以用一套對整過的數字去預估，但要確保團隊中是用一樣的衡量標準。
- 3 = 超高度影響力
- 2 = 高度影響力
- 1 = 中度影響力
- 0.5 = 低影響力
- 0.25 = 微乎其微的影響力
評估後將這個數字帶入公式中 Impact 的位置
Confidence 信心
根據這項新的功能或是服務你覺得會帶來蠻大的影響力，但是沒有數據佐證，就可以用信心程度來控制這點。雖然產品開發是很講究數據導向的，但是不見得每個專案都是可以用數字去衡量的。
而常見的信心程度有：100%＝高度信心、80%＝中度信心、50%＝低度信心，如果你的信心程度低於 50%，那就可以先把這項功能降級。
評估後將這個數字帶入公式中 Confidence 的位置
Effort 投入工作量（時間）
根據這項新的功能或是服務，所需要花費的開發時間有多少？這個數字需要所有參與的人員提供他們需要投入的工作時數。常見的估算方式是用人力和月份估算，假設這個功能需要三個人一個月的時間，那 Effort = 3 人 x 1 = 3，只要花費的時間少於一個月那就等於 0.5，假設需要三個人 2 個禮拜，那 Effort = 3 人 x 0.5 = 1.5。
因為 Effort 是在分母的位置，如果估算出來需要投入的時間越多，那觸及人數、影響力和信心程度要夠高才值得去執行。
評估後將這個數字帶入公式中 Effort 的位置
最後，算出 RICE 分數，這個數值在所有規劃中的開發專案彼此相比後，越高的月應該優先開發。
Kano 模型
Kano 模型背後的概念是幫助產品經理加開發的功能分類在這三個種類下，開發出使用者滿意度高的功能或是服務。主要分成三種需求：
1. 基本型需求（Must Have）
- 為了服務使用者最基本的需求而必須要有的功能，如果沒有這項功能使用者滿意程度會指數型衰退，因此不能沒有而且一定要達到最基本的需求
2. 期望型需求（Performance: More is Better）
- 這個產品功能或服務開發後會等比例的提升使用者滿意度。
3. 興奮型需求（Delighter: Wow）
- 使用者不會過度期望的需求，所以如果有開發這樣的產品功能，使用者滿意度會指數型成長，但是就算功能滿意程度度不夠，使用者也不會太在意。
想要知道這個功能或是服務對使用者來說的價值，可以透過簡單的問卷或訪談了解如果有了這個功能或服務會如何改變他們的體驗。
但是對於一個產品來說，現在是興奮型的需求長期也有可能變成期望型或是基本型需求。最好的例子就是手機，過去可以上網可能是興奮型需求，到現在，已經是基本型需求了。
這三種方法，我該用哪個？
三種框架各有特點，MoSCoW 將產品開發聚焦在對消費者和團隊中的其他 stakeholder，而且對於非技術背景的利益關係人來說也更好懂。缺點就是，還是有可能把太多產品功能或服務放到「一定要有」（Must have）的分類。
RICE score 是很多產品經理喜歡使用的模型，因為其中有包含到信心程度。Kano 則是適合用在使用者為主的專案和決策，但是為了精準度你可能要花不少時間透過問卷蒐集使用者的回覆。
總而言之，其實沒有一個通用的框架，而且除了這三個之外還有很多別的方法，厲害的產品經理甚至可以發展自己的一些開發決策跟開發方式。最重要的還是不斷地嘗試不同的方法，找出最適合你的決策方式。
身為產品經理最大的課題之一就是——功能/服務開發的優先級。大家對於安排優先級可能多少都有一些概念，例如，你會根據不同事情的重要性和時間期限決定要先處理哪件事情，或是先回誰的訊息和 email。但是產品開發的優先級就這麼簡單嗎？
----
⭐️ sofasoda 產品思維系列課程－優先級方程式：用量化公式帶你決定產品開發順序
馬上去看看：傳送門
