用戶訪談、釐清用戶需求幾乎是產品經理必備的技能之一,但在 B 端和 C 端的用戶訪談方式略為不同,這篇會記錄我在 B 端公司蒐集用戶需求的方式。
⠀⠀
在 B 端做產品有個特點是使用者通常比較明確,以電商平台的後台為例,真實使用者通常是「商品上架人員、出貨人員、行銷人員」,因此身為 B 端後台的產品經理,我們需要了解「用戶他想要完成的任務是什麼」。
相比 C 端產品可以透過「使用者研究、定期蒐集用戶回饋」來「主動規劃功能給用戶」,B 端產品相對比較「被動」,被動的意思是 B 端產品通常不會在不清楚用戶情境就主動為使用者規劃功能,而是要針對「真實的用戶情境」去提出解方。
⠀⠀
用戶情境是指「用戶在特定環境下與產品互動的情況,包括他們的任務、目標、挑戰和使用條件」,例如:
了解這些任務可以讓 B 端產品經理在規畫每個功能時,更清楚知道「一定要支援什麼情境、不支援什麼情境」。
⠀⠀
那要如何約到「B 端用戶」進行訪談呢?每間公司的做法不太一樣,像是:
比起 C 端可以每個月舉辦用戶研究工作坊,B 端的話滿常需要透過 AM、Sales 才聯繫到對的窗口。
⠀⠀
⠀⠀
在和 B 端使用者的訪談,會有 3 個明確的目的,下面以「電商後台的上架商品」為訪談案例:
⠀⠀
對於 C 端的訪談技巧,市面上有滿多訪談技巧的文章,包含起手式要盡可能「你上次操作 OOO 的經驗是?」、「你對此產品的印象是?」,產品經理可以收集完情境後,回去規劃一個新功能給 C 端使用者。
但 B 端產品會稍微偏向「對方想透過產品解決他原本的什麼任務?」,因此比起 C 端的開發式提問,B 端的提問會更細節,有時甚至會希望對方直接講出他原本的情境,像是問「你平常怎麼處理商品上架作業的?是否可以分享 SOP?」、「你過往使用其他平台的上架功能時,遇到的痛點有哪些?」
⠀⠀
蒐集完對方的任務之後,接著就會開始進行產品初步分析,例如詢問「你原本沒有使用此系統時,是怎麼處理 A 任務的?」、「這個功能和你平常的操作習慣差異在哪?」。
藉由問出「差異點」,來思考如何讓自家系統可以滿足更多情境,雖然無法 100% 滿足每個使用者的情境,但可以盡可能找出最大公約數,產品經理除了收集完對方的期待,也要以「我希望別人怎麼使用產品」的方向來思考產品走向。
⠀⠀
收斂完使用者的需求和期待後,因為不可能每項需求都承接,勢必需要列出優先順序,但 B 端產品的開發優先順序不完全是產品經理說了算,而是納入客戶期待的順序。
因此在訪談時,我們也會請對方提出「針對這 OO項待優化的項目,能不能幫我們列出哪幾項是使用系統的優先項目,沒有優化就不願意執行的」,確保能掌握對方的期待值。
⠀⠀
⠀⠀
用戶訪談過程的技巧,以 B 端的流程如下:
上述和 C 端流程有點差異,C 端的話有時只會收集對方的使用情境,不一定會在訪談過程中向使用者提案。
但 B 端會透過「引導 + 提案」的方式,讓對方半接受系統的現況,並適時提出我們可以修改的範疇,畢竟 B 端產品很難遇到每個客戶就大改一次架構,僅能針對不同情境微調功能,因此在調整功能前,一定要問清楚對方的所有情境,甚至有些訪談場合在當下就要拍板定案解法。
⠀⠀
在訪談前,身為產品經理也滿常被主管提問:
對方回答是或不是,對你規劃功能有什麼具體的影響?是的話你會怎麼做?不是的話你會怎麼改?
因此訪談前要保持:
我對產品走向已有初步的看法,想透過訪談驗證規劃中的功能是否可以解決對方需求。
訪談過程的提案,要留意不能客戶說什麼就按照他的需求做,而是要思考「根據產品多數使用者的操作模式,要如何做才是產品正確的開發方向」,避免落入客製化情境。
⠀⠀
看了好幾篇用戶訪談的文章,但訪談能力仍需要一次次與客戶應對才能培養,進到訪談前需要自己先演練一遍,思考當客戶回答 A 我要說什麼、回答 B 要說什麼,謹記訪談目標「詢問情境、場景提案、收斂需求」。
如對這系列文章有興趣可以再觀看: