產品狗：^ – ^

……

作為一個產品人，寫到這里再回憶一下那時的場景，瞬間低下頭看了下手表上的心率，果然變高了。

2. 需求質疑的實質

很多人會把這些問題歸咎為溝通層面的問題，例如需求的講解不夠簡單而詳細，沒有讓領導和開發聽懂；又或者說是因為“魅力”的問題（？），讓一個妹子產品經理來說可能就更合適了，當然也會有人說是開發的問題，開發就應該老老實實地接需求做事情就行了……

但一年后，兩年后，三年后這種情況還會出現難道也是溝通問題嗎？

現象反映本質，我們需要看到這類現象背后的實質問題： 團隊內部對目標用戶的認知不統一。

無論是領導、開發、設計還是運營同事，他們盡管會有意識避免自己的主觀偏見，但或多或少都會基于自己的經驗來解讀用戶，自然導致對需求理解的不一致。

說的不好聽點， 他們不信任你的需求結論 ，甚至有些產品人都無法說服自己相信。

很多中小公司項目所謂的經過分析而得出的 需求本身就是畸形的 ，因為需求結論背后的依據大部分是二手貨。

什么是二手貨？就是各類行業市場產品報告中的用戶畫像。

大家的檢索能力都不差，拿到同樣的報告數據，最后大多淪為主觀否定主觀之純憑經驗解讀，那么作為領導、作為同事憑什么相信你的解讀呢？

當這些數據只有少部分人拿到的情況下，數據才是可貴有效的，通過解讀可以拿到超額剩余價值，但數據每個人都能拿到的話，那數據就變成了全行業都得到的相對剩余價值了。

之后就是看能否拿到更為詳細的一手數據，數據越精確越獨立，價值才會越高，解讀才會讓人信服（又卷起來了哈）。

所以，要保證團隊對用戶需求認知的一致，就需要保證基礎的用戶數據是真實有效的，你需要對當前項目的目標用戶進行有效的調研。

二、用戶研究的無

1. 無用研的原因

明白了很多人生道理，但還是過不好這一生。

作為產品人，自然知道用戶研究的重要性，可實際上由于各種原因，用戶研究最終還是不了了之，或者蜻蜓點水而散去。

主要的原因可分為外部和內部。

1）內部原因：產品人的用戶意識不強

產品經理的專業背景一部分是設計專業或心理專業，是有過用戶體驗相關的課程學習和研究經歷的，所以他們的用戶調研意識會比較強，但大多數的產品崗都是跨專業背景更多，尤其是工程技術導向的專業，雖然他們轉行學習過相關的用戶需求板塊，也有基礎的用戶意識，但很難變為行為上的重視。

2）外部原因：公司部門的支持不足

很多的大廠都直接或間接地組建了自己的用戶研究團隊或用戶體驗團隊，但很多的公司是沒有足夠的資源去建立用戶研究部門或者團隊，甚至連用戶研究員都沒有。

大多數小公司，處于成本的考慮，都可能會讓產品經理既要負責交互設計，又要負責產品測試，對于“沒有看得見摸得著的產出”的用戶研究，公司更不會考慮花錢招人了。

產品團隊面對繁多的任務，必定會導致精力的分散，很多人面對用戶研究眾多的耗時耗力的方法望而卻步，就會草草了事，要么電話和幾個用戶對著問題聊聊天，要么就直接花錢買一份報告，好一點的可能會聘請外包的市場團隊進行線下的拉人寫問卷。

當然了，還有其他一些眾多原因，就不再一一列舉了，但 無論是什么原因，都不是不做用戶研究的借口。

2. 無用研的影響

需求，尤其是面對 C端市場 的需求，都需要花費一定的成本去接觸真實的用戶，需求一旦剛開始就弄錯，后面很多都是做無用功，無論是時間還是人力，都是極大的損耗。

1）影響其一：導致立項評審反復修改

俗話說，一鼓作氣，再而衰，三而竭。需求部分作為立項的重要一環，如果各方溝通無法達到統一極易引起對立情緒，業務方會陷入反復修改的時間浪費中。

2）影響二：開發理解不一致，驗收易沖突

在需求評審和技術評估后，項目就進入了開發階段，雖然開發同事明白功能所要實現的整體效果，但他們如果在前期沒有和產品同事保持對功能背后需求的一致的理解，那么很多的細節就會存在問題，因為對于開發來說，“跑通了就問題不大”，若需要修改的東西涉及到底層的架構，那開發分分鐘要撕了產品。

3）影響三：運營方案定位存在問題，ROI過高

嚴格意義上說，運營部門需要在立項的時候就要參與到溝通中，需要了解核心的需求，方便產品開發的時候他們準備方案的制定。

術業有專攻，方案的制定也是耗時耗力，若雙方對需求和定位的理解不一致，最后投入的資金和活動必定是竹籃打水一場空，雙方又陷入鍋誰背的扯皮中。

所以，前期做好用研，保持各方認知一致，能夠很大程度上減少后續的溝通成本和資金浪費。

三、敏捷式用研

1. 解決思路

那么，在沒有用研資源的支持下，作為產品經理如何用較短的時間、較小的成本完成有效的用戶研究活動呢？

首先，強化用戶意識。

當對某事物的意識不堅定的時候，只要是個人，他就不會主動去付諸行動，哪怕是嘗試了，一旦遇到他人的勸說或過程上存在困難，便會輕易放棄。

當你正在準備問卷的時候，同事拿著咖啡走過來看了眼說：“這個我之前做過的，沒有什么用，看看報告就行了。”

當你完成一半的訪談的時候，你發現收集的答復非常凌亂，你心中是不是想過：“收集一半差不多了吧，就把這些數據自己優化處理下，作為自己觀點的論據就行了。”

如果沒有較強的用戶意識，很難堅持下去。

其次，避免學術，敏捷處理。

商業產品，不是學術研究項目，不要帶有書生氣去看待問題，也不要去追求所謂的完美主義。

功能實現不了，那就降低維度換一種方式來實現。

同樣的，用戶研究本身就是一個龐大的領域，不可能短時間內掌握（除非轉崗沉浸其中），若沒有專業人員的支持下， 產品經理只需要系統了解后根據目前項目情況選取合適的方法進行刪減以及恰當的組合即可。

麻雀雖小，但也五臟俱全。

最后，mvp快速試錯，及時調整。

任何一種方法論不可能在初期就能一次成功，作為產品經理一定要在出第一版方案后，先找同事進行快速排查流程問題，再邀請小體量用戶進行預調研，從中發現關鍵問題進行優化，再調整后才可大范圍投入。

方法論并不是一成不變，一個項目結束后，需要針對性進行復盤，在下一個項目中繼續發現問題、優化問題，方法論是隨著項目經驗的不斷增多而越發完善的，會成為產品人的一大筆經驗財富。

2. 定義敏捷用研

敏捷式開發我們知道，那么什么是敏捷用研呢？

我們先看下傳統的用研定義：

用戶研究（User Research）是指基于以用戶為中心的設計理念，為了確定用戶需求痛點、提供設計啟發與優化，通過各種不同方法調查研究產品潛在用戶和現有用戶的而開展的研究活動。

用戶研究根據研究的重點，可分為態度和行為研究，根據研究方法的性質，可分為定性和定量的研究。其常見的方法類別有訪談法、觀察法、問卷法、測試法等。

具體的內容介紹就不多說了，很多文章和書籍有較為完善的說明，大家可以自行檢索歸納。

從上可以看到用戶研究方法眾多，有的涉及到非常專業的知識，包含了社會學、心理學等等，甚至一些嚴謹的活動會用到專業級設備，如眼動儀、生理監測等等。

實際上，我們沒有必要（實際上沒錢沒人）做到如此嚴謹復雜，完全可以根據自己的需要進行方法的改造，主要維持其理念核心（道）不變，方法（術）和工具（器）都可以進行調整，這就是敏捷式用研。

個人將敏捷用戶調研定義為：

基于現有項目限制條件下，選取并組合一定比例的結構性方法來對目標用戶進行分批次的迭代式研究活動。

核心一：現有項目限制條件。

需要根據當前項目的進度，計劃好一定的時間和資源支持，如一人力投入一周、資金預算（獎勵、訪談地點等）3000元。

核心二：選取和組合方法。

時間略短的情況下，可將部分定性和定量方法結合在一起進行某一環節的研究，例如個人訪談和可用性測試。

核心三：分批次迭代式。

如果符合條件可配合研究的用戶有限，可以進行分組，例如原本十人的焦點小組，可以分為兩次五人焦點小組，根據前組情況調整下一組的提問內容。

四、QTI法

QTI法是筆者 根據自己之前用研經歷所使用的方法的總結 ，也可以說是敏捷用研下的一個方法模板。

QTI由Questionnaires（問卷）+Test（測試)+I nterview（訪談）三個部分 組成。

1. 核心要素

1）要素Q：分為問卷調查和主觀體驗量表

問卷在前期可用于篩選用戶群，一方面可以大范圍收集相關的人口學數據，另一方面通過問題的分析可在一群人中篩出適合調研的用戶。

量表主要用于產品測試后的感受量化工作，通過分數來統計用戶的整體感受。

2）要素T：分為可用性測試和協作測試

可用性測試，不僅可用于本項目產品的評估，還可以使用在競品上，幫助發現一些問題，提前避免。

協作測試，如若存在沉默用戶（不發聲思考）或涉及到多人配合使用的產品，可以組織多位用戶進行測試。

3）要素I：分為個人訪談和多人訪談（焦點小組）

顧名思義，訪談對象是個人和多人（狗頭），但一定要分配好活躍用戶或意見領袖的比例。

說了理念，筆者將自己的項目背景作為例子進行簡單使用說明，后續有空再開幾篇文章詳細說下具體的使用流程和操作。

2. 舉例說明

首先大家要明確一點，沒有什么方法是一成不變的，QTI法并 不是嚴格按照順序 進行執行，該方法根據項目的不同情況可進行自由組合和適當增減。

我的一個項目背景：

根據公司戰略，負責一個APP從0到1的落地工作，但因為疫情大環境和支持不足原因沒有做過用戶調研，只是根據報告和競品完成了1.0版本的功能開發，測試包出來的時候，我需要組織用戶調研，一方面就是來挖掘用戶需求以便后續迭代規劃，另一方面就是發現APP的使用問題。

方法實例：

1）向上級申請許可并要到了一些獎品。

2）制定了調研主題、流程和時間安排，完成問卷、訪談綱要、測試任務集和量表設計。

3）向相關用戶群發送有償調查動態，從中選取一批合適的用戶，將參與者分成了個人和小組兩個大類，人數比例基本為1:1。

4）抓3位同事進行預先演練，調整內容描述和流程，再邀請2位用戶進行預調研，確保流程無問題。

5）先進行個人調研，流程為問卷調查、APP可用性測試、量表填寫、問題回顧以及訪談 （QTQII）。

6）將個人分成三組，第一組結束后快速統計問題，調整完操作問題后進行第二組，此時重點關注第一組提及的問題，第二組結束后統計兩組的共同問題，涉及到APP操作問題的迅速反饋給開發，接著進行第三組，針對共同問題可適當側重。

7）個人調研結束后，將三組的內容進行整理，提取關鍵的共同問題和差異點，以此調整后續小組調研的內容，盡快安排開發完成問題修復。

8）將小組人數分成兩個焦點小組，流程為問卷調查、訪談討論、APP可用性測試、量表法以及回顧法 （QITQI）。

9）調研結束后，盡快處理數據統計，遇到疑惑的地方可查看錄制的視頻或音頻，必要的時候可以聯系相關的用戶。對了，別忘了給每個用戶的獎品。

以上就是我當時處理用研的流程，基本上是按照實際情況進行調整的，例如個人和小組的APP可用性測試環節順序是不一樣的，主要是考慮到焦點小組耗時更長，訪談放在后期不容易進行問題的廣泛討論，放在前期效果更好。

以此類推，假如 立項結束，有目標領域報告但無直接競品，打算調研需求，那么如何處理呢？

方法例：

1. 根據市場報告劃定目標用戶所在的用戶群體；
2. 發放篩選問卷，招募10人；
3. 將10人分為三組（4，3，3），協商好訪談時間，準備流程和材料，并進行預演；
4. 對第一組4人發放問卷，根據訪談大綱進行個人訪談，結束后發放獎品；
5. 根據第一組得到的回答情況，適當調整問卷和訪談內容，進行第二組；
6. 根據兩組的回答情況，取出共同點針對性調整，進行第三組，第三組注重共同點的回答；
7. 三組結束后，結合錄像或音頻進行整理，有問題或遺漏的地方詢問相關用戶。

大家發現了，這里只會用到QI，按照實際情況減去了T的內容。

那么再比如： 產品上線了，但使用流程存在問題，已經迭代了一個大版本，需要驗證流程可用性，那如何處理？

方法例：Q（產品使用用戶）+I（焦點小組收集反饋）+T（可用性測試）+Q（量表），當然嚴謹還是需要一批未使用過的用戶過一遍流程。

……

3. 三個問題

無論大家最后是采用大而全的方法好，還是采取短快的敏捷式也好，在面對用戶提出的需求時，都需要注意三個問題：

1. 你所接觸的這個用戶真的是目標用戶嗎？
2. 這個用戶所說的就是用戶真實的想法嗎？
3. 用戶反饋的這個需要可以直接拿來用需求嗎？

第一個問題，如果做一個游戲項目，結果招來的人并不是那么熱愛游戲，那么這個用戶說的話就需要打上一個大大的問號了。

第二個問題，在和用戶接觸的時候，礙于情面或隱私，用戶往往會說出自己認為可能合適的回答，這種回答一旦和產品經理的偏好接近，會直接影響到產品經理的后續判斷。

第三個問題，用戶反饋的內容，即 “我需要一個XX”、“有一個XX功能就更好了” ，這種功能上的回答往往都是基于他們的認知所得出的解決方法，就好比他們想要更快的馬。

作為產品經理不能將用戶所說的需求當作以用戶為中心的圣旨，因為作為商業產品，必定是在商業、需求和技術中取得平衡，產品經理要站在更高的緯度去看待產品，而不局限于一些零碎的說法。

五、結尾

本文從需求質疑現象出發，分析了原因以及解決思路，提供了可供參考的QTI敏捷法，希望大家無論做什么產品，都能夠切切實實去主動接觸自己的目標用戶， 多一些實事求是與變通 ，少一些僵化和偏執。

感謝你看到這里，如果你覺得我的文章對你有用的話，歡迎大家在留言區提問和交流，下次有空的話會寫幾篇文章說說具體的實施步驟和方法細節。

?

本文由 @蘋果核 原創發布于人人都是產品經理，未經許可，禁止轉載

題圖來自Unsplash，基于 CC0 協議