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

11 評論 5435 瀏覽 41 收藏 14 分鐘

提升需求決策的質量或業(yè)務決策的質量是產品最重要的必修課,保持持續(xù)高質量的決策水平,能夠保證團隊的效率,提升公司內部管理效率。

需求決策質量對個人和團隊效率都起到杠杠作用,好的模型可以降低對個人能力的依賴性,減少變動變量,減少需求決策過程中的不穩(wěn)定性,提升需求決策質量。

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

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

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

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

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

B端產品普遍是付費產品,B端產品需求的決策很可能會直接影響續(xù)約或新簽,而部分對用戶有很大價值,但對續(xù)約或新簽沒有價值的功能優(yōu)先級也可能會低。B端需求決策模型上,公司商業(yè)價值影響因素更大,如對續(xù)約的影響,對新簽的影響等。

而C端產品在剛開始普遍是免費產品,更多的考慮用戶價值,較少的考慮商業(yè)價值,而后期即便考慮商業(yè)價值,商業(yè)價值和需求功能之間的關聯性較B端也是相對弱。

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

KANO模型

四象限模型

03?公司業(yè)務梳理

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

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

這些對于一個公司而言是短期不會變,是需求決策的基礎框架。而這些基礎框架則構成了需求決策過程中的固定變量(短期的固定變量,長期可迭代)。基礎框架影響決策模型,保證整體需求內容不偏離主航道,而不被單點價值影響

用戶故事地圖是很好的梳理業(yè)務角色及業(yè)務場景,并可以結合業(yè)務商業(yè)價值及戰(zhàn)略定位的一個實用工具。舉例如下:

2. 用戶故事地圖實踐指導

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

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

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

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

04?需求決策影響因素梳理

1. 個人能力:用戶洞察

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

對用戶洞察的能力會直接影響主觀判斷部分的準確度,斷產品價值的時候會有偏差【(新體驗-舊體驗)-遷移成本】,這里可以通過公式的分解,在需求評審環(huán)節(jié),其他同學幫忙把關。

2. 其他需求決策的影響因素

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

這里有的因素是比較容易判斷的,也不容易出錯如當前的用戶量,這樣依來產品人員中等水平即可。

有的因素比較容易依賴個人經驗、能力判斷,比如用戶可感知價值、商業(yè)價值等,這些比較依賴個人經驗、能力判斷的因素也是需求評審過程中的重點,需要產品團隊協(xié)作把關。

3. 梳理一個最穩(wěn)健的需求決策表

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

4. 需求決策表補充說明

需求決策表維度梳理:

需求決策表的維度是在四象限模型基礎上衍生,結合自己多年的產品經理經驗逐步拆解、梳理及歸納而來。

字段補充說明:

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

字段底色說明:

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

應用說明:

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

5. 需求決策表簡化示例

適用于中等需求:

適用于小需求:

04?需求決策模型

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

補充說明:

  • BRES:Business,ROI,Urgent,Strategy
  • 需求決策:基于商業(yè)/戰(zhàn)略基礎線之上,且在投資回報系數基礎線上的需求才在考慮范圍,然后根據投資回報率、緊急程度排序即可。

05?優(yōu)化迭代

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

 

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

本文由 @Sunny 原創(chuàng)發(fā)布于人人都是產品經理。未經許可,禁止轉載

題圖來自Unsplash,基于CC0協(xié)議

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 不是特別明白,希望能舉個例子

    回復
  2. 用戶情緒:業(yè)務環(huán)節(jié)中,用戶情緒越低用戶價值越大,怎么理解這點呢?

    來自廣東 回復
    1. 理解為用戶情緒越低,場景可信度越高,價值也就越大。

      來自浙江 回復
  3. 作者可以解釋一下什么是“前置需求”呢?它是做什么用的呢?

    來自山西 回復
    1. 如果一個需求有前置需求,則需要在前置需求實現之后再做該需求,或者至少一起上線。前置需求即依賴的需求,比如角色權限的功能是很多高級自定義設置的前置需求

      回復
  4. 修改下文章,文章竟然沒了?!

    回復
    1. 辛苦編輯同學聯系下我??估計是人人產品平臺的bug??

      回復
  5. 可以分享下文章中的圖片表格嗎

    來自廣東 回復
    1. 看不清那個需求決策表,可以上傳一個高清圖嗎?

      來自山西 回復
    2. 圖片放大可以看清,不建議直接拿表格,建議大家自己梳理一遍,做適當調整以適應業(yè)務。

      回復
  6. ??

    來自上海 回復