Jobs to Be Done 需求理論
假設我們准備做一個會議紀要工具。從功能出發，很容易列出轉寫、摘要、待辦提取和文檔導出。但這些功能並不能回答一個更基本的問題：使用者為什麼要在會議結束後使用它？
Jobs to Be Done（JTBD）用“使用者想完成的任務”來回答這個問題。它關心具體情境、期望的結果和現有做法，而不是先假定某個功能必然有用。
本章先介紹 JTBD 的基本概念，再說明如何把功能描述改寫為可驗證的需求假設。
1. 從功能轉向任務
Jobs to Be Done 常簡寫為 JTBD。它把產品看作使用者用來完成某項任務的工具。
這裡的“事”，不是待辦清單裡那種表面動作，而是使用者希望自己狀態發生的一種 進展 。比如：
- 不是“我要一個 AI 紀要工具”，而是“我想在會後 10 分鐘內把重點、待辦和責任人整理清楚，別再靠回憶補筆記”
- 不是“我要一個記賬 App”，而是“我想知道錢到底花去哪了，好讓我月底別再焦慮”
- 不是“我要一個簡歷優化器”，而是“我想更有把握地投出一份像樣的簡歷，不想每次投遞都懷疑自己寫得太差”
因此，JTBD 區分了產品的實現方式和使用者需要完成的任務。
這也是為什麼很多看似不同的產品，實際上在競爭同一個 job。使用者想“在上班路上不那麼無聊”，可雇用的對象可能是短影片、播客、遊戲、聊天，甚至打瞌睡。使用者想“快速搞懂一份很長的 PDF”，可雇用的對象可能是 AI 摘要工具、實習生、同事、自己硬著頭皮看，或者乾脆先不看。
因而，一個產品的競爭對手不一定是同類應用，也包括使用者已經在採用的其他做法。
2. 與使用者畫像和功能列表的區別
很多新手剛開始做需求分析時，會先寫使用者畫像：25 歲，女生，一線城市，白領，喜歡效率工具，願意嘗試新產品。這樣的資訊不能說完全沒用，但它通常 不夠解釋一個人為什麼會在此刻採取行動。
JTBD 更關心的是下面這些問題：
- 他是在什麼場景下決定找解決方案的
- 當時到底卡住了什麼
- 他想把什麼事情推進到下一步
- 現在正在用什麼笨辦法撐著
- 如果事情解決得好，什麼結果會讓他覺得“值了”
也就是說，使用者畫像更像“這個人大概是誰”，JTBD 更像“這個人現在到底想完成什麼”。
同樣地，功能列表也容易把人帶偏。使用者說“我想要導出 Word”“我想要 AI 改寫”“我想要語音輸入”，這些都只是表層表達。JTBD 會繼續往下追問：
- 為什麼你現在需要導出 Word，而不是 PDF？
- 你想改寫，是因為文風太差，還是因為需要適配不同對象？
- 你想語音輸入，是因為懶得打字，還是因為你經常在走路、開車、開會後馬上記錄？
很多時候，功能只是 job 的一種臨時翻譯 。如果你只收集功能，很容易把產品做成“使用者說什麼就堆什麼”；如果你能看見背後的 job，才更有機會做出真正順手、真正有競爭力的方案。
3. 例子：會議紀要
假設我們准備開發一個會議紀要工具。如果從功能開始，可以列出：
- 要不要支援上傳音頻
- 要不要接入說話者分離
- 要不要導出 Markdown
- 要不要自動生成待辦
這些都是可能的實現方式。但是，使用者任務可能是：
- 我想在會後 10 分鐘內，把討論結果同步給沒參會的人
- 我想把待辦、責任人和截止時間提乾淨，別讓團隊靠記憶協作
- 我想減少重複整理會議內容的時間，把精力留給決策和推進
由此可以判斷，第一版的重點可能不是“支援 12 種導出格式”，而是：
- 紀要結構要足夠清楚
- 待辦提取要穩定
- 分享連結要方便
- 輸出結果要讓人敢直接轉發給團隊
產品功能的取捨因此可以回到使用者任務上進行。
下面的對照給出了三個場景。切換場景時，注意“產品功能”和“使用者任務”分別描述了什麼。
區分產品功能與使用者任務
情境當我準備應徵一個心儀職位時，
我想快速把現有經歷改得更貼合職位，
以便更有把握地完成投遞，不再邊改邊懷疑自己。
4. JTBD 的五個要素
JTBD 描述通常包含五個要素：場景、觸發、期望的進展、當前替代方案和成功標准。
4.1 場景
使用者是在什麼時刻、什麼環境裡想起這個產品的？
- 是開完會以後
- 是老闆臨時要材料的時候
- 是晚上准備投簡歷的時候
- 是月底發現錢又不夠花的時候
沒有場景的需求，通常都還不夠真實。
4.2 觸發
是什麼讓他決定立刻找解決方案？
- 被長文檔壓住，不知道從哪開始看
- 明天要交材料，今天才發現格式亂七八糟
- 剛被領導追問進度，意識到自己沒有整理清楚
- 想堅持記錄，但手寫、複制、整理都太麻煩
觸發點往往帶著情緒。這個情緒很重要，因為它決定了使用者為什麼會在這一刻產生行動。
4.3 想完成的進展
他不只是想“做個動作”，而是想把自己推進到什麼新狀態？
- 從混亂到清楚
- 從焦慮到安心
- 從拖延到啟動
- 從低效到順手
- 從說不明白到能直接交付
這一步裡，“進展”這個詞非常關鍵。因為很多人真正買的不是工具，而是 狀態變化 。
4.4 當前替代方案
現在沒有你的產品時，他怎麼做？
- 手工複制粘貼
- 用 Excel 或備忘錄勉強支撐
- 找同事幫忙
- 拖著不做
- 在幾個工具之間來回切
誰是替代方案，誰就是你的真實競爭環境。
4.5 成功標准
事情怎樣才算真的被解決？
- 10 分鐘內得到可分享的結果
- 不需要二次大改就能發給別人
- 不容易漏項、出錯、忘事
- 第一次用就知道下一步怎麼走
如果你連“使用者怎麼判斷值不值”都說不清，那這個方向大概率還沒有收斂好。
5. JTBD 句式
當你想梳理一個產品方向時，可以先套這個非常實用的句式：
當 __________ 的時候，我想要 __________，以便於 __________。 現在我只能通過 __________ 來勉強完成這件事。
比如：
當我開完一場資訊量很大的項目會時，我想要快速得到一份帶待辦、責任人和截止時間的紀要，以便於我能馬上同步團隊並推進執行。 現在我只能靠自己回憶、翻聊天記錄和手工整理來勉強完成這件事。
再比如：
當我准備投遞一個新崗位時，我想要快速把已有經歷改寫成更貼合崗位的版本，以便於我能更有把握地投出一份像樣的簡歷。 現在我只能反複複制舊簡歷、手改措辭，改到最後越來越不確定。
如果你能把一句話寫到這種清楚程度，後面的頁面設計、提示詞設計、功能優先級判斷，都會容易很多。
6. 做 AI 產品時，特別要看的三層 job
很多 AI 產品在功能演示時看上去很強，但真正上線之後卻留不住人，常見原因是只解決了表層動作，沒有解決更深的 job。
你可以把一個 job 粗略分成三層來看：
6.1 功能層
最表面的任務是什麼？
- 總結文檔
- 改寫文案
- 提取待辦
- 生成圖片
這是使用者嘴上最容易說出來的一層。
6.2 情緒層
使用者希望減少什麼不舒服，或者獲得什麼感受？
- 不想那麼慌
- 不想顯得不專業
- 不想每次都從零開始
- 想更有掌控感
很多付費意願，實際上和情緒層關係很大。
6.3 社會層
使用者希望在別人眼裡變成什麼樣？
- 看起來更靠譜
- 在團隊裡更有組織能力
- 在客戶面前更專業
- 在社交平台上更會表達
如果你只做功能層，產品很容易被替代；如果你同時理解了情緒層和社會層，你就更容易找到真正有黏性的價值。
7. 用 JTBD 反過來篩產品方向
有時候不是你已經有產品，而是你手裡有 3 到 5 個點子，不知道做哪個。這時 JTBD 很適合拿來做篩選。
你可以拿著每個點子，分別問自己 5 個問題：
- 這個點子對應的場景是不是足夠具體？
- 使用者現在是否已經在用某種笨辦法解決？
- 這個 job 的痛感是否足夠強，或者足夠高頻？
- 如果我做好了，使用者會不會明顯感受到“狀態變好了”？
- 第一版能不能只圍繞這個 job 的關鍵一步，做出一個很小但有用的版本？
如果一個方向講到最後還是只能說“感覺挺有意思”，卻說不清觸發、替代方案和成功標准，那它大概率還只是一個模糊靈感，不是一個成熟方向。
8. 可以直接拿去訪談使用者的問題
很多人一做研究就問：“你想要什麼功能？”這種問法很容易得到表面答案。
JTBD 更適合問下面這些問題：
- 最近一次你遇到這個問題是什麼時候？
- 當時你在做什麼，為什麼會卡住？
- 你最後是怎麼解決的？
- 這個過程裡最煩、最慢、最不放心的地方是什麼？
- 如果有一個工具能幫你，什麼結果會讓你覺得真的有用？
- 你試過哪些替代方法？為什麼它們不夠好？
這種問法有個好處：它會把對話拉回真實經歷，而不是停留在想像中的偏好。
9. 用 AI 幫你做 JTBD 拆解
JTBD 本身不是 AI 發明的，但 AI 很適合幫你整理和提煉 JTBD。
比如你已經收集了 5 到 10 條使用者回饋，就可以把它們丟給模型，讓它按以下結構總結：
請你扮演產品研究助手。
我會給你一些使用者原話，請你不要先給功能建議，
而是先按 Jobs to Be Done 的框架整理：
1. 使用者處在什麼場景
2. 觸發他採取行動的事件是什麼
3. 他真正想完成的進展是什麼
4. 當前替代方案是什麼
5. 他最在意的成功標准是什麼
6. 這些回饋裡反複出現的情緒詞有哪些
最後，請把這些內容整理成 3 個最值得優先驗證的 JTBD 假設。如果你已經有一個點子，也可以讓 AI 幫你做第一輪收斂：
我想做一個 [你的產品想法]。
請不要直接給我功能列表，而是用 Jobs to Be Done 方法幫我分析：
1. 這個產品可能服務哪些具體場景
2. 每個場景中使用者想完成的核心 job 是什麼
3. 現有替代方案有哪些
4. 哪個 job 最適合作為 MVP 的起點，為什麼
5. 請把最終推薦的 job 寫成一句清楚的 JTBD 句子這樣做的好處是，你不會一上來就被 AI 帶去“腦暴 50 個功能”，而是先把方向講清楚。
10. 新手最常見的 4 個誤區
10.1 把 job 寫成功能名
“AI 總結”“智能分類”“自動生成”都不是 job，它們只是可能的實現方式。
10.2 把人群寫得很寬
“所有職場人”“所有學生”“所有創業者”通常都太泛。越泛，你越難看見真實場景。
10.3 只聽使用者說，不看使用者怎麼做
使用者會描述自己想要什麼，但他真正的優先級，常常藏在他現在如何湊合解決問題裡。
10.4 一開始就想做完整平台
JTBD 不要求一開始就覆蓋完整流程。通常應先選擇一個具體場景，並確定其中優先驗證的一步。
11. 使用 AI 整理 JTBD 材料
JTBD 不是 AI 發明的，但 AI 很適合在這套方法裡當你的研究助手、整理助手和對照助手。關鍵是：讓 AI 幫你整理和擴展，而不是替你臆測使用者。
你可以這樣用：
12.1 讓 AI 幫你把模糊點子改寫成 JTBD 假設
當你腦子裡只有一句模糊描述，比如“我想做一個幫大學生找實習的工具”，可以先讓 AI 幫你把它拆成幾種可能的 job：
我現在有一個模糊產品點子：[你的點子]
請不要直接給我功能列表，而是用 Jobs to Be Done 的方式幫我分析：
1. 可能對應哪些具體場景
2. 每個場景裡使用者真正想完成的進展是什麼
3. 當前替代方案可能是什麼
4. 哪個 job 最適合先做 MVP
請最後把每個 job 寫成一句清楚的 JTBD 句子。你甚至可以把輸入寫得很小白：
我想做一個幫大學生找實習的內容。
我現在也說不清具體是做什麼，你幫我想想使用者到底想完成什麼事。AI 可能給出的有用輸出會像這樣：
可能的 JTBD 方向：
1. 當我第一次准備投實習時，我想快速知道應該先准備哪些材料，
以便我不要因為資訊混亂一直拖著不投。
2. 當我看到一個實習崗位時，我想快速判斷自己是否值得投，
以便我不要在不合適的崗位上浪費太多時間。
3. 當我開始投遞時，我想把現有簡歷改成更貼合崗位的版本，
以便我能更快完成投遞並提高通過率。這種輸出的價值在於，它會把你原本一句很泛的想法，拆成幾個更接近真實場景的方向。
12.2 讓 AI 幫你整理訪談原話
如果你已經做了幾次使用者訪談，可以把訪談記錄交給 AI，讓它幫你提煉反複出現的場景、觸發點、替代方案和成功標准。
下面是 5 位使用者的訪談原話。
請不要先給解決方案，而是按 JTBD 框架整理：
1. 使用者處在什麼場景
2. 觸發他採取行動的事件是什麼
3. 他真正想完成的進展是什麼
4. 當前替代方案是什麼
5. 他最在意的成功標准是什麼
6. 哪些資訊在多位使用者中重複出現
最後整理成 3 條最值得優先驗證的 JTBD 假設。一個很簡單的小白輸入也可以這樣寫：
我問了 3 個人，他們大概是這樣說的：
1. 每次要投實習我都得重新改簡歷，特別煩。
2. 我其實最怕的是不知道自己寫得對不對。
3. 我現在會先找學長學姐幫我看，但每次都不好意思總麻煩別人。
你幫我整理一下，他們真正想完成的事情是什麼。AI 可能輸出：
整理結果：
- 共同場景：准備投遞實習前，需要處理簡歷
- 共同困難：不知道如何修改到“夠好”
- 當前替代方案：找學長學姐幫看，自己反複修改
- 可能的 JTBD：
當我准備投遞實習時，我想更快判斷簡歷是否已經達到可投遞水準，
以便我不要一直卡在“再改一改”而遲遲投不出去。這種輸出很有用，因為它幫你從零散原話裡提煉出更像“需求”的內容。
12.3 讓 AI 幫你做一輪輕量級網絡研究
在你還沒開始大規模訪談前，可以先讓 AI 幫你做一些很輕的外部資訊掃描，比如：
- 公開論壇或社群裡，大家是怎麼抱怨這個問題的
- 市面上已有產品主要在解決哪一層問題
- 使用者最常見的替代方案是什麼
- 常見評價裡，大家最滿意和最不滿意的點是什麼
這種研究不能代替真實使用者訪談，但很適合作為 Discover 階段的熱身，幫你先建立問題地圖。
一個簡單輸入可以是：
請你幫我查一查：
“大學生改簡歷、投實習時最常見的痛點是什麼？”
優先看公開論壇、經驗帖、求職社群裡大家自己說的話。
幫我整理成 5 條最常見問題。AI 可能輸出：
常見痛點整理：
1. 不知道簡歷該寫什麼，經歷太少
2. 不知道怎麼針對不同崗位修改
3. 改了很多版，但始終不確定是否夠好
4. 找不到可靠的人幫忙看
5. 投遞流程複雜，容易拖延這類輸出不能當最終結論，但很適合幫你先決定要優先訪談哪類問題。
12.4 讓 AI 充當“反方”
很多時候，我們會對自己的想法太有感情。你可以專門讓 AI 扮演一個挑刺的人，逼你把問題說得更清楚：
請你扮演一個非常嚴格的產品研究顧問。
下面是我的 JTBD 假設：[你的假設]
請從以下角度批判它：
1. 這個場景是否過寬
2. 這個 job 是否寫成了功能而不是真正進展
3. 替代方案是否太弱
4. 成功標准是否不夠清楚
5. 這個假設最需要被驗證的風險是什麼這樣做的好處是，你能更快發現自己是在看需求，還是只是在看自己喜歡的方案。
12. 小結
- JTBD 將分析對象從產品功能轉向使用者想完成的任務。
- 一條 JTBD 假設應說明場景、觸發、期望進展、當前替代方案和成功標准。
- 產品功能是完成任務的一種方案，不應與使用者任務混為一談。
- JTBD 是需求假設，還需要通過使用者訪談和行為證據檢查。
13. 練習
寫清使用者真正想完成的事
- 選一個產品點子，寫下使用者在什麼情況下會需要它。
- 寫清使用者想得到的結果，以及他現在使用什麼辦法代替。
- 找一位可能遇到這個問題的人，問問他最近一次真實經歷。
- 根據對方的原話，改寫你最開始的 JTBD 描述。
最後得到一句普通人能讀懂的話就夠了，不需要為了套公式把句子寫得很複雜。