需求價值與優先級

2020-12-19 人人都是產品經理

編輯導讀:產品經理通過各種渠道接到產品需求後,第一步要做的就是對需求進行分析和處理,對需求的優先級進行評估。具體怎麼做?需要遵循哪些標準?本文作者從自身工作實踐出發,對此展開了分析討論,一起來看看~

我們會接到不同來源的需求,有的來源於業務部門、領導要求,有的來源於用戶反饋、線上問題,有的是市場反饋建議,或者競品已支持等等。

收到原始需求之後,我們怎麼知道哪些需求要做?哪些需求要優先做,哪些可以往後排?或者在需要澄清需求價值時,我們要回答哪些問題後,才算講清楚了需求價值,又如何做需求的優先級排序。

首先,我們需要對原始需求進行分析,明確該需求解決了誰的什麼問題。即目標用戶是誰,提出需求的動機是什麼,該需求能解決目標用戶的什麼問題。當我知道了需求的目標用戶和問題之後,問自己幾個問題:

與我的產品相關嗎?該需求目標用戶與產品核心用戶匹配嗎?需求價值怎麼判斷,如何量化?

01 與我的產品相關嗎?

這個問題實際上是去思考新需求是否與產品定位匹配,我們回溯產品定位,將需求與產品定位做個匹配,如果和我的產品不相關也不是產品將要演進的方向,就不做這個需求。可以思考是否與組織內部其他產品匹配,並記錄下來。

02 該需求目標用戶與產品核心用戶匹配嗎?

要識別核心用戶,先做用戶細分,再聚焦核心用戶,就是明確用戶的優先級。B端產品的用戶與C端產品用戶不太相同,下圖是兩類用戶細分的參考緯度。

C端用戶細分參考緯度

B端用戶細分參考緯度

舉個例子,例如宜家APP做用戶細分時考慮從用戶基本屬性開始,以用戶收入、職業、家庭出發去考慮。而對於KEEP來說以需求來做用戶細分,想要嘗試的健身小白,需要健康及定期執行鍛鍊的這類喜愛健身的職場人士,熱愛健身、分享的健身大牛……

對於車企銷售管理系統,以不同的用戶職責為緯度,例如銷售顧問、試駕體驗專家、銷售經理、區域經理等等。

用戶細分具體方法這裡沒給出,這裡只是一個用戶細分緯度參考,用戶識別實際上需要更大的篇幅討論,B端、C端用戶識別各有適用的方法。做好用戶細分後,然後可以進行核心用戶識別,這裡推薦使用價值表格能很好量化用戶權重,方便我們後續量化需求價值,以評估優先級。

一般來說評估用戶價值的緯度,有用戶的影響力、花費的錢、使用頻率、權利、用戶規模等。這裡以上面提到的銷售管理系統舉個簡單的例子:

用戶權重

通過分析用戶的權重識別用戶優先級,如果需求的目標用戶產品用戶或僅針對於產品低優先級的用戶,我們其實可以快速調低這個需求優先級,或者基於實際情況直接砍掉這個需求。

03 需求價值如何量化?

需求價值優先級分析方法很多,比如KANO模型、二八原則、價值矩陣、收益導向、價值模型等等。這裡介紹一種綜合方法,對B端、C端產品同時適用。

需求價值是用戶價值和企業/業務價值的綜合,還會受領導意志的影響。以橫軸代表用戶價值,縱軸是企業價值、領導意志之和,計算其所佔面積,面積大小即需求價值量化分值,即

需求價值 = 用戶價值 *(企業價值+領導意志)

而用戶價值包括用戶權重,以及用戶對需求是否提供的感受。用戶權重,我們可以基於以上用戶識別的結果得出,而KANO模型能很好幫助我們識別用戶對需求的感受。

用戶價值 = 用戶權重 * KANO模型

通常可以將KANO模型不同需求類別:必備型需求,期望型需求,魅力型需求,無差異型需求,反向需求,分別定義為3,2,1,0,-1的分值。

企業價值一般包含了,企業戰略,合乎法律法規,提升業務運營效率(B端),擴大市場佔有率,增加收入/降低成本,更好的客戶滿意度等緯度。舉個例子,去年國家頒布法規要求登記售出新能源車,那這個就是企業價值,因為企業要合乎法律法規。

基於需求涉及到的緯度,基於實際情況給定權重後相加計算出企業價值。即

企業價值 = 戰略 + 法律法規 + 提升業務運營效率(B端)+ 擴大市場佔有率 + 增加收入/降低成本 + 提升客戶滿意度 + …

回答完這三個問題,我們已經明確了需求是否具有業務價值和用戶價值。我們可以通過以上問題快速做一些決策。也可以進一步對需求優先級進行分析。

04 最後需求的優先級如何定義?

優先級定量方法是將得到的需求價值量化評分/成本,成本即開發測試投入,最後得到的比值越大,則優先級最高。

也可以製作可視化的價值矩陣圖,定性的來看需求優先級,如

優先級價值矩陣

先做高價值低投入的需求,再做高價值中高投入需求,適當的做低價值低投入的需求,儘量避免做低價值高投入的需求。

本文由 @半個 原創發布於人人都是產品經理,未經作者許可,禁止轉載。

題圖來自Unsplash,基於CC0協議。

相關焦點

  • 產品需求的優先級排序方法
    然而關於需求優先級排序的內容卻很少見,在NPDP組合管理這一章可以知道:需求優先級排序在新產品開發中非常重要,是有效管理的核心原則之一。希望通過本次分享可以讓大家對這部分內容有一個更加深入的了解。首先,讓我們通過兩幅圖來理解一下優先級排序的重要性。
  • 實戰中,需求優先級怎麼定
    因為我這邊對接的需求方是好幾個相對獨立的方向,這就導致在每一個需求方眼裡,自己的需求都是P0優先級,而最後匯總到我這邊時,就會出現所有需求優先級都是高優,需求排期中的優先級因素基本相當於無效。這種情況很危險。原因在於,需求主次拎不清,不單單在於無法滿足需求方希望數據同學提供一些數據洞察的需求;同時,數據同學數據驅動的工作部分會被擠佔地越來越少,數據同學存在的價值在「降低」。
  • 定義產品需求優先級的方法
    在日常生活中,處理任務的優先級有四種情況:重要且緊急、重要不緊急、緊急不重要、不緊急不重要。這四種情況是我們處理需求優先級的原則,那麼作為未上市的產品是否也同樣適合呢?根據馬斯洛的需求理論,分別是生理需求、安全需求、社交需求、尊重需求和自我實現需求。
  • 產品管理流程及規範1:產品需求來源、收集、管理、優先級確定及...
    此部分需求,具體使用部門一般主要集中在對現有產品的優化迭代,在流程的優化、體驗的優化,業務線的深化拓展。內部客戶的需求收集整個流程:由內部用戶填寫需求功能收集表,按照一定的周期提交產品經理,並進行溝通討論,根據商業價值、技術可實現度、優先級、產品路線節奏規劃等考慮點判斷是否要做,及做的安排。
  • 產品經理方法論:通過卡諾模型進行需求分類和優先級排序
    本文將向大家介紹一種科學的需求歸類和優先級排序方法——卡諾模型!並通過一步步的實操向大家展示怎樣卡諾模型怎樣應用到具體的工作中。一、卡諾模型是什麼簡單通俗的講,卡諾模型是一種以調查問卷為手段,通過收集用戶對產品功能特點的雙向反饋、獲取用戶對產品功能的真實感受的的需求分類和優先級排序方法。
  • 三種簡化產品優先級排序的簡單方法
    我們低估了做事情所花費的時間,我們還對自己的想法賦予更高的價值,並且不喜歡權衡取捨,但這並非不可能。根據產品團隊的工作方式和需求,這裡有一些方法可以幫助解決優先級問題。一起來看看~技術的偉大之處在於一切皆有可能。
  • 善用KANO模型,做需求分類與評估優先級
    產品設計過程中,各方都會提出對應的需求,那麼產品經理又該如何抉擇,對需求優先級進行排序呢?筆者認為使用KANO模型會是不錯的辦法。在項目中,設計需求從四面八方而來,你也許經歷過下面的某個場景:1. 競品調研PM:競品出了XX新功能,我們也不能落後,緊鑼密鼓跟上。2.
  • 需求優先級評估引爭議,我用卡諾模型做調研說服領導
    卡諾模型是需求管理中非常有用的一個工具。最近在和產品討論功能開發進度的時候,就某個需求的開發優先級有了爭議。這裡我們看到需求2雖然對產品核心指標貢獻大,但是預計開發時間較長;而需求1雖然對產品核心指標貢獻相比需求2要略小,但開發時間短。
  • 產品優先級應該怎麼定?
    我理解產品經理要為以下幾點負責1.挖掘需求;2.排列優先級;3.產出產品化方案;4.推動需求上線,解決業務問題這4點,我認為排列優先級是最玄學的。一千個人排列優先級,就有一千種排列方式。那為什麼是玄學呢?
  • 【轉帖】debuff優先級分析
    發帖原因:馬上要開P5了,raid時法師即將多佔據團隊16個debuff位置中2個額外的debuff位(點燃/強化灼燒), 作為一個普通公會(缺乏高效的debuff位置管理)的法師玩家,了解debuff的優先級可以幫助公會在
  • 依據項目對業務的價值判定項目優先級,列出項目有必要結束的過程
    坦率地說,單獨布置活絡並沒有多大實用價值。事實上,這不是活絡團隊的錯。公司的戰略和實施不一致,導致團隊的效果與預期相反,這並不稀有。這些公司的安排結構一般存在巨大的「脫節」。知道怎樣補償這種脫節的公司可以確保以正確的方法進行正確的投資和組成。但更重要的是,他們可以守時以較低的本錢改動正在生產的產品,以跟上商場需求,並在開發過程中發明最大價值。
  • 產品經理決策時的核心3原則:核心業務優先、二八法則和價值優先原則
    2/8原則的核心在於讓我們去關注重要的東西,當一對需求擺在面前的時候,要清楚地知曉,他們並不是同等重要的,是需要分出重要級的,基於2/8原則,我們要不斷的去尋找2那部分的需求。做完了2,剩下的8怎麼辦呢?
  • 優先級隊列與堆排序
    ,比如首先處理優先級最高的對象,然後處理次高的對象。最簡單的一個例子就是,在手機上玩遊戲的時候,如果有來電,那麼系統應該優先處理打進來的電話。在這種情況下,我們的數據結構應該提供兩個最基本的操作,一個是返回最高優先級對象,一個是添加新的對象。這種數據結構就是優先級隊列(Priority Queue) 。
  • 軍轉安置優先,為什麼沒有連級主官?
    而優先安置的範圍中,擔任作戰部隊的師旅團營單位主官,是屬於優先安置範圍的,然而讓人意外的是,連級主官卻沒有在優先之列。是無意忘記了還是有意為之?還是連級主官說起來重要優先起來不重要呢?所以無意中忘記的可能性不大,只可能是在擬制過程中,考慮到很多因素最終決定不將連級主官納入其中,是有意為之。安置優先的價值,其實是很重要的。如果能取得優先的資格,必然會在安置的加分、順序、選崗的範圍等方面有一定的優勢和照顧。
  • 私募股權基金有優先級與劣後級嗎?
    二、優先級、劣後級私募股權基金,是有分「優先級」與「劣後級」的。1、定義優先級與劣後級的「優先」和「劣後」指的是分配收益的順序。一般而言,優先級先取得較低的固定回報,劣後級之後才取得剩下的收益。舉個慄子,一隻私募基金的規模為1000萬,即份額為1000萬份,其中優先級和劣後級的份額各500萬,優先級要求固定的年化10%回報,剩餘的盈虧由劣後級來承擔。
  • 產品經理:需求排序大法
    作為產品經理,每天都會面對一大堆需求,時間和人力有限,只能給每個需求排序,決定先後順序。本文從三個方面,用兩種方法決定需求的先後順序,希望對你有幫助。每個產品都有一堆永遠做不完的堆積如山的需求,每個團隊都感覺人不夠用。怎麼辦?產品經理的重要工作之一是:決定優先級先後順序。決定需求的先後順序有兩種方法:定性評估法和定量計算法。
  • MATLAB運算符優先級一覽表
    MATLAB 在執行含有關係運算和邏輯運算的數學運算時,同樣遵循一套優先級原則。
  • 需求管理的兩個維度:需求來源管理和需求實現管理
    1、KANO模型分析法需求的優先級首先應該根據需求對用戶的價值來判斷。日本教授狩野紀昭在1984年提出構了KANO模型,用來對客戶需求的滿意度進行分類,一共分為五類影響因素(引自維基百科):必備因素:滿足基礎需求時,用戶才會使用產品,不會對用戶滿意度產生影響。
  • STM32(Cortex-M3)中的優先級理解
    為了便於大家理解,有必要先解釋兩個概念:搶佔式優先級/響應優先級:本文引用地址:http://www.eepw.com.cn/article/201611/322703.htmSTM32(Cortex-M3)中有兩個優先級的概念——搶佔式優先級和響應優先級,有人把響應優先級稱作亞優先級或副優先級
  • 如何確定產品待辦事項(Product Backlog)的優先級?
    導語:產品待辦事項(Product Backlog)是必不可少的產品管理工具:它捕獲詳細的產品決策並指導開發團隊的工作,後者要求對其進行優先級排序。但是,當所有事情似乎都同樣重要時,如何確定產品待辦事項的優先級呢? 本文作者建議採取四個步驟來獲得有效的優先產品積壓,並分別進行了梳理說明,與大家分享。