✍️ Jobs-to-be-Done Framework에 대한 또다른 좋은 아티클 1. JTBD의 기본적인 구조 : 고객은 {특정 상황}에서 {이런 제약} 때문에 {자신이 원하는 바}를 이루지 못하고

✍️ Jobs-to-be-Done Framework에 대한 또다른 좋은 아티클 1. JTBD의 기본적인 구조 : 고객은 {특정 상황}에서 {이런 제약} 때문에 {자신이 원하는 바}를 이루지 못하고, 그로 인해 {특정한 감정}을 느낀다. a. 여기서 특히 중요한 건 고객이 처한 상황(맥락). b. 또, 이 문제는 고객에게 반복되어야 한다. 고객은 스스로 문제를 해결하려는 노력이 반복해서 실패할 때 제품 구입을 고려한다. ➡️ 상황(맥락)에 대한 얘기는 JTBD에 대한 다른 아티클에서도 많이 나오는 내용. 고객이 처한 상황을 이해하려면 기본적으로 인간에 대한 이해가 필요하지 않을까 생각. 인간을 공부하자.. 2. JTBD를 위해 답해야 할 질문 a. “고객의 문제”라는 걸 어떻게 정의할 수 있을까? 문제란 어떤 상태를 의미하는가? b. 고객의 문제를 발견하는 방법은 무엇이 있을까? 설문조사? 인터뷰? c. “문제를 해결한다”는 것은 어떻게 정의할 수 있을까? 어떤 상태가 해결된 상태인가? 3. 가장 큰 위험 요소는, 존재하지 않는 문제를 해결하려 드는 것. ➡️ 번뜩이는 아이디어가 생각났을 때 가장 빠지기 쉬운 함정인 것 같다. 일단 아이디어는 생각났는데, 모든 아이디어는 어떤 문제를 해결해야 한다고들 하니 그제서야 문제를 찾는다. 순서가 거꾸로 된 것. 4. 문제에 대한 정의를 계속 다듬어서 구체화해야 한다. 이 문제가 왜 발생했는지, 근본 원인이 무엇인지 계속 파야 한다. 우리가 원인이 아닌 증상을 해결하려고 하는 건 아닌지? 5. 크게 네 가지 : (1) 고객의 돈을 절약해 주거나, (2) 고객의 시간을 절약해 주거나, (3) 고객이 하지 못하는 일을 대신해 주거나, (4) 고객이 기존에 하지 못 했던 일을 할 수 있게 해주어야 한다. 6. 고객이 원한다고 해서 무작정 이 기능, 저 기능을 추가하는 건 잘못된 것. 설령 개발하는 데 비용이 얼마 들지 않는다고 해도, 그에 따른 대가를 오랜 시간에 걸쳐 치를 수도 있다. 기능 추가에 따른 이익보다는 손해가 큰 경우가 많다. 기능을 더하기만 하면 제품이 복잡해져서 사용성이 떨어진다. ➡️ 마티 케이건이 말하는 "나쁜 팀"이 빠지기 쉬운 함정이라고 생각. ("나쁜 팀은 기능이 출시되었을 때 기뻐하고, 좋은 팀은 비즈니스 성과를 냈을 때 기뻐한다") 7. 고객이 실제로 문제를 겪고 있는지 파악하는 가장 쉬운 방법은, 고객이 이미 그 문제를 해결하기 위해 시간/노력/돈을 들이고 있는지 보는 것. 진짜 문제라면, 사람들은 이미 ‘그럭저럭’ 문제를 해결하고 있었을 것.