產品實戰中，如何聰明地解決需求排期問題
本篇主要幫助大家梳理下產品開發中所有能影響需求排期的因素，爲大家提供一個個人的分析框架。enjoy~
關於產品需求優先級的排期目前常用的模型有很多，比如KANO模型，重要緊急模型等等。但這些模型一旦在實際產品開發中應用，就可能遇到很多問題。因爲這些模型，只考慮了模型中的因素，還有很多影響因素在模型中並沒有體現。
然而在真實世界裏，這些其他因素正是會導致需求排期複雜的罪魁禍首。過度依賴簡化的模型，往往並不能良好的解決產品開發中的優先級排序問題。
所以本篇主要幫助大家梳理下產品開發中所有能影響需求排期的因素，爲大家提供一個個人的分析框架。
價值（Value）
公司、老闆價值（Value of the Company/Boss）
不同公司的產品的價值觀差異，比如有的公司，比起極致的產品用戶體驗，更看重的是產品的ARPU（Average Revenue Per User），如何從每個用戶身上賺多少錢，纔是他們最關心的。而另一些公司可能相對與ROI（Return of Investment），對用戶體驗會極其看中，這些公司相信，只要用戶體驗得好，收益問題並不是太大的問題。
不同階段的公司對產品的價值觀差異，比如：很多創業公司早期更多會關注能夠幫助實現用戶快速增長的需求和功能，到了成熟後纔會更多考慮幫助產品變現的功能和需求。
不同Leader或老闆產品價值觀差異，可能會有一些小夥伴也遇到過換了Leader，或Boss後產品價值觀大變樣的情況。例如：以前的Leader天天強調要用戶體驗優先，換了人之後就變成了更關注用戶增長，不相關的需求一律可以稍後考慮的情況。
所以一個合格的產品經理考慮需求時，第一步是考慮內需，及公司目前現階段更看重的是什麼。哪些需求能更好的滿足當前公司的價值觀，以及leader或boss的（如果有）。
用戶價值（Value of Customers）
不同用戶對不同產品的核心需求會有很大的差異，比如：工具型產品的用戶更關注的是效率，如果你是Uber用戶，你更關心的一定是能多快的叫到車，價格是不是合理，而UI方面可能並不太在意。但如果是一個社交APP，用戶可能更多關心的這個APP設計的酷不酷，能不能彰顯自己的特別，吸引到更多的人關注自己。
需求排期時要抓住目標用戶的核心需求或者痛點優先做，其他的癢點非核心都可以後需考慮。
很多時候，公司的價值會與用戶的價值有所衝突，比如：公司爲了賺更多錢在產品上投放了大量廣告，但這就會降低用戶體驗損害用戶利益。產品經理這時候就應當想辦法平衡這兩方面的需求，爲了解決這樣的衝突提出新的解決方案。
當然有些公司的產品核心價值觀就是給用戶提供最大的價值，這個時候公司的價值就和用戶價值重合，不再存在任何衝突。這時產品經理也是比較好做的，只需要全心全意考慮如何給用戶提供最大的價值即可。
影響力（Impact）
衡量一個需求或功能的優先級還需關注它的影響力，考察需求的影響力用產品數據做指標最爲直觀。
廣度
需求的影響廣度是衡量優先級的一個重要因素，可以根據需求的期望日活率作爲一個衡量指標。這個功能上線後會有多少用戶會使用到，期望使用的人越多自然優先級就更高。
深度
用戶影響深度：是否影響到核心用戶，還是隻影響到一般用戶。
功能影響深度的：功能是否爲核心功能或者前置功能，核心功能是解決用戶最核心痛點的功能。前置功能是整個用戶體驗流程的前置功能，比如：登錄，商品加入購物車。前置功能如果不完成或者有問題會直接導致流程無法走通。
性價比與風險（Cost Efficiency and Risk）
收益
衡量一個需求的收益可以從以下2個角度去考慮
- 做這個功能能帶來的期望收益（P），比如：多少的7日用戶留存的提高，多少用戶增長。
- 不做這個功能的期望損失（L），比如：不做這個需求，可能會有15%用戶流失到競爭對手產品上。
成本（C）
衡量一個功能的成本可以從開發時間，開發人力，開發費用來考慮。
風險（R：0——1）
風險是一個很重要但是容易被忽略的因素，尤其體量大的產品在上線新功能時一定要考慮到可能產生的負面效果。一般解決風險因素的方案是A/B Test， 國內叫灰度發佈，但A/B Test也需要成本，和時間，所以風險較大又收益不高的需求排期會後推。
如果我們用公式來表示成本，收益，風險這幾個指標。用P（Profit）代表做這個功能的期望收益。用L（Lost）代表不做這個功能的損失，L爲負值。C（Cost）表示開發所需成本。R（Risk）表示功能上線後風險，R的值爲0—1，風險越大越趨近與1。則我們可以得出一個公式：
計算得出的X越大，優先級越高。當然實際應用時還要考慮到影響力，和價值這兩點因素。
總結
在產品需求排期時要從三個大方面考慮：價值；影響力；性價比與風險。
最後以一張腦圖來總結以上的一些觀點。歡迎大家留言，交流下對此問題的看法~
本文由 @ RyanT 原創發佈於人人都是產品經理。未經許可，禁止轉載
題圖來自Unsplash，基於CC0協議
