B端產(chǎn)品案例，剖析需求調(diào)研的方法策略

公眾號(hào)回“1”，抽取50本電子書

一、后端需求調(diào)研

二、需求調(diào)研的落地方法

三、后端需求類型與策略

前后端分離的實(shí)現(xiàn)方式，使得每一個(gè)完整的產(chǎn)品體系都包含了前端和后端部分。

相對而言,B端產(chǎn)品更依賴于后端部分的支撐。

一些公司也習(xí)慣于將這些后端提供支撐的部分，稱為“后端產(chǎn)品”。

后端產(chǎn)品甚至不具有視覺化，而僅僅是一些中間件等。

后端產(chǎn)品如冰山之下，卻承擔(dān)相當(dāng)重要的幕后工作：支撐、運(yùn)算、監(jiān)控、調(diào)度、分配、統(tǒng)計(jì)分析、決策……

由于后端產(chǎn)品部分的復(fù)雜性，因此負(fù)責(zé)這部分的產(chǎn)品經(jīng)理，需要做更多、更深入的需求調(diào)研工作，才能完成方案設(shè)計(jì)。

? 一、后端需求調(diào)研

需求調(diào)研，是需求分析的前題。

需求分析，是產(chǎn)品方案決策的前題。

從需求調(diào)研到產(chǎn)品決策，占據(jù)了產(chǎn)品經(jīng)理80%的工作精力。

由于調(diào)研和分析往往一起完成，所以在本文中我門統(tǒng)一將二者以“需求調(diào)研”代替。

按通用的模型表達(dá)方式，我們可以簡單畫下：

如上圖：需求調(diào)研是一個(gè)過程，其產(chǎn)物是解決方案。

后端需求研調(diào)，與前端需求調(diào)研很大的區(qū)別。比如用戶的角色化、業(yè)務(wù)的全還原、場景的窮舉、新舊邏輯兼容等。

我們簡單說下期中的用戶、業(yè)務(wù)和兼容性的話題：

1、用戶

后端產(chǎn)品的用戶非最終的價(jià)值用戶，而是服務(wù)人員（如客服、運(yùn)營）。

因此這些用戶具有業(yè)務(wù)垂直性，是格式化的“人”，具有戒色性和行業(yè)屬性。

不同職位不同權(quán)重，關(guān)心的價(jià)值目標(biāo)、決策權(quán)、使用人數(shù)不同。

不同用戶的具體使用場景不同。

可以較容易的獲取前端產(chǎn)品用戶畫像，因?yàn)槲覀冏陨砘蛘咚煜さ娜硕荚诎缪葜?前 端的角色，也就意味著設(shè)計(jì)過程中也很容易進(jìn)行角色代入。

而后端用戶畫像的獲取往往艱難得多，最快捷的方式就是和公司的業(yè)務(wù)層交流，業(yè)務(wù)部門是最直接與客戶打交道的，他們熟知大量的典型客戶案例，可以幫助我們快速高效的描繪出用戶畫像。

由于我們自身與后端用戶的相剝離性，用戶畫像的作用顯得尤為關(guān)鍵，可以時(shí)刻提醒我們是在為誰做設(shè)計(jì)，每一個(gè)關(guān)鍵訴求都在產(chǎn)品設(shè)計(jì)中有對應(yīng)的抓手。

2、業(yè)務(wù)

• 業(yè)務(wù)目標(biāo)——>訴求——>用戶需求。

• 業(yè)務(wù)手段——>途徑——>產(chǎn)品功能。

了解業(yè)務(wù)最好的方法，是輪崗參與業(yè)務(wù)環(huán)節(jié)中去。此外，更加便捷快速的方法，是調(diào)研訪談。

調(diào)研之前，最好對業(yè)務(wù)能有大體的認(rèn)知，安排好訪談的對象，提前準(zhǔn)備好問題，讓訪談更加高效。

調(diào)研方式：訪談、數(shù)據(jù)分析、問卷調(diào)查、頭腦風(fēng)暴、德爾菲、觀察，完成用戶需求的收集；通過親和圖、提示清單等，整合需求信息。

調(diào)研目標(biāo)：

? 了解業(yè)務(wù)模式和業(yè)務(wù)特點(diǎn)

? 了解業(yè)務(wù)目標(biāo)和業(yè)務(wù)規(guī)劃

? 了解當(dāng)前業(yè)務(wù)運(yùn)轉(zhuǎn)方式

? 挖掘當(dāng)前問題與痛點(diǎn)

對于后端產(chǎn)品，場景往往是很多的，需求的邏輯性大于故事性，需要由遠(yuǎn)及近規(guī)劃處業(yè)務(wù)場景地圖，才能勾畫出業(yè)務(wù)架構(gòu)，最終聚合出產(chǎn)品生態(tài)。

在這個(gè)過程中，可以借助用戶故事地圖等等手段。

通過整個(gè)業(yè)務(wù)的架構(gòu)，厘清整個(gè)平臺(tái)的用戶對象、業(yè)務(wù)關(guān)系，也就確定了整個(gè)產(chǎn)品的業(yè)務(wù)邊界范圍，確定了整個(gè)團(tuán)隊(duì)內(nèi)的業(yè)務(wù)語言。

3、新舊邏輯兼容

掌握后端產(chǎn)品邏輯真相的密碼通常在開發(fā)手里，但是開發(fā)常常也需要臨時(shí)查代碼。

在這種情況下，所有對舊功能的迭代都充滿著風(fēng)險(xiǎn)。

于此同時(shí)，無論是集成的大系統(tǒng)，還是拆開的煙囪林立服務(wù)，各個(gè)體系之間總是有邏輯調(diào)用。比如接口、公共數(shù)據(jù)等。

后端產(chǎn)品大約60%的bug都是來自于這種牽一發(fā)而動(dòng)全身的邏輯耦合。

唯一能確保系統(tǒng)安全的辦法就是做深入的可能影響的調(diào)研。

為了避免空談，我們結(jié)合《后端產(chǎn)品經(jīng)理寶典》一書，介紹需求調(diào)研落地的常用方法，和需求的類型。

? 二、需求調(diào)研的落地方法

1、過濾需求的方法

做后端系統(tǒng)，要學(xué)會(huì)的第一個(gè)技能就是砍需求。也就是過濾需求。

這不是一個(gè)貶義詞，反而是體現(xiàn)后端產(chǎn)品價(jià)值判斷的基礎(chǔ)。

過濾需求的方法，就是通過一定的手段判斷需求是否是偽需求，應(yīng)該被過濾掉。

（1）用戶場景模擬法

后端產(chǎn)品的出發(fā)點(diǎn)就是幫助業(yè)務(wù)用戶，因此在調(diào)研需求的時(shí)候要模擬業(yè)務(wù)的場景，分析業(yè)務(wù)用戶提到的需求是否能解決他的問題。

如果不能幫助用戶，那么這個(gè)需求就可能是偽需求。

以下面的案例說明：

背景：“貨到付款”類型的訂單會(huì)因?yàn)槿必浂鵁o法發(fā)出，如果超過一定的時(shí)間，客服就會(huì)跟顧客溝通，幫顧客取消訂單。

需求：由于這種訂單的數(shù)量還是蠻多的，逐個(gè)取消太費(fèi)時(shí)間，因此業(yè)務(wù)用戶要求在“缺貨訂單”列表頁增加“批量取消訂單”按鈕。

分析：調(diào)研到業(yè)務(wù)操作場景,是先找到該類缺貨訂單，然后和顧客溝通，顧客同意刪除，才進(jìn)行刪除。也就是逐個(gè)溝通確認(rèn)，再逐個(gè)取消訂單的，所以“批量取消訂單”無法被有效使用。

因此，該需求是個(gè)偽需求，應(yīng)該被過濾掉。

（2）功能歸屬分析

專門的系統(tǒng)做專職功能，有助于合理的產(chǎn)品體系建設(shè)。

因此需求調(diào)研的時(shí)候，可以通過系統(tǒng)的定位，判斷需求是否應(yīng)該在該系統(tǒng)完成。

如果不屬于該系統(tǒng)范疇，那么直接說服需求方更換方案。以下面的案例說明：

背景：CRM系統(tǒng)（顧客關(guān)系管理系統(tǒng)）有一個(gè)顧客標(biāo)簽生成功能，就是根據(jù)顧客的消費(fèi)行為數(shù)據(jù)，自動(dòng)對應(yīng)關(guān)聯(lián)上標(biāo)簽，如優(yōu)質(zhì)顧客、高潛力顧客、欺詐顧客等。

需求：業(yè)務(wù)用戶提出需求，除了做上述的基礎(chǔ)標(biāo)簽之外，還要做出英語版本的標(biāo)簽（就是把標(biāo)簽文案翻譯成英文），這樣歐美員工可以在英語版本的系統(tǒng)下使用。

分析：調(diào)研到翻譯之后的標(biāo)簽不是在CRM系統(tǒng)使用的，而是給到SMS（客服系統(tǒng)）使用的。

所以應(yīng)該由SMS根據(jù)CMS提供的基礎(chǔ)標(biāo)簽數(shù)據(jù)，自己做二次的衍生。

之所以這樣，首先是為了避免未來更多語言版本的擴(kuò)展需求或更多系統(tǒng)提出類似的需求；

其次，CRM系統(tǒng)已經(jīng)完成了“接力賽”的第一棒，創(chuàng)造了基礎(chǔ)數(shù)據(jù)，那么其他系統(tǒng)要特殊化使用，完全可以自行進(jìn)行特殊化處理，無需耦合回CRM系統(tǒng)。

結(jié)論：案例的需求本身是真需求，并且實(shí)現(xiàn)上也沒難度，但是該功能的定位超出了本系統(tǒng)范疇，專門系統(tǒng)做專職功能，化衍生需求應(yīng)該在下游執(zhí)行。

否則，耦合性過高只會(huì)增加系統(tǒng)的復(fù)雜程度，難以維護(hù)和擴(kuò)展。

2、拆分和聚合的方法

（1） 拆分需求法

收到的需求，很可能只是短短的一段話。

但是不要高興太早，可能這一句話暗含了很多線索，因此要善于拆分：

先找他要解決的核心問題，再圍繞核心點(diǎn)，理清前、后、左、右、上、下的旁系需求點(diǎn)。

每個(gè)需求點(diǎn)再當(dāng)做一個(gè)子需求進(jìn)行調(diào)研，最后再聚合在一起。

以下面的案例說明：

背景：訂單業(yè)務(wù)的類型很多，訂單退貨之后需要?jiǎng)?chuàng)建售后單據(jù)，但是因?yàn)閿?shù)量大，所以花費(fèi)很多人力，且手動(dòng)創(chuàng)建有出錯(cuò)的風(fēng)險(xiǎn)。

需求：業(yè)務(wù)提出的需求是“增加退貨訂單自動(dòng)創(chuàng)建售后單的功能”，這是個(gè)一句話需求。

分析：該一句話需求，其實(shí)包含了多種具體的訂單類型和場景，那么我們就要拆分調(diào)研，拆分的維度比如：

自營訂單、第三方訂單、貨到付款訂單、先款后貨訂單、部分退貨訂單、完全退貨訂單、服裝事業(yè)部訂單、電子事業(yè)部訂單等，其中每一個(gè)維度就相當(dāng)于一個(gè)小需求。

這里不一一展開。

（2）聚合需求法

拆分法是對單個(gè)需求分解成若干小需求進(jìn)行調(diào)研，聚合法相反，是找到許多個(gè)相互關(guān)聯(lián)的小需求的共性，然后統(tǒng)籌成一個(gè)大需求去完成。例如：

由于業(yè)務(wù)用戶分散在不同的部門，各自為政，于是張三、李四可能都對一個(gè)業(yè)務(wù)流程有相同的需求，或者對同一個(gè)功能有相同的優(yōu)化期望，結(jié)果倆人分別提了需求過來。那么產(chǎn)品經(jīng)理就要找到二者背后的相關(guān)性和交叉區(qū)。

然后統(tǒng)籌規(guī)劃，聚合在一起當(dāng)作一個(gè)需求來調(diào)研，最終輸出一個(gè)整體的需求調(diào)研結(jié)果。

 3、利用輔助功能調(diào)研需求

調(diào)研產(chǎn)品現(xiàn)有功能，可以用來確認(rèn)原有功能的邏輯，或者確定新需求方案是否可行。

比如業(yè)務(wù)用戶需要更新一個(gè)功能，為了避免更新出錯(cuò)或遺漏，產(chǎn)品經(jīng)理需要知道修改前和修改后是否會(huì)能正常運(yùn)行。

最基礎(chǔ)的辦法就是自己設(shè)計(jì)一個(gè)測試用例，記錄操作方式、狀態(tài)變化、數(shù)據(jù)流向等?？纯聪旅娴睦樱?/span>

背景：從銷售網(wǎng)站獲取到OMS系統(tǒng)（訂單管理系統(tǒng)）的訂單信息中帶著顧客的郵箱。顧客下完單，可能會(huì)在銷售網(wǎng)站修改郵箱，而此時(shí)已經(jīng)獲取到OMS的歷史訂單中的郵箱是不變的。

需求：顧客若在銷售網(wǎng)站修改郵箱，要求已獲取到OMS的該顧客的訂單中的郵箱也要同步修改。

分析：需求是很明白的，也有它的意義，但有風(fēng)險(xiǎn)。

因?yàn)槲覀冎烙唵涡畔⒇灤┯谡麄€(gè)訂單流轉(zhuǎn)過程中，牽扯到訂單編輯、審核、取消、配貨、發(fā)貨等，而這些環(huán)節(jié)跳轉(zhuǎn)的觸發(fā)條件可能就是某個(gè)信息更新（這里面就可能包括有郵箱更新）。

因此，更新郵箱是否會(huì)影響流程中的某些環(huán)節(jié)，一時(shí)間很難準(zhǔn)確知道。

于是，我們可以采用預(yù)測試的方式，設(shè)計(jì)測試用例，在測試機(jī)運(yùn)行一些訂單，觀察各個(gè)環(huán)節(jié)郵箱變更的影響，然后收集起來分析對策。

測試法就像是探雷一樣，主要用來解決未知風(fēng)險(xiǎn)點(diǎn)。這個(gè)方式的重點(diǎn)是記錄和分析操作前狀態(tài)、操作位點(diǎn)、操作后狀態(tài)、操作后觸發(fā)的連鎖反應(yīng)、數(shù)據(jù)流向等。

4、“拔蘿卜帶出泥”的方式調(diào)研需求

調(diào)研需求時(shí)，產(chǎn)品經(jīng)理要拔蘿卜帶出泥,挖掘用戶沒看到的需求點(diǎn)和價(jià)值。舉例說明：

背景：公司入駐到銷售平臺(tái)后，銷售平臺(tái)會(huì)對入駐的店鋪的違規(guī)行為進(jìn)行罰款。

需求：業(yè)務(wù)用戶提出需求，將銷售平臺(tái)的罰款數(shù)據(jù)抓取到訂單系統(tǒng)，關(guān)聯(lián)訂單數(shù)據(jù)，以便進(jìn)行人工分析。

分析：

第一步，先拆分需求，確定什么是罰款數(shù)據(jù)，總共有哪些罰款種類，需要對接哪些罰款種類，罰款數(shù)據(jù)與訂單系統(tǒng)關(guān)聯(lián)方式是什么，是否都能關(guān)聯(lián)到，關(guān)聯(lián)不到怎么辦，銷售平臺(tái)是否已經(jīng)提供了公用的罰款接口，Token（請求權(quán)限）如何獲取，抓取頻率怎么樣，數(shù)據(jù)增長幅度多大，獲取之后做哪些展示和搜索，用戶權(quán)限怎么設(shè)置，需要和訂單系統(tǒng)做哪些交互，該需求的價(jià)值是什么……

第二步，挖掘需求：是否需要作分析功能，分析功能的規(guī)則是什么；是否需要做監(jiān)控和預(yù)警，是否需要指派負(fù)責(zé)人；其他業(yè)務(wù)人員是否也有類似需求，其他平臺(tái)是否也有類似需求……

通過“拔蘿卜帶出泥”的方式，連帶出更多需求點(diǎn)。將上述調(diào)研結(jié)果重新組裝起來，得到一個(gè)系統(tǒng)化的完整需求。

羅列出需求要點(diǎn)和對應(yīng)的驗(yàn)收目標(biāo)，這樣使得需求具象化，同時(shí)又不會(huì)遺漏細(xì)節(jié)，內(nèi)部充實(shí)，外部閉環(huán)，并且進(jìn)行了價(jià)值挖掘，做成控制閾值、預(yù)警、責(zé)任人分派、趨勢分析、損失分析等高價(jià)值的功能，超出業(yè)務(wù)的預(yù)期。

 5、需求得分權(quán)重法

該方法的思路就是將需求質(zhì)量的維度進(jìn)行權(quán)重，然后對需求進(jìn)行打分，根據(jù)最終得分的多少排列順序。

可以采用五個(gè)維度：重要、緊急、收益、成本、風(fēng)險(xiǎn)，其中成本和風(fēng)險(xiǎn)是給予負(fù)分，五個(gè)維度的分值權(quán)重分別為30%、30%、20%、10%、10%。

那么一旦對需求打了分，就可以用分?jǐn)?shù)*權(quán)重，得到最終得分。

注意：負(fù)分的要減。并且為了方便計(jì)算，分值最好設(shè)置0.5-5.0之間，或者0-10之間。這樣避免打分的跨度過大出現(xiàn)較大偏差。

如表所示，需求1的得分=

6*30%+6*30%+8*20%-3*10%-7*10%=4.6。而需求2得分3.5，需求3的得分為-0.1。

由此可以判斷需求的價(jià)值順序?yàn)椋盒枨?>需求2>需求3。對于需求3，可以予以淘汰。

以上的維度、分值和權(quán)重可以根據(jù)實(shí)際情況自行設(shè)計(jì)，但是要多考察和驗(yàn)證什么樣的參數(shù)是較為合理的。并且也不能唯權(quán)重得分是從，而只是把它當(dāng)做一個(gè)輔助工具。

6、其他需求調(diào)研工具

需求調(diào)研適合核心環(huán)節(jié)，該過程就會(huì)涉及到很多工具或分析方法，以確保需求調(diào)研高效、高質(zhì)量。

比如問卷調(diào)查、訪談、名義小組會(huì)議、頭腦風(fēng)暴法、觀察法、親和圖、蒙特卡洛技術(shù)、魚骨圖、提示清單等。

? 三、需求的類型和態(tài)度

筆者對B端或泛后臺(tái)產(chǎn)品需求的一個(gè)定性劃分：粗淺需求、噱頭需求、踢球需求、過剩需求、建設(shè)性需求。

1、被動(dòng)的粗淺需求

這類需求，屬于想當(dāng)然的需求，不考慮系統(tǒng)的兼容性和業(yè)務(wù)兼容性的。

比如：電商場景中，要求：若庫存為0，則果斷給予下架；庫存變?yōu)榉?，果斷自動(dòng)上架。

這種強(qiáng)制自然是存在極大風(fēng)險(xiǎn)的。并且?guī)齑鏋?也有曝光的價(jià)值；非零也有下架的場景。二者不等同。

這種情況下實(shí)際是“概念偷換”的錯(cuò)謬，無庫存=下架。

對這類需求，產(chǎn)品可以持保留態(tài)度，持續(xù)觀望，收集更多用戶的深層次數(shù)據(jù)反饋。但不能輕舉妄動(dòng)。

 2、戰(zhàn)略的噱頭需求

這種很好理解，很多公司其實(shí)都是這么玩沒的。

比如：看到競爭對手有的功能，我們要有；對手無的，我們也要有。這樣可以顯得產(chǎn)品更強(qiáng)大。

或者是強(qiáng)行“組合創(chuàng)新”：一個(gè)做醫(yī)藥電商的，你讓他做直播帶貨，且不說是否合規(guī)，你能想象藥師在店里當(dāng)著店長的面做網(wǎng)紅嗎？

這種情況下實(shí)際是“感覺謬誤”。理論上，產(chǎn)品經(jīng)理需要拿數(shù)據(jù)論證的。

所以產(chǎn)品經(jīng)理能做的就是慢點(diǎn)做，保留資源。找機(jī)會(huì)慢慢把意見滲透到高層，試圖止損。

3、隔壁的踢球需求

在多組織的團(tuán)隊(duì)中，這種踢來踢去丟需求的情況相當(dāng)普遍。

比如，對醫(yī)藥商品，配置一段免責(zé)聲明，展示在商城。

那么讓商品后臺(tái)在商品維度加字段并傳給前端，看似從后端到前端，且商品維度的，似乎沒錯(cuò)。但是沒必要的。

因?yàn)?，這是共性字段，商品維度幾乎不需要重復(fù)維護(hù)，也沒有操作差異性。

這類需求，產(chǎn)品經(jīng)理需要從分工、系統(tǒng)職能、收益考慮，將事情客觀表述出來，完成博弈。

 4、客服的過剩需求

這類需求，往往是客服傳達(dá)來自用戶的需求。通常目的很明確，但是對功能設(shè)計(jì)進(jìn)行了干涉，可能影響產(chǎn)品的分析。

比如，客服傳達(dá)某O2O用戶的需求：要在商品的實(shí)際銷售價(jià)旁邊，展示線下零售價(jià)格。

產(chǎn)品：然后呢？

客服：若對比到差異，則修改線上價(jià)？

產(chǎn)品：怎么修改？ 

客服：在線下零售價(jià)的基礎(chǔ)上按公式計(jì)算，比如上漲1%，得出線上零售價(jià)，然后逐個(gè)編輯。

產(chǎn)品：是否可以理解為，目的是讓線上價(jià)格，按自己期望的賣，不取線下零售價(jià)？ 

客服：是 

產(chǎn)品：那么為什么不在根源處理呢：創(chuàng)建一組用于線上銷售的價(jià)格，直接引用不就可以了嗎？

這類問題，一定是要挖掘到用戶的場景的，從用戶的場景下尋求同理心，不受制于現(xiàn)有功能的設(shè)定。

只有這樣才能不受局限，找到用戶的初心。以解決問題為標(biāo)準(zhǔn)。

5、產(chǎn)品經(jīng)理的建設(shè)需求

所謂建設(shè)性需求，可能是每個(gè)產(chǎn)品經(jīng)理心中都有的夙愿。前提是，產(chǎn)品經(jīng)理的決策正確。

比如：自主優(yōu)化產(chǎn)品模型，拆分微服務(wù)，界面統(tǒng)一等，統(tǒng)籌規(guī)劃和重構(gòu)的類的內(nèi)容。

若前四類需求過多，將會(huì)擠壓產(chǎn)品的建設(shè)性需求。

產(chǎn)品經(jīng)理能夠騰出手來做一些真正正確的事情，往往能對全局帶來增益。

推薦大家關(guān)注他的公眾號(hào)：唧唧歪歪PM

?????最后也歡迎有其他面試問題的小伙伴加微信：chanin628 溝通交流。?????

此外我們的官方網(wǎng)站也上線了，每日分享高質(zhì)量的文章、原型素材和行業(yè)報(bào)告，小伙伴可自行前往索取，支持搜索，需要的小伙伴可點(diǎn)擊底部的閱讀原文直接查看，或者復(fù)制網(wǎng)址：www.dadaghp.com 打開。

更多干貨可關(guān)注微信公眾號(hào)：產(chǎn)品劉

想學(xué)習(xí)更多關(guān)于產(chǎn)品、職場、心理、認(rèn)知等干貨，可長按右邊二維碼，關(guān)注我們。

··················END··················

RECOMMEND

推薦閱讀

產(chǎn)品經(jīng)理如何晉升為產(chǎn)品總監(jiān)

B 端設(shè)計(jì)師必不可少的表單設(shè)計(jì)（上）

線下實(shí)戰(zhàn)2.0

面試題，你覺得產(chǎn)品經(jīng)理的職責(zé)有哪些？

點(diǎn)擊“閱讀原文”

查看更多干貨