當你在聊需求時,到底在聊什么?

8 評論 4440 瀏覽 48 收藏 9 分鐘

在產品管理和客戶需求溝通的過程中,我們常常會遇到一個普遍的誤區:人們往往將他們認為的解決方案誤認為是需求本身。這篇文章深入探討了需求與方案之間的區別,并提供了實用的策略來識別和處理這一問題。

最近有兩個洞察,它們跟需求溝通有關,也跟人有關。

第一個洞察是產品經理日常溝通中,絕大多數人(包括客戶、銷售、實施、客服、客成等),都不知道什么是需求,他們只是以需求之名,在給你提解決方案,期望讓你這個“傀儡”去幫TA實現自己的目標。

比如銷售同學會跟你說:

境哥,客戶的需求是希望工資報表導出公式,這個如果二開的話,需要多少人天?客戶對接人說,如果沒有這個支持的話,可能會影響合作(??????)

再比如客成會跟你說:

咱們薪資設置跟自定義報表頁面,希望可以取到員工計薪周期最后一天的工時制類型,否則會影響客戶算薪

再比如客服主管跟你說:

咱們工資、考勤的字段計算邏輯比較復雜,客戶會有很多客訴問題,導致客服效率比較低,咱們可以結合現有系統,做一個單獨的頁面,把這些字段的計算的公式、規則都清楚顯示給客戶嗎?

你覺得“工資報表導出公式”、“自定義報表支持工時制類型”、“單獨一個頁面顯示計算公式”是需求嗎?

不是。

可他們明明跟你說的是“找你溝通個需求啊”。

想到這里,就讓我發現了第二個洞察:絕大多數人都喜歡抽象表達,而不喜歡具象化(哈哈,當我寫下這句話的時候,就是對這個洞察最好的印證)。

人們好像覺得抽象化表達,可以隱藏自己的真實想法,避免有一種被人看透的感覺,期望保持對對話的絕對掌控感和主導權,仿佛一旦開口就把自己的問題(或目的)說出來,瞬間就輸了一樣。

比如那位銷售同學,TA其實想說的是:

境哥,我們最近在跟進一家做人力資源外包的A類客戶,他們跟多個公司合作,如果采購咱們的系統的話,他們需要每個月導出對應的工資、考勤報表,讓每個合作方確認,擔心直接給結果會導致對方有疑問時,反復追問,所以最好是可以把對應公式一并導出,她們線下就是這么干的。

那位客成同學想說的是:

客戶會有綜合工時制、標準工時制等不同工時制員工,如果當月發生過轉崗時,希望可以在工資報表中,有效進行篩選與區分,便于最終工資分別核算。

而客服主管想說的是:

咱們系統的工資字段計算邏輯復雜,導致客訴問題較多,最近3個月相關客訴問題有13起,每次客服都需要花10分鐘以上才能解釋清楚邏輯,你這邊有什么好的解決方案嗎?

01 方案 ≠ 需求

方案不等于需求,就像觀點不等于事實一樣,可情感腦總會戰勝理智腦,讓你懶得分辨。

什么是需求?

需求是目的,是回答“為什么”的問題。用一個公式表達就是:需求 = 用戶 + 場景 + 問題

一般會有兩種表現形式:

第一種是大白話式。即誰在什么情況下遇到了什么問題,產生了什么樣的情緒感受。

比如我最近兩天遇到了上述三個案例,每次都需要反復追問(獲取有價值信息)和解釋(避免對方覺得你是拿雞毛當令箭),才能獲取到所需要的信息,產生了一種心累、不想反復解釋的心情。

第二種是用戶故事式。即作為一名[角色],我期望在做[XX]的時候,有一個[XX]功能,以便于實現[XX目的]。

比如作為一名產品經理,我期望客戶(或銷售/客成等)在提需求時,可以直接去且具體的說問題,以便于我可以快速了解需求本身,尋求不同解決方案。

什么是方案?

方案是手段,是回答“怎么辦”的問題。用公式表達的話,就是:方案 = 問題 + 工具/服務。

換句話說,方案是服務于問題本身,不能獨立存在,而它的形態可能是一個工具或一項服務。

比如針對上述三個案例,我可以提供一個標準化的解決方案:需求池+提需求模板解決。

如果你有需求,按需求模板(即描述清楚遇到的問題、現在的解決方案、期望解決方案)先提需求池,我基于需求進行回復,避免過多私聊。

02 如何判斷是需求,還是方案?

第一,如果用戶描述“需求”時,完全跟系統/產品相關,那就是方案。比如“導出報表“、“自定義報表新增工時制”等,本身就蘊含了“系統”在里面,基本就可以判斷它是方案。

它們之間的關系,就有點像用戶問題跟產品之間的關系,用戶的目的不是使用產品,而是解決自身問題。

第二,如果用戶描述“需求”時,完全沒有提到人(或角色)、完全沒有提到問題(或困擾),那就是方案。反之,則是需求;

03 如何解決用戶總是提方案,而不提需求的問題?

如果是口語溝通的話,可以追問三句話:

  • 第一句:“咱們現在是遇到了什么問題?”
  • 第二句:“咱們現在是怎么解決的?”
  • 第三句:“咱們期望的結果是什么?”

如果是書面溝通的話,可以提供一個需求模板:

  • 請描述你當前遇到了什么問題?
  • 請描述當前你是怎么解決的?
  • 請描述你期望的理想結果是什么?

04 總結

今天主要跟你分享了兩個洞察:

  • 絕大多數人(包括客戶、銷售、實施、客服、客成等),都不知道什么是需求,他們只是以需求之名,在給你提解決方案;
  • 絕大多數人都喜歡抽象表達,而不喜歡具象化。

如何有效識別是需求,還是方案?

根據用戶提“需求”時,是否隱含了“系統”在內?或是否沒有描述遇到的問題?如是,則是方案;

如何有效解決提方案,而不提需求的問題?

請使用關鍵三問(即遇到什么問題、現在如何解決、期望結果是什么)。

專欄作家

邢小作,微信公眾號:產品方法論集散地,人人都是產品經理專欄作家。一枚在線教育的產品,關注互聯網教育,喜歡研究用戶心理。

本文原創發布于人人都是產品經理。未經許可,禁止轉載。

題圖來自 Unsplash,基于CC0協議

該文觀點僅代表作者本人,人人都是產品經理平臺僅提供信息存儲空間服務。

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 也有例外的情況,就是專業性很強的需求,你不及業務部門的人員專業,就算明確需求也無法為他們提供需求方案,還是要依賴專業業務人員的方案執行

    來自山東 回復
    1. 嗯,是的,但產品經理對需求的洞察以及提出有效解決方案,跟最終落地執行是自身,還是依賴業務人員,并不沖突

      來自北京 回復
  2. 對方直接將方案是較快實現對方需求的一種方式,但有可能不是最佳方式。
    聊清楚需求僅是第一步,后續還需要積累需求實現方式,以保證功能真正滿足需求,不容易啊

    來自浙江 回復
    1. 對,所以我會推薦“需求是1,方案是0”的方法論,前提就是需要先區分什么是需求,什么是方案

      來自北京 回復
  3. 這個其實很考驗產品經理對需求的判斷力,要判斷這個是真實的市場需求還是看似真實其實沒辦法通過市場檢驗

    來自廣東 回復
    1. 對,這是需要經驗,以及刻意練習的結果

      來自北京 回復
  4. 聊需求就是在找問題和答案嘛,搞清楚要啥,怎么實現,感覺像是在做偵探游戲。????♀?????

    來自遼寧 回復
    1. 哈哈,我喜歡你的這個類比,確實有相似之處

      來自北京 回復