產品經理不做客服,怎么能說了解用戶?

19 評論 16038 瀏覽 129 收藏 17 分鐘

上個月,筆者負責的新產品上線,為了深入用戶中,及時了解用戶需求,解決用戶問題,筆者做了一個月的產品客服。在與大量用戶面對面的溝通中,感觸良多,尤其對如何理解、識別、滿足“用戶需求”,有了全新認識。本篇文章就跟大家分享一些我的收獲。

背景

筆者負責的是一個B端產品,產品上線后的推廣由另外一些同事負責,筆者則專注于客服工作,每天在十幾個微信群來回切換,解答、處理用戶提出的問題。所以本文側重B端產品的介紹,希望對做C端的產品經理也能有一定啟發。

第一部分:B端產品經理,如何深入用戶中?

做產品時,為了避免臆想用戶需求,產品經理一方面需要做自己產品的重度用戶,另一方面需要把自己的觸角伸到其他用戶當中,去傾聽他們真實的聲音。對于B端產品經理,我們經常處于比較尷尬的境地——自己并不是產品的目標用戶,更別談重度用戶了。所以只剩一條路——深入到用戶中,了解用戶真實的使用場景和想法。

對于B端產品,當產品上線后,最高效深入用戶的方式就是做客服和遠程指導。

客服溝通

做客服可以直接與大量用戶面對面溝通,直面用戶問題,既能了解用戶問題、需求背景,不囿于表象,又有足夠大的樣本量,快速發現共性問題,避免樣本量少導致的主觀因素影響。

遠程指導

遠程指導是在無法理解用戶使用場景、不能快速定位問題時使用,借此方式可以清楚的看到用戶要完成某個任務時的操作路徑、習慣。很多小白用戶,因為對產品不理解,會作出很多你想象不到的操作,遠程能讓你看到用戶是如何認識產品的。

第二部分:用戶問題分類,區分對待

產品上線初期,用戶使用產品過程會出現大量問題,大致可以分為產品bug、操作問題、業務問題需求四大類,不同類型的問題,應對方式會有差異。產品經理面對這些問題時,不應該一視同仁,而是要能夠從不同類型的問題里提取為后續產品迭代提供方向的信息。

1. 產品bug

這類問題不必多說,直接影響產品在用戶心中的形象,需要快速定位、快速解決。對于新的產品,用戶大多還是有一定寬容度的,但不能無止境的透支。所以為了不讓產品在用戶心中“信用賬戶”余額過快消耗,團隊要快速響應,快速解決。當時公司領導甚至要求上線初期“bug不過夜”,所以那段時間我們每天都要發新版本,以修復這些漏洞。

2. 操作問題

這類問題是指用戶對產品某些名詞、操作不理解,或者操作出錯導致無法完成任務的問題,例如我要看XX應該在哪看?我要XX應該怎么操作之類的。

用戶出現操作問題的根本原因有兩個:

(1)視角差異

左側是產品經理以自己的理解做的設計,用戶則以右側的視角看產品,我們以為用戶很容易就能理解,實際他看到的可能是另一幅模樣。

(2)遺漏部分場景

我們在產品上線后的第二個迭代,增加了“自動保存”功能,用戶編輯一條信息詳情時,如果沒點“保存”按鈕,直接退出或切到其他頁面,系統會自動把當前最新的內容進行保存。上線這個功能的目的就是為了方便那些忘記點“保存”的用戶,以免填寫的心血付之東流。

一般來說,這個功能可以提升用戶體驗,解決用戶困擾,但當我們上線這個功能后,卻給用戶造成了另一個更大的問題——信息覆蓋。

出現這個問題的場景是:我們產品對于同一條信息,多人都有編輯權限。當多人同時打開同一條信息時,其中用戶A進行編輯,保存退出了,另一個用戶B頁面還在那里,也沒有刷新。所以用戶B頁面信息還是舊信息,當用戶B退出信息編輯頁面后,因為系統的“自動保存”功能,就導致舊信息覆蓋了用戶A編輯的新信息。

當時我們一直以為用戶沒保存成功,保存功能有bug,測試又無法復現,無法修復。導致用戶對產品信心有很大動搖,都不敢繼續使用了,直到一家公司在這個場景下使用時我們才發現,于是當天就把“自動保存”功能去掉了。

所以,如果產品設計之初有些場景沒考慮到,也會造成用戶的一些操作問題,但如果想一開始就把所有場景都設想到,那也不現實。能夠思考到多少用戶使用場景,一方面需要產品經理功力和經驗,另一方面還是需要產品經理深入用戶,及時發現那些被遺漏的場景,快速調整產品策略。

3. 業務問題

這類問題是用戶因為對業務不了解導致的對產品中名詞、規則的不理解。對于很多專業性較強的B端產品,都會遇到這種問題,如果是小白用戶,這類問題更突出,而產品經理能做的,就是多些提示、多些名詞解釋,讓用戶盡量明白些。但要想解釋清楚所有內容,那是不可能的,B端產品業務的專業性決定了較高的使用門檻,所以這類問題產品經理可以適當減少投入精力。

4. 需求

因為用戶能夠與產品經理直接接觸,可以方便的提出自己的需求和想法,所以筆者做客服期間收到用戶提的各種需求、面對這些需求,自然不能照單全收,納入需求池后,如何識別真偽需求?如何識別共性還是個性需求?如何判斷需求優先級等等一系列問題,將在第三部分分享我的一些想法。

在這里要說的是,這些需求無論如何處理,都要給提出人一個回復,以增強用戶的參與感,讓用戶感覺自己也參與了產品的設計,以鼓勵用戶提出更多好的建議。

第三部分:思考與收獲

這部分是筆者做了一個月客服后的思考與收獲,主要是從產品視角,對一開始做得不足的地方的反思。

1. 需求層面

(1)“完美主義”陷阱

業務方、產品經理在產品設計階段,很容易陷入“完美主義”陷阱??傁胫研枨笞黾?,權限控制精準,因此制定的業務規則過于復雜、過于細致。導致產品開發周期變長,產品上線后,用戶使用既不方便,又難以理解。

舉個例子:我們在設計角色權限時,把權限控制得比較細,每個角色能做的操作都做了明確的限制,也投入了比較多的精力開發這個功能。但上線后發現用戶抱怨很多,感覺這也不能做,那也不能做,每走一步都很小心翼翼,生怕一旦寫了什么東西,下次就改不了了。后來我們不得不把部分權限放開,或增加新的有更大權限的角色去完成某些特定操作。

所以,我們考慮產品規則時可以細致,但定義這些規則時,應把握的原則是給用戶更大的空間、更多的權限、更自由的操作,尤其是產品初期,沒有對用戶和業務場景足夠的了解,很容易把“理想的規則”變成“體驗的制約”。

(2)需求的“二律背反”性

需求的“二律背反”性是指同一個功能,對不同的用戶會產生截然相反的影響。

對于B端產品,不同角色的需求沖突更頻繁、更明顯。

我們做需求調研時,業務方需求里有兩個很類似的概念,需要填寫,只是填寫時間不一樣,代表含義沒差別。產品上線后,很多填寫者對這兩個概念不理解,也不明白為什么要有兩個概念類似的值,給填寫造成困擾,增加工作量。所以作為填寫者,他們希望能去掉其中一個。

但提這個需求的是管理者,管理者希望管理更精確,于是導致需求上的沖突,最后還是犧牲了填寫者的需求,保留了這兩個類似的概念。

每個產品,每增加一個功能都要考慮清楚,這個功能給10%的用戶帶來好感的時候是否會給90%的用戶帶來困惑。有沖突的時候要聰明,分情況避免,當無法避免或找不到折中方案時,就需要識別這個需求相關角色的重要性,做出取舍,并想辦法補償被犧牲角色,減少抵觸心理。

每個功能不一定要用得多才是好,而是用了的人覺得好才是真正的好。

(3)“沉默的大多數”

在微信群里做客服,很容易被活躍用戶蒙蔽,讓產品經理誤以為他們提的需求是優先的、緊急的?!敖械庙憽钡挠脩魰谏w沉默用戶需求。

尤其是B端產品,這個現象更明顯,影響也更大。因為我們與各個公司對接人溝通會更多、更頻繁,對接人在反饋需求時,會出現“領導需求優先、對接人需求優先”的情況,而其他角色的需求會有意無意的弱化甚至忽略。

所以在收集這些需求時,需要把需求提出人的角色也記錄上,回頭整理需求池時,就能一目了然的發現哪些角色需求被弱化了,然后針對性的調研被弱化的角色需求,主動溝通,了解這部分用戶的使用痛點。

(4)無處不在的“墨菲定律”

“墨菲定律”是指只要系統有這個可能,那一定有人會這么操作。

這個道理其實很簡單,也很早就明白,但直到深入用戶中后,才深刻體會到,如果一個操作沒有定義好或含糊過去,就一定會有用戶挖出來,成為你產品的槽點,并且造成這樣或那樣的問題。

所以產品經理們,定義需求時,一定要定義清楚哪些能做,哪些不能做,不要含糊處理,否則一定會成為后面的坑。

2. 體驗層面

(1)并不是路徑最短的就是最好的,而是最容易理解、最符合習慣的才是最好的

設計任務操作流程時,我們會盡量把每個任務的流程設計得最短,本著“能少一步就少一步”的原則,讓用戶少做操作,提升體驗,在多數情況下,這個原則是對的,但當“路徑短”與“習慣”沖突時,我們要優先符合用戶“習慣”。

我們產品中有一個配置用戶角色的功能,其中有個角色的配置方式和其他四個角色配置方式不一樣,第一個版本中,筆者把這五個角色都放在一個地方設置,不過這樣會導致那個特殊角色配置流程變長。為了讓路徑最短,第二個版本筆者就把這個角色與其他角色配置地方分開了。

這樣調整后,發現用戶并不買賬,他們其實沒怎么感知到路徑的縮短,而對這種不好理解的設置非常介意,導致我們要花很多時間一遍一遍的解釋。

所以,對于體驗,要重新認識。

  • 體驗是用戶主觀的綜合感受,這個綜合感受很復雜,影響因素很多,不同的變化對綜合感受的影響程度也不同,但結果只有好或不好。原則沖突時,要認清影響更大的因素,優先滿足;
  • 用戶只有好理解了,才能好操作;
  • 每個人都喜歡在自己的舒適區中,這個舒適區就是用戶習慣,在舒適區內的路徑最短才是好的體驗;
  • 能感知到的優化體驗,才是好的體驗,否則用戶不會買賬;
  • 習慣 > 易理解 > 路徑短。

(2)用戶是懶的,但是可以規范的

用戶永遠是懶的,永遠都會找最習慣、最近、最便捷的方式,但并不意味著放任自流。

在微信群里做客服,能夠與用戶實時溝通,實時反饋,但也會造成問題多的時候出現遺漏的情況,所以我們都會建議用戶重要問題發送郵件,避免因遺漏造成更大的問題。

這個原則做產品同樣適用。如果讓用戶改變習慣所獲得回報是值得的,那我們就需要這么做,在用戶可接受范圍培養甚至調整用戶習慣,以換回更大收益。

(3)“用戶思維”知易行難

體驗的好壞與產品經理的用戶思維強弱息息相關,但用戶思維是一個知易行難的事,因為你絕不可能代表所有用戶,每個用戶閱歷、角色、使用產品目的、場景都不一樣,產品經理無法成為那個人,只能盡量“還原”那個人。

“如果我是用戶”這句話,應該換成“根據我對用戶的了解”,這個過程才是用戶思維提升的過程。

好了,我要去做客服了,有人艾特我了。

 

作者:周翔,起點學院深圳1609期產品經理實戰訓練營學員

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

題圖來自 Unsplash,基于CC0協議。

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 我的新書《不枯燥的B端產品實戰課》已上線,更多干貨盡在書里,京東地址:https://item.jd.com/12786741.html

    來自廣東 回復
  2. 很受用,謝謝

    回復
  3. 老哥,書寫完了沒?

    來自湖南 回復
    1. 都在盼著呢

      來自湖北 回復
  4. 從事不同的工作有利于產品思考

    回復
  5. 我贊同你的觀點,我也同意你的做法,但是c端會有很多竟然對手和使壞的人會拼命的想搞你,讓你的產品方向改變,或者拖你的節奏和刁難。時間長了會影響一些心態,望注意

    回復
  6. 你們都是公司沒有客服,產品兼客服角色嗎?

    回復
    1. 人家意思是深入角色中,研究客戶

      來自廣東 回復
  7. 學到了很多,謝謝!現正式入行B端產品,準小白一枚。入職4天了,除了讓我熟悉產品的流程和操作,讓我在做操作手冊熟悉業務三天了,我已經沒有什么思路做下去了,現在處于學習,但是無從下手的狀態。請問有什么指教的地方嗎

    回復
    1. 建議可以結合手頭資料輸出一些框架圖和流程圖,然后想一想是否有可優化的地方。感覺自己準備充分后,可以把輸出結果給leader,并詢問下一步的任務。如有問題,可隨時與我溝通哈。

      來自北京 回復
    2. 好 非常感謝!

      來自河北 回復
  8. 我也會主動去做一下客服,但不是全精力的,而是產品有問題或需要動作的時侯,才會去做客服了解一下,問題出處是否能從客戶得到答案。

    回復
    1. 嗯,產品經理做客服的目的不是真的做客服,而是了解用戶

      來自廣東 回復
  9. 我現在也是產品兼客服??

    回復
  10. 多跟用戶溝通及時了解問題甚至競品信息肯定是有必要的,不過對于形式,我個人認為是要分階段,產品早期可以接手部分客服工作,當用戶量級上去了,應該需要更合理的團隊(售前顧問+客服+售后技術支持)+多個反饋渠道(比如留言+客服QQ+客服400電話)+更詳細的數據統計(數據比人說的靠譜)。

    來自四川 回復
    1. 贊同這個觀點。早期可以多投入一些精力,因為早期產品的不確定性大,對用戶了解太少

      來自廣東 回復
  11. 很多也都是自己遇到的問題,收獲不少,學習了

    來自北京 回復
  12. 做了客服之后,就會很容易被客戶帶動。

    回復
    1. 這也是我寫這篇文章原因之一。記住產品經理做客服的意義,也學會區分用戶反饋

      來自廣東 回復