본문으로 이동
ㅇㅈㅁㅆ
리서치·고객이해

JTBD(고객 과업)

Jobs to Be Done · JTBD · 잡투비던 · 고객 과업 · Jobs to be Done

JTBD(고객 과업)는 고객이 특정 상황에서 더 나은 상태로 나아가기 위해 해결하려는 기능적·사회적·감정적 진전입니다. 직무명이나 제품 기능 목록이 아니라 선택을 일으킨 상황과 힘을 설명합니다.

AI 보조 조사·작성 후 원문과 대조한 설명입니다. 사례·계산은 별도 출처 표기가 없는 한 이해를 위한 가상 예시이며 실제 고객 성과가 아닙니다.

JTBD(고객 과업)이 성립하려면 무엇이 필요한가요?

제품을 언제 왜 선택하거나 포기했는지 실제 전환 사건과 당시 상황을 추적해야 JTBD 조사가 성립합니다. Christensen Institute는 결정을 향하거나 멀어지게 하는 상황과 기능·사회·감정의 힘을 강조하고 Harvard Business School Online은 고객이 제품을 특정 진전에 고용한다는 관점과 기능 목록의 차이를 설명합니다. "빠른 앱이 필요하다"는 해결책 표현이라 그 전에 하려던 일을 더 물어야 합니다.

실제 질문과 표본은 어떻게 정하나요?

"어떤 기능을 원하세요"보다 "기존 방식을 그만두기로 한 날 무슨 일이 있었나요", "새 방법을 찾기 시작한 계기와 걱정은 무엇이었나요", "비교한 대안은 무엇이었나요"라고 묻습니다.

아래는 JTBD 구조를 보여 주는 가상 사례입니다. 회계 앱 구매자 14명을 인터뷰했더니 기능 수보다 월말마다 누락된 증빙을 찾는 시간을 줄이고 팀에 재촉하는 부담을 피하려는 상황이 반복됐다고 가정합니다. 이 문장은 기능 제안이 아니라 추가 검증할 과업 가설입니다.

14명 중 9명에게 같은 상황이 나왔어도 고객 전체의 64.3% 과업이라고 쓰지 않습니다. 구매 시점, 회사 규모와 기존 대안을 비교해 같은 진전인지 살피고 별도 설문이나 행동 데이터로 범위를 확인합니다.

설계 확인 순서

  1. 최근 구매·전환·포기 사건이 있는 참여자를 모집합니다.
  2. 사건 전후의 계기·대안·불안·결과를 시간 순서로 묻습니다.
  3. 과업 가설과 기능 아이디어를 분리해 검증합니다.

인접 개념과 무엇이 다른가요?

JTBD는 특정 상황에서 원하는 진전과 선택의 힘을 설명합니다. 고객 불편은 과정에서 생긴 장애와 비용에 초점을 두고 고객 필요는 서비스가 충족해야 할 결과를 넓게 가리킵니다. 사용자 스토리는 제품 개발 문장 형식이므로 조사 없이 작성하면 JTBD 근거가 되지 않습니다.

결과를 해석할 때 무엇을 조심해야 하나요?

인터뷰 뒤에 그럴듯한 과업 문장을 만들기 쉬워 반례와 실제 행동 확인이 필요합니다. 브랜드 선호, 예산과 조직 승인처럼 선택에 작용한 조건을 감정 과업 하나로 축소하면 설명력이 떨어집니다. 제공 기관의 유명 사례를 다른 시장의 보편 법칙으로 옮기지 않습니다.

자주 묻는 질문

JTBD는 고객이 원하는 기능 목록인가요?
아닙니다. 기능보다 특정 상황에서 고객이 이루려는 진전과 선택을 움직인 힘을 설명합니다.
직무가 같으면 고객 과업도 같은가요?
직무명이 같아도 상황, 기존 대안과 원하는 결과가 다르면 과업이 달라질 수 있습니다.

출처와 확인 범위

  1. Jobs to Be Done Theory · Christensen Institute · 확인 2026-10-27

    JTBD examines circumstances and functional, social, and emotional forces that move people toward or away from a decision, not just demographics or requested features.

    확인 범위: 표시한 절과 페이지에서 직접 확인한 정의·설계 조건·한계만 사용했습니다. 제공사의 제품 홍보, 벤치마크와 성과 주장은 보편적 효과의 근거로 사용하지 않았습니다.

  2. The Jobs to Be Done Framework Explained and Real-World Examples · Harvard Business School Online · 확인 2026-10-27

    The framework asks what progress a customer is trying to make and why a product is hired in a particular circumstance; a job statement should not be reduced to a product feature.

    확인 범위: 표시한 절과 페이지에서 직접 확인한 정의·설계 조건·한계만 사용했습니다. 제공사의 제품 홍보, 벤치마크와 성과 주장은 보편적 효과의 근거로 사용하지 않았습니다.

용어 설명 정정 요청