jobs-to-be-done

jobs-to-be-done 스킬 개요

jobs-to-be-done 스킬은 막연한 고객 문제를 구조화된 JTBD 분석으로 바꿔줍니다. 기능적 job, 사회적 job, 감정적 job, pains, gains까지 정리할 수 있게 해주며, 고객이 단순히 무엇을 원한다고 말하는지보다 왜 그 제품을 선택하는지 이해해야 할 때 특히 유용합니다. Product Management, 메시지 작업, discovery 인터뷰, 제품 포지셔닝에 잘 맞습니다.

일반적인 프롬프트보다 더 체계적인 도구가 필요하다면 좋은 설치 후보입니다. 이 스킬은 표면적인 기능 요청과 그 뒤에 있는 동기를 구분하는 반복 가능한 관점을 제공하므로, 로드맵 논쟁, churn 분석, 신제품 discovery가 의견만 오가는 상태일 때 특히 도움이 됩니다.

jobs-to-be-done 스킬이 하는 일

고객 맥락을 제품이나 세그먼트 전반에 재사용할 수 있는 실용적인 템플릿으로 정리합니다. 핵심 가치는 명확성입니다. 어떤 job을 수행하려는지, 어디서 마찰이 생기는지, 사용자에게 진짜 “더 나은 것”이 무엇인지 정의하도록 도와줍니다.

누가 사용하면 좋은가

Product Manager, 창업자, 마케터, UX 리서처, 분석가처럼 제품 discovery를 개선하거나 고객 언어를 실행 가능한 인사이트로 바꾸고 싶은 사람에게 적합합니다. 이미 피드백은 많지만 그 의미를 깔끔하게 해석하지 못하고 있을 때 특히 유용합니다.

언제 특히 잘 맞는가

해결되지 않은 니즈를 이해해야 하거나, 아이디어를 검증해야 하거나, 포지셔닝을 날카롭게 다듬어야 하거나, 현재 솔루션을 고객의 실제 job과 비교해야 할 때 선택하면 좋습니다. 반대로 빠른 카피라이팅만 필요하거나, 고객 증거 없이 대략적인 브레인스토밍만 하면 되는 상황에는 덜 유용합니다.

jobs-to-be-done 스킬 사용법

설치한 뒤 실제 문제에 연결하기

스킬 매니저에서 jobs-to-be-done install 흐름을 사용한 다음 skills/jobs-to-be-done 경로를 기준으로 작업하세요. 상위 스킬은 가볍고 파일 기반이므로, 가장 먼저 볼 파일은 SKILL.md이고 그다음은 template.md, examples/sample.md입니다.

구체적인 고객 맥락을 넣기

이 스킬은 대상 사용자, 상황, 결정을 명시할 때 가장 잘 작동합니다. 약한 입력은 “우리 제품을 분석해줘” 같은 식입니다. 더 나은 입력은 “프리랜서가 결제를 놓친 뒤 스프레드시트에서 전환하는 구독형 인보이싱 도구에 대해 Product Management 관점으로 jobs-to-be-done를 적용해줘”처럼 씁니다.

대략적인 목표를 쓸 수 있는 프롬프트로 바꾸기

좋은 jobs-to-be-done 사용 프롬프트에는 다음이 들어가야 합니다.

• 대상 사용자 세그먼트
• 수요를 만들어내는 트리거 이벤트
• 현재의 대체 수단 또는 경쟁 제품
• 개선하고 싶은 결과
• 이미 가진 근거, 예를 들면 인터뷰 노트나 지원 티켓

예: “프로젝트 납품 후 더 빨리 인보이스를 보내야 하는 소규모 에이전시 운영자를 위한 JTBD 분석을 만들어줘. job, pains, gains에 집중하고, 수동 후속 확인이 어디서 마찰을 만드는지도 강조해줘.”

쓰기 전에 템플릿부터 읽기

template.md는 스킬이 기대하는 구조를 보여주고, examples/sample.md는 출력물을 실제로 유용하게 만드는 구체성의 수준을 보여줍니다. 입력이 빈약하면 출력도 대체로 빈약해집니다. 템플릿을 먼저 보면 모델에 무엇을 채워 달라고 해야 하는지, 어떤 정보가 빠졌는지 더 쉽게 파악할 수 있습니다.

jobs-to-be-done 스킬 FAQ

jobs-to-be-done는 일반 프롬프트보다 나은가?

일관성이 필요할 때는 그렇습니다. 일반 프롬프트도 한 번은 잘 작동할 수 있지만, jobs-to-be-done 스킬은 분석 간 흐트러짐을 줄이고 세그먼트 간 비교를 더 쉽게 만드는 재사용 가능한 구조를 제공합니다.

이 jobs-to-be-done 스킬은 초보자도 쓰기 쉬운가?

사용자와 상황을 설명할 수 있다면 그렇습니다. 시작하려면 깊은 JTBD 이론이 꼭 필요하지는 않지만, 일반적인 출력으로 흐르지 않게 할 만큼의 맥락은 필요합니다. 이미 제품 영역을 알고 있고, 그 프레이밍을 더 날카롭게 만들고 싶을 때 가장 강합니다.

잘하지 못하는 것은 무엇인가?

인터뷰, 행동 데이터, 시장 조사를 대체하지는 못합니다. 입력이 내부 의견뿐이면 분석이 그럴듯하게 보이더라도 실제 고객 job을 놓칠 수 있습니다. 또한 순수한 기술 문서나 기능 명세를 만드는 용도로는 최선의 선택이 아닙니다.

Product Management에 유용한가?

그렇습니다. Product Management용 jobs-to-be-done 스킬은 solution으로 바로 뛰어들기 전에 문제를 고객 언어로 정의하게 만들기 때문에, discovery, 포지셔닝, 우선순위 결정, 메시지 테스트에 잘 맞습니다.

jobs-to-be-done 스킬 개선하기

더 풍부한 원본 자료를 넣기

품질을 가장 크게 끌어올리는 것은 입력을 더 좋게 만드는 일입니다. 인터뷰 인용문, 지원 이슈 주제, churn 사유, 세일즈 콜 메모, 또는 사용자가 제품 전에 시도했던 방법의 예시를 넣으세요. 맥락이 구체적일수록 스킬이 추론해야 할 부분은 줄어듭니다.

기능이 아니라 job을 명확히 쓰기

“온보딩을 더 좋게”라고 요청하면 흔한 조언만 나올 수 있습니다. “처음 사용하는 사용자가 지원팀에 묻지 않고 첫 인보이스를 완료하게 돕기”처럼 요청하면, jobs-to-be-done 결과가 훨씬 실행 가능해집니다. job 자체가 검증 가능한 형태가 되기 때문입니다.

흔한 실패 패턴을 점검하기

가장 흔한 실패는 기능에만 치우치고 사용자의 상황 설명이 부족한 경우입니다. 또 하나는 여러 세그먼트를 한 번에 섞는 것입니다. 첫 결과가 너무 넓게 느껴지면, 하나의 세그먼트, 하나의 트리거, 하나의 원하는 결과만으로 jobs-to-be-done 가이드를 다시 돌리세요.

빈틈과 모순을 바탕으로 반복하기

첫 결과를 받은 뒤에는 무엇이 빠졌는지 묻는 방식으로 개선하세요. 어떤 pains가 가장 비용이 큰가? 어떤 gains는 필수이고 어떤 것은 있으면 좋은 수준인가? 어떤 사회적 job이나 감정적 job이 adoption을 끌고 있는가? 이 두 번째 패스는 대개 Product Management 의사결정과 메시지 작업에 가장 쓸모 있는 결과를 만들어냅니다.