選讀：Y Combinator SUS - How to Talk to Users

選讀系列我會翻譯我覺得不錯的文章或影片。這個系列的第一篇我選了 Eric Migicovsky 在 Y Combinator Startup School 分享的 How to Talk to Users，這堂課在分享如何和使用者溝通，也就是 YC 認為新創公司唯一該專注的兩件事的其中一個 - 動手做事 (Write Codes) 以及和使用者溝通 (Talk to Users)。

Eric Migicovsky 是智慧手錶 Pebble 的創辦人，同時也是 YC Partner。

進入正題。

https://youtu.be/MT4Ig2uqjTc

內容 Jump to heading #

大家好，我是 Eric Migicovsky，我是 YC 的其中一位合夥人，在 2011 年時我創辦的公司加入了 YC，我創辦的公司叫做 Pebble，我們是最早開始研發智慧手錶的其中一間公司。我很高興可以跟各位分享如何和使用者溝通這個題目，你會不斷的聽人說到這是在創辦公司的過程中非常重要的一個要素。

最好的創辦人會和他的使用者直接對話。不假他人之手！

最好的創辦人在經營公司的整個過程中都和他的使用者持續溝通。為了要在經營公司的不同階段中持續的向使用者蒐集資訊，他們會和使用者保持著直接的溝通。有些創辦人會認為自己是 CEO 或 CTO，需要專注在帶領技術和產品開發，所以他們想將和使用者溝通的工作交給公司裡的其他人，例如聘請業務或是產品經理。重點來了，那些創辦人直接和使用者保持溝通的公司才是最棒的。如果你是 CEO，和使用者溝通是你的職責，如果真的有 CEO 的職務說明，上面應該要有這一項。因此，花點時間學習應該怎麼樣和使用者保持溝通。

所有的創辦人都應該要參與這個過程，不要認為因為你是負責程式開發的部份就能置身事外。電影「Office Space」（上班一條蟲）中有一幕很經典，其中一個角色說「我很會在工程師和使用者間遊走，我知道怎麼跟人溝通，我有 people skills！」，而這是一件你不會想要發生在你身上的事。你應該要確保創辦人和核心成員習得這些技能，而不是聘請這樣的人。

和使用者溝通這件事重要到，在 YC 的核心概念中，新創公司應該只專注在兩件事情，發展產品以及和使用者溝通。

寫程式然後和使用者溝通。

Y Combinator

說得比做的容易，我今天想要提供一些策略上的建議，包括如何規劃使用者訪談以及一些訪談中你可以提出的問題。

許多我今天提供的建議很意外的契合一位 YC 合夥人所寫的「The Mom Test」這本書裡的論述。這本書的書名來自一個我們大概都經歷過的事，當我們向父母介紹我們的公司是在做什麼時，我們以為和愛我們且支持我們的人聊聊，我們就可以發掘出如何改進的資訊，但事實上這不是最好的方法！

1. 談受訪者的經歷，而不是你的主意

The Mom Test

Rob 在「The Mom Test」中提出三個在使用者訪談中常見的錯誤，第一個錯誤我們大概都會犯，就是我們喜歡談我們的主意。我們是創辦人，我們熱愛宣揚我們的主意，我們喜歡介紹我們的產品，但在使用者訪談中，那不是宣揚主意的好時機，使用者訪談的目的是蒐集受訪者的資訊，蒐集可以讓你改善產品、改善行銷方法、改善產品定位的資訊，而不是去推銷受訪者來使用你的產品。使用者訪談的關鍵是去了解受訪者的經歷，去確實的了解你想解決而使用者經歷過的麻煩。

2. 談實實在在的經歷，而不是還沒發生的未來

The Mom Test

第二個我們常犯的錯誤是我們去談假設性的事情，我們談我們的產品「可能」長什麼樣子，我們談那些我們想要做的功能，我們會問「如果我們做這個功能，你會願意使用，或你會願意付費嗎」，這是錯的！取而代之的，我們應該要談那些已經發生在受訪者身上的事，如此一來你會得到更有力且更好的資訊來做產品和做出改變的決定。另外，你也應該要了解受訪者生活的全貌，而非只談你提出的解決方法，試著去問出他們是如何遇到這個問題，試著用廣泛一點的問題去問出他們是怎麼遇到這個問題，去了解他們的動機，去了解為什麼他們會落入這個的窘境。

3. Don't talk, listen.
3. 閉上嘴聆聽

The Mom Test

第三個我們常犯的錯誤是我們很愛搶話，我們說很多話，我們是創辦人，我們總是在說服投資人，我們總是在說服員工，我們總是在招聘，我們總是在找合作機會，所以我們很習慣不停的說話。在一場使用者訪談中，試著去克制自己說話的欲望，試著去聆聽，作筆記，仔細了解受訪者在說些什麼，因為你必須在那十幾、二十幾、三十幾分鐘中盡可能的蒐集資訊，所以當你回到辦公室時，才能帶給其他創辦人真真切切的資訊。

1. What's the hardest part about [doing this thing]?
1. 你在做這件事的過程中最難的部份是什麼？

這裡有五個很適合早期使用者訪談中提出的問題，第一個問題是「你在做這件事的過程中最難的部份是什麼？」，以 Dropbox 為例，你們大多應該都不太記得在沒有 Dropbox 之前的世界，讓我們回到 2005，假裝我們是 Dropbox 創辦人 Drew 當時在 MIT 唸書時試著發想 Dropbox 的雛型，想像你正在 MIT 的電腦實驗室，坐在你的朋友旁邊，你轉向這個朋友，此時你正在進行 Dropbox 這個專案，你想深入了解大家都怎麼分享檔案給其他人，你想知道有沒有潛在的使用者，以及有沒有什麼問題是我可以用這個新科技來解決的，於是你問你的朋友「用學校的電腦進行一個多人專案中最難的部份是什麼？」。你正坐在電腦實驗室裡，這是一個絕佳的機會提出這樣的問題，透過開放的對談去試著了解這個人目前都怎麼進行多人專案，最好的情況是得知具體的痛點，例如他們登入公用電腦後可以從某個地方抓下需要的檔案，像是學校的網路硬碟，但是和他共事的朋友不見得當下可以存取到學校的網路硬碟；又例如你得知他們需要共同編輯一份檔案而造成檔案同步問題，像是同時需要編輯同一份文件時他們會怎麼做。一般來說，最好的新創公司會想解決人們定期遇到的麻煩，或是麻煩大到他們不得不解決，這個問題可以幫助你確定這個麻煩是使用者痛到想主動解決的。

2. Tell me about the last time you encountered that problem...
2. 告訴我上一次你遇到這個麻煩的狀況

第二個問題是關於我前面提到去談確實發生的經歷，而不是假設性的情況，「告訴我上次你遇到這個麻煩的狀況」，這個問題的目標是去了解受訪者遇到這個麻煩的背景，以 Dropbox 為例，你可能從你的朋友那裡得知，一週前的某個時候，這個朋友在和誰共事、在哪堂課程中，是資工相關的還是英文論文相關的，盡可能的蒐集他如何解決這個麻煩的相關資訊，當你在開發產品時，你就可以參照過去確實發生過得案例，然後套用你的解決方法看看是否解決了那個情境的狀況。

3. Why was that hard?
3. 為什麼這個麻煩這麼難以解決？

第三個問題是「為什麼這個麻煩難以解決」，為什麼那個朋友和其他人進行多人專案時很麻煩，他們具體上遇到什麼事情是困難的，你會想問這個問題的原因是你會聽到每個人都有不同的答案，再以 Dropbox 為例，你可能會聽到有些人回饋他們遇到最麻煩的事是，他們得重複的透過 email 來回傳遞檔案，因為他們沒辦法同時存取同一份的文件；你可能又會聽到另一些人回饋他們繳了錯誤的檔案給教授，因為他們的檔名後面有亂七八糟的版本編號。問這個問題的好處不僅是找出你可以解決的問題，你還有機會了解你可以怎麼行銷你的產品，你可以怎麼跟潛在的使用者這個產品的價值和好處。一般來說，客戶買的不是「什麼產品」，而是「為什麼要用這個產品」，以 Dropbox 為例，客戶不會為了這個產品可以同步檔案而感到興奮，他們會因為這個產品可以解決兩個禮拜前他和朋友進行多人專案時遇到的問題而購買。這個問題所得到的答案很可能為你帶來行銷和文案的方向。

4. What, if anything, have you done to try to solve the problem?
4. 你是否試著解決過這個麻煩？

第四個問題是「你是否試著解決過這個麻煩？」，這幾年在幫助 YC 的新創公司的過程中，其中一個我很常遇到的大問題是，如果潛在的客戶並沒有嘗試解決他們遇到的麻煩，那很有可能這個麻煩並沒有「麻煩」到他們會對你提出的解決方法有興趣，這個問題可以讓你找出你想解決的這個麻煩是否有這樣的特性，是否遇到這個麻煩的人嘗試過解決這個麻煩。以 Dropbox 為例，當你在和某個曾經進行過多人專案的人訪談，試者去找出他們試過什麼樣的方法來解決這個麻煩，或許他們把大家集合在一起進行專案，以便即時的討論，或許他們嘗試過用 email，或許 Dropbox 當年上線成為 Hacker News 上最熱門的討論時，他們曾經在下面留言，或許他們嘗試過 rsync 或 SFTP 等工具來解決問題。再強調一遍，你是為了兩個原因而問這個問題，第一，找出人們是否已經嘗試著解決你想解決的這個麻煩，第二，找出有哪些競爭者，當你的產品上線時會被拿來跟哪些產品比較。

5. What don't you love about the solutions you've tried?
5. 你不喜歡你嘗試過得解法的哪個部份？

第五個問題非常的有技術性，「你不喜歡你嘗試過得解法的哪個部份？」，這個問題為你的產品開展了潛在的功能，這個問題讓你了解你的更好的解法應該要包含哪些功能，注意，這並不是在問受訪者「你想要一個新的檔案同步工具有哪些功能」，如果以 Dropbox 為例，因為那是一個假設性的問題，大部分的使用者並不擅長刻劃一個產品的未來樣貌，就像亨利福特曾經說過「當我在發明汽車時，使用者只會想要一匹跑得更快的馬，而不是一部汽車」，這個問題是在特別針對於找出受訪者嘗試過的解決方法有哪些問題，這些要是確實存在的，你可以從比較你的方法和已經存在的方法有哪些不同開始。

就如同我前面提過得，使用者訪談在公司發展的不同階段中都有用，但公司發展的初期（我把他定義為尚未達到 product-market fit 的狀態）中，有三個關鍵的階段是使用者訪談非常有用的，這三個階段分別是構想主題時，在你動手開發前；打造雛型時，在你開始粗略的開發產品時，但還沒有任何一個顧客，甚至是使用者前；第三是上線後，不斷的在迭代改善產品，以達到 product-market fit 時。接下來我想針對這三個階段分別提供一些秘訣。

Idea Stage

Find first users with problem
如何找到有麻煩的初期使用者
- Friends, coworkers, intros
朋友、同事、透過引薦得來的人
- Drop by in person!
直搗黃龍
- Industry events
產業活動

在構想主題的階段，你可能有個靈光乍現的想法、你可能有個粗略的想法、你可能試著想讓某個你夢想中的科技能夠商業化，但你還沒有任何一個使用者，所以你得先找到一個人能夠告訴你他遇到的麻煩，或成為你的第一個使用者。許多人會來問我他該怎麼找到第一個使用者，老實說，很多頂尖公司提供的產品或服務其實是來自創辦人自己的需求，所以你可以從自身開始，試著把你的使用者訪談策略運用在你自己身上，試著回顧過去你遇到那個麻煩時的狀況，接下來你可以去找你的朋友聊聊，去找你的同事聊聊，去找其他人引薦給你的人聊聊，你不需要找很多人，你不需要訪談上千位使用者，所有好的使用者研究都從一兩位使用者開始，重點是達成沒有偏見且細微的訪談，而不是推銷你的構想。

我看過的另一個很棒且有效的方法是，這期的一個 YC 公司想賣產品給消防員，他們發現突兀的發出 email 無法為他們和使用者搭上線，所以他們直接跑到消防局去，他們甚至沒有事先 email 告知，他們直接跑到消防局說「我們想和隊長或任何人聊聊我們對於某個問題的解法」，你知道嗎，這超有用，他們靠著直接拜訪得到數十個 10 到 15 分鐘的面對面談話。當你心中有疑慮時，如果你想從某個使用者族群取得意見，試試直接去找他們談談，這可能有點彆扭，感覺像在強迫他們，換個心態想想，如果你打從心底認為你在為他們解決麻煩，你其實是佔用他們的 15 分鐘在未雨綢繆。

產業活動也是一個能找到潛在客戶聊聊的機會，當我開始開發 Pebble 時，我們去了 CES，那是一個在拉斯維加斯舉辦的大型消費性電子產品展覽，我們沒有攤位，我們很隨性的找人聊天，像是在會場周遭的咖啡店。這樣做不需要任何一毛行銷預算，因為很多產業相關人士會聚集在那裡，而我們知道其中有很多潛在的客戶我可以聊聊。

Idea Stage

Tips
秘訣
- Take notes
做筆記
- Keep it casual
不要太拘謹
- Careful with their time
不要浪費他們的時間

這裡有一些適合這個階段的秘訣，做筆記，仔細的作筆記，因為如同我前面提過得，你不會知道這些訪談的細節中有哪些可能其實很有用，如果你不擅長邊對談邊做筆記，帶個朋友或其他創辦人一起去、詢問受訪者能不能錄音，如果你不確定什麼有用，盡可能的把一切紀錄下來。不要太拘謹，如同我前面提過得，你可以直接去拜訪，你不需要嚴密的事前規劃，你不需要在行事曆上排滿 20 分鐘的訪談，見機行事，事實上在經過 5~10 個訪談後你會漸入佳境，不用覺得你需要一次安排上百個訪談，就從一個、三個、五個開始，直到你抓到訣竅。第三個秘訣是你得注意受訪者的時間，就如同我前面提過得，我們熱愛我們的構想，我們是創辦人，我們喜歡談論我們的構想，但你必須克制自己，不要浪費受訪者的時間，事實上第一次訪談很可能只需要 10~15 分鐘就足以讓你得到足夠的資訊，而你很可能也只需要這樣的時間來進行第一次訪談。

Prototype Stage

Identify best first customers
早出最適合的早期客戶

當你從構想主題的階段進入驗證雛型的階段時，進行使用者訪談可以為你帶來的主要好處是找出誰會是最適合你的早期使用者，這點非常重要，因為不適合的使用者很可能會帶領你走向最終不願付費的困境，我們建立的一個框架來協助你在開始接觸前找出最適合的早期客戶。

Prototype Stage

Find numerical answers to:
找出這些問題的量化的答案
- How much does this problem cost them?
這個麻煩花他們多少錢？
- How frequent is the problem?
他們多頻繁的遇到這個麻煩？
- How large is their budget?
他們有多少預算（權力）？

在這個階段的使用者訪談，我喜歡詢問客戶關於三件事的量化數字，第一個我想深入了解的是，這個麻煩目前會花他們多少錢，而且我希望得到確切的數字，要嘛是解決這個麻煩可以增加他們多少營收，或是他們現在得花多少錢來解決這個問題，他們得浪費多少錢來解決這個問題；第二個我想深入了解的是，他們多頻繁的遇到這個麻煩，是每個小時、每天、每季還是每年，最適合新創公司去解決的麻煩是那些愈頻繁發生的愈好，有兩個原因，第一是他們定期的遇到這個麻煩代表客戶定期的感到痛苦，而這些人對潛在的解決方法回比較有感覺，第二你會想瞄準頻繁發生的麻煩的原因是，你會更有機會了解你的產品是否有解決那個麻煩，以我的 Pebble 為例，我熱愛我的產品是一個應該每天都被使用的設備，每天早上起床你都會戴上你的手錶，這對我來說很棒，因為如果我知道使用者沒有定期的戴上手錶，那就代表我某個地方做錯了，所以最好的早期使用者是那些非常頻繁遇到問題的人；第三個我想深入了解的是，他們解決這個問題的預算有多少，想像你在解決生產線上的某個麻煩，如果你跟作業員訪談，那些真的在生產線上遇到麻煩的人，他們可能很頻繁的遇到這個麻煩，但他們沒有預算解決它，他們沒有權力解決它，那應該是他們的主管負責，某個在總部辦公室的人，所以當你試著找出早期使用者，請務必確認他們真的有能力可以解決這個麻煩。

讓我用范氏圖來視覺化這三組問題的答案，最好的早期實用者就是圖中央的那塊，也就是針對三個問題有最高的量化答案。舉個簡單的例子，假設你在開發一個超級聰明的攪拌機，可以用來製作一種最新最好吃的冰沙，你和幾個使用者談過，像是麥當勞、The French laundry、和 Google 的員工餐廳，你做了一個三行的表格來紀錄訪談的內容，這份資料可以讓你用來決定你應該先從哪個客戶開始下手，舉例來說，The French Laundry 是納帕的一間很棒的餐廳，假設剛好有個機會他們可以運用你的新科技來推出一款頂級炫炮的水果冰沙，每賣出一杯可以為他們帶來不少收入，但賣出的頻率不高，沒有很多 The French Laundry 的客人對水果冰沙有興趣，而你可能是和餐廳的二廚訪談，並了解餐廳並沒有那麼多錢可以解決這個問題，即使他們想要解決。另一個你談過得潛在客戶是某一間 Google 員工餐廳的主廚，很不幸的是 Google 免費提供餐點給員工，所以這個主廚即使採用你的科技，他也不需對盈虧負責，而因為有很多 Googler，所以每週可能會製作很多冰沙，但同樣的，你可以想像這個主廚並沒有預算來解決這個麻煩。你從這些早期的訪談中得知麥當勞是最棒的潛在客戶，即便麥當勞的一款新的冰沙不會帶來多少營收，但他們有超多據點，而且這些據點服務很多客戶，除此之外，你碰巧被引薦認識了「食品長」之類的角色，我不知道他們是不是有這樣的職位，但這個人剛好掌握了數十億的預算，如果他想要解決這個麻煩，他會有權力和預算來執行。你把這些資訊都填進表格裡，你可以很容易的排序出最好的答案，透過這個框架你可以集結所有訪談所得到的資訊，以便找出最適合的客戶。

Launched Stage

Iterate towards Product Market Fit
不斷迭代以達 Product Market Fit 的狀態

最後一個階段，也就是在你達到 product-market fit 的狀態之前，你可以透過使用者訪談得到的好處是，其實就是不斷迭代以達到 product-market fit 的狀態的過程。Paul Graham 把 product-market fit 定義為當你做出了某樣東西是人們想要的，Marc Andreessen 也有一篇很棒的部落格在談 product-market fit，他形容 product-market fit 為當你的產品是被「拉」出來的，當你不再需要將產品推給客戶，他們不斷的從你這裡拉出去。但這些針對 product-market fit 的定義的問題是它們很模糊，它們只能透過回顧得知，你必須已經達到 product-market fit 的狀態才能知道你達成了，所以這並沒辦法幫助你在迭代的過程中知道哪些功能是必要的以達到這個狀態。

你可能聽過一個 app 叫 Superhuman，這是一個超快的 email 軟體，它的 CEO 寫過一篇很棒的部落格文章分享他如何受到 product-market fit 的模糊定義所擾，而且這是一個無法幫助他預測的落後指標，僅能事後才讓他知道是否已經達標，他想要創造一個即時且量化的系統來引導他的公司達到 product-market fit，而其中理所當然的包含了和使用者訪談，他寫了一篇很好的部落格文章，大家可以去 google 一下，我只會粗略的提到內容，但我非常推薦大家去閱讀，因為這真的是太棒了。他在文章裡面介紹了一個流程，每週他會問幾乎所有的客戶一個問題，但其實不需要真的是所有的客戶，可以僅是 30 或 40 個人，「如果你不再能夠使用 Superman，你會覺得如何？」，有三個答案選項，「非常失望」、「有點失望」、以及「不失望」，他會衡量回答「非常失望」的使用者比例，這些是最受惠於你的產品的使用者，你的產品是這些使用者生活中很關鍵的一部分，有點像是融入在他們的生活習慣當中，他讀到某個研究指出當每週有超過 40% 的使用者對於不能再使用你的產品回答「非常失望」，那就是一個訊號、一個分水嶺，一旦你跨過去就代表你的產品會呈現指數型的成長，這篇研究分析了不少成功的公司，發現這個數字幾乎都是 40% 左右甚至更高。我沒辦法談太多細節，但我非常推薦去閱讀這篇部落格文章，如果你正在迭代階段且你有使用者，你可以對你的使用者問這個問題，這對於了解你近幾周在開發的功能是否有助於 product-market fit 是一個非常有用的量化數據。

Launched Stage

Tips:
- Ask for phone # during sign up
在註冊流程中請使用者留下電話號碼
- Don't design by committee
不要用「委員會設計」的方式決策
- Discard bad data
去掉不好的資訊

很適合這個階段的一些秘訣其實很簡單，在使用者註冊的時請他們留下電話號碼，因為很常發生的是當你在觀察使用者行為時，你會疑惑為什麼使用者會這樣做，而且你可能會發現 20% 的使用者有這樣的狀況，這時很有用的一個方法就是打電話給其中一位使用者聊聊，所以我總是建議創辦人們在註冊流程中把使用者的電話號碼放在重要的位置。第二個秘訣是，不要用「委員會設計」的方式決策，你不能直接問你的使用者他們想要哪些功能，你得先了解那些功能是不是真的能讓你的產品變得更被需要且更有用，你可以參考 Superhuman CEO 在他的部落格文章中提出的建議，或者你可以問一些技術性的問題，舉例來說，與其問使用者他們會不會有興趣使用這個產品或這個新功能，不如在你甚至還沒開發出那個功能前說「如果你想要這個產品，這裡有一個升級的選項，請輸入你的信用卡資訊或事先付費」，這可以幫助你了解你在進行的功能是不是使用者真的需要的。第三個這個階段的使用者訪談可以做的是去掉不好的資訊，你可能會遇到的其中一個最差的資訊是讚美，人們可能會說「噢，我超愛這個新的設計」，或是「嘿，這個東西真的超有用」，在使用者訪談中你可能會感覺良好，但這些資訊其實不是很有用，因為它們不夠精確，比較像是對於你的產品的一種廣泛的陳述，對於你可以怎改善無法實質的幫助，第二種主要的不好的資訊是談論遙不可及的廢話，這些僅是假設性的，是無有意義的陳述，當你在使用者訪談的過程中開始談到未來的假設，像是「噢，這是這個產品未來可能的樣貌」，試者後退一步回到確實的經歷，你是在進行使用者訪談，不是在推銷你的產品，而應該是去了解使用者過去遇到的問題，以便你可以想辦法改善。

大概是這樣，這是一個對使用者訪談很快速的認識。