Jobs to Be Done으로 사용자가 진짜 완료하고 싶은 일 찾기
본 장 안내
최소 SOP
목적: 읽고 나면 흐릿한 아이디어를, 기능 이름만 잔뜩 있는 상태가 아니라 실제 사용자 장면이 있는 수요 한 문장으로 수렴하는 법을 더 명확히 알게 됩니다.
행동 항목: 흐릿한 아이디어 1문장을 쓰고, 잠재 사용자 3명에게 "최근 한 번은 어떻게 처리했는지"를 묻고, JTBD 문장 1개로 정리합니다.
결과: 더 명확한 수요 가설을 얻고, 첫 버전에서 무엇을 먼저 해결해야 하는지 알게 됩니다.
키워드 이동: JTBD란 무엇인가 · 한 문장 공식 · AI는 어떻게 도와줄 수 있나
다음 내용을 배우게 됩니다
- Jobs to Be Done이 무엇이고, 왜 "기능 브레인스토밍"보다 실제 수요에 더 가까운지
- "사용자가 원한다고 말한 기능"과 "사용자가 진짜 완료하고 싶은 일"을 구분하는 법
- 간단한 템플릿으로 흐릿한 아이디어를 장면, 트리거, 장애물, 성공 기준으로 분해하는 법
- JTBD를 AI 제품, 인터뷰 질문, 프롬프트 정리에 활용하는 법
1. Jobs to Be Done이란 무엇인가
Jobs to Be Done은 보통 JTBD라고 줄여 부릅니다. 그 핵심 생각은 Clayton Christensen 팀이 널리 알린 고전적인 표현과 관련 있습니다. 사용자는 어떤 제품을 "고용"해 하나의 일을 완성한다는 것입니다.
여기서 말하는 "일"은 할 일 목록의 표면적 동작이 아니라, 사용자가 자신의 상태에서 일으키고 싶은 어떤 진전입니다. 예를 들면 다음과 같습니다.
- "AI 회의록 도구가 필요하다"가 아니라, "회의 후 10분 안에 핵심, 할 일, 담당자를 정리해서 기억에 의존해 메모를 보충하지 않고 싶다"
- "가계부 App이 필요하다"가 아니라, "돈이 정확히 어디로 갔는지 알고 싶어서 월말에 다시 불안해지고 싶지 않다"
- "이력서 최적화기가 필요하다"가 아니라, "그럴듯한 이력서를 더 확신 있게 제출하고 싶고, 매번 지원할 때마다 내가 너무 못 쓴 건 아닌지 의심하고 싶지 않다"
따라서 JTBD가 주목하는 것은 제품이 어떻게 생겼는지가 아니라, 사용자가 왜 이 순간 그것을 필요로 하는가입니다.
그래서 겉으로는 서로 달라 보이는 제품도 실제로는 같은 job을 두고 경쟁할 수 있습니다. 사용자가 "출근길을 덜 지루하게 보내고 싶다"면 고용할 수 있는 대상은 숏폼 영상, 팟캐스트, 게임, 채팅, 심지어 잠깐 조는 것일 수 있습니다. 사용자가 "긴 PDF를 빠르게 이해하고 싶다"면 고용할 수 있는 대상은 AI 요약 도구, 인턴, 동료, 억지로 직접 읽기, 또는 일단 안 읽기일 수 있습니다.
이 관점으로 문제를 보면 진짜 경쟁자는 대개 "당신과 비슷하게 생긴 다른 App"만이 아니라, 사용자가 현재 받아들일 수 있는 모든 대체 방안이라는 것을 알게 됩니다.
2. JTBD는 사용자 페르소나, 기능 목록과 무엇이 다른가
많은 초보자는 수요 분석을 시작할 때 먼저 사용자 페르소나를 씁니다. 25세, 여성, 1선 도시, 직장인, 효율 도구를 좋아하고 새 제품을 시도할 의향이 있음. 이런 정보가 완전히 쓸모없다고 할 수는 없지만, 보통 한 사람이 왜 이 순간 행동을 취하는지 설명하기에는 부족합니다.
JTBD는 아래 질문에 더 관심이 있습니다.
- 그는 어떤 장면에서 해결책을 찾기로 결정했는가
- 당시 정확히 무엇에 막혔는가
- 무엇을 다음 단계로 밀고 싶었는가
- 지금은 어떤 서툰 방법으로 버티고 있는가
- 일이 잘 해결된다면 어떤 결과가 "가치 있었다"고 느끼게 하는가
즉, 사용자 페르소나는 "이 사람이 대략 누구인가"에 가깝고, JTBD는 "이 사람이 지금 정확히 무엇을 완료하고 싶은가"에 가깝습니다.
마찬가지로 기능 목록도 사람을 쉽게 빗나가게 합니다. 사용자가 "Word로 내보내고 싶어요", "AI 문장 개선이 있으면 좋겠어요", "음성 입력이 필요해요"라고 말할 수 있습니다. 하지만 이것들은 모두 표면 표현입니다. JTBD는 계속 아래로 묻습니다.
- 왜 지금 PDF가 아니라 Word 내보내기가 필요한가?
- 문장을 고치고 싶은 이유는 문체가 나빠서인가, 아니면 대상에 맞게 바꿔야 해서인가?
- 음성 입력이 필요한 이유는 타이핑이 귀찮아서인가, 아니면 자주 걸으면서, 운전하면서, 회의 직후에 바로 기록해야 해서인가?
많은 경우 기능은 job의 임시 번역일 뿐입니다. 기능만 수집하면 "사용자가 말하는 것을 전부 쌓는" 제품이 되기 쉽습니다. 뒤에 있는 job을 볼 수 있어야 진짜로 쓰기 편하고 경쟁력 있는 솔루션을 만들 가능성이 커집니다.
3. 제로 베이스도 이해할 수 있는 예시
복잡한 AI 제품을 서둘러 생각하지 말고, 먼저 생활 속 예시에서 시작해 봅시다.
어떤 사람이 아침에 나가기 전 늘 아침을 먹을 시간이 부족해서 지하철역 입구에서 샌드위치와 커피를 자주 산다고 가정해 봅시다. 표면적으로 그는 "아침 식사"를 구매합니다. 하지만 JTBD로 보면 그가 진짜 완료하고 싶은 일은 이럴 수 있습니다.
- 바쁜 아침에 가장 머리를 덜 쓰는 방식으로 한 끼를 해결한다.
- 회사에 도착하기 전에 배고파 불안해지지 않도록 한다.
- 아침 식사 때문에 출근 리듬을 망치지 않는다.
이때 사용자가 고용한 것은 "어떤 고정 브랜드의 샌드위치"가 아니라, 아침을 순조롭게 앞으로 밀어 주는 해결책입니다. 옆 편의점이 더 빠르고, 더 가깝고, 더 안정적이면 그는 원래 선택을 바로 바꿀 수 있습니다.
이 논리를 AI 제품으로 옮기면 더 분명해집니다.
예를 들어 "AI 회의록 도구"를 만들고 싶다고 합시다. 기능 층위에만 머물면 쉽게 이런 생각을 하게 됩니다.
- 오디오 업로드를 지원할까
- 화자 분리를 붙일까
- Markdown 내보내기를 할까
- 할 일을 자동 생성할까
이것들은 모두 틀리지 않지만 충분하지 않습니다. JTBD로 한 층 더 물으면 사용자가 진짜 완료하고 싶은 것은 다음일 수 있습니다.
- 회의 후 10분 안에 참석하지 못한 사람에게 논의 결과를 동기화하고 싶다.
- 할 일, 담당자, 마감일을 깔끔하게 뽑아 팀이 기억에 의존해 협업하지 않게 하고 싶다.
- 회의 내용을 반복 정리하는 시간을 줄이고, 에너지를 의사결정과 추진에 남기고 싶다.
job이 명확해지면 많은 기능의 우선순위가 자동으로 떠오릅니다. 첫 버전에서 가장 중요한 것은 "12가지 내보내기 형식 지원"이 아니라 다음일 수 있습니다.
- 회의록 구조가 충분히 명확해야 한다.
- 할 일 추출이 안정적이어야 한다.
- 공유 링크가 편리해야 한다.
- 출력 결과를 팀에 바로 전달할 수 있을 만큼 믿을 수 있어야 한다.
이것이 JTBD의 가치입니다. "어떤 능력을 쌓을까"에서 "사용자가 어떤 진전을 이루도록 도울까"로 되돌려 줍니다.
4. 쓰기 좋은 JTBD 템플릿
제로 베이스라면 JTBD를 너무 학술적으로 생각하지 않아도 됩니다. 가장 실용적인 5개 요소만 잡으면 충분합니다.
4.1 장면
사용자는 어떤 순간, 어떤 환경에서 이 제품을 떠올리는가?
- 회의가 끝난 뒤인가
- 상사가 갑자기 자료를 요구할 때인가
- 밤에 이력서를 제출하려고 준비할 때인가
- 월말에 돈이 또 부족하다는 것을 발견했을 때인가
장면이 없는 수요는 보통 아직 충분히 진짜가 아닙니다.
4.2 트리거
무엇이 그를 즉시 해결책을 찾게 만들었는가?
- 긴 문서에 눌려 어디서부터 봐야 할지 모른다.
- 내일 제출해야 하는 자료가 있는데 오늘서야 형식이 엉망이라는 것을 발견했다.
- 방금 리더에게 진행 상황을 추궁당했고, 자신이 정리를 제대로 해 두지 않았다는 것을 깨달았다.
- 기록을 꾸준히 하고 싶지만 손글씨, 복사, 정리가 모두 너무 번거롭다.
트리거에는 보통 감정이 함께 있습니다. 이 감정은 매우 중요합니다. 왜냐하면 사용자가 왜 바로 이 순간 행동하게 되는지를 결정하기 때문입니다.
4.3 완료하고 싶은 진전
그는 단지 "동작 하나"를 하고 싶은 것이 아니라, 자신을 어떤 새로운 상태로 밀어 넣고 싶은가?
- 혼란에서 명확함으로
- 불안에서 안심으로
- 미룸에서 시작으로
- 비효율에서 매끄러움으로
- 설명하지 못함에서 바로 전달 가능함으로
이 단계에서 "진전"이라는 단어가 매우 중요합니다. 많은 사람이 진짜로 사는 것은 도구가 아니라 상태 변화이기 때문입니다.
4.4 현재 대체 방안
당신의 제품이 없을 때 그는 지금 어떻게 하는가?
- 수동 복사/붙여넣기
- Excel이나 메모장으로 억지로 버티기
- 동료에게 부탁하기
- 미뤄 두기
- 여러 도구 사이를 왔다 갔다 하기
대체 방안이 누구인지가 곧 당신의 실제 경쟁 환경입니다.
4.5 성공 기준
어떤 상태가 되어야 일이 진짜 해결되었다고 볼 수 있는가?
- 10분 안에 공유 가능한 결과를 얻는다.
- 크게 다시 고치지 않아도 다른 사람에게 보낼 수 있다.
- 누락, 오류, 잊어버림이 쉽게 생기지 않는다.
- 처음 써도 다음에 무엇을 해야 하는지 안다.
"사용자가 어떻게 가치 있다고 판단하는지"조차 말하지 못한다면, 이 방향은 아직 충분히 수렴되지 않았을 가능성이 큽니다.
5. 바로 적용할 수 있는 한 문장 공식
제품 방향을 정리하고 싶을 때는 먼저 이 매우 실용적인 문장 형식을 사용할 수 있습니다.
__________ 할 때, 나는 __________ 하고 싶다. 그래야 __________ 할 수 있다.
지금은 __________ 방식으로 겨우 이 일을 해내고 있다.
예를 들면:
정보량이 많은 프로젝트 회의가 끝났을 때, 나는 할 일, 담당자, 마감일이 포함된 회의록을 빠르게 얻고 싶다. 그래야 팀에 바로 동기화하고 실행을 추진할 수 있다.
지금은 기억을 더듬고, 채팅 기록을 뒤지고, 손으로 정리하는 방식으로 겨우 이 일을 해내고 있다.
또 다른 예:
새로운 직무에 지원하려고 할 때, 나는 기존 경험을 해당 직무에 더 맞는 표현으로 빠르게 고치고 싶다. 그래야 더 확신 있게 그럴듯한 이력서를 제출할 수 있다.
지금은 예전 이력서를 반복해서 복사하고, 문구를 손으로 고치고, 마지막에는 점점 더 확신이 없어지는 방식으로 버티고 있다.
이 한 문장을 이 정도로 명확하게 쓸 수 있다면, 뒤의 페이지 설계, 프롬프트 설계, 기능 우선순위 판단이 훨씬 쉬워집니다.
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. 이 피드백들에서 반복해서 등장하는 감정 단어는 무엇인가
마지막으로 이 내용을 검증 우선순위가 높은 JTBD 가설 3개로 정리해 줘.이미 아이디어가 있다면 AI에게 1차 수렴을 도와달라고 할 수도 있습니다.
[제품 아이디어]를 만들고 싶어.
기능 목록을 바로 주지 말고, 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. 정리
Jobs to Be Done의 가장 가치 있는 점은 새로운 용어를 하나 주는 것이 아니라, 관찰 관점을 바꿔 준다는 것입니다. 제품 기능만 바라보지 말고, 사용자가 어떤 일을 다음 단계로 밀고 싶어 하는지 바라보세요.
다음 질문을 반복해 묻기 시작하면:
- 사용자는 어떤 장면에서 이 제품을 고용하는가
- 정확히 어디에서 막혔는가
- 지금은 어떤 방식으로 버티고 있는가
- 일이 해결되면 상태가 어떻게 변하는가
원래 흐릿했던 많은 아이디어가 갑자기 선명해지고, 원래 화려해 보였던 많은 기능이 갑자기 그다지 중요하지 않게 됩니다.
제품을 만들 때, 특히 AI 제품을 만들 때 가장 위험한 것은 처음부터 능력 시연에 빠지는 것입니다. JTBD는 당신의 주의를 진짜 중요한 곳으로 되돌립니다. 사용자가 왜 당신을 필요로 하는가, 그리고 당신은 정확히 어떤 진전을 완성하도록 돕는가.
12. 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. 여러 사용자에게 반복해서 나타난 정보는 무엇인가
마지막에는 검증 우선순위가 높은 JTBD 가설 3개로 정리해 줘.아주 간단한 초보자 입력도 이렇게 쓸 수 있습니다.
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. 이 가설에서 가장 먼저 검증해야 할 위험은 무엇인가이렇게 하면 당신이 수요를 보고 있는지, 아니면 좋아하는 솔루션만 보고 있는지 더 빨리 발견할 수 있습니다.
📚 Assignments
위 내용을 바탕으로 다음 과제를 완료하세요.
- 최근 만들고 싶은 제품 아이디어 하나를 고르고, JTBD 공식 한 문장으로 명확하게 쓰세요.
- 이 아이디어에 5개 요소를 보충하세요: 장면, 트리거, 진전, 대체 방안, 성공 기준.
- 잠재 사용자 3명을 찾아 최소 한 번은 "최근에 이 문제를 만난 것은 언제였나요?"라고 물어보세요.
- 인터뷰 원문을 AI에게 주고 검증 우선순위가 높은 JTBD 가설 3개로 정리하세요.