最近筆者在負責一款toB的SaaS產品,在兩周的時間內拜訪了多家企業級客戶,為產品的新業務開展收集了不少意見。本文將分享在此次密集調研客戶工作中的總結與反思,希望能提供給toB產品同行們一點參考幫助~
B端產品經理對業務的理解是否足夠透徹,影響著能否規劃好產品需求。業務調研不夠充分,設計出來的產品方案大多不能滿足客戶的實際需求,難以令人滿意。而B端產品的業務調研方式有很多,客戶調研只是其中一種。
一般B端產品在售出之后,公司都會安排一位專屬的商務人員與客戶保持長期對接。此商務人員因為會經常拜訪客戶現場、指導操作、收集問題等,所以對客戶反饋的需求背景相對有話語權。但是要注意,此種方式收集回來的需求基本都經過商務人員的加工,屬于二手需求,同時又因為商務人員的職責原因,存在夸大客戶需求重要程度的可能性。
產品經理在工作中必須保持數據敏感,每一次不尋常的數據波動,都有可能是業務出現了問題,而B端產品的重要數據通常分為行為數據和業務結果數據。對于筆者目前負責的分銷產品來說,行為數據包括客戶開戶注冊時長、客戶使用功能頻率、商機跟進處理率等,業務結果數據包括訂單數量、銷售額、C端訪客數等。
B端產品的競品資料并不像C端產品那么豐富易得,但還是要盡量去利用各種資源獲取信息。例如:申請公司經費購買優秀友商的產品服務。
這是筆者認為最有效果的業務調研方式。通過與客戶的一對一溝通,可以直面問題,迅速獲取自己想要的答案。同時又因為在客戶現場,可以調研不同角色的客戶,對快速熟悉客戶的業務全貌有很好的幫助。
客戶現場調研,雖然是最有效的業務調研方式,但是成本也是最高的。客戶公司所處城市往往遍布全國,當你舟車勞頓跑到客戶現場,若是因為調研工作沒做徹底,導致調研效果不佳,這對個人或是公司都是一次不小的士氣打擊。
筆者認為,要做好一次效果良好的客戶調研,流程包括明確調研目的->選取調研對象->制作調研記錄表->現場調研->輸出調研報告。
(1)挖掘功能缺陷
要牢記一點,B端客戶對產品的容忍度是很低的。客戶花錢購買了產品,希望享受到業務運轉效率的提升或是業績的增長。當前版本的業務流程,如果因為已經不符合企業運轉的實際需求,導致了客戶損失,那就怪不了客戶的熊熊怒火。
為了盡量避免此類業務缺陷,產品經理除了被動接收客戶的反饋外,平時多觀察數據,多與商務交流,必要時候拜訪調研客戶,便于梳理業務現狀,及時挖掘業務缺陷,防止客戶損失。
(2)為新功能預研
做B端產品不能以上帝視角規劃客戶需求,你難以像C端產品經理一樣成為產品的超級用戶,你認為的產品剛需功能也并不一定是B端客戶們的需求。
要梳理一個新功能模塊對企業運轉效率的提升程度,需要從企業的經營思路、管理模式等多個緯度去發散,通常都會涉及到客戶企業的多種職務人員,所以去到客戶現場預研,是最快確認方案可行性的方式。
區別于傳統外包B端產品,SaaS產品沒辦法為每一個客戶做功能的定制規劃,所以SaaS的每個功能模塊對不同客戶的適配程度不一樣。基于這個原因,為調研目的所涉及到的功能模塊選取正確的調研對象,能夠事半功倍。
(1)客戶畫像
C端產品有用戶畫像,我們B端產品也有對應的客戶畫像:
PS:畫像字段以自己負責的產品業務所需為準。
筆者認為,B端產品的客戶畫像分兩個大類:
通過客戶畫像,結合調研涉及的功能模塊,可以篩選出適合調研的客戶企業清單。
客戶組織架構
選對企業還不夠,我們不能調研企業的所有員工,因此還得選對職務員工。通過企業的組織架構,確認功能模塊的使用者。
例如筆者本次調研主要為了開展新業務:增加客戶關系維護模塊的商機分配和跟進功能,那么,我需要調研的職務對象是銷售主管和銷售人員。
工欲善其事,必先利其器。面對面調研客戶,形似記者進行采訪工作,提前準備問題大綱,避免調研時邏輯混亂,無法得出有效信息。同時,在調研記錄表上寫下客戶的答復,方便調研后查閱,反復研究客戶真實需求。
關于現場調研,主要考驗產品經理的社交溝通和臨場反應能力。其實沒有太多技巧,無他,唯手熟爾。筆者在此分享幾點血淚經驗總結,希望幫助大家少踩些坑。
不論公司有無要求,筆者認為,在調研完成的當天及時輸出調研報告是一個好的工作習慣。既趁著腦里對調研印象還深刻,整理起來比較快速,又在領導面前凸顯了積極和效率。發送報告一般通過郵件,直接發送關聯的同事,同時抄送相關領導和調研的客戶。
B端產品面向企業客戶,產品目標是更好地支持業務運轉。在自認沒有成為業務專家之前,都要虛心向客戶請教,那就免不了需要經常到客戶現場調研。