大多數上線前的使用者研究都是一場戲，最糟的是雙方都心知肚明台詞。你問「你會用這樣的東西嗎」，電話另一頭的人——出於禮貌、毫無利害關係、想像著一個根本不存在的產品——會說「會」。你把它記錄為驗證。其實不是。那只是陌生人對一個假設情境的客套回應。
我以前虔誠地執行這類訪談，因為每本產品策略書都這麼教。寫程式碼之前先跟五十位使用者聊聊，找出痛點，先驗證問題再談解法。這聽起來很有紀律，寫在白板上也很好看。但十通探索性訪談的實際產出，是十個人告訴你他們認為你想聽的話，還經過他們自己對某個問題模糊記憶的過濾——而這個問題自訪談開始後他們根本沒再想過。沒有人故意騙你，他們只是還沒有那些資訊——因為在東西真正存在之前，那些資訊根本不存在。
訪談無法產生的東西
在動手開發前，你真正需要知道的是行為層面，而非態度層面：這個人會不會再次打開這個應用程式、會不會付費、會不會卡在第三個畫面就放棄。這些都不會出現在對話裡，而是出現在操作紀錄回放、流失率圖表、客服工單裡。使用者可能非常真誠地告訴你，引導流程「說得通」，然後四十秒後就放棄——因為自我陳述和實際行為，是兩種衡量不同事物的工具。
過去的經濟考量無論如何都會迫使人先訪談再開發。如果做出東西要花八週、三名工程師，你負擔不起等上線後才發現方向錯了——所以你把風險提前壓進廉價的對話裡，寄望它們能抓出那些昂貴的錯誤。當開發本身是瓶頸時，這樣的取捨很合理。但現在不再是了。一個能運作的原型——真正的驗證機制、真正的資料庫、使用者能實際點擊操作的介面——如今只要用對工具（包括我開發的工具），一個下午就能做出來。一旦第一版的成本降到這種程度，訪談就不再是廉價的風險降低手段，反而成了昂貴的步驟。你正在用好幾週的行事曆時間，去避免一個只需一個週末就能完成的開發工作。
我改用的做法
先做出這個點子最小可行的真實版本，找三到五位真正有這個問題的人來試用，然後觀察，而不是提問。不是問「你覺得怎麼樣」，而是看游標在哪裡猶豫、點了什麼卻沒有反應、嘗試做什麼但產品根本不支援。最後這一點才是真正的寶藏：他們在沒人提示的情況下嘗試去做的事，比他們在假設性訪談中告訴你的任何話都更真實，因為那是顯露偏好，而非陳述偏好。
這顛倒了傳統的研究漏斗，值得明確說明改變了什麼：
| 先訪談 | 先開發 | |
|---|---|---|
| 你在衡量什麼 | 陳述的意圖（「我大概會用這個」） | 顯露的行為（他們這週打開了三次，或是根本沒打開） |
| 犯錯的成本 | 每次循環成本低，但你可能在數十場訪談中錯了好幾個月 | 一次開發循環，數據就能快速修正你 |
| 最好問的問題 | 「你現在的做法有哪裡讓你覺得困擾？」 | 「讓我看看你上次在這裡嘗試做 X 的情形」 |
| 它擅長發現什麼 | 問題是否真的存在 | 你的具體解決方案是否有效 |
| 失敗模式 | 每個人都很客氣，沒人說實話，你自信滿滿地做出錯的東西 | 你在還沒建立信任前就推出粗糙的成品，留下不好的第一印象 |
注意這兩列並不會互相抵消——它們回答的是不同的問題。訪談擅長確認問題確實存在，但不擅長告訴你你的具體解決方案是否正確，因為你的具體解決方案根本還不存在，沒人能對它做出誠實的反應。這正是大多數「多與使用者交談」建議忽略的區別：這對於發掘問題來說通常是好建議，但對於驗證解決方案卻是壞建議,而人們常常兩者都套用。
我認識的一位創辦人為一款針對美髮沙龍的排程工具做了十四場訪談。十三位受訪者都說重複預約的問題確實存在且令人頭痛。她因此把產品做了出來,結果採用率卻毫無起色。原來沙龍老闆們在抽象層面上確實討厭重複預約，但他們早已建立了不想放棄的脆弱個人變通方法——這件事沒有人提起,因為除非你能展示替代方案並親眼看到他們拒絕使用,否則沒有人會想到要描述自己的應對機制。
批評者說對的地方
這個道理並非放諸四海皆準，若我假裝它是,那就是言過其實了。如果建置成本真的很難逆轉——硬體、受監管的醫療流程,或是每次變更都要走合規審查的東西——那麼「先訪談」的算盤就會反過來,因為讓「先建置」變得划算的成本不對稱性在那裡根本不成立。一個下午就能丟掉的原型,和一個已經開模具的裝置,完全是兩回事。
另一個研究能發揮價值的地方，是銷售週期長的企業銷售。如果你的買家是採購委員會,銷售週期長達四個月,你就無法靠「先出貨再觀察」來拿到簽約合約——你需要在建置之前就知道這個產品是否能通過安全審查,因為一筆在六個月後被拒絕的交易,代價遠高於任何訪談。此外,純粹的問題發掘——早期且成本低廉地進行,坐在旁邊觀察對方實際執行工作,而不是要求他們想像未來的產品——確實還被低估,也確實很有用。我並不反對與人交談,我反對的是把一場客氣的假設性對話當成證據,而其實一個粗糙但真實的成品放在同一個人面前十分鐘,就能告訴你真相。
