產(chǎn)品經(jīng)理們總是認(rèn)為特別了解用戶，而實際上，在每一次的迭代策劃中，如果沒有建立在充足的數(shù)據(jù)前，基本上是處于“策劃越進(jìn)，離用戶越遠(yuǎn)”的狀態(tài)，相反，如果產(chǎn)品經(jīng)理所擁有的判斷信息越充足，那么越有利于產(chǎn)品的策劃。而用戶訪談從某種程度上講，也正是產(chǎn)品經(jīng)理進(jìn)行迭代前審時度勢的關(guān)鍵一步，下面進(jìn)入主題。
一、用戶訪談的好處
1.了解當(dāng)前產(chǎn)品的漏洞
我們知道，每一次的迭代發(fā)布前，都會經(jīng)過大量的測試，其實包括產(chǎn)品經(jīng)理、設(shè)計師、測試人員等的參與。優(yōu)勢在于內(nèi)部人員測試的范圍都會從比較專業(yè)的角度出發(fā)，但恰恰也會忽略用戶的真實感受。
當(dāng)不同類型的用戶接觸新的功能時，由于使用方法、認(rèn)知都存在誤差，基本上所發(fā)現(xiàn)的問題都是直接使用的感悟，而這種感悟是產(chǎn)品經(jīng)理少有的，畢竟策劃者在某種情況下并不是正常使用產(chǎn)品的用戶。
2.根據(jù)場景分析需求的適用度
如果說迭代后的產(chǎn)品數(shù)據(jù)呈現(xiàn)不斷上升的狀態(tài)，那么是滿街歡喜的地步，也是產(chǎn)品經(jīng)理希望看到的狀態(tài)。但數(shù)據(jù)并沒有達(dá)到預(yù)期的狀況，那么肯定是需求實現(xiàn)、業(yè)務(wù)出現(xiàn)了問題。這個時候多數(shù)產(chǎn)品經(jīng)理的做法是內(nèi)部分析，不斷地考量，但這種做法很有可能是錯誤的。
主要原因在于沒有真正的用戶場景，去建立業(yè)務(wù)的分析，基本上會按照策劃時的思路，一條道走到黑。舉個例子會更形象，在河邊搭了一條橋，在成功搭建后，卻發(fā)現(xiàn)沒有人來用橋過河，這個時候即使做了分析也停留在內(nèi)部的“臆想”中，真正的方式去咨詢準(zhǔn)備過橋的用戶為什么不去使用了，是哪里出了問題。有了場景化的判斷，產(chǎn)品經(jīng)理才知道當(dāng)前存在的真實狀況，也減少閉門造車的錯誤率。
3.為下次迭代做好充足的驗證準(zhǔn)備
每次產(chǎn)品的迭代都會從綜合維度去考量，一方面去新增新的功能，另外一方面又進(jìn)行原有業(yè)務(wù)的優(yōu)化。這個時候，如果有了上次迭代的訪談分析，那么回大大加強產(chǎn)品經(jīng)理的信心。
二、用戶訪談的注意事項
對訪談的用戶信息進(jìn)行細(xì)化記錄，比如年齡、職業(yè)、使用功能點、使用時間、遇到的問題，相當(dāng)于是在梳理真實的用戶畫像。
確定用戶訪談的側(cè)重點，比如發(fā)現(xiàn)某個用戶經(jīng)常使用某個功能點，那么就從此點出發(fā)，重點記錄與之相關(guān)的問題，比如好在哪里，不好在哪里，還希望可以看到什么等。也就是針對不同用戶使用的點不同，進(jìn)行分層訪談。
對于訪談的記錄，只做一手的記錄，切忌融入自己的主觀感受及分析。比如說用戶認(rèn)為某處的顏色過于沉重，那么記錄的結(jié)果也為顏色過重，不可記錄希望得到亮色的結(jié)論。
三、用戶訪談的處理方式：
當(dāng)記錄好訪談記錄時，產(chǎn)品經(jīng)理首先做的事情是進(jìn)行記錄的拆解，比如哪些記錄是產(chǎn)品需求層面的、哪些是設(shè)計層面，哪些是技術(shù)層面的。
拆解后，將不同類型的記錄結(jié)果傳達(dá)給團(tuán)隊對應(yīng)內(nèi)部成員，讓他們各自進(jìn)行理解。而在信息每一層級的傳遞過程中，產(chǎn)品經(jīng)理如果融入過多感受，那么很有可能干擾其他團(tuán)隊成員的優(yōu)化思路。
最后根據(jù)不同類型的記錄分析，再進(jìn)行產(chǎn)品的優(yōu)化策劃，而不是說用戶說明了哪些問題，就立即去處理。
關(guān)于用戶訪談的部分就到這里。另外在實際協(xié)作中，存在有些團(tuán)隊運營人員也在做用戶反饋，那么這個時候也可以參考訪談的方式去做。同時在進(jìn)行結(jié)果的輸出時，融入從運營角度所發(fā)現(xiàn)的問題，一同整理反饋于產(chǎn)品經(jīng)理。
產(chǎn)品經(jīng)理需要時刻離用戶更近一些~