戳破「用途探索」的 BS：JTBD 只是漂亮的事後諸葛嗎？
身為一個 UX 設計師和產品經理，我欣賞「用途探索」(Jobs-to-be-Done, JTBD) 這個理論，因為它非常「反 BS」（反-廢話，Anti-BS），直指核心：顧客不是在買你的產品，他們是在「雇用」你的產品，來完成他們生活中的某項「任務/用途」。
但我並不是一個盲目的粉絲。相反地，我對這個理論抱持著務實的懷疑：
我擔心它的「規模性」、「統計顯著性」、以及「實作上的容易度」。
當我們拿著一份精彩的案例分析，說「用戶真正的 Job 是『消除身為老闆的焦慮感』」時，我會忍不住懷疑... 這是不是也只是在「事後諸葛」？
我腦中「反 BS」的警鈴會響起，冒出三個同樣尖銳的問題：
這全是「事後諸葛」吧？
- 你怎麼知道這不是你穿鑿附會、過度解讀的？你當然可以把任何購買行為，都歸因到一個很深層的 Job。這跟算命有什麼兩樣？
這根本無法「規模化」
- 要挖到這麼深的「因果旅程」，難道我需要對每個用戶都做一次長達兩小時的深度訪談嗎？這聽起來像藝術，不像是可複製的工程。
「個案」能代表「全體」嗎？
- 就算你真的挖到了一個用戶的「真實 Job」，你怎麼能證明這不是一個特例？我如何能拿這個「個案」去說服我的團隊，砍掉一個已經排程的功能？
這些懷疑是 100% 合理的。
如果我們無法回答這些問題，那 JTBD 對我們來說，實用性就大打折扣。
我的觀點是：這可能代表我們搞錯了「用戶研究」的重點。
一個「反 BS」的 Job，重點不在於模糊的「屬性」，而在於一套清晰、可驗證的「因果關係」。
真正的 Job 不在「表面」，而在「掙扎的因果」
大部分人把「用戶研究」搞砸，也許是因為我們都在「錯的樹」下找答案 (barking up the wrong tree)。
我們可能過度執著於「表面屬性」，例如：
功能 (Features)： 「你希望有 A 還是 B 功能？」「你給這個功能打幾分？」
屬性 (Persona)： 「你是 30-35 歲、住在大安區、年收入百萬的女性...」
意見 (Opinions)： 「你『覺得』這個設計如何？」「你『未來』會想要...」
這可能就是我們所說的「BS」。
這些「表面屬性」頂多是「相關」，但不一定是「因果」。
一個「反 BS」的 JTBD 實踐者，更像是個「偵探」。我們在找的不是「意見」，而是導致「改變」的那個「掙扎 (The Struggle)」。這個掙扎同時包含了功能、情感、和社交層面。
沒有「掙扎」，就沒有「改變」，也就沒有「Job」。
戰術一：如何找到「真實 Job」，而不是「事後諸葛」
你之所以會覺得是「事後諸葛」，可能是因為問錯了問題。
BS 訪談： 「你『未來』會想要什麼功能？」「你『覺得』這個設計如何？」（這是在問「意見」，參考價值可能不高）
反 BS 訪談： 「回想你『過去』決定購買的那一天，在那之前，你都怎麼解決這個問題的？」（這是在問「事實」，這能提供更紮實的線索）
一個好用的「反 BS 偵探工具」，是「購買/轉換時間軸 (The Switch Timeline)」。
我們不問「未來」，我們只問「過去」。我們要像拍紀錄片一樣，重建用戶從「舊方法」切換到「新方法」的完整因果鏈：
第一次動念 (First Thought)： 「那天，發生了什麼事，讓你第一次覺得『舊方法好像不太行』？」
被動尋找 (Passive Looking)： 「你忍受了多久？你有隨便Google 看看嗎？」
主動尋找 (Active Looking)： 「又是哪一天，發生了什麼事，讓你覺得『我受不了了，我今天一定要找到解法』？」（這通常是「掙扎」的引爆點！）
決策與購買 (The Switch)： 「你比較了 A、B、C，最後是什麼讓你選了 A？你下單時，最大的『焦慮』和『期待』是什麼？」
使用與適應 (Onboarding)： 「你第一次使用時，跟你『期待』的一樣嗎？」
當你用這個「時間軸」去訪談，你會發現：
Job 比較不是「猜」出來的，而是「聽」出來的。
Job 不是一個「點」，而是一條「因果鏈」。
那個「事後諸葛」的感覺消失了，因為你擁有的不是「結論」，而是紮紮實實的「證據鏈」。
戰術二：如何驗證「個案」，而不是「自嗨」
好，你透過「時間軸」訪談了 5 個人，發現了 3 個共通的「掙扎」模式。
你怎麼知道這 3 個模式，能代表你剩下的 10,000 個用戶？
我的看法是：質化訪談結束後，才是「規模化」的開始。
JTBD 訪談（質化）的主要目的，不是為了找到「統計顯著性」，而是為了找到「清晰的洞察假說」。
你從 5 個訪談中提煉出的，應該是這樣的「Job 規格 (Job Specs)」：
情境： 當我的團隊擴展到 10 人以上時...
掙扎： 我發現我每天都花 2 小時在 Slack 上問「進度」，我覺得自己像個討厭的「微觀管理者 (Micromanager)」...
Job (任務)： 幫我能「一目了然地掌握進度」（功能 Job），同時讓我感覺「自己是個支持者，而不是監視者」（情感 & 社交 Job）。
現在，你拿著這個「假說」去做「量化驗證」：
設計一份「反 BS」的問卷，發給你所有的用戶。
BS 問卷： 「你是否需要『一目了然的進度看板』？」（1-5 分）
- (這類問題的參考價值不高，因為多數人都會說 5 分)
反 BS 問卷： 「在過去一個月，你有多常感覺自己像個『微觀管理者』？」
反 BS 問卷： 「在過去一個月，你有多常『為了問進度而打斷團隊』？」
看到差別了嗎？
你不是在驗證「功能」，你是在驗證「掙扎的情境」。
如果你的問卷顯示，有 40% 的用戶高度認同那個「掙扎」，你就不再是「個案」。你手上的，是一個已被量化驗證的「高價值市場區隔」。
戰術三：為什麼 JTBD 才是「真・規模化」
只「挖掘意見」很難規模化。
「找因果」是工程，可以規模化。
傳統的「5 個 Why」分析法，有時會流於 BS。因為你往下問 5 次 Why，可能會得到 5 個不同的模糊答案。
但 JTBD 的「時間軸」是有結構的。它只專注在「是什麼『力量』，推動 (Push) 你離開舊方法？是什麼『力量』，拉 (Pull) 你走向新方法？」
這個「推拉動態」的因果模型，是可複製、可傳授、可規模化的。
更重要的是：
Persona (人物誌) 會變： 30 歲的 PM，跟 40 歲的 PM，Persona 不同。
Solution (解法) 會變： 以前用 Excel，現在用 SaaS。
Job (任務) 不會變： 「幫我掌握團隊進度，同時不讓我覺得自己像個渾蛋」這個 Job，在 50 年前、跟 50 年後，都一樣穩定。
一個「反 BS」的策略師，傾向把時間投資在「穩定不變」的資產上。
這就是為什麼 JTBD 看似「無法規模化」，實際上卻是「一種」能幫你建立「長期、可規模化」的產品策略的工具。
結論：JTBD 不只是「事後諸葛」，它更像「因果的診斷」
JTBD 不是一颗能預測未來的水晶球。
它可以當作一套「反 BS」的偵探工具。
它幫助我們減少「猜測」用戶要什麼，轉而多做「驗證」，看看用戶在什麼「掙扎情境」下，才會真正掏錢。
它不只是「事後諸葛」，更像是一種「因果的診斷」——在你的產品還沒屈服於「沒人要用」之前，就幫你找出那個「真正驅動購買」的因果鏈。
我們需要的，也許不是「更多意見」，而是「更少的 BS」和「更清晰的因果」。
行動呼籲
我叫 Zac，一名產品策略長。
我會在這裡分享我打過仗的 MVP 驗證筆記，有成功的，也有像 TOZZI 這樣「關鍵的失敗經驗」。
理論很棒，但 PM 要的是能馬上用的實戰心法。來追我的 Threads @zac.yang吧！