點進這篇文章的夥伴，可能多少對於產品優先級可能都已經有基本的認識，但就算完全不瞭解也沒有關係，偷偷推薦 Anne 的這篇文章（笑），裡面針對什麼是產品優先級，常見的優先級制定框架等都已經幫各位夥伴整理得非常清楚 🎉
如果只是想要快速認識幾個常見優先級框架的小夥伴（例如 MoSCoW、RICE、KANO 等等），建議可以直接閱讀這篇文章，除此之外，在 Product Roadmap 產品路線圖 這本書裡面也有完整的章節在討論產品優先級該如何被規劃和設計，非常推薦各位花點時間好好研讀一下這本書 👍。
回到正題，今天最主要想和各位夥伴分享「當我們運用優先級框架」在企業端產品時可能會面對到的理想與現實，畢竟通常這種東西，理論是一回事用起來又是另外一回事，再加上規劃企業端產品的開發優先級本身就是件困難的事情，畢竟它涉及的層面很廣，需要溝通的對象也很…雜？在應用上的困難度呈指數上升，很容易不小心淪為大甲方大乙方的悲慘故事。如果對於這類型的溝通流程或產品設計有興趣的夥伴，可以閱讀我之前想不開時做的整理：
相較於 C 端的使用者，B 端產品團隊的夥伴其實並不容易直接接觸到「產品的直接使用者」，加上大部分的決策者常常不是產品的使用者，導致在規劃 2B 產品優先順序時，產品經理更需要綜合評估各項需求的來源，需求希望達到的目的（例如是解決問題？是讓決策者買單？還是…老闆開心？），並且釐清企業中決策者、使用者和管理者在合作專案中所扮演的角色，這對於許多經驗在 Ｃ端，過去基本專注商業指標、產品指標或體驗指標的脈絡其實有很大的差別，常常是許多 2B 產品經理在踏入時所無法克服的困難。
但不論是 C 端還是 B 端的產品，我們所謂「需求」都是具體和產品有相關性，且為解決特定問題（人）而被提出或者原問題尚未被滿足的要求，人人都是產品經理的文章中有提到，在企業端產品的世界中，需求主要可以被分為三種類型：
1）業務需求
業務需求實際上為滿足企業（客戶）特定使用場景和目的，必須實現的功能，主要體現在滿足業務規則、管理制度、業務流程等方面。
2）用戶需求
在滿足業務需求後，產品是否好用，會成為評判產品優劣的重要指標， 2B 的市場中用戶需求又有可能分別來自於管理者、使用者甚至決策者。
3）產品需求
產品需求一般是由產品團隊提出，基於公司戰略及產品戰略，滿足企業持續發展的需要，如使用者中心、訊息中心、訂單中心、帳號管理、課程管理、信件服務等服務建設。解決產品發展的重復建設問題，搭建技術平台；滿足產品生態建設、合作夥伴開放平台等等，都可以歸類於產品需求，產品需求在一定階段時又會轉化為業務需求和用戶需求。
在產品需求中，我們可以再將它拆解為「功能性需求」和「非功能性需求」，會需要產品經理根據業務場景、發展方向來評估各自的重要性：
- 功能性需求：是那些用以處理產品所必須滿足用戶需求的功能特性，功能型需求是最基礎也最核心的用戶需求，功能型需求有時也被稱為業務需求。
- 非功能性需求：包括可用性需求、性能需求、可靠性需求和安全需求等；這類需求在系統建設早期重視度往往不高，當用戶量上升，產品越來越重要時，非功能性需求的重要性將會越來越突出（同時也可能會變的更加難以補救）。
另外，我很喜歡 Gusto CPO Tomer 在 Comparing Apples and Oranges: A New Prioritization Framework for Product Managers 裡面分享的概念 — 大部分的優先權比較並不是 Apples to apples（相當目標）
通常會是 Apples to oranges 的比較，問題也常常會從單一維度升級到多重維度，但是在理解需求後，我們仍然可以嘗試用「降維」的方式來進行比較。
其實也是滿有趣的且簡單的概念，當然文章裡面的插圖有夠可愛的（笑），好啦！接下來，我們就來看看這些滿坑滿谷的需求該如何被安排優先級吧。
企業端產品優先級框架版本（一）
隨著產品越來越完整，整個業務、客戶成功團隊都會開始漸漸擴張，此時，來自四面八方的需求開始變得層出不窮，今天業務和你說客戶急著要這個，明天換隔壁棚的大客戶要那個，如果沒有一個判斷標準常常會限於需求轟炸的焦慮中；最開始傻乎乎的決定直接套用 RICE，結果發現：
- Reach 指的是多少客戶在固定期間內會被這個功能影響到，但在企業端產品中，使用者越多真的代表這個功能越能夠讓客戶買單？企業導入你家的產品肯定有其希望能夠達到的目標，例如「提高 HR 的工作效率」或者「增加員工的工作績效」等等，除此之外，企業端有著各式各樣的使用者，而且他們各自的影響力也不是同等分佈的。
- Impact 就是這個功能對產品目標以及戰略的影響，產品目標可能清晰且明確，但它並不一定會符合現階段企業客戶的需求，反而需要綜合考慮我們當下在解決的問題是什麼，我們在客戶眼中的定位是什麼？
- Confidence 就是有多大的把握這個功能會成功，100%表示很大把握，80%表示適中，50%表示比較低，這考慮的範圍就更廣泛，回到所謂「成功」的定義是什麼？如果讓客戶買單是否成功？如果客戶中的使用者非常喜歡但客戶不買單又如何？
- Effort 可以用人月的單位來計算，這個項目相對單純。
基於上述盤根錯節各種理不出頭緒的場景獨特性，很快我們經歷到 RICE 實在不足以阻擋業務與企業們的許願，基於 RICE 我們調整出一套新的產品優先級框架，將原本 RICE 中的 R（Reach）進行調整，同時新增 B（Business Value）的維度加入綜合評估：
- （B）需求的商業價值：客戶維繫價值 + 客戶建立價值 x 客戶權重
- （R+）使用者的產品價值：使用者的影響範圍 x 使用者權重 x KANO 產品價值
- （I）需求影響力價值：功能對產品目標、產品戰略或商業策略的影響
- （C）需求信心指標：對於該功能所能帶來影響的信心指數
- （E）複雜度指標：該項功能實作的複雜度指標
裡面可能會看到幾個沒見過的名詞先稍微來說明一下，由於企業端產品在商業價值的部分是由「續約（舊）客戶」和「新客戶」所組成，針對這兩個項目我們可以分別計算所謂「客戶維繫價值」與「客戶建立價值」，客戶維繫價值需要考慮這個選擇，對於續約率的提高是否有信心、
- 客戶建立價值：新客戶價值 x 新客戶優先級權重 x 新客戶成單信心指數
- 客戶維繫價值：續約客戶價值 x 續約客戶優先級權重 x 續約信心指數
- 針對裡面各自的客戶價值，可以考慮用「客戶規模 x 客戶市場權重 x 客戶忠誠度」或者可以很單純用營業額來設計。
到這裡是不是開始覺得頭昏眼花？別放棄，最後再稍微說明一下「客戶續約」和「新客戶」的優先級權重，這邊當然會因為產品特性或者市場而有差異，理想的狀況可以再多乘上一個變異係數（🔥），舉個案例：
- 客戶續約優先級權重：優先級可能根據當前客戶數量、策略面向調整，簡單拆分為霸王條款 = 1.0、特定目標客戶 = 0.5、基本續約價值 = 0.2
- 新客戶優先級權重：優先級可能根據市場客戶數量、策略面向，分析市場客戶預估成交金額、數量，再加上霸王條款等因素
這邊還要特別強調，裡面幾個項目的計算是需要跨團隊協作的，舉例來說需求商業價值就會需要客戶成功經理和業務共同進行評估，信心指標可能需要團隊進行綜合評估等等，綜合以上條件，我們能夠計算出一個產品開發優先權的分數，提供各位參考。
到這裡問題就結束了…看起來世界很美好嗎？不，問題馬上就來了，先暫時拋開實際的排序是否實際產生幫助，試營運幾個 Sprint 我們就發現 2 個世紀大問題：
- 主觀與客觀綜合因素：由於優先級框架中主觀影響的項目過多，同時許多項目需要跨團隊的討論與評估，人多口雜（是這樣說？）往往無法達成一致的共識。
- 教育與溝通成本：由於優先級框架中的計算方式複雜，對於新加入的夥伴學習成本高，同時在溝通時也無法輕易的讓各方理解其重要性，向上管理更是無比困難。
除此之外，擔任產品經理一段時間其實會慢慢發現不論所選擇的「優先級框架」制定有多麽完整，產品團隊可以選擇使用不論 KONO、RICE 或者主觀策略面向進行評估，但對於平常就有在觀察數據指標，同時有著產品藍圖的產品經理來說，優先級框架其實常常就是一個與不同團隊「溝通的工具」，讓產品經理能夠使用一個更加量化的方式來說服團隊中的業務、工程師或者老闆「為什麼產品團隊要這麼做？」，但這也意味著…
如果跨團隊間是沒有信任的，不論優先級框架制訂的再好老實說都不會讓你的功能運作上更加順利，建立團隊間的信任絕對是你的首要任務。
文章的最後（什麼？！），還有一個重點會回扣到自家產品的願景與它期待能夠帶給客戶的價值，協助客戶解決的問題；產品經理需要持續與內部、外部的需求方進行溝通甚至教育，提供各種資料與視覺化的成果，協助利益關係人們用更長遠的視角來評估功能開發的優先順序，避免團隊僅僅受限在眼前的商業指標而失去長期發展的優勢。
決定故事就先停在這裡，是不是很北爛？我希望藉由這篇文章能引導各位思考框架導入的理想與現實，同時其中還是有不少企業視角維度，老實說是滿可以借鏡參考的！
未來的文章會和各位更新優先級框架的「後續」並帶來全新的「企業端產品優先級框架版本（二）」，聊聊我們最終如何規選擇企業產品的優先權，如何預留彈性並且評估該保留多少的彈性與溝通的籌碼，如果有興趣的小夥伴請密切追蹤 🎉
Hello，我是 Samuel，目前在 Hahow 好學校擔任 Head of Product。覺得分享和傳遞資訊這個行為能夠改變整個環境與業界氛圍，喜歡產品設計、教育、商業思維和攝影，有任何想法或者合作的機會都歡迎一起喝杯咖啡。Facebook：https：//www.facebook.com/citysite1025
Instagram：https://www.instagram.com/citysite1025
Linkedin：https://www.linkedin.com/in/samuel-kao-87972482/
