【本文出自產品三眼怪實驗室作者Anne Hsiao】
回想我第一次面試產品經理職位時，被問到這個問題：
「你如何決定要開發什麼功能？」
『如果不知道要開發什麼功能的話，我會先了解客戶的需求，針對使用者做簡單的訪談，來決定接下來要開發什麼功能。』
「摁…你說的沒錯，但我們遇到的情況有點不同。我們每天從各種不同管道，收到一堆來自客戶、使用者的回饋，希望我們盡快開發各式各樣的功能，同時客服、業務團隊也對產品功能有很多具體的想法，面對這樣的情況，你會怎麼決定要先開發什麼功能？」
面試當時，我過往的經驗比較專案導向，因此聽到這個問題時很直覺的反應就是「不知道要做什麼？問客戶、使用者、老闆就對了！」秉持著來一個需求就做一個功能的心態，First In, First Out！
但在開發自有產品的團隊內，事情卻複雜許多，問題在於有太多的需求，在持續優化與維護產品的過程中，資源有限慾望無窮時，排定優先級成為非常重要的決策能力。
什麼是優先級（prioritization）？
Prioritization，中文可以翻譯為優先級、優先序、優先順序，亦即先做什麼、後做什麼，在軟體產品領域中，即為決定先做A還是先做B、要優化現有功能還是開發新功能等等。
排定優先級背後隱含的意義，其實是「資源分配」與「機會成本」的概念，當我把時間與工程資源花在A功能上，就無法同時花在B功能上（加班不算啊，老闆幫幫忙）。
在瀑布式（waterfall）開發流程中，產品經理在早期就會跟相關部門討論好完整的功能，若有分不同版本交付，就需要決定每個版本分別要開發哪些功能，也就是說在一開始就會定調好產品開發的優先級。
而在敏捷式（agile）開發流程中，核心價值是快速產出、測試/學習、迭代/修正，因此會更頻繁與動態的調整優先級，產品經理要有根據實驗與回饋的成果來隨時調整優先級的心理準備，除此之外也難以避免插件的產生，因此心裡有一套排序優先級的方法與邏輯是很重要的。
先排序問題，再排序解法！
使用者、客戶、其他相關部門提出的回饋，以及使用者研究分析出的洞見，常常是亂到不知道如何整理 Backlog！其內容可能包含現有功能優化、新功能開發（會員集點功能）、很直覺的 Issue/Bug，或是一個大大的問題（如何幫助我們吸引會員回來電商網站購物）等等，也就是說有些是明確的功能、有些則是模糊的問題。
在一些非常成熟的產業當中，直接按照功能來分類需求、按照競品的樣子刻一個功能出去給使用者也許是沒問題的，但在變動快速的產業中，了解使用者提出這個功能背後的問題、需求與使用情境，才能幫助我們想出更多的解法、更好地去服務使用者。
有時候，使用者也不知道他為什麼想要這個功能，也許他之前有看過這個功能，所以想說問問看有沒有可能開發（問一下不用錢嘛）。但在缺乏使用情境的情況下，產品團隊很難滿足每個使用者的需求、也無法判斷該解決的核心問題是什麼，因此多問使用者一個「為什麼」總是不會錯，也能夠釐清這是否一個值得解決的問題。
將使用者提出的功能回饋拆解成問題與需求後，可以先排定「問題」的優先級，專注於我們想要解決的問題、能帶給公司的價值，而當開始定義問題、想解決方案後，產出一堆功能的想法時再來排定「解法」的優先級。排定優先級這件事情，會不斷地在產品設計與開發的環節中發生。
三種常見的優先級考量標準
一、問題規模
溝通對象：使用者、客服團隊、使用者研究員
對於「使用者中心」的產品設計團隊，從使用者需求出發來考慮排序的優先級是常見的方法，問題規模可以包涵：使用者針對該需求提出的數量與頻率、該問題影響到使用者數量、該問題發生的頻率/功能的使用頻率來判斷問題的規模有多大，以及是否值得優先被處理。
二、商業價值
溝通對象：業務、BD、商業相關部門
在很多大公司中，會先處理商業價值最大的問題，可能是可以立即賺錢的、或是可以幫助團隊在未來打下更多市場的市場需求，舉例來說 B2B 產品團隊接到與大型品牌客戶的合作、與強大第三方服務商的合作，或是比競品更早推出新功能而有機會可以搶到更多客戶時，會將這類型的功能獨立拉出來提高優先級。
商業價值也包含可以協助獲取新用戶、提高留存率、提高轉換率、提高營收等指標，保持與公司的目標一致。
三、資源考量
溝通對象：設計師、資料科學家、軟體工程師、QA
資源考量常在排序解法時出現，與技術團隊共同判斷技術可行性、所需資源、與其他功能之間的相依性（dependency），來決定現階段要用哪個解法來解決問題。
制定優先級的策略
- 團隊目標
在有規模與制度的公司內，每年、每季都會制定公司的目標與策略，例如營收成長、客戶成長、會員數成長、新市場拓展等等，而產品團隊也會因應公司目標而訂定階段性的產品目標，產品目標可以協助我做決策時定出不同的考量要點、權重並保持與商業目標的一致性。
- 風險測試
在很早期的產品團隊，或是產品本身發展潛力還很多元的時候，可以選擇將不確定性最高（亦即報酬很大但失敗性也可能最高）的功能推出去測試，先完成第一階段的最小可行性產品（Phase 1 MVP）來看看成效，從中學習並快速迭代，來快速取捨接下來的發展方向。
另外一個思考方式，則是先處理風險低、信心程度高的問題，確保推出的解法是真正能夠解決現有使用者的問題，創造影響力。
但其實撇開風險高低不說，早期花少少的資源透過小測試來快速得到回饋，每次收完回饋就重新調整優先級，將反應好的功能加碼優化也是一個很好的開發策略，對於資源的安排也會更有彈性。
延伸閱讀：產品上線規劃：分階段釋出網路產品的實作流程與工具
排定優先級的工作流程
在實際操作上並不會只參考一個面向，而是動態的考量不同因素來排定一個優先級。有時候這些方法其實是互相衝突的，舉例來說商業價值最高的可能要花費的技術成本也最高，因此產品經理最困難的工作就是找出平衡點並跟團隊一起討論出大家都認同的產品路線圖。
工作流程
1. 確立團隊目標
2. 蒐集使用者問題、商業問題
3. 排序問題優先級
4. 依照資源多寡，選擇高優先級的問題來進行使用者與市場研究
5. 針對研究結果，發想不同的解法
6. 排序解法優先級
最後最重要的，是要跟內外部團隊都充分討論與告知目前的優先級，確保大家瞭解決策過程並且能夠安排相對應的資源。以下分享兩個思考決策與解決問題的小案例：
案例一：少數大客戶 v.s. 多數小客戶
在 B2B 的產品世界裡，Key Accounts（KA）總是說話最大聲的人，但當面對到只有少數幾個 KA 提出某個問題，而大部份的小型客戶都沒提過，這個問題是否就不重要而應該被排到比較低的優先級呢？
這個問題困擾我的地方在於，不確定「問題規模」的大小。
有鑒於使用者除了常常不知道自己要什麼，幫助他們釐清問題就是產品團隊的責任！
舉例來說，其中一位電商賣家 KA 每週上新品的數量達 100 件，因此要求優化後台大量新增、上架商品的功能。此時除了確認 KA 本身的使用情境與需求外（包含老闆、小幫手等不同使用者），也可以透過市場研究、競品研究，並針對一般小型賣家發問卷、做訪談，了解他們目前的狀況：
- 如何上架商品、誰負責上架
- 是否曾經有需要大量新增的需求、最大量是多少
- 上架商品過程中遇過哪些問題...等等。
瞭解「未發聲」的中小型賣家是否也遭遇類似的問題，或是他們未來成長變大的過程中會不會遇到相同問題，來初步判斷這個問題是否值得優先被排程。
案例二：目標優先級、問題優先級、解法優先級
有時候跟使用者聊得太開心，蒐集到一堆回饋，就會直接落到「該功能/需求被提出的次數」這個最直覺的方法來決定要優先開發什麼功能。
舉例來說，若設立的團隊目標是幫助賣家提升顧客來到電商網站的轉換率（結帳完成！），其中一個被放在高優先級的問題是「許多顧客將商品加入購物車，但沒有完成結帳動作」，針對這個問題做使用者研究後，發現超爆多顧客提出的回饋是「喔我其實當時還沒有要買，只是網站沒有那種可以蒐集我的最愛商品的地方，所以想說先放在購物車裡面之後慢慢挑～」仔細想想，這個功能好像可以做喔！
不對！你才沒有仔細想想 ！
此時的團隊目標是幫助賣家提升顧客來到電商網站的轉換率。也許顧客此時提出的功能看似需求量很高，但在現在這個時間點不見得是最重要的事。但對於你的產品同事（例如負責顧客體驗的PM，如果有這個人的話）這個發現也許就很重要，應此可以將這個問題轉而放入他們的 Backlog 中供他們未來做研究。
綜合量化的排序架構
在團隊眾多的產品公司裡面，對於資源安排的方式更是斤斤計較，因此能夠用更有架構的方式，甚至量化的數字來比較，會更有說服力。
以下架構我並沒有全都使用過，因此分享一些好文章給大家參考：
KANO：定義了三種不同層級的使用者需求 — — 基本型需求（Basic, Must-Be）、期望型需求（Performance）、興奮型需求（Excitement）
MoSCoW：定義了四種不同層級的使用者需求 — — 必須要有（Must Have）、應該要有（Should Have）、能做（Could Have）、不能做（Won’t Have）
RICE：RICE score = (Reach*Impact*Confidence) / Effort
ICE：ICE score = Impact * Confidence * Ease
參考書籍：《產品路線圖》Chapter 7 — 掌握排定優先順序的科學！
最後的最後…
自問自答時間
- 現階段的團隊目標是什麼？最需要解決的問題是什麼？
- 在排定優先級時，邏輯與權重分別是什麼？
- 有哪些資源與限制？
- 如果現在不處理某個問題，會發生什麼事？
線上 BUG 永遠最急
前面說了很多理想美好的排定優先及方式，但產品線上發生的 BUG 永遠是第一優先要處理的，因此在面對線上功能壞掉的情況，也可以訂定出一套處理插件與救急的標準。
以電商產品舉例，與註冊、登入、購物車結帳、錢高度相關的地方壞掉絕對是 hotfix 等級，需要馬上被解決，這時候什麼團隊目標就放在一旁，先把最最核心的產品功能修好才是至關重要的。
保持決策的一致性
優先級會不斷的變動，插件也難免會產生，有一套一致的邏輯與決策方式來說服設計與工程團隊內部、以及與外部業務部門溝通，可以幫助產品經理增進溝通效率。重點不只是方法，更是挑選這個排序方法背後的原因。
從使用者回饋與測試中來調整優先級
如同前面風險測試提到的，將每次要驗證的問題切小，快速迭代和蒐集回饋來重新調整優先級，對於資源的安排會更有彈性。
更重要的是，優先級的重點不只在於順序，更在於資源的運用，如果能夠因此用市場回饋說服老闆直接「增加資源」，很多事情似乎就更好解決了呢！
