JTBD

Properties2
tags狀態/草稿, 領域/ux, 領域/設計, 領域/pm, 領域/設計思考
aliasesJobs To Be Done, Jobs-to-be-Done, 待辦工作理論, JTBD 框架

閱讀時間約 10 分鐘

JTBD

一句話定義

把使用者不視為人物特徵而視為「處於某個情境、想完成某件工作的雇主」的需求框架——核心句型 「When [情境], I want to [動機], so I can [結果]」——讓設計者把焦點從「誰是用戶」（人物誌）轉到「用戶想做什麼工作」（任務情境）。

核心要點

標準句型

When _________________, I want to _________________, so I can _________________
當    [情境]            ，我想要    [動機]              ，我才能    [結果]

範例

當我剛搬到一個新城市時，我想要認識志同道合的人，我才能交到興趣相投的朋友。

→ 三段對應使用者的「處境 / 動機 / 終局收穫」——產品設計師看完這句，就知道要解的「工作」是「協助新搬入者建立社交圈」，而不是「設計交友 App」。

元命題：人是把產品「雇」來完成工作

Clay Christensen：「People don’t want a quarter-inch drill, they want a quarter-inch hole.」（人不要 1/4 英寸的鑽頭，他們要 1/4 英寸的洞。）

→ 進階版：他們要的不是洞，是架在牆上的家庭照；最終要的是有家的感覺。JTBD 把產品設計從「功能規格」推到「深層工作」。

為什麼比人物誌好用（補位場景）

人物誌 的失敗模式：把使用者貼上永久人格標籤（「30 歲女性 / 喜歡瑜伽 / 月薪 5 萬」），但同一個人在不同情境下會雇用完全不同的產品——

  • 上班通勤時雇 Spotify「讓我隔絕嘈雜」
  • 健身時雇 Spotify「讓我維持節奏」
  • 睡前雇 Spotify「讓我快速入睡」

→ 同一人 / 同一產品 / 三個 jobs。人物誌看到「她」、JTBD 看到「她在三個情境下要解的三件事」。情境變化 > 人格變化 是 JTBD 的設計起點。

三類 jobs

  • Functional jobs（功能性工作）— 可量化的任務完成（「快速到達公司」）
  • Emotional jobs（情緒性工作）— 對自己的感受（「覺得自己有效率」）
  • Social jobs（社會性工作）— 對他人展示的形象（「在同事面前看起來像個努力的人」）

→ 同一個 functional job 背後常有更深的 emotional / social job——這才是真正的設計入口。

切換決策層：Customer Forces

Customer-Forces 補上 JTBD 的下一個問題：使用者知道自己有 job，不代表他會從 old way 切換到你的 new way。Ash Maurya 的 The Innovator’s Gift 把創新焦點放在「舊解法如何創造新問題」：

  • Old way：顧客現在雇用什麼既有替代品完成 job？
  • Trigger / push：什麼事件或不滿讓他想離開舊方式？
  • Pull：新解法承諾的結果是否足夠有吸引力？
  • Inertia / friction：舊習慣與新方案風險如何阻止切換？

→ JTBD 描述 job；Customer-Forces 描述 switch。沒有 switch 動機的 job，只會停在研究洞察，不會變成採用。

句型常見錯誤

  • ❌ 加入解法：「When 我想學設計時，我想要報名 Unblock 課程，so I can 成為設計師」——「報名 Unblock 課程」是解法不是 job
  • ✅ 保持中性：「When 我想轉職設計師時，I want to 系統性學習設計流程，so I can 進入設計團隊」——讓 PM / 設計師有空間提出多種解法
  • ❌ 太抽象：「When 我活著時，I want to 變得更好」——失去情境鎖定能力
  • ✅ 情境具體：「When 我面試前一晚緊張到睡不著時，I want to 快速放鬆，so I can 隔天表現好」

與其他概念的關係

同 cluster：設計思考 工作坊工具

  • 設計觀點 / Point-of-View — 同為單句結構化使用者描述工具
    • POV：「【User】needs to【need】because【insight】」—— 強調洞察根源（為什麼）
    • JTBD：「When _, I want _, so I can _」—— 強調情境動機（什麼時候、為了什麼結果）
    • 兩者互補：POV 寫出「洞見」、JTBD 寫出「情境」；好的設計觀點論述常包含兩者
  • How-Might-We — JTBD 是「問題本身」的句型 / HMW 是「問題轉解法」的句型；常見流程：JTBD → POV → HMW → Ideate
  • 同理心地圖 — 同理心地圖是 4 象限觀察工具、JTBD 是 1 行濃縮工具；前者是廣度蒐集 / 後者是深度濃縮；通常先做同理心地圖再做 JTBD
  • 人物誌 — JTBD 是 Persona 的情境化補位；不是替代而是補強：Persona 答「她是誰」、JTBD 答「她現在要做什麼」
  • 人物誌光譜 — 與 JTBD 同精神：不要把使用者凍結為單一類型；光譜是「人軸」的解凍 / JTBD 是「情境軸」的解凍

工作坊使用情境

  • 利害關係人管理 — Ep15 步驟 3「工作坊應釐清的指導原則」推薦活動之一即為 JTBD（影片提及但 vault 未建頁，本頁補位）；JTBD 的價值是讓多方利害關係人對「使用者真正要解的工作」達成共識
  • 價值主張畫布 — Strategyzer 的 customer profile 三段（jobs / pains / gains）直接源於 JTBD；價值主張畫布是 JTBD 的商業模式擴展版
  • Customer-Forces — JTBD 的切換決策層；把「顧客想完成什麼工作」推進到「顧客何時願意從 old way 切到 new way」

哲學對位

  • 使用者研究 — JTBD 不是研究方法（不告訴你怎麼問），而是研究結果的呈現結構；JTBD 句型常作為使用者訪談的輸出格式
  • 問題發現訪談 — 把 Customer-Forces 轉成 early-stage discovery 的訪談順序，先問既有替代品與切換阻力，再整理成 JTBD
  • 拆分需求 — JTBD 的「why（情境）/ what（動機）/ outcome（結果）」三段對應拆分需求的「水平 vs 垂直」討論：垂直拆分對應「同一情境的不同動機」、水平拆分對應「同一動機的不同子任務」

相關來源

備註

學術出處：JTBD 框架由 Tony Ulwick（《What Customers Want》, 2005）系統化、由 Clayton Christensen（《Competing Against Luck》, 2016）廣為傳播。Ulwick 的版本偏 Outcome-Driven Innovation（量化的 jobs / outcomes / desired outcomes 三層）；Christensen 的版本偏敘事性訪談（一次購買決策的情境重建）。本頁初版以 Blair 懶人包句型版為主，未展開兩派差異。

未來累積方向：

  • Outcome-Driven Innovation（Ulwick）的量化版本：把 job 拆成 desired outcomes，每個 outcome 評分 importance × satisfaction，找出 underserved 機會
  • Switch Interview（Christensen 派）的訪談技法：重建「上次選擇購買 / 切換產品」的情境細節；2026-05-06 先以 Ash Maurya 問題發現訪談 補入 problem discovery script，但仍待 Christensen 派原典
  • Job Map（job 的 8 步驟拆解：define / locate / prepare / confirm / execute / monitor / modify / conclude）
  • 與 Goal-Signal-Metric 的對位：JTBD 是「使用者目標」、G-S-M 是「商業目標 → 量測」；雙向對齊是設計師的關鍵能力
  • Forces of Progress / Customer Forces：2026-05-06 已以 Customer-Forces 落地 Ash Maurya 版本；後續可補 Rewired Group / Christensen 系四力原典

反向連結