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

英文原文：5 MISTAKES WE ALL MAKE WITH PRODUCT FEEDBACK

譯/天地會珠海分舵；微信公眾號：TechGoGoGo / @techgogogo 

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

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

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

1.  細化反饋獲取對象

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

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

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

解決方案: 其實你應該把不同類型用戶的反饋給區分開來，以下就是一些方法

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

2. 獲取反饋不應是一次性的

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

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

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

解決方案：周期性的跟用戶進行交互。最簡單且有效的做法就是在投放市場后的 30 天，60 天，120 天，1 年這些時間點去找用戶拿反饋。一個更高級的做法是去根據產品/功能點的使用情況去獲得用戶使用反饋。比如，假如你的產品有個日歷的功能點的話，你可以在某 些用戶使用該功能的第 1 次，20 次，50 次的時候來獲取相應的反饋。當一個用戶習慣了某個產品的時候，他們的反饋才會趨逐漸向于成熟和理性。往往用戶第一次使用的時候的反饋是關于該功能如何讓他 困惑之類的，第 20 次使用時候會抱怨該功能讓人沮喪，第 50 次時就會抱怨該功能哪些地方需要增強了。

3. 免費和收費用戶應分而治之

上圖描述的是關于免費用戶和收費用戶不同的反饋，免費用戶通常會不斷的索求新功能：

• 請提供與...同步的功能。
• 這可以放在我自己的主機上面運行嗎？
• 這支持 Atom 協議的 Feed 嗎？
• 請和下面這些...進行集成。
• 可以提供用 Dropbox 作為數據存儲端的功能嗎？
• 請增加一個日歷功能。
• 你如果能提供...功能的話，我就會購買。

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

• 請改善郵件邀請團隊成員加入的功能。
• 請提升搜索性能。
• 請改善團隊協助的功能。
• 請提供更好的檢索工具。
• 請提供任務完成通知功能。
• 請改善任務安排功能，讓其更簡單。
• 請為檢索加速。

如第 1 點所言，我們往往錯誤的把所有的用戶的需求一視同仁，而沒有考慮到他們究竟是付費用戶還是免費用戶。當然，如果細分的話你還要去區分究竟是 50 塊錢的付費用戶還是 500 塊錢的付費用戶，但大處著墨，我們首要區分開來的就是免費和付費的用戶。長期免費使用你的產品的用戶往往只能給你提供如何改進你的免費功能的建議反饋，而 這往往不應該是你的生意應該優先關注的部分。我們提供免費的功能的目的是去把用戶給先粘住，然后慢慢的想辦法讓他們去掏錢購買付費的功能，同時也提高自己 產品的知名度。所以這里你就要注意了，你此時不應去相信那些充滿欺騙的假設性的反饋：“如果...的話，我就會掏錢購買了"， "當...的時候我就會付費了“。這種帶有欺騙性的假定性的反饋往往都是虛無縹緲不足取的，不能兌現的，我們需要的是實實在在的反饋。

解決方案：

• 如果要為你的的付費用戶解決付費功能的話，去找付費用戶拿反饋。
• 如果要勾引那些免費用戶掏錢購買付費功能，去找那些掏了錢的客戶談談。
• 如果要改進你的免費功能點，請那些免費用戶喝喝咖啡吧。算了，我建議你還是別跟他們去喝咖啡了，直接免費的郵件咨詢算了。因為我相信他們的反饋必然是想要更多的功能，免費的功能。

4. 偶發并不代表必然

俗語有云，偶發并不代表必然。當然，這并不能說一些偶發事件一點都不值得關注了。有些偶發事件其實跟容易去驗證其可行性，我們去快速驗證下就好了。

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

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

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

圖左的對話是這樣的：

團隊成員們好，

功能需求：你們是在打造一匹快馬嗎？如果是的話，該馬可以在預期計劃中造出來嗎？

此致敬禮，Dave

Dave,

你好啊。

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

圖右的對話是這樣的：

團隊成員們好，

功能需求：你們是在打造一匹快馬嗎？如果是的話，該馬可以在預期計劃中造出來嗎？

此致敬禮，Dave

Dave，

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

團隊成員，

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

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

上圖的“快馬故事”常常被用來描述那些沒有認真傾聽客戶反饋的情況。當中說明了，如果一個客戶告訴你他想要一個更快的馬的時候，他給你傳遞的信 息就是僅僅告訴你“速度”是馬進行運輸過程中一個很重要的他想要的功能。然后你就會先入為主的圍繞速度這個點展開漫長的開發。返回我們上一點所提到的日歷 這個例子，如果那幾個用戶同時提出來說該日歷的已有事件功能過于復雜了，你可能就會耗費幾個月的時間重新去打造一個流暢用戶體驗的事件表單功能給這些用戶 重新體驗，幾經改版后，最終你發覺其實問題并沒有解決。最終你再去找其他所有使用該日歷功能的用戶獲取反饋的時候，你發覺痛點原來并不是來自這些事件表單 的復雜度，而是在這些事件的可復用性上面。所以你最終的解決該痛點的辦法其實只需要 1 個星期的時間來提供事件循環和事件復制的功能就完事了。

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

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

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