上個月，筆者負責的新產品上線，為了深入用戶中，及時瞭解用戶需求，解決用戶問題，筆者做了一個月的產品客服。在與大量用戶面對面的溝通中，感觸良多，尤其對如何理解、識別、滿足“用戶需求”，有了全新認識。本篇文章就跟大家分享一些我的收穫。
背景
筆者負責的是一個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）“沉默的大多數”
在微信群裡做客服，很容易被活躍用戶矇蔽，讓產品經理誤以為他們提的需求是優先的、緊急的。“叫得響”的用戶會掩蓋沉默用戶需求。
尤其是B端產品，這個現象更明顯，影響也更大。因為我們與各個公司對接人溝通會更多、更頻繁，對接人在反饋需求時，會出現“領導需求優先、對接人需求優先”的情況，而其他角色的需求會有意無意的弱化甚至忽略。
所以在收集這些需求時，需要把需求提出人的角色也記錄上，回頭整理需求池時，就能一目瞭然的發現哪些角色需求被弱化了，然後針對性的調研被弱化的角色需求，主動溝通，瞭解這部分用戶的使用痛點。
（4）無處不在的“墨菲定律”
“墨菲定律”是指只要系統有這個可能，那一定有人會這麼操作。
這個道理其實很簡單，也很早就明白，但直到深入用戶中後，才深刻體會到，如果一個操作沒有定義好或含糊過去，就一定會有用戶挖出來，成為你產品的槽點，並且造成這樣或那樣的問題。
所以產品經理們，定義需求時，一定要定義清楚哪些能做，哪些不能做，不要含糊處理，否則一定會成為後面的坑。
2. 體驗層面
（1）並不是路徑最短的就是最好的，而是最容易理解、最符合習慣的才是最好的
設計任務操作流程時，我們會盡量把每個任務的流程設計得最短，本著“能少一步就少一步”的原則，讓用戶少做操作，提升體驗，在多數情況下，這個原則是對的，但當“路徑短”與“習慣”衝突時，我們要優先符合用戶“習慣”。
我們產品中有一個配置用戶角色的功能，其中有個角色的配置方式和其他四個角色配置方式不一樣，第一個版本中，筆者把這五個角色都放在一個地方設置，不過這樣會導致那個特殊角色配置流程變長。為了讓路徑最短，第二個版本筆者就把這個角色與其他角色配置地方分開了。
這樣調整後，發現用戶並不買賬，他們其實沒怎麼感知到路徑的縮短，而對這種不好理解的設置非常介意，導致我們要花很多時間一遍一遍的解釋。
所以，對於體驗，要重新認識。
- 體驗是用戶主觀的綜合感受，這個綜合感受很複雜，影響因素很多，不同的變化對綜合感受的影響程度也不同，但結果只有好或不好。原則衝突時，要認清影響更大的因素，優先滿足；
- 用戶只有好理解了，才能好操作；
- 每個人都喜歡在自己的舒適區中，這個舒適區就是用戶習慣，在舒適區內的路徑最短才是好的體驗；
- 能感知到的優化體驗，才是好的體驗，否則用戶不會買賬；
- 習慣 > 易理解 > 路徑短。
（2）用戶是懶的，但是可以規範的
用戶永遠是懶的，永遠都會找最習慣、最近、最便捷的方式，但並不意味著放任自流。
在微信群裡做客服，能夠與用戶實時溝通，實時反饋，但也會造成問題多的時候出現遺漏的情況，所以我們都會建議用戶重要問題發送郵件，避免因遺漏造成更大的問題。
這個原則做產品同樣適用。如果讓用戶改變習慣所獲得回報是值得的，那我們就需要這麼做，在用戶可接受範圍培養甚至調整用戶習慣，以換回更大收益。
（3）“用戶思維”知易行難
體驗的好壞與產品經理的用戶思維強弱息息相關，但用戶思維是一個知易行難的事，因為你絕不可能代表所有用戶，每個用戶閱歷、角色、使用產品目的、場景都不一樣，產品經理無法成為那個人，只能儘量“還原”那個人。
“如果我是用戶”這句話，應該換成“根據我對用戶的瞭解”，這個過程才是用戶思維提升的過程。
好了，我要去做客服了，有人艾特我了。
作者：周翔，起點學院深圳1609期產品經理實戰訓練營學員
本文由 @周翔 原創發佈於人人都是產品經理。未經許可，禁止轉載。
題圖來自 Unsplash，基於CC0協議。