都說快速迭代反饋,問題是你的反饋真有效嗎?

0 評論 20322 瀏覽 9 收藏 15 分鐘

大家有做過產(chǎn)品的話,無論是成功還是失敗,應(yīng)該都深有感觸:往往我們無論什么情況都去綜合考慮所有的用戶反饋,其實這是不現(xiàn)實,也不正確的。而去滿足所有用戶的請求更是一個非常愚蠢的行為。

當你在開展一個新的項目,特別是當你在接手另外一個產(chǎn)品的開發(fā)的時候,往往我們都傾向于先去對所有的用戶進行調(diào)研,以便找出產(chǎn)品功能該怎么去定位。而我們的做法往往卻是往著錯誤的方向前行的。事實上我們獲取用戶反饋的過程中反反復復犯的錯誤就有那么5個。當前很多成熟的工具都能讓我們快速的得到用戶的反饋(比如Intercom),結(jié)果我們往往就會因為反饋來得太容易而有點得意忘形而亂開槍,為每個用戶的訴求都去提供實現(xiàn)。

下面我們就好好看下這5個我們常犯的錯誤以及對應(yīng)的解決方案。

1. 細化反饋獲取對象

All-Users

上圖的英語按從左到右再從上到下的順序是這樣的:

  • 所有用戶
  • 新用戶
  • 最近潛水用戶
  • 正在嘗試Beta版本的用戶
  • 長期忠實擁躉
  • 跟所有用戶進行交談獲取反饋是沒有必要的

當你過于發(fā)散的對所有的用戶一起進行調(diào)研的時候,往往你就會丟失掉重點。你往往就會把昨天才剛剛注冊的用戶和一直伴你的產(chǎn)品成長的客戶混為一談;把那些每天都在使用著你的產(chǎn)品的用戶和那些只是偶爾造訪的用戶一視同仁;把那些只用了你的產(chǎn)品的某個功能的用戶和使用了全部功能的用戶相提并論。

解決方案: 其實你應(yīng)該把不同類型用戶的反饋給區(qū)分開來,以下就是一些方法

  • 如果你想要的是增加新客戶,那么去訪談那些新客戶就好了。
  • 如果你想要的是增強某一個功能,那么跟使用該功能的用戶交流就足夠了。
  • 如果你想要知道為什么你產(chǎn)品的某個功能很少人使用,那么就去跟那些不使用該功能的人群溝通就可以了。
  • 如果你想找出你的產(chǎn)品有哪些不足的地方,那么就去咨詢下那些活躍的用戶的看法就解決了。

2. 獲取反饋不應(yīng)是一次性的

Ongoing-feedback

我們對獲取反饋往往存在一個先入為主的想法:在需要的時候才會去尋找用戶的反饋。但這也就意味著往往你需要等上將近一個星期才能獲得想要的用戶反饋。在這種情況下,你通常就會臨時抱佛腳的開始廣撒大網(wǎng) – 開始主動的找所有的用戶來問各種不同的問題,這你又重新犯了上面的第一條錯誤了。

這個錯誤的做法其實帶來了雙倍的害處:

  • 首先是當你真正需要有反饋給你進行分析的時候你卻兩手空空如也;
  • 其次是你只有在決定主動找用戶調(diào)研的時候你才會得到有關(guān)你的產(chǎn)品的反饋。這就意味著你對你的產(chǎn)品就算已經(jīng)逐漸被市場淘汰也一無所知了。

解決方案:周期性的跟用戶進行交互。最簡單且有效的做法就是在投放市場后的30天,60天,120天,1年這些時間點去找用戶拿反饋。一個更高級的做法是去根據(jù)產(chǎn)品/功能點的使用情況去獲得用戶使用反饋。

比如,假如你的產(chǎn)品有個日歷的功能點的話,你可以在某些用戶使用該功能的第1次,20次,50次的時候來獲取相應(yīng)的反饋。當一個用戶習慣了某個產(chǎn)品的時候,他們的反饋才會趨逐漸向于成熟和理性。往往用戶第一次使用的時候的反饋是關(guān)于該功能如何讓他困惑之類的,第20次使用時候會抱怨該功能讓人沮喪,第50次時就會抱怨該功能哪些地方需要增強了。

3. 免費和收費用戶應(yīng)分而治之

Free-vs-Paying-new

上圖描述的是關(guān)于免費用戶和收費用戶不同的反饋,免費用戶通常會不斷的索求新功能:

  • 請?zhí)峁┡c…同步的功能。
  • 這可以放在我自己的主機上面運行嗎?
  • 這支持Atom協(xié)議的Feed嗎?
  • 請和下面這些…進行集成。
  • 可以提供用Dropbox作為數(shù)據(jù)存儲端的功能嗎?
  • 請增加一個日歷功能。
  • 你如果能提供…功能的話,我就會購買。

而收費用戶跟多的是要求對已有功能進行改進:

  • 請改善郵件邀請團隊成員加入的功能。
  • 請?zhí)嵘阉餍阅堋?/li>
  • 請改善團隊協(xié)助的功能。
  • 請?zhí)峁└玫臋z索工具。
  • 請?zhí)峁┤蝿?wù)完成通知功能。
  • 請改善任務(wù)安排功能,讓其更簡單。
  • 請為檢索加速。

如第1點所言,我們往往錯誤的把所有的用戶的需求一視同仁,而沒有考慮到他們究竟是付費用戶還是免費用戶。當然,如果細分的話你還要去區(qū)分究竟是50塊錢的付費用戶還是500塊錢的付費用戶,但大處著墨,我們首要區(qū)分開來的就是免費和付費的用戶。長期免費使用你的產(chǎn)品的用戶往往只能給你提供如何改進你的免費功能的建議反饋,而這往往不應(yīng)該是你的生意應(yīng)該優(yōu)先關(guān)注的部分。

我們提供免費的功能的目的是去把用戶給先粘住,然后慢慢的想辦法讓他們?nèi)ヌ湾X購買付費的功能,同時也提高自己產(chǎn)品的知名度。所以這里你就要注意了,你此時不應(yīng)去相信那些充滿欺騙的假設(shè)性的反饋:“如果…的話,我就會掏錢購買了”, “當…的時候我就會付費了“。這種帶有欺騙性的假定性的反饋往往都是虛無縹緲不足取的,不能兌現(xiàn)的,我們需要的是實實在在的反饋。

解決方案:

  • 如果要為你的的付費用戶解決付費功能的話,去找付費用戶拿反饋。
  • 如果要勾引那些免費用戶掏錢購買付費功能,去找那些掏了錢的客戶談?wù)劇?/li>
  • 如果要改進你的免費功能點,請那些免費用戶喝喝咖啡吧。算了,我建議你還是別跟他們?nèi)ズ瓤Х攘?,直接免費的郵件咨詢算了。因為我相信他們的反饋必然是想要更多的功能,免費的功能。

?4. 偶發(fā)并不代表必然

Vocal-Minority

俗語有云,偶發(fā)并不代表必然。當然,這并不能說一些偶發(fā)事件一點都不值得關(guān)注了。有些偶發(fā)事件其實跟容易去驗證其可行性,我們?nèi)タ焖衮炞C下就好了。

但,當有一天你發(fā)現(xiàn)有5個用戶同時給你反饋說想在你的日歷功能中增加一個事件提醒功能的時候,你不要立刻拍腦袋就去組建人員開始立項。你首要去做的是去確定這5個用戶是否代表了所有其他的用戶,你要去跟其他經(jīng)常使用日歷功能的用戶進行交談,聽聽他們是怎么說的。

解決方案:先把偶然發(fā)生的請求當作一個假設(shè),別急著去實現(xiàn)它,先去驗證它是否真存在價值。一旦你發(fā)現(xiàn)它真的是一個痛點的時候,也別急于立馬去“實現(xiàn)滿足用戶請求的方案”,你需要再挖深點。這就到了我們下面將要談的最后這一點了。

5. 用戶往往表達不清楚想要什么

horse

圖左的對話是這樣的

團隊成員們好,

功能需求:你們是在打造一匹快馬嗎?如果是的話,該馬可以在預(yù)期計劃中造出來嗎?

此致敬禮,Dave

Dave,

你好啊。

我們已經(jīng)把你的反饋需求納入計劃中了,我們將會在2015年第一季度把該更快的馬交到您的手上。下圖是該馬的原型。

圖右的對話是這樣的:

團隊成員們好,

功能需求:你們是在打造一匹快馬嗎?如果是的話,該馬可以在預(yù)期計劃中造出來嗎?

此致敬禮,Dave

Dave,

你好啊。很感謝你提出對馬的速度的重要性非常感興趣,你還有其他需要我們可以改進的嗎?

團隊成員,

速度當然是很重要的一點了,但總的來說可靠性和耐力也同樣的重要了。一匹可以讓我一天能從甘肅跑到北京的馬對我來說就最好不過了,不然我要運到北京賣的切糕就過期了…

“信息傳遞的過程中很容易產(chǎn)生失真!”,一個很生動的詮釋這種情況的例子就是:“當客戶用手指指著月亮的時候,我們天真的產(chǎn)品經(jīng)理往往就會伸出自己的中指好好觀察,沉思該用戶想表達的究竟是他的手指出了什么問題呢還是客戶在伸出中指對自己進行侮辱。而事實上用戶真實想要的是月亮”。

上圖的“快馬故事”常常被用來描述那些沒有認真傾聽客戶反饋的情況。當中說明了,如果一個客戶告訴你他想要一個更快的馬的時候,他給你傳遞的信息就是僅僅告訴你“速度”是馬進行運輸過程中一個很重要的他想要的功能。然后你就會先入為主的圍繞速度這個點展開漫長的開發(fā)。

返回我們上一點所提到的日歷這個例子,如果那幾個用戶同時提出來說該日歷的已有事件功能過于復雜了,你可能就會耗費幾個月的時間重新去打造一個流暢用戶體驗的事件表單功能給這些用戶重新體驗,幾經(jīng)改版后,最終你發(fā)覺其實問題并沒有解決。最終你再去找其他所有使用該日歷功能的用戶獲取反饋的時候,你發(fā)覺痛點原來并不是來自這些事件表單的復雜度,而是在這些事件的可復用性上面。所以你最終的解決該痛點的辦法其實只需要1個星期的時間來提供事件循環(huán)和事件復制的功能就完事了。

解決方案:請清楚認識到,客戶提出的功能需求其實摻雜著他們自己對設(shè)計的理解,對你的產(chǎn)品的熟悉程度,以及他們對自己所認為的痛點的理解。他們其實并不清楚你的產(chǎn)品的愿景是什么,你正在完善功能的方案是怎么一回事,以及什么樣的技術(shù)是最可行的。所以這就是為什么你往往需要在用戶的需求上再做一層到兩層的抽象提煉,直到發(fā)現(xiàn)真正的用戶痛點,這樣才能讓所有的用戶都受惠。

當然,在一些已經(jīng)成為共識的功能點上面,我們并不需要每次都檢查上面的幾點用戶反饋才能行動,比如在我們中國,你一個日歷工具加上個農(nóng)歷功能我相信沒有多少用戶會反對的。

但,在其他需要用戶協(xié)助才能確定的功能上面,請你還是按照上面的幾步跟你的客戶好好互動并獲得有效的反饋進行分析,這會讓你的行動變得更理智,更聰明,更敏捷。

#專欄作家#

朱佰添,網(wǎng)名:天地會珠海分舵,微信公眾號:techgogogo。人人都是產(chǎn)品經(jīng)理專欄作家兼高級翻譯官。9年軟件行業(yè)從業(yè)經(jīng)驗,涉獵海外最新創(chuàng)業(yè)、融資、產(chǎn)品類的資訊和方法論,喜愛結(jié)交各行各業(yè)的朋友,歡迎聯(lián)系。

本文系作者授權(quán)發(fā)布,未經(jīng)許可,不得轉(zhuǎn)載。

更多精彩內(nèi)容,請關(guān)注人人都是產(chǎn)品經(jīng)理微信公眾號或下載App
評論
評論請登錄
  1. 目前還沒評論,等你發(fā)揮!