本文作者闡述了其在事件中認為比較有效的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 協議。

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