[내일배움캠프] PM - JTBD와 5 Whys Framework에 대한 고찰

썸넬 할 일을 때려치는 나.

 

주말이 너무 빨리 지나간다..

 

오늘 정말 TIL 작성하기 역대급으로 힘들었던 날이다.

 

머리가 복잡하구먼~

 

바로 맛보도록 하자.

 

---

https://www.youtube.com/watch?v=h3qk0utrpHs

<루피(Loopy) - Reasons>

정말 좋아하는 국내 힙합 곡 중 하나.

 

사운드나 랩이나 외힙에 견줄만 하다고 생각한다.

 

가장 기억에 남는 구절은 '포기해야하는 이유와 해야하는 이유는 늘 같아' 였다.

 

다들 들어보시길..

---

❓'5 Whys Framework'의 단점

최근에 서비스 기획 입문 과제를 진행하면서 5 Whys Framework를 사용했었는데,

 

관련해서 여러번 질타를 받고 수정을 하면서 느꼈던 점은

 

질문을 어떻게 하느냐에 따라 문제 원인이 천차만별로 다르게 정의될 수 있다는 점이었다.

 

 

 

위의 예시에서 볼 수 있듯,

 

과연 대리석 부식의 근본 원인이 '전등'때문일까?

 

두 번째 질문에서 '대리석을 자주 씻는다' / '사용하는 세제' 둘 중 어떤 것을 문제로 보느냐에 따라서

 

문제 정의가 갈라지고, 또 이후의 질문에서 더욱 갈라지게 된다.

 

즉, 5 Whys Framework는 근본 문제의 원인으로 가는 갈림길에서 길을 얼마나 잘 선택하느냐 가 핵심이다

 

하지만 그 갈림길에서 어느 길이 옳은지를 도대체 어케 암?

 

이에 대해서 오늘 튜터님께 질문 드린 결과,

 

5 Whys Framework는 '감의 영역'이라고 하셨다.

 

서비스에 대해 전반적인 지식이 있고 이해도가 깊은 시니어 PM 일수록 '아 이쪽 길이 더 정답에 가깝겠구나' 감이 온다고 한다.

 

하지만 이번 과제를 진행하면서 나는 초보 PM이었기에 해당 프레임워크를 쓰는 것은 맞지 않았던 것이다.

 

그리고 5 Whys Framework는 이미 있는 문제(1 to 100)를 해결하기에 더 좋고,

 

이번에 알게된 'JTBD(Jobs To Be Done)' 프레임워크는 처음 발생한 문제를 해결하기에 좋다고 하셨다. (0 to 1)

 

이번 과제는 0 to 1, PO의 작업에 가까웠다.

 

사용할 수 있는 데이터는 문제 키워드의 빈도수 뿐이었고, 이외의 제공된 Amplitude 데이터는 없었기 때문이다.

 

그래서 이번에 튜터님께서 내 어려움을 알아주셨는지, 이번에 'JTBD' Framework를 소개해주셨다.

 

---

💎 JTBD (Jobs To Be Done) 란?

출처 : https://acquiredentrepreneur.tistory.com/76

 

JTBD를 직역하자면 '완수해야 할 과업'이다.

 

그러나 진짜 의미는 '고객이 수행해야 하는 과업'이다.

 

위의 사진이 조금 복잡하게 되어 있는데, 아래 이미지를 보도록 하자.

 

출처 : https://acquiredentrepreneur.tistory.com/76

 

Product와 고객 / JTBD 간의 관계도이다.

 

JTBD는 결국 고객의 정확한 니즈이다.

 

JTBD가 완수되면 고객이 기대하는 바가 제공되는 것.

 

JTBD Framework의 의의는 고객의 핵심 Job 및 그와 관련된 니즈를 파악하고 분석함으로써,

 

제품 개선 혹은 기획 단계에서 고객의 니즈를 충족시키는 데에 있다.

 

JTBD를 구성할 땐 '고객', '제품 관련 이해관계자(판매자)', '구매자(=사용자, 아닌 경우도 있음)' 3가지로 나뉜다.

 

지난 과제 키워드 중 '가격 비교'에 대해 JTBD 프레임워크를 적용한 결과이다.

 

위와 같이 고객의 JTBD / 네이버플러스스토어(판매자)의 JTBD를 정의하고, 이에 대해 사고하는 과정을 거친다.

 

5 Whys 프레임워크를 적용했을 때와 비교했을 때 훨씬 효율적으로 비슷한 결론에 도달하는 것을 알 수 있다.

 

어떻게 질문해야할지, 어떤 선택을 해야할 지 늘 고민했던 5 Whys 프레임워크에 비해 더욱 효과적이다.

 

 

JTBD를 고객의 니즈에 대해 구체화할 때, User Story와 상당히 비슷한 것을 알 수 있다.

 

유저 스토리 - 'As, I want, So that'의 구조인 것과 비슷하게

 

JTBD - 'As I(상황), So that(목적)'의 구조로 이루어져있다.

 

Jira를 사용할 때 JTBD 프레임워크를 이용한다면 훨씬 더 상호작용을 잘 할 수 있을 것이라고 생각되었다.

 

다음 시간에는 해당 프레임워크를 실사례에 적용해보도록 하겠다.