這系列文章的命題是：當把產品做完後，不管是已改版多次還是 MVP，只要是產品，永遠有變得更好、持續進步的空間，但要如何改善呢？該從哪裡下手呢？
以下整理了一個概略的產品優化流程，會在接下來的文章中細講每個步驟。
經過前三個步驟，現在終於把意見都聚焦為產品需求，也找到要透過哪些指標來驗證這些需求是否真正能解決問題。
但一整理完發現：需求清單有夠長……偏偏人力、時間都有限，怎麼可能做得完？這時，優先級排序（prioritization）就是非常重要的產品管理技能（之一）了！
為什麼需要排序？
時間有限、人力有限，想改的東西、想做的需求卻總是源源不絕。而且每個人都說自己的東西最緊急、最重要，到底該先做誰的？
最常見的排序方式就是象限圖，X 軸是緊急或重要程度（商業價值、影響範圍），Y 軸則是複雜程度或執行難易度（開發成本）。
於是會區分出 4 個象限：重要但困難、不重要又困難、不重要但簡單、重要又簡單。
這個對應出的結果有點像是 CP 值，「重要又簡單」的代表 CP 值很高，可以用很少的時間或人力成本搞定重要的問題；反之，「不重要又困難」代表的是得花許多資源處理不重要的事情，CP 值顯然較低。
怎麼定義上述的「重要程度」？
正常情況下，會先處理 CP 值最高的需求，這時有人可能會問：但什麼需求才被稱為「重要」？這就是前面提到的「目標」與「指標」的重要性。
不論是產品、團隊還是公司，「訂好核心目標」是非常重要的事，一來可以確定團隊是否有往想要的方向前進，二來就是在這種需要排序或取捨的情境時，可以藉此分辨輕重緩急。
如果公司沒有明確或統一的目標，便很容易出現各部門目標不同，甚至相悖的情況。
比如行銷部門想要衝 app 下載數，但產品部門想要提升用戶留存度，這兩個目標不見得相斥，但對應的做法明顯不同。如果想提升用戶留存度，行銷部門應該是著重於既有用戶的喚醒或經營；如果想衝 app 下載數，則需要產品部門改動 app strore 或 google play 內的一些資訊，藉此經營 ASO。
💡 如果還是覺得很難拿捏所謂的「重要程度」，也可以從「產品成果」（老闆或利益關係人對於這個產品的期待、他們想使用 / 將會使用 / 需要使用產品的哪些功能）回推，藉此弄清楚對這些人而言，哪些功能是他們所定義的「重要」。或者，也可以從「使用情境」 盤點，大多數用戶需要哪些功能？哪些功能即使沒有也不會影響操作？哪些功能是一旦沒做，就會影響用戶的使用流程？
怎麼定義上述的「複雜程度」？
一個產品需求的複雜度，通常需要由設計師與工程師一起衡量，畢竟 PM 只是開需求與規格，真正在畫圖與寫程式的並不是 PM。
要衡量複雜程度時，通常會有 2 種方式：
1.相對值
比如總共有 5 個需求需要排序，PM 雖然不知道這些需求各自實際上要花多少幾天才能做完，但隨著經驗累積，通常至少能知道這幾個需求的複雜度，比如「在網站內新增深色模式」跟「在首頁新增一行公告文字」，前者的複雜度顯然比較高。
又或者「在頁面上新增一個『馬上購買』按鈕」跟「在結帳流程中，新增 paypal 的付款方式」，後者的複雜度較高，而且前者通常只需要前端工程師做，後者需要前後端一起處理。
如果真的不確定，也可以先提供一些背景資訊和粗略的想法，讓工程師稍微估算複雜度或工時。如果資訊不足，則可以再補上簡單的手稿或網路上找到的示意圖，方便工程師具體地估算。
2. 絕對值
一般來說，都會先等設計師完稿後，才請工程師估時，因為有了具體的畫面後，估算會更為準確（尤其對於前端）。
然而，有時因為工程資源得和其他專案共用，需要明確卡一個時段來做這個需求，做完後就得去做其他專案，PM 在排序時就得知道預計工時，那就得請工程師先估時了。
💡 不過，在這個階段時，PM 跟設計師還沒確認好整個改動幅度與畫面，許多細節可能也還沒有考量到，所以提供的資訊不會太周全，也可能影響到估時的精準度。這個是 PM 可以先提前預告的，以免實際執行時的工時跟預估差太多，到時就很難交代啦。
結語
將所有需求排序後，就可以篩選出要先做哪些了。但實際執行時，還是會因為需求端的「死線精確度」而有點差異。
以我的現職公司為例，所在部門負責的是全公司的內部工具，而我負責的產品線之一是考績系統。公司打考績有固定時間，比如 1/1~1/31 主管要進入系統開始寫評語，那各種需求就得在 1/1 之前完成，這樣主管才有新功能可以用。
在這種「有明確死線的產品」的情況下，就得確認哪些需求非在 1/1 之前完成不可，並且得在死線前想辦法完成。
但相對地，我手上的另一個產品是公司的目標訂定系統，它的使用期間就比較彈性。雖然大部分的團隊都是以「季」為單位在訂目標，但因為相關制度還在試行，所以沒有明確要大家去訂目標的時間點。也因為這樣，這套系統的功能的優化期限也不會太緊，主管可能只會說「Q2（4~6 月）完成就好」，那有機會能處理那些在定義優先順序時，被放到「沒那麼重要」的需求了。
💡 不過，即使時間充裕，PM 仍然要有排序的概念，並且要跟團隊建立共識，請團隊依照輕重緩急處理需求，重要的需求完成後（不需等其他較不重要的完成），就可以先推上線了！若時間足夠，再去做不重要的需求。
總之，這篇試圖整理 PM 如何判斷優先順序，但一定很多 PM 在整理各種需求、綜合排序時，仍會覺得「每個東西都好重要、每個需求都很急」，尤其許多需求端 / 利益關係人也會施壓「我的東西最緊急」，這時還是一句老話：不論是對於產品、團隊還是公司，「訂好核心目標」非常、非常、非常重要。
這個目標通常就是 PM 在做判斷的最高準則，當團隊成員意見不同時，這也很可能成為 PM 的「擋箭牌」，讓大家知道這些決策並非是 PM 或任何人的主觀意識或一意孤行，而是大家本來就該有的共識。
所以，如果 PM 在排序時真的遇到困難，不如先回頭看看最初的目標是什麼；如果沒有目標，那應該先把它找出來，畢竟這是打造出每個團隊 / 產品最重要的基礎元素。
