"B 端需求決策模型及實踐指導"

需求決策是產品經理的最基本也是最重要的工作,這部分工作會對後面的工作質量和公司團隊的有重要影響。因此,構建需求決策模型是產品經理的必修課。

本文結構圖:

01 為什麼要構建需求決策模型

需求決策是產品經理的最基本&重要的工作,這部分工作影響了後續成倍的工作量,對團隊工作的質和量都起到杠杠作用,需求決策的正確率影響了團隊/公司的效率及機會。

需求決策在沒有框架指引下,高度依賴產品經理的個人經驗及素質,並且即便是同一個產品經理,面對不同的場景時,其需求決策的質量受限於其經驗和知識背景,也具有一定的不穩定性。

需求決策模型可以將需求決策過程中的影響因子提煉出來,將部分的因子通過產品團隊整理和共同迭代變成固定變量而非依賴個人判斷的可變變量;通過需求決策過程的把控,降低個人決策的不穩定性,提升需求決策的質量;通過需求決策過程中的中間輸出結果整理,也可以讓相關人員或其他產品經理協助識別需求決策過程中可以的判斷錯誤,進而提升需求評審環節時的有效性。

02 B端產品的特點及對需求決策模型的要求

B端產品普遍是付費產品,B端產品需求的決策很可能會直接影響續約或新簽,而部分對用戶有很大價值,但對續約或新簽沒有價值的功能優先級也可能會低。

B端需求決策模型上,公司商業價值影響因素更大,如對續約的影響,對新簽的影響等。而C端產品在剛開始普遍是免費產品,更多的考慮用戶價值,較少的考慮商業價值,而後期即便考慮商業價值,商業價值和需求功能之間的關聯性較B端也是相對弱。

因此一些C端常用的KANO模型、四象限模型可以作為判斷用戶價值的輔助,而不能直接應用於B端需求決策模型;

KANO模型 四象限模型

03 公司業務梳理

基本框架:用故事地圖梳理短期固定變量

B端需求決策前,最重要的是梳理清楚業務邏輯,這裡的業務邏輯包括業務角色、業務場景、業務場景中涉及的功能特性,業務在商業中的價值,以及戰略定位。

這些對於一個公司而言是短期不會變,是需求決策的基礎框架。而這些基礎框架則構成了需求決策過程中的固定變量(短期的固定變量,長期可迭代)。基礎框架影響決策模型,保證整體需求內容不偏離主航道,而不被單點價值影響。用戶故事地圖是很好的梳理業務角色及業務場景,並可以結合業務商業價值及戰略定位的一個實用工具。舉例如下:

用戶故事地圖實踐指導

首先,用戶故事地圖最重要的是梳理清楚業務角色、業務故事(流程)、故事細節,及對應的商業價值和戰略定位。這裡面涉及一些定義,如下:

  • 用戶情緒:業務環節中,用戶情緒越低用戶價值越大(在價值判斷的時候參考,不一定在用戶故事地圖中畫出)
  • 用戶價值:(新體驗價值-舊體驗價值)-替代成本(評估商業價值的時候需要用到)
  • 商業價值:(用戶價值*付費比例)*(付費意願*用戶群數量)
  • 戰略定位:由公司戰略層根據公司定位、戰略、當前發展確定

其次,以季度或年度刷新企業級別的用戶故事地圖,基於市場環節的變化和領導層認知的變化及時刷新用戶故事地圖,理論上B端產品的企業級別用戶地圖一旦確定,短期很少變動,即便變動也更多的是變動“故事細節”;

最後,企業級別的用戶故事地圖在短期對於需求決策模型來講是固定變量,這裡可以減少因不同產品人員能力或認知偏差造成的偏離大方向。企業級別用戶故事地圖中故事的模塊對應的商業價值和戰略定位,作為需求決策表的輸入參數。

04 需求決策影響因素梳理

個人能力:用戶洞察

用戶洞察是對用戶的理解和對用戶場景的理解,這是一個持續加強的部分,比如用戶當前是怎麼解決問題的?是否有其他替代方案?用戶是否會從當前的解決方案中遷移過來?如果不做有什麼不好?

如有興趣可以看下歷史關於“用戶洞察”的文章,對用戶洞察的能力會直接影響主觀判斷部分的準確度,斷產品價值的時候會有偏差【(新體驗-舊體驗)-遷移成本】,這裡可以通過公式的分解,在需求評審環節,其他同學幫忙把關。

其他需求決策的影響因素

需求、需求面向的用戶群、解決的問題、當前用戶的量級、當前用戶頻次、目標用戶的量級、目標用戶頻次、時效性(緊急程度)、前置需求、對用戶實際價值、用戶的可感知價值、開發成本、其他成本、是否影響續費、是否影響新簽、其他商業價值、投入產出比等。

這裡有的因素是比較容易判斷的,也不容易出錯如當前的用戶量,這樣依來產品人員中等水平即可。有的因素比較容易依賴個人經驗、能力判斷,比如用戶可感知價值、商業價值等,這些比較依賴個人經驗、能力判斷的因素也是需求評審過程中的重點,需要產品團隊協作把關。

梳理一個最穩健的需求決策表

需求決策表是將需求評估時涉及的各維度均考慮到,以降低需求設計過程中忽視的因素或存在的漏洞,比如“價值感知度”評估,也可以讓產品設計同學更多的考慮如果讓用戶感知到該功能或特性的價值,以優化產品設計,“其他人力成本”也可以讓在需求評估的時候除了考慮研發成本也考慮到需求上線之後的其他事項,如下:

需求決策表補充說明:

字段補充說明:

  • 用戶可感知價值=用戶實際價值*可感知度
  • 投入產出繫數=(總價值度*用戶量)/總成本,使用投資產品繫數,是因為一個功能(僅是產品的很小一部分)的價值很難直接用錢來衡量,這裡用相對值來替代人民幣的值,用投入產出繫數替代投入產出比
  • 前置需求:前置需求為1不代表不做,前置需求和當前需求如果並行開發,則也可以接納,但不建議;
  • 緊急程度:有的是因為客戶投訴原因緊急,有的是因為配合用戶年度周期性場景緊急,如展會場景;聖誕節祝福場景;因為借助這些場景可以借勢,所以也就相對緊急。

字段底色說明:

  • 橙色底:是來自於用戶故事地圖的固定變量;
  • 黃色底:是相對固定的變量,即不太容易錯的部分,但評審的時候需要關註;
  • 紅色底:是更依賴相關人經驗、能力判斷的部分,也是評審的重點;

應用說明:

  • 可以跟進自己的業務、產品、特性適當調整需求評審表,如增加需求的來源,需求負責人等在評審需求的時候好追蹤;
  • 一次評審的需求不應該過多,當需求過多的時候,不同小團隊應該內部按需求評評審表過濾一遍需求;
  • 需求評審表可以做簡化,但應盡可能的讓強大依賴人的經驗評估的部分變得可拆解;
  • 需求對應的公司級別的/大業務級別的用戶故事地圖是需求評審的基礎框架,保證需求不要偏離主航道,因為雖然有的需求單點投資回報率高,但如果偏離主航道,那麼不利於構建主航道的價值壁壘,當一個需求涉及多個故事模塊的時候可以以商業價值或戰略定位價值高的模塊為準;
  • 需求評審表中生的投資產出繫數、緊急程度、模塊商業價值、模塊戰略價值,構成需求決策模型的4要素,生成需求決策圖;

需求決策表簡化示例

適用於中等需求

適用於小需求

04 需求決策模型

需求決策模型,應該考慮投資回報繫數、緊急程度、所屬模塊的商業價值、所屬模塊的戰略定位,這樣即圍繞了構建企業長期壁壘為中心的框架內,基於投資回報繫數和緊急程度來決策需求的優先級等,這裡的表現形式大家可以根據自己習慣調整。以上的四個因素通過需求決策表得出,然後自動生成需求決策模型即可,以下為舉例:

補充說明

  • BRES:Business,ROI,Urgent,Strategy
  • 需求決策:基於商業/戰略基礎線之上,且在投資回報繫數基礎線上的需求才在考慮範圍,然後根據投資回報率、緊急程度排序即可。

05 優化迭代

提升需求決策的質量或業務決策的質量是產品最重要的必修課,對個人或公司而言優化需求決策過程也是需要不斷升級迭代,以保證持續高質量的決策水平,進而保證團隊的效率,提升公司內部管理效率,這或許也覺得了一個公司的成敗。大家有更好的建議也可以留言,歡迎探討。

作者:Sunny;微信號公眾號:yaoyao202001,前華為產品經理,曾擔任AI領域創業公司COO,現SaaS領域產品經理,5年互聯網產品設計經驗。

本文由 @Sunny 原創發佈於人人都是產品經理。未經許可,禁止轉載

題圖來自Unsplash,基於CC0協議

發佈留言

發佈留言必須填寫的電子郵件地址不會公開。 必填欄位標示為 *