建立「需求管理機制」的流程和要點

5 評論 13856 瀏覽 86 收藏 23 分鐘

編輯導讀:需求,是戴在每一個產(chǎn)品經(jīng)理頭上的緊箍咒。產(chǎn)品經(jīng)理每天要面對大量的需求,建立需求管理機制能夠幫助產(chǎn)品經(jīng)理更好地工作。本文作者對此進行了分析,希望對你有幫助。

產(chǎn)品經(jīng)理每天都需要面對大量需求,很多朋友會通過“需求池”對零散需求進行統(tǒng)一、高效、有序的管理。但需求池只是需求呈現(xiàn)的載體和工具,并不能包治百病,實際操作中會出現(xiàn)各種意外,比如:

  • 無效的需求記錄:不是指需求記錄的不清晰,而是指明顯不符合產(chǎn)品定位、場景不明確的需求未經(jīng)篩選就被記錄。
  • 超量的高優(yōu)先級:需求方都認為自己的需求更重要更緊急。面對多方的各種催促,出現(xiàn)了大量高級別需求,導致等級制度失效。
  • 短視的版本規(guī)劃:將迭代周期內(nèi)的需求塞滿即可。把需求、設計、上線做成了下意識的循環(huán),缺乏產(chǎn)品整體層面的發(fā)展規(guī)劃。

為了避免需求管理的效果打折扣,接下來根據(jù)需求的流轉(zhuǎn),依次講解需求處理過程的管控要點。

01?需求的有效采集和過濾

需求是產(chǎn)品的源頭,產(chǎn)品是需求的解決方案。所以,有效采集需求是需求管理的第一步。雖然每個產(chǎn)品所處的環(huán)境存在差異,但是為了不在需求階段迷失其中,需要從全局角度對需求來源、采集方法、需求篩選(初步)有整體的認知,便于后續(xù)對不同需求采取更合適的應對策略。

1. 需求獲取渠道

不同產(chǎn)品的適用場景和使用角色都不一樣,造成了需求來源較為復雜的現(xiàn)象。可以通過渠道通用屬性的方式進行分類。

分類目的在于全面了解產(chǎn)品的相關方,避免遺漏。畢竟不是每個角色都會主動反饋問題和需求,更多情況下需要產(chǎn)品經(jīng)理主動溝通和挖掘。產(chǎn)品經(jīng)理不要忘記“沉默的大多數(shù)”。

渠道分類的維度也多有不同,本文以內(nèi)外渠道區(qū)分為例:

  • 內(nèi)部同事:組織內(nèi)任何和產(chǎn)品相關的角色都有提建議的權(quán)利。比如:Boss、銷售、運營、技術(shù)等。
  • 外部客戶:客戶通過對應渠道反饋產(chǎn)品需求或問題。在項目中客戶也區(qū)分決策人、使用人等多種角色。
  • 產(chǎn)品經(jīng)理:基于對產(chǎn)品、用戶、發(fā)展戰(zhàn)略的觀察、分析等行為,進而得出需求。

2. 需求采集方法

需求獲取的方法是多樣的,有的是產(chǎn)品經(jīng)理通過設計進行獲取,有的是客戶主動進行反饋。具體方法如下:

  • 產(chǎn)品方獲取:由產(chǎn)品方主動獲取需求的方式。如:行業(yè)研究、調(diào)研問卷、實習輪崗、數(shù)據(jù)分析、現(xiàn)場訪談……(詳見:B端需求調(diào)研:客戶訪談操作詳解)
  • 客戶方反饋:由客戶方主動反饋需求或問題的方式。如:客服咨詢、用戶投訴、意見建議、公開渠道的評價(微博、垂直社交媒體……)

客戶主動反饋時,產(chǎn)品經(jīng)理并不能改變采集方式。針對產(chǎn)品經(jīng)理主動獲取情況下,采集方式應當如何選擇?我們知道每種方法各有優(yōu)劣,要結(jié)合實際情況靈活選用。影響選擇的關鍵因素有哪些呢?我認為至少考慮以下3方面:

  • 用戶是否接受此方式?面向不同角色,或同一角色的不同場合。用戶對各方式的接收程度都是不一樣的。有時我們希望面談,但客戶總是沒時間……
  • 資源是否支持此方式?公司的時間、人力等資源都是有限的,產(chǎn)品經(jīng)理需要在合理資源限度內(nèi)完成采集。比如實習輪崗,可以較深入的了解現(xiàn)場,但耗時太長,通常采用的比較少。
  • 能否達到采集的目的和效果?如果調(diào)研后沒有達到目標,意味著采集無效以及投入資源的浪費。

3. 需求初步篩選

通過各個渠道獲取需求后,就進入的記錄階段。會發(fā)現(xiàn)需求總是源源不斷的過來,但是產(chǎn)品經(jīng)理的精力以及公司的資源都是有限的。所以要辨別需求的真?zhèn)魏蜐撛趦r值,把不符合要求的需求剔除,不計入該產(chǎn)品的需求池中,避免后續(xù)資源的無效投入。

篩選的過程是“砍需求”的過程,是對需求潛在價值判斷的過程。除了要對產(chǎn)品本身有所了解,也需要專業(yè)能力的支撐才能更加準確的判斷。事實上,從需求收集到研發(fā)上線之間會經(jīng)過多次“砍需求”。

此時作為初步篩選,要求并不嚴格。只需要做2件事:需求場景還原,需求屬性分類。

1)需求場景還原

需求有對應的完整場景是篩選的第一步,如果還原不了場景,則認為需求是假需求。場景還原只需要問幾個問題,能回答出來且邏輯自洽即可——誰(角色)在什么情況(背景)下,遇到了什么問題(需求)?當前的處理方法是什么?

場景還原時需要將相關的場景進行窮舉,避免因場景遺漏導致后續(xù)產(chǎn)品設計時出現(xiàn)漏洞。

需要注意的是,有的需求場景還原完整,但不符合本產(chǎn)品定位,此類需求對本產(chǎn)品無價值,但需求本身沒問題。建議記錄在另一張需求池表單中,作為外延產(chǎn)品的需求儲備。

2)需求屬性分類

除了需求基本的信息記錄,還要判斷需求的類型,為后續(xù)的需求評級和需求分析提供支持。比如:核心需求,基礎需求,衍生需求,技術(shù)需求,運營需求,體驗需求……

需求分類同樣沒有標準答案,存在多種維度的分類方式。重點在于你定義的需求類型,在后續(xù)分析中是否存在對應行動策略,如果僅作為需求池的統(tǒng)計查看使用,意義不大。

存在潛在價值的需求將被一一記錄在需求池中,等待下一輪的篩選和價值分析,直到被某個版本選中……

02??優(yōu)先級的制定和維護

初步過濾可以把部分需求排除在外,剩余需求將被納入到需求池中。至于選擇哪些需求進入實現(xiàn)階段,則根據(jù)需求的優(yōu)先級來排序。每個團隊都應該有自己的優(yōu)先級評估標準——你的優(yōu)先級評估標準是什么?評估標準又是怎么維護的?

1. 區(qū)分需求所屬類型

在制定具體的優(yōu)先級規(guī)則之前要先區(qū)分需求類別,不同類型的等級制定策略存在差異??梢曰凇爱a(chǎn)品管理權(quán)”和“需求確定性”來劃分需求類型。

1)基于“產(chǎn)品管理權(quán)”劃分

在公司內(nèi)部,一款產(chǎn)品的管理權(quán)限通常是由多個角色共同組成。不僅有產(chǎn)品經(jīng)理,還有運營、上級領導等其他角色也具備管理權(quán)。

  • 響應性需求:對應角色行使自己對產(chǎn)品的管理權(quán)限,產(chǎn)品經(jīng)理沒有拒絕的權(quán)利,根據(jù)具體要求排期和執(zhí)行即可。比如運營同事策劃了一場活動,需要在產(chǎn)品中實現(xiàn)。此時產(chǎn)品經(jīng)理沒有拒絕的權(quán)利,只要建議的權(quán)利。
  • 自主性需求:當產(chǎn)品經(jīng)理在處理自己管理模塊內(nèi)的需求時,其他角色也不能拒絕(領導可以拒絕)。其他人同樣可以提供建議。并不是要產(chǎn)品經(jīng)理剛愎自用。

2)基于“需求確定性”劃分

針對自主性需求也要區(qū)別對待,首先是判斷需求實現(xiàn)結(jié)果的可控性,面對可控和失控的需求要制定不同的策略來應對。

  • 不確定需求:對需求實現(xiàn)的結(jié)果預測精準度過低,不具備參考價值。常見于全新業(yè)務情況,沒有過往數(shù)據(jù)和歷史經(jīng)驗作為參考。面對此類需求通常采取MVP策略。
  • 確定性需求:對需求實現(xiàn)的結(jié)果預測相對準確的,可以將需求代入制定好的優(yōu)先級等級,進而找到優(yōu)先級順序。(本文針對此類需求的優(yōu)先級進行講解)

2. 制定優(yōu)先級標準

優(yōu)先級標準是判斷各需求實現(xiàn)先后的依據(jù)。比如Bug優(yōu)先還是需求優(yōu)先,實際上當然不會如此粗獷??梢杂贸R姷闹匾o急程度、KANO模型等方法幫助我們建立和細化等級標準。

1)重要程度:以產(chǎn)品目標為中心

假設有2個需求,實現(xiàn)需求A可以帶來新用戶10000人,實現(xiàn)需求B可以提高活躍用戶10000人。可使用的資源有限,只能實現(xiàn)1個需求。你會選擇那個需求實現(xiàn)呢?選擇依據(jù)是什么?

需求重要程度的判斷依據(jù)是“產(chǎn)品目標”,契合產(chǎn)品目標的需求就是重要的需求,偏離產(chǎn)品目標的,不論能夠帶來多大的收益,都不能稱之為重要。

產(chǎn)品目標是根據(jù)公司戰(zhàn)略、產(chǎn)品定位、發(fā)展規(guī)劃、領導決策、用戶反饋(KANO模型 – 期望型需求)等綜合因素制定的。產(chǎn)品目標落實到執(zhí)行層面,會反應在某項數(shù)據(jù)指標的變化上。比如:產(chǎn)品/某活動/某功能的拉新;產(chǎn)品/某功能的促活;某環(huán)節(jié)/某功能模塊轉(zhuǎn)化;商業(yè)化指標……

需要注意區(qū)分用戶目標和產(chǎn)品目標。提升效率、降低成本、優(yōu)化體驗等以用戶視角提出的訴求都是用戶目標。需要把用戶目標轉(zhuǎn)化轉(zhuǎn)為為產(chǎn)品目標。比如,在滿足了提升效率的用戶目標后,會達成產(chǎn)品目標數(shù)據(jù)指標A的變化。

2)緊急程度:以嚴重程度為中心

假設產(chǎn)品目標是提升拉新數(shù)據(jù),現(xiàn)在有2個需求,需求A可以帶來新用戶10000人,需求B會帶來新用戶1000人??墒褂玫馁Y源有限,只能處理其中1個。你認為那個更緊急呢?

很顯然,多個需求都滿足產(chǎn)品目標時,效果越好的越優(yōu)先(緊急)。

假設產(chǎn)品目標是提升拉新數(shù)據(jù),現(xiàn)在有1個需求和1個Bug,需求可以帶來新用戶10000人,Bug會造成流失用戶5000人??墒褂玫馁Y源有限,只能處理其中1個。你認為那個更緊急呢?

處理Bug時不考慮產(chǎn)品目標(重要程度),只考慮緊急程度。把需求和Bug的緊急程度放一起對比,之后再根據(jù)各自評估的嚴重程度來決定先后順序。通常采用如下的緊急程度標準:

P1:處理需求,獲得良好的正面效果

P2:處理Bug ,避免持續(xù)的嚴重損失

P3:處理需求,獲得一定的正面效果

P4:處理Bug ,避免持續(xù)的輕微損失

3)其他代價:關聯(lián)指標的變動

經(jīng)過重要緊急程度的篩選,我們可以得到重要(符合產(chǎn)品目標)的需求和Bug,并根據(jù)緊急程度進行排序。實際操作中還需要注意需求實現(xiàn)后的其他代價!

這里的代價不是指實現(xiàn)需求的成本,而是指需求實現(xiàn)后對產(chǎn)品目標之外的其他數(shù)據(jù)的影響。正面影響也就罷了,需要格外注意負面影響,負面影響會改變需求的價值。

假設產(chǎn)品目標是提升營收,現(xiàn)在需求A是向用戶端投放廣告,預測能夠獲得50萬營收,但是會造成3萬名用戶的流失。這時候需求A還是高優(yōu)先級的需求嗎?

3. 需求等級的動態(tài)調(diào)整

產(chǎn)品目標不是一成不變的,產(chǎn)品目標變更后對應的優(yōu)先級標準也同步變化。標準變更后,各需求的優(yōu)先級也要重新評估。

比如:產(chǎn)品目標從原來的提升“活躍”數(shù)據(jù),變成了現(xiàn)在的提升“拉新”數(shù)據(jù)。對需求A的結(jié)果預測是能夠拉新1000人,促活100人。需求A對拉新顯然價值更大。結(jié)合產(chǎn)品目標來看,需求A的價值隨著產(chǎn)品目標變更而同步變更,從低優(yōu)先級轉(zhuǎn)變成高優(yōu)先級。

產(chǎn)品目標的變更有什么規(guī)律?變更的影響因素和建立時一樣,此時更關注目標變更的觸發(fā)點?;痉譃?種:定期變更、臨時變更。

  • 定期變更:通常以1個季度為周期,定期檢查產(chǎn)品所處環(huán)境和發(fā)展進度是否符合計劃。出現(xiàn)脫節(jié)時要及時調(diào)整,避免發(fā)展偏航。
  • 臨時變更:通常是因為市場、政策、競品、產(chǎn)品自身發(fā)展突然出現(xiàn)重大變化,所以需要及時關注產(chǎn)品相關的重大事件,便于及時應對。

03?契合優(yōu)先級的需求序列

當我們獲取了有效需求,建立了優(yōu)先級規(guī)則。各個需求具體的優(yōu)先級順序如何排列呢?大部分公司都有自己的優(yōu)先級制度,但是為什么執(zhí)行總是不如人意?可能是因為執(zhí)行力松散,也可能是因為對需求價值的判斷失誤。

一旦實現(xiàn)的需求選擇錯誤,會造成數(shù)據(jù)結(jié)果不能滿足產(chǎn)品目標。意味著投入的時間,人力等資源的浪費,也可能導致產(chǎn)品在瞬息萬變的市場上失去競爭機會。所以要建立更加細化的規(guī)則,進而量化需求的價值。

1. 判斷需求屬性

對“確定性需求”的優(yōu)先級排序,首先根據(jù)“優(yōu)先級”的重要程度判斷需求屬性——即:需求是否符合產(chǎn)品目標。

需求的實現(xiàn)會影響產(chǎn)品的多項數(shù)據(jù)表現(xiàn),列出受需求影響程度較高的數(shù)據(jù)項和產(chǎn)品目標進行匹配。選取匹配程度更高的需求進入當前版本的“待定清單”中。

比如:產(chǎn)品目標是提升拉新數(shù)據(jù);需求A有效提升活躍數(shù)據(jù),拉新數(shù)據(jù)影響不大;需求B有效提升拉新數(shù)據(jù),活躍數(shù)據(jù)影響不大。所以會選取和產(chǎn)品目標更匹配的需求B。

通常1個版本中只有1個產(chǎn)品目標,更有利于增強目標的實現(xiàn)效果。如果設立了多個目標,則需要先對各目標本身做優(yōu)先級排序,并分配對應的權(quán)重。估算需求的對各目標的效果后,結(jié)合目標權(quán)重再重新進行需求排序。

2. 量化需求價值

假設需求A、B、C都進入了本版本的待定清單中,現(xiàn)有的資源有只能夠?qū)崿F(xiàn)2個需求。那么淘汰誰?剩下的誰先誰后?只有對需求價值或Bug的影響進行量化,才能夠得出較為客觀的結(jié)論。換言之對產(chǎn)品所帶來的正向數(shù)據(jù)變化就是需求的價值所在。

需求價值的計算過程中,需要充分考慮關鍵影響因素。公式表達:需求價值 = 潛在用戶數(shù) x 轉(zhuǎn)化率 x 使用頻次 x 用戶價值 – 關聯(lián)指標負面影響

1)潛在用戶數(shù)

  • 評估需求會影響的用戶類型,再估算對應類型客戶的數(shù)量。
  • 用戶類型根據(jù)企業(yè)內(nèi)部對客戶的分類。比如:普通用戶、會員用戶、活躍用戶。
  • 估算對應用戶數(shù)量時,注意用戶的存量數(shù)據(jù)和增量數(shù)據(jù)。

2)轉(zhuǎn)化率

  • 預估潛在用戶使用該需求對應功能的轉(zhuǎn)化率。
  • 轉(zhuǎn)化率一般按照活躍度來計算,不同類型用戶的活躍度不一樣。

3)使用頻次

  • 估算目標用戶一定時間內(nèi)使用該功能的次數(shù)。針對不同類型的需求采用不同的時間長度計算。
  • 見效快的需求,計算時間周期短,如1~3月;見效慢的需求,計算時間周期長,如3~6月。

4)用戶價值

不同類型的用戶價值需要分別計算。比如:普通用戶和VIP用戶對產(chǎn)品的貢獻是有巨大差別的。

5)關聯(lián)指標的負面影響

  • 考慮效果時不僅要考慮正面收益,也要考慮需求實現(xiàn)對關聯(lián)指標的負面影響。
  • 計算收益要減去需求關聯(lián)bug負面影響。比如:需求A可促活3000用戶,bug可導致1000用戶流失。所以預估效果應是促活2000用戶。
  • 特別需要注意需求實現(xiàn)付出的其他代價。比如:添加廣告可以提升收益數(shù)據(jù),但是會降低活躍等數(shù)據(jù)。

3. 需求的性價比

計算出需求價值后,按照價值高低排序就是我們要的需求優(yōu)先級了嗎?這樣的想法依然過于片面。做決策不僅要考慮收益,也要考慮成本和性價比。

1)需求成本估算

這里的成本是指實現(xiàn)需求所需要投入的人力成本。同時為了計算方便,一般會將不同崗位的人力成本設定為同一個價格。用公式表達:人力成本 = 所需人天 x 單位人天費用。

比如:需求A實現(xiàn)需要產(chǎn)品設計3天、UI設計2天、研發(fā)測試5天,人力成本是500元/人天,則需要A的人力成本是5000元。

2)實現(xiàn)的性價比

最后一個步驟就是計算需要實現(xiàn)的性價比。根據(jù)性價比排序,性價比越高則排序越靠前。到此,完整的需求優(yōu)先級才算制定完成。用公司表達:性價比 = 需求價值 / 人力成本

比如:需求A的需求價值50000元,實現(xiàn)需求的人力成本5000元,則性價比是10;需求B的需求價值20000元,實現(xiàn)需求的人力成本1000元,則性價比是20。綜合來看,雖然需求A更有價值,但是需求B的性價比更高。因此需求B的優(yōu)先級高于需求A。

附:“需求池”概況介紹

1、創(chuàng)建方式

需求池的創(chuàng)建方式并不固定,團隊內(nèi)保持一致即可,使用Excel或項目協(xié)同軟件都行。比如:Teambition、禪道……

2、表單字段

需求池的具體字段可根據(jù)團隊關注的要素自行調(diào)整,也可以把部分字段轉(zhuǎn)移至關聯(lián)文件中,比如在“產(chǎn)品版本”文件中記錄各環(huán)節(jié)的負責人、計劃用時和時間段、實際用時和時間段等信息。主要包含以下:

  • 基礎信息:需求方、提出時間、需求編號、需求概述、需求詳情
  • 需求屬性:所屬模塊、所屬功能、需求類型、需求狀態(tài)、重要程度、緊急程度、需求等級、產(chǎn)品負責人、產(chǎn)品版本

3、補充說明

  • 需求詳情:完整需求的描述較多,通過圖文等形式呈現(xiàn),不便在excel上呈現(xiàn)。通常會用獨立文檔記錄。通過“需求編號”檢索查看“需求詳情”。需求詳情同時會記錄需求方、提出時間等信息。
  • 所屬版本:版本規(guī)劃屬于項目管理內(nèi)容,在對應“項目管理”表單中會標記需求實現(xiàn)各環(huán)節(jié)的負責人、交付物、計劃和實際用時、開始和結(jié)束時間等信息。

 

本文由 @耳目不染 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可,禁止轉(zhuǎn)載。

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

更多精彩內(nèi)容,請關注人人都是產(chǎn)品經(jīng)理微信公眾號或下載App
評論
評論請登錄
  1. 感覺挺有用噠,愛了!這就收藏了慢慢看哈哈哈

    來自廣東 回復
    1. 哈哈 歡迎交流~共同進步

      來自安徽 回復
  2. 寫的不錯

    來自廣東 回復
    1. 感謝認可,希望有幫助~

      來自貴州 回復
  3. 畢竟不是每個角色都會主動反饋問題和需求,更多情況下需要產(chǎn)品經(jīng)理主動溝通和挖掘。產(chǎn)品經(jīng)理不能忘記“沉默的大多數(shù)”。

    來自湖北 回復