本文將從投入產出比，成功率，其他因素等三個方面討論如何進行項目Prioritization。
一、考慮價值/成本
當我們進行項目prioritization的時候，一般來說是希望找到投入產出比最高的項目先做。
1. 項目價值衡量
那我們如何衡量各個項目的價值呢？我認為，能幫助團隊實現目標的項目就是有更高價值的項目。
第一步：只做產品戰略相關的項目
團隊每年都需要定義和重新審視產品的戰略目標，製定產品策略。策略不僅是要做什麼，更是不要做什麼。
一個團隊的精力一定是有限的，時間有限的情況下，不可能在相關領域全都做的非常好；這個策略目標的取捨需要定義清楚，才可以作為後期項目取捨的準繩。
Tips：
一個項目可以對幾個戰略目標都有幫助，也可以只對一個戰略目標有幫助。
可以設置戰略目標的權重（weight），也可以長期給特定目標有限的時間/資源；比如說，每個季度10%的時間可以用來debug，20%的時間用來團隊內部流程/工具建設。
有時也需要計算某段時間內roamap裡的項目對各個戰略目標的總實現程度，不然可能項目全都只實現某一個戰略目標，發展不均衡，短板太明顯。
有時也會將戰略簡化為一個關鍵指標（北極星指標）。
產品策略受公司發展階段影響，但具體這裡不討論。
第二步，考察項目對戰略目標的滿足度
決策選項決定決策的上限。要做出好的決策需要有足夠多的好的選項；所以，確定戰略以後，需要有一定的時間對能達到戰略目標的項目進行探索，再對探索出的可行方案進行優先級排序。
這裡只討論排序，默認項目前期發散已經做過。
達成同一個戰略目標的項目可以有非常多，但哪一個是目前看來最有效果的呢？
不同的項目類型有不同的衡量方式。
1）產品設計項目的價值
產品設計項目的價值可以通過以下metrics判斷：
Framework 1
常用於衡量某個新功能對用戶行為的影響。
Reach：能觸達哪些人。Number：人數數量有多少： 當前一個client還是所有clients？這個client裡的所有人還是一部分人？Quality：這些人是哪個群體（比如現有customer還是prospects，是kol嗎）？這個群體對於現階段的產品有多重要？
Impact：對觸達的人群能帶來多大影響。Breadth：被觸達的人有多少作出反饋。Depth：反饋行動有多強烈，對目標/戰略的實現度有多高。Persistence：反饋行動持續多長時間。
Framework 2
常用於衡量提昇現有用戶體驗的項目。比如說，現在有一批bug（眾所周知bug是修不完的），那先修哪些呢？
Frequency：這個問題會出現在多少人的產品使用體驗中？
Impact：這個問題會多大程度上影響用戶完成任務？影響的是主任務嗎？
Persistency：這個問題是出現一次以後用戶就知道如何解決問題了嗎，還是每一次出現都給用戶帶來困擾？
2）團隊流程/工具項目的價值
我入職以來就做了不少團隊development的項目，比如說design system, data tracking, set retrospective meeting, backlog building之類的。
但我有時候就會想，對於一個startup來說，這些基礎設施建設到哪個程度是Sweet Spot？我的時間花在產品項目上會不會對整個公司來說更有價值？將這類項目的價值量化，和產品類項目拉通排序，就可以解決這個問題了。
團隊流程/工具項目的價值可以這樣衡量：
幫助團隊高效地做事：
Breadth：現在做了這件事，整個團隊將在哪些方面提昇效率？
Depth：一年能省下多少時間？
Scalability：隨著團隊壯大，這件事情的價值又會如何變化？
幫助團隊做出正確決定/做正確的事：
Breadth：這個項目能幫助進行哪些決策？這些決策發生多少次？這些決策都有多重要？（比如說產品早期可能找到PMF很重要，那能幫助identify產品PMF的工具/流程就很重要，提高UX的項目就可以緩緩。）
Depth：不同類型的決策的成功率將如何提高？
3）對Sales的價值
作為B端SaaS產品，是要賣的呀。大家都知道B端的客戶和用戶是分開的，那這個功能對用戶的價值和是否能提高客戶的購買慾望是不同的兩件事。
Reach：能為哪些客戶帶來價值？客戶的體量多大？是否是典型客戶？
Impact：對客戶的影響流程優化類：現在Sales funnel 的主要問題集中在哪裡？這個功能能多大程度提高Sales funnel轉化率？新增功能類：客戶願意出多少錢來買這個功能？（可以自行估計）如果今天不做這個功能，我們將失去多少客戶，多少收入？
項目的價值可以用公式計算出來。
當我們需要在不同類型的項目進行選擇時，需要將他們拉到同一個水平線再進行對比，如何設置這個水平線依然取決於第一部分說到的各目標的權重分配。
2. 項目成本衡量
在定義清楚項目價值後，我們還需要估算，上線這個項目需要多少精力？
工作量的估算單位可以以人/月，人/sprint，小時，人/天 為單位。
需要估算團隊的所有成員（產品，設計和工程）的總時間。
當團隊某個工種（產品/設計/開發）的時間緊張的時候，可以將該工種需要的時間分開計算。
在讓團隊開始估算之前，可以先根據MoSCoW的框架分解項目任務。這將有效幫助團隊成員理解項目具體要做什麼，以及更高效準確的估算任務量。
二、考慮成功率
對於簡單可預測的項目來說，上面的價值/成本衡量已經能很好地解決優先級問題；但有時項目價值很難預期，我們希望加入成功率的因素考慮。
1）項目背後的假設
這是我們需要考慮項目成功背後關於用戶需求，關於市場反應的核心假設是什麼，比如說“用戶在平台的核心訴求是找到能幫他們解決工作上的問題的人。”
這個假設非常重要，最好在項目開發前就明確清楚，並時刻關注項目結果以判斷這個假設知否正確，以後是否可以複用。
2）假設成功的概率
這個假設是否經過驗證？是否有數據支持？成功率是多少？
如果成功率比較低，現階段是否需要進行進一步驗證再進行下去？還能進一步驗證嗎？
這個項目是否值得冒險？冒險的成本是什麼？機會成本又是什麼？
三、考慮其他因素
1）Dependency
這個項目和其他項目是否有關系？
他們是否形成飛輪/閉環？是否互相增強？是否1+1>2?
某項目是否是另一項目的前提條件？
一起做是否能大幅降低成本？
2）Scalability
這個項目裡建設的系統能力是否可複用？
做成可複用組件的成本是多少？以後來做會不會更合適？
3）Risk
這個項目有什麼法律，政策方面的風險嗎？
如果項目失敗，是否會造成嚴重後果？
4）Unpredictability
這個項目中是否有不可控的，變數很大的部分？變數的range有多大？最壞結果是什麼？
可以留出一些機動時間給最新遇到的問題（需要滅火的地方，比如現有大客戶提出的維護需求）
需要注意的是，以上metrics顆粒度非常細。能相對精確地衡量項目價值的同時也需要付出更多時間進行判斷。大家按需取用就好。
四、Prioritization公式
在對項目價值，風險，其他補充信息進行思考後，我們又將如何進行最後一步的prioritization呢？相信大部分小夥伴看了分析已經知道怎麼寫公式了。
這裡可以放上我在使用的公式：
Value = (Sales Value + User Value + Team Value + Other Values)*Confidence*Urgency/Effort
Sales Value = “Sales Value” * 2
User Value = Sqrt( “User Reached” * “User Impact” )
Team Value = “Team Time Saved” + “Helps to Do the Right Thing”
Urgency = “Urgency”/2 + 1
Effort = (“Product/Design effort” + “Development Effort”)/2
公式中的常數，比如2，1等都可以根據自己產品的情況修改。
帶引號的數值為輸入數值。
至於每個要素，比如“Sales Value”如何定義，大家可以繼續細化為公式，也可以考慮上main列出的sale value要點後心算，最後直接給出數值。
本文將從投入產出比，成功率，其他因素等三個方面討論如何進行項目Prioritization。
一、考慮價值/成本
當我們進行項目prioritization的時候，一般來說是希望找到投入產出比最高的項目先做。
1. 項目價值衡量
那我們如何衡量各個項目的價值呢？我認為，能幫助團隊實現目標的項目就是有更高價值的項目。
第一步：只做產品戰略相關的項目
團隊每年都需要定義和重新審視產品的戰略目標，製定產品策略。策略不僅是要做什麼，更是不要做什麼。
一個團隊的精力一定是有限的，時間有限的情況下，不可能在相關領域全都做的非常好；這個策略目標的取捨需要定義清楚，才可以作為後期項目取捨的準繩。
Tips：
一個項目可以對幾個戰略目標都有幫助，也可以只對一個戰略目標有幫助。
可以設置戰略目標的權重（weight），也可以長期給特定目標有限的時間/資源；比如說，每個季度10%的時間可以用來debug，20%的時間用來團隊內部流程/工具建設。
有時也需要計算某段時間內roamap裡的項目對各個戰略目標的總實現程度，不然可能項目全都只實現某一個戰略目標，發展不均衡，短板太明顯。
有時也會將戰略簡化為一個關鍵指標（北極星指標）。
產品策略受公司發展階段影響，但具體這裡不討論。
第二步，考察項目對戰略目標的滿足度
決策選項決定決策的上限。要做出好的決策需要有足夠多的好的選項；所以，確定戰略以後，需要有一定的時間對能達到戰略目標的項目進行探索，再對探索出的可行方案進行優先級排序。
這裡只討論排序，默認項目前期發散已經做過。
達成同一個戰略目標的項目可以有非常多，但哪一個是目前看來最有效果的呢？
不同的項目類型有不同的衡量方式。
1）產品設計項目的價值
產品設計項目的價值可以通過以下metrics判斷：
Framework 1
常用於衡量某個新功能對用戶行為的影響。
Reach：能觸達哪些人。Number：人數數量有多少： 當前一個client還是所有clients？這個client裡的所有人還是一部分人？Quality：這些人是哪個群體（比如現有customer還是prospects，是kol嗎）？這個群體對於現階段的產品有多重要？
Impact：對觸達的人群能帶來多大影響。Breadth：被觸達的人有多少作出反饋。Depth：反饋行動有多強烈，對目標/戰略的實現度有多高。Persistence：反饋行動持續多長時間。
Framework 2
常用於衡量提昇現有用戶體驗的項目。比如說，現在有一批bug（眾所周知bug是修不完的），那先修哪些呢？
Frequency：這個問題會出現在多少人的產品使用體驗中？
Impact：這個問題會多大程度上影響用戶完成任務？影響的是主任務嗎？
Persistency：這個問題是出現一次以後用戶就知道如何解決問題了嗎，還是每一次出現都給用戶帶來困擾？
2）團隊流程/工具項目的價值
我入職以來就做了不少團隊development的項目，比如說design system, data tracking, set retrospective meeting, backlog building之類的。
但我有時候就會想，對於一個startup來說，這些基礎設施建設到哪個程度是Sweet Spot？我的時間花在產品項目上會不會對整個公司來說更有價值？將這類項目的價值量化，和產品類項目拉通排序，就可以解決這個問題了。
團隊流程/工具項目的價值可以這樣衡量：
幫助團隊高效地做事：
Breadth：現在做了這件事，整個團隊將在哪些方面提昇效率？
Depth：一年能省下多少時間？
Scalability：隨著團隊壯大，這件事情的價值又會如何變化？
幫助團隊做出正確決定/做正確的事：
Breadth：這個項目能幫助進行哪些決策？這些決策發生多少次？這些決策都有多重要？（比如說產品早期可能找到PMF很重要，那能幫助identify產品PMF的工具/流程就很重要，提高UX的項目就可以緩緩。）
Depth：不同類型的決策的成功率將如何提高？
3）對Sales的價值
作為B端SaaS產品，是要賣的呀。大家都知道B端的客戶和用戶是分開的，那這個功能對用戶的價值和是否能提高客戶的購買慾望是不同的兩件事。
Reach：能為哪些客戶帶來價值？客戶的體量多大？是否是典型客戶？
Impact：對客戶的影響流程優化類：現在Sales funnel 的主要問題集中在哪裡？這個功能能多大程度提高Sales funnel轉化率？新增功能類：客戶願意出多少錢來買這個功能？（可以自行估計）如果今天不做這個功能，我們將失去多少客戶，多少收入？
Tips：
項目的價值可以用公式計算出來。
當我們需要在不同類型的項目進行選擇時，需要將他們拉到同一個水平線再進行對比，如何設置這個水平線依然取決於第一部分說到的各目標的權重分配。
2. 項目成本衡量
在定義清楚項目價值後，我們還需要估算，上線這個項目需要多少精力？
Tips：
工作量的估算單位可以以人/月，人/sprint，小時，人/天 為單位。
需要估算團隊的所有成員（產品，設計和工程）的總時間。
當團隊某個工種（產品/設計/開發）的時間緊張的時候，可以將該工種需要的時間分開計算。
在讓團隊開始估算之前，可以先根據MoSCoW的框架分解項目任務。這將有效幫助團隊成員理解項目具體要做什麼，以及更高效準確的估算任務量。
二、考慮成功率
對於簡單可預測的項目來說，上面的價值/成本衡量已經能很好地解決優先級問題；但有時項目價值很難預期，我們希望加入成功率的因素考慮。
1）項目背後的假設
這是我們需要考慮項目成功背後關於用戶需求，關於市場反應的核心假設是什麼，比如說“用戶在平台的核心訴求是找到能幫他們解決工作上的問題的人。”
這個假設非常重要，最好在項目開發前就明確清楚，並時刻關注項目結果以判斷這個假設知否正確，以後是否可以複用。
2）假設成功的概率
這個假設是否經過驗證？是否有數據支持？成功率是多少？
如果成功率比較低，現階段是否需要進行進一步驗證再進行下去？還能進一步驗證嗎？
這個項目是否值得冒險？冒險的成本是什麼？機會成本又是什麼？
三、考慮其他因素
1）Dependency
這個項目和其他項目是否有關系？
他們是否形成飛輪/閉環？是否互相增強？是否1+1>2?
某項目是否是另一項目的前提條件？
一起做是否能大幅降低成本？
2）Scalability
這個項目裡建設的系統能力是否可複用？
做成可複用組件的成本是多少？以後來做會不會更合適？
3）Risk
這個項目有什麼法律，政策方面的風險嗎？
如果項目失敗，是否會造成嚴重後果？
4）Unpredictability
這個項目中是否有不可控的，變數很大的部分？變數的range有多大？最壞結果是什麼？
可以留出一些機動時間給最新遇到的問題（需要滅火的地方，比如現有大客戶提出的維護需求）
需要注意的是，以上metrics顆粒度非常細。能相對精確地衡量項目價值的同時也需要付出更多時間進行判斷。大家按需取用就好。
四、Prioritization公式
在對項目價值，風險，其他補充信息進行思考後，我們又將如何進行最後一步的prioritization呢？相信大部分小夥伴看了分析已經知道怎麼寫公式了。
這裡可以放上我在使用的公式：
Value = (Sales Value + User Value + Team Value + Other Values)*Confidence*Urgency/Effort
Sales Value = “Sales Value” * 2
User Value = Sqrt( “User Reached” * “User Impact” )
Team Value = “Team Time Saved” + “Helps to Do the Right Thing”
Urgency = “Urgency”/2 + 1
Effort = (“Product/Design effort” + “Development Effort”)/2
Tips：
公式中的常數，比如2，1等都可以根據自己產品的情況修改。
帶引號的數值為輸入數值。
至於每個要素，比如“Sales Value”如何定義，大家可以繼續細化為公式，也可以考慮上main列出的sale value要點後心算，最後直接給出數值。