在產品開發工作中，面多多重需求，產品經理不知道先去做什麼，該把什麼需求放在前面，如此下來會造成工作多而混亂。作者結合相關案例，總結了如何評估產品工作優先順序的一些方法，希望對你有所幫助。

回想我第一次面試產品經理職位時，被問到這個問題：

「你如何決定要開發什麼功能？」

『如果不知道要開發什麼功能的話，我會先了解客戶的需求，針對使用者做簡單的訪談，來決定接下來要開發什麼功能。』

「嗯…你說的沒錯，但我們遇到的情況有點不同。我們每天從各種不同渠道，收到一堆來自客戶、使用者的反饋，希望我們儘快開發各式各樣的功能，同時客服、業務團隊也對產品功能有很多具體的想法，面對這樣的情況，你會怎麼決定要先開發什麼功能？」

面試當時，我過往的經驗比較專案導向，因此聽到這個問題時很直覺的反應就是「不知道要做什麼？問客戶、使用者、老闆就對了！」秉持著來一個需求就做一個功能的心態，First In， First Out！

但在開發自有產品的團隊內，事情卻複雜許多，問題在於有太多的需求，在持續最佳化與產品迭代的過程中，資源有限慾望無窮時，排定優先順序成為非常重要的決策能力。

一、什麼是優先順序

Prioritization，中文可以翻譯為優先順序、優先序、優先順序，亦即先做什麼、後做什麼，在網際網路產品領域中，即為決定先做A還是先做B、要最佳化現有功能還是開發新功能等等。

排定優先順序背後隱含的意義，其實是「資源分配」與「機會成本」的概念，當我把時間與工程資源花在A功能上，就無法同時花在B功能上。

在瀑布式（waterfall）開發流程中，產品經理在早期就會跟相關部門討論好完整的功能，若分不同版本交付，就需要決定每個版本分別要開發哪些功能，也就是說在一開始就會定好產品開發的優先順序。

而在敏捷式（agile）開發流程中，核心價值是快速產出、測試/學習、迭代/修正，因此會更頻繁與動態的調整優先順序，產品經理要有根據實驗與回饋的成果來隨時調整優先順序的心理準備，除此之外也難以避免緊急需求插入的產生，因此心裡有一套排序優先順序的方法與邏輯是很重要的。

二、先排序問題，再排序解法

使用者、客戶、其他相關部門提出的反饋，以及使用者研究分析出的洞見，常常亂到不知道如何整理！其內容可能包含現有功能最佳化、新功能開發、 Bug，或是一個很大的問題（如何幫助我們吸引會員回來電商網站購物）等等，也就是說有些是明確的功能、有些則是模糊的問題。

在一些非常成熟的行業當中，直接按照功能來分類需求、按照競品的樣子複製一個功能出去給使用者也許是沒問題的。

但在變動快速的行業中，瞭解使用者提出這個功能背後的問題、需求與使用場景，才能幫助我們想出更多的解法、更好地去服務使用者。

在缺乏使用場景的情況下，產品團隊很難滿足每個使用者的需求、也無法判斷該解決的核心問題是什麼，因此多問使用者一個「為什麼」總是不會錯，也能夠理清這是否一個值得解決的問題。

將使用者提出的功能反饋拆解成問題與需求後，可以先排定「問題」的優先順序，專注於我們想要解決的問題、能帶給公司的價值，而當開始定義問題、想解決方案後，產出一堆功能的想法時再來排定「解法」的優先順序。排定優先順序這件事情，會不斷地在產品設計與開發的環節中發生。

三、三種常見的優先順序評估標準

1. 問題規模

溝通物件：使用者/客戶、業務、客服、社群、使用者研究員

對於「使用者中心」的產品設計團隊，從使用者需求出發來考慮排序的優先順序是常見的方法，問題規模可以包含：使用者針對該需求提出的數量與頻率、該問題影響到使用者數量、該問題發生的頻率/功能的使用頻率來判斷問題的規模有多大，以及是否值得優先被處理。

2. 商業價值

溝通物件：業務、BD、商業相關部門、各種利益關係人

在很多公司中，會先處理商業價值最大的問題，可能是可以立即賺錢的、或是可以幫助團隊在未來打下更多市場的市場需求。

舉例來說 B2B 產品團隊接到與大型品牌客戶的合作、B2C 產品團隊與強大的第三方服務商合作，或是比競品更早推出新功能而有機會可以搶到更多客戶時，都有可能會將這型別的需求獨立拉出來提高優先順序。

商業價值也包含可以協助獲取新使用者、提高留存率、提高轉換率、提高營收等指標，保持與公司的目標一致。

3. 資源考量

溝通物件：設計師、研發工程師、QA

資源考量常在排序解法時出現，與技術團隊共同判斷技術可行性、所需資源、與其他功能之間的相依性，來決定現階段要用哪個解法來解決問題。

四、制定優先順序的策略

1. 團隊目標

在有規模與制度的公司內，每年、每季都會制定公司的目標與策略，例如營收成長、客戶成長、會員數成長、新市場拓展等等，而產品團隊也會因應公司目標而制定階段性的產品目標，產品目標可以協助我做決策時定出不同的評估要點、權重並保持與商業目標的一致性。

2. 風險測試

在很早期的產品團隊，或是產品本身發展潛力還很多元的時候，可以選擇將不確定性最高（亦即報酬很大但失敗性也可能最高）的功能推出去測試，先完成第一階段的最小可行性產品（MVP）來看看成效，從中學習並快速迭代，來快速取捨接下來的發展方向。

另外一個思考方式，則是先處理風險低、信心程度高的問題，確保推出的解法是真正能夠解決現有使用者的問題，創造影響力。

但其實撇開風險高低不說，早期花較少的資源透過小測試來快速得到反饋，每次收完反饋就重新調整優先順序，將反應好的功能最佳化也是一個很好的開發策略，對於資源的安排也會更有彈性。

五、排定優先順序的工作流程

在實際操作上並不會只參考一個方面，而是動態的考量不同因素來排定一個優先順序。有時候這些方法其實是互相沖突的，舉例來說商業價值最高的可能要花費的技術成本也最高，因此產品經理最困難的工作就是找出平衡點並跟團隊一起討論出大家都認同的產品路線圖。

工作流程：

確立團隊目標

收集使用者問題、商業問題

排序問題優先順序

依照資源多寡，選擇高優先順序的問題來進行使用者與市場研究

針對研究結果，制定不同的解法

排序解法優先順序

最後最重要的，是要跟內外部團隊都充分討論與告知目前的優先順序，確保大家瞭解決策過程並且能夠安排相對應的資源。以下分享兩個思考決策與解決問題的小案例：

六、案例解析

案例一：少數大客戶 v.s. 多數小客戶

以B2B產品為例，Key Accounts（KA）總是說話最大聲的人，但當面對只有少數幾個 KA 提出某個問題，而大部分的小型客戶都沒提過，這個問題是否就不重要而應該被排到比較低的優先順序呢？

這個問題困擾我的地方在於，不確定「問題規模」的大小。有鑑於使用者除了常常不知道自己要什麼，幫助他們理清問題就是產品團隊的責任！

舉例來說，其中一位電商賣家 KA 每週上新品的數量達 100 件，因此要求最佳化後臺大量新增、上架商品的功能。此時除了確認 KA 本身的使用情境與需求外（包含老闆、小幫手等不同使用者），也可以透過市場研究、競品研究，並針對一般小型賣家發問卷、做訪談，瞭解他們目前的狀況：

– 如何上架商品、誰負責上架

– 是否曾經有需要大量新增的需求、最大量是多少

– 上架商品過程中遇過哪些問題…等等

瞭解「未發聲」的中小型賣家是否也遭遇類似的問題，或是他們未來成長變大的過程中會不會遇到相同問題，來初步判斷這個問題是否值得優先被排期。

案例二：目標優先順序、問題優先順序、解法優先順序

有時候跟使用者聊得太開心，收集到一堆反饋，就會直接落到「該功能/需求被提出的次數」這個最直覺的方法來決定要優先開發什麼功能。

舉例來說，若設立的團隊目標是幫助賣家提升顧客來到電商網站的轉化率，其中一個被放在高優先順序的問題是「許多顧客將商品加入購物車，但沒有完成結帳動作」，針對這個問題做使用者研究後，發現超多顧客提出的反饋是「我其實當時還沒有要買，只是網站沒有那種可以收集我的最愛商品的地方，所以想說先放在購物車裡面之後慢慢挑」。

此時的團隊目標是幫助賣家提升顧客來到電商網站的轉化率。也許顧客此時提出的功能看似需求量很高，但他反映的可能只是產品體驗的問題，比如透過收藏可以滿足？我們要分析的是，使用者從登入、瀏覽、進入詳情頁、加入購物車、下單、付款的整個漏斗中，哪個環節流失最大，做針對性的最佳化。

但同樣這個問題對於負責產品體驗的團隊來說，可能就是優先順序最高的事，因為你們的目標不同，要提升的核心指標不同。

七、綜合量化的排序架構

在團隊眾多的產品公司裡面，對於資源安排的方式更是斤斤計較，因此能夠用更有架構的方式，甚至量化的數字來比較，會更有說服力。

分析一些我曾經使用過的方法：

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

寫在最後

前面說了很多理想美好的排定優先及方式，但產品線上發生的 BUG 永遠是第一優先要處理的，因此在面對線上功能出問題的情況，也可以制定出一套處理流程和標準。

以電商產品舉例，與註冊、登入、購物車結帳、錢高度相關的地方出問題絕對是 P0等級，需要馬上被解決，這時候什麼團隊目標就放在一旁，先把最最核心的產品功能修好才是至關重要的。

1. 保持決策的一致性

優先順序會不斷的變動，高優需求插入也難免會產生，有一套一致的邏輯與決策方式來說服設計與工程團隊內部、以及與外部業務部門溝通，可以幫助產品經理增進溝通效率。重點不只是方法，更是挑選這個排序方法背後的原因。

2. 從使用者反饋與測試中來調整優先順序

如同前面風險測試提到的，將每次要驗證的問題切小，快速迭代和收集反饋來重新調整優先順序，對於資源的安排會更有彈性。

更重要的是，優先順序的重點不只在於順序，更在於資源的運用，如果能夠因此用市場反饋說服老闆直接「增加資源」，很多事情似乎就更好解決了！

就聊這麼多。

作者：駱齊；公眾號：產品經理駱齊

本文由 @產品經理駱齊 原創釋出於人人都是產品經理，未經許可，禁止轉載。

題圖來自Unsplash，基於CC0協議。

該文觀點僅代表作者本人，人人都是產品經理平臺僅提供資訊儲存空間服務。

TAG: 優先順序使用者功能問題團隊