起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識B端從入門到進階：常用需求優先級評估模型
本文作者闡述了其在事件中認為比較有效的3種排序模型，以及適用的場景。另外也對需求評估的目標以及拒絕需求的個人實戰經驗，做了一些分享。相信對各位B端新人能夠帶來幫助，歡迎閱讀。
B 端產品的需求來源通常有老板、管理層、市場、銷售、法務、財務、一線業務、技術團隊內部、用戶反饋、市場調研等渠道。
據某上市企業產品總監反饋，當前中國的 SaaS 產品中能消耗掉來自各個渠道 30% 的需求就達到了優秀的水準。
本文將從需求優先級常用方法論、評估的目標以及拒絕需求的個人實戰經驗，做一些分享。
01 需求評估方法論的適用場景
總的來說，筆者的實踐中比較有效的排序模型按場景分三種，在此拋磚引玉：
- 戰略級需求規劃：用戶價值 = 新體驗 – 舊體驗 – 替換成本
- 日常需求排序：RICE 模型，觸達、影響、信心、努力，可根據業務情況靈活調整
- 需求顆粒度選擇：KANO 模型，充分考慮對用戶的滿足程度
△ 需求評估模型的適用場景
一、用戶體驗 = 新體驗 – 舊體驗 – 替換成本
用戶價值 = 新體驗 – 舊體驗 – 替換成本，筆者認為在重大決策時可以作為產品第一參考原則。
例如在進入新型的市場或者新的方向時，限于企業的資源有限性，產品決策點在于“應該選擇圍繞成熟優勢去拓展業務，還是應該選擇新產品、新方向呢？”
按照這一理論的解釋，如果潛在市場的需求量比較大并且有看到新的要素，導致未來的市場是成長型的市場，那么企業有沒有優勢都不重要，策略上應該著重提高市場滲透率，將先發優勢變成企業最大的優勢，占領“定義新體驗”的卡點。
《創新者的窘境》一書也對此有所說明（點擊可查看我的讀書筆記），企業優先進入某一新興市場的市場份額，可能是后進者的6倍。
如下圖所示，確定業務方向后，在需求排期時也就有了更加清晰的理論基礎：有助于提升新體驗，提供了新的要素（新技術、新人群、新渠道、新方法、新工具），精確客群定位、降低用戶流失率、降低替換成本的事項就是需求優先排序的“直通車”。
△ 信息源于《俞軍產品方法論》，整理人：RaRa
以替換成本為例，某電商SaaS平臺基本沒有開放免費的商品搬家功能，而是將此服務開放給了第三方，例如螞蟻搬家，或者收取定制服務費。
這可能是出于打造平臺生態或者平衡商業價值的最終結果，但無形中抬高了替換成本。
筆者遇到過某甲方企業如果借助這類平臺開發新的銷售渠道，首要面對的就是海量商品遷移的問題，接下來就會繞進這些坑：
- 找第三方吧，指定了可搬家的綜合電商平臺，不接受內研系統搬家
- 找平臺吧，收取萬元級別的的定制服務費
- 有自研能力的企業，倒是可以選擇api對接，接口收費價格倒是可以接受，但是不付費定制是沒有任何服務的，api的通用性、文檔邏輯、數據調取范圍、對接模式，對雙方都是一種挑戰
用戶能順利從其他平臺切換到新的平臺，必定是新平臺的用戶價值 > 本平臺體驗 – 舊平臺體驗 – 替換成本，而商品遷移的體驗做的不夠好，遷移成本過高，用戶會再三考量是否有必要繼續。
如果你是負責跨系統數據同步的產品，就需要在商業價值與用戶價值之間做權衡。這種情形下，要如何定義跨系統數據互通需求的優先級呢？大家可以在評論區聊一聊~
當然，需求的排序不是簡單的加減法就可以完成的，這一理論只是主觀價值判斷的輔助工具，比如在政府政策的指導下、行業壟斷下，這一規則就失去了適用性，需要靈活處理。
用戶價值理論只是提供了決策的思路，提升個人預測的準確性和決策的質量。
俞軍老師的用戶價值理論很適用于 C 端產品，在 B 端的應用條件，筆者本人也還在不斷的摸索中。在 B 端戰略性需求的規劃，大方向上還需要考慮：
- 是否符合產品長期規劃
- 是否符合產品定位
- 是否能標準化
這三條可以作為 B 端產品設計的原則。
大多數產品不是死于需求做的太少，而是做的太多，超出了產品的邊界越做越臃腫，迭代困難。
需求的規劃需要從產品的定位著手，打造自己的核心賣點，服務于業務的北極星指標。也需要通過標準化設計攤平研發成本，低成本服務更多的用戶。
下文一起來看一下作者作為 B 端產品最常用的需求優先級排序模型：RICE 模型。
二、RICE 模型
RICE 模型的出處難以求證，百度搜索關鍵詞，大家可以看到長期排在榜首的就是知乎的一篇海外的譯文。
筆者開始使用這一模型，也是受這篇文章啟發，結合自己的項目情況做了一些調整。
R（Reach），觸達：
筆者將觸達分為了觸達的用戶數、頻次，兩者相乘得到觸達的綜合得分（具體參數和規則說明見截圖）。
I（Influence），影響：
影響力分為技術、管理、商業方面的影響，好的需求能帶來的影響是多方面的，所以權重可以疊加，也可以根據企業所處的階段調整權重值。
例如在業務合規階段的企業，風險控制因素大于其他一切因素，可賦予高權重值；例如信息系統優化階段，產品力因素又要高于經濟價值的追求等，需要在項目中靈活調整。
C（Confidence），信心：
“這個需求我說了算，怎么實現我不管，明天上線”，雖然是一句調侃的話，但是在魚龍混雜的需求中，難免會存在創意性的想法需要驗證后才有量化指標的狀況產品。
筆者會對這類主觀性的需求設置信心度指標，提醒自己多辯證思考，接納批判性的聲音，規避決策偏誤。
而且后續會根據最終上線的結果，驗證此類需求的提出人是否足夠可靠（證偽），成為下次此人提出此類需求的參考指標。
看一個是否靠譜，要看他做成了什么事情，做成功的幾率有多高。一個長期判斷失誤的人是不值得信任的。
E（Effort），努力：
努力按照預估的人工量化，是一項負面指標，因為我們總是希望用最少的時間做最有價值的事情，特別是需求還在價值分析階段，并未得到真實驗證的情況下，B端也講求MVP，或者說最小場景閉環。
△筆者的常用需求排序模型
需求的最終目標都是響應企業戰略規劃獲得商業利潤，決策人因為其掌握的資源、視野不同，提出的需求分量也不同。
若量化這一指標，可以考慮設置決策人權重，排序按照老板 > 管理層 > 客戶 > 一線業務設置，畢竟B端產品的推廣運營有由上自下的特性，老板和管理層也很大程度上決定了產品的價值評估。
需求不閉環，是不少初階產品容易忽略的事情。有了調研、評估、開發，但是缺少了上線結果的觀察和復盤。筆者有習慣針對每個需求點分析上線結果，若二次迭代，本次的評估打分和最終結果就是下一次評估的參考。
△ 筆者的常用需求排序模型
關于這一套模型，筆者在團隊內部做過培訓分享，有小伙伴問，你真的會用這么復雜的模型來評估需求嗎？國外的這些東西，套用到國內有些不適用性吧？業務他們認可這一套嗎？
是否有必要，大家可以用需求分析過中的批判性思考、需求的有效性、最終產出價值來驗證。不適用也很正常，沒有一套準則能放之四海而皆準。
理論都是有使用限制條件和前置條件的影響，也有或多或少的干擾因素。它存在的價值在于提供了結構化的思考方式，幫助自己盡量規避主觀決策的局限性和決策偏誤。
三、KANO模型
網上有很多寫 KANO 模型（基本型、期望型、興奮型、無差異型、反向型）的文章，都分析的很好，但是對于B端產品而言，此模型的局限性也比較大，例如：
- 適用于測試用戶對新功能的接受程度，在 C 端通過需要通過專業的調研工具打分評定
- 僅評估了用戶價值，沒有評估商業價值
俞軍老師將產品效用對用戶需求的滿足程度劃分為：底線需求（不能低于）、夠用就好（不用高于）、越多越好（愿意多支付）、驚喜（超過驚喜或參照系），兩者有相通之處。筆者在日常工作中，遇到功能的顆粒度問題需要決策時，會用到此模型。
例如在一次跨系統批量數據同步時，在同步數據的顆粒度和交互細節上，大家產生了不同的看法：批量同步數據，要通過隊列傳輸成功就存儲，還是等到批量任務執行完畢之后，通過校驗再統一存儲。
△ 跨系統批量數據同步的顆粒度問題
從商業價值上來說，這兩者并不會產生什么差異，但是從用戶價值來說，兩個方案的體驗感是不一樣的。
單條存儲適用于小批量數據同步，即同步成功一條存儲一條，失敗后繼續執行下一條。這種同步方式對用戶的及時反饋性高，也無需長時間等待。最終傳輸失敗給出統一報錯，便于用戶排查，對接口響應的要求也不高。
批量存儲適用于大批量數據同步，同步成功后統一存儲。但是同步過程中一旦校驗失敗即停止任務，且信息不會存儲下來，也難以精準報錯，此方案在用戶體驗上的優劣勢顯而易見。
所以這個需求就可以從需要滿足用戶的程度去衡量。
在我司的業務中這是一個高頻操作、多業務角色參與、小批量數據同步的場景，在資源支持到位的情況下，按照期望型需求（夠用就好）的程度去滿足，達到提升數據多系統同步的效率，高可用、易操作的效果即可。
最終我們采用了方案一，這項功能贏得了較好的業務口碑 。
四、四象限原則
四象限原則也是比較常用的排序方式，包含緊急且重要 > 重要不緊急 > 緊急不重要 > 不重要不緊急的規則，使用此原則需要有一套判斷事情是否緊急、是否重要的標準。
筆者也會用四象限原則來規劃日常的工作安排：
緊急且重要的事情需要立刻行動起來；
重要不緊急的事情，可以分解后制定計劃，分步執行；
警惕需要長期做緊急需求的工作。在需求的優先級排序中較少用此抽象模型，本文就不展開啦。
△ 四象限原則
02 需求優先級評估的目標
一、保持個人決策的質量
產品經理是一個非標準化的崗位，特別是對于B端產品而言，很難衡量其價值所在。
而非標的原因在于產品經理的真正關鍵能力，不是能學習的知識（雖然產品經理也需要學習相關知識和技能），而是在實踐中權衡取舍持續迭代以追求價值最大化。
需求優先級的評估建立在嚴謹的行業了解、深度調研、邏輯推理、用戶洞察、數據分析之上，這些行為不代表成功的結果，畢竟產品的成功受大環境、團隊、產品力多重影響，但是能確保產品個人決策的質量維持在比較高的水準。
二、平衡用戶價值與商業價值，確保資源最優配置
很認同純銀的一個觀點，需求池的排序，雖然一定程度上服務于老板的情緒價值，但是老板喜不喜歡你，還是在于產品是否能創造高價值。
好的需求是在用戶價值于商業價值之間取得最優解，單單靠需求池的排序是難以做到的，但是有一套可行的需求評估方式，能樹立產品團隊在業務端的專業形象，有理有據爭取資源支持，從而獲取資源配置和產品團隊決策的自主權，實現收益最大化。
三、管理用戶預期
跨部門溝通是B端產品日常要處理的場景。筆者在需求調研過程中就遇到過各個部門負責人爭論需求優先級的問題，因為各個部門負責人更多的是從自己的業務角度出發，追求局部效益的最大化。
比如一個系統間數據互導的功能，就能讓供應鏈人員的工作時效從1小時降低到2分鐘，如果爭取下來優先開發，就會得到部門員工的感激，哪怕該功能并不會產生直接的經濟收益。
所以遇到多需求渠道的情況下，有一套公開、透明、可靠的需求評估機制，能協調好各方對于需求優先級、上線時間的預期，避免對產品部門產生抱怨、不配合的情緒。當然，產品的滿意度不是由此決定，篇幅原因，話題就不再做延伸。
03 怎么合理拒絕需求？
小白產品從入門的進階的里程碑在于合理的拒絕需求開始，不懂得砍需求的產品經理不是好產品經理。只要符合以下幾個規則，我們就要警惕并拒絕。
1、貫徹5why原則，業務背景不清晰的不做
產品經理要有究竟精神，只有刨根問底找到問題的根源才能定義合適的解決方案。如果業務的背景都不清晰，做出來的需求也是浮于表面，甚至容易弄巧成拙。
找到問題的本質，5why原則是簡單又容易操作的方式，真正的挑戰在于是否能提出合適的問題。
2、投產比得不到認可的需求不做
需求要獲得商業價值或者用戶價值，當價值的產出和實際要投入的成本（ROI）得不到管理層的認可時，就可以有理有據的拒絕掉，想辦法低成本解決問題比埋頭干活更重要。
3、不符合產品定位的需求不做
為核心用戶解決核心問題，打造產品的護城河才是我們的追求，不符合產品定位的需求，一方面會分散研發資源，使團隊偏離企業戰略規劃；另一方面還會讓產品越來越臃腫，維護成本過高，最終落得推到重來的過程。
例如當前產品的定位是解決多渠道訂單高效履約的痛點，SCRM相關的營銷需求就不符合產品定位，需要謹慎決策系統的耦合程度。
4、違反法律的需求不做
這一點就不必多說了，好的產品必定是有效用（滿足用戶價值）、可持續（用戶價值與商業價值統一）、有利潤（企業可獲利）的，缺一不可。
專欄作家
RaRa，公眾號：B 端產品的避坑歲月，人人都是產品經理專欄作家。半路出家、一路摸索的 B 端產品經理，擅長企業級產品架構，長期關注私域電商、供應鏈領域。
本文原創發布于人人都是產品經理。未經許可，禁止轉載。
題圖來自unsplash，基于 CC0 協議。
該文觀點僅代表作者本人，人人都是產品經理平臺僅提供信息存儲空間服務。
- 目前還沒評論，等你發揮！
