brunch

매거진 PM Bootcamp

라이킷 28 댓글

You can make anything
by writing

C.S.Lewis

계정을 잊어버리셨나요?

by KitaiKeith Nov 08. 2021

고객의 진짜 문제(Customer Job) 찾기

Intercome on Jobs-to-be-done 정리

PM초반에는 제품을, 기능을 잘 만들어서 일정에 맞춰서 배포하는 것에 집중했다. 사용자와 대화를 하거나, 데이터를 보면서 지표에 영향을 줄만한 기능을 선택해서 배포를 했지만 뭔가 부족했다. 정말 사용자에게 필요한 것인가? 그렇다면 왜 필요한가? 우리가 구현하려는 기능이 정말 사용자의 문제를 해결해줄 것인가? 사실 지금도 같은 고민을 하고 헤매고 있다.

이러한 문제를 해결하기 위한 Framework가 바로 JTBD (Jobs-to-be-done)이다. 내가 정리한 내용의 출처는 Intercom on Jobs‑to‑be‑Done 이다. JTBD가 무엇인지, '왜', '어떻게' 이걸 써야 하는지에 Intercom의 사례를 통해 얘기하고 있다.

좀 더 이 부분에 집중이 필요한 것 같아, 위 아티클을 다시 읽고 정리를 해보았다.

Job에 집중하기

Customer Job이란 무엇일까? 고객이 해결하려는(혹은 겪고 있는) 문제다. '문제'라는 단어가 추상적인데, CH1에서는 Persona와 비교를 하며 Customer Job을 얘기한다. persona는 팀원과 타겟 유저에 대한 공통 비전을 공유하기에 좋은 장점이 있지만, 모든 사용자를 대변하기 어렵다는 한계가 있다. Customer Job은 특정 제품(혹은 서비스)을 사용하기로 결정한 사용자의 상황에 집중한다. 좀 더 근본적인 원인을 생각해본다.

예를 들어, 사진을 찍어 온라인에 업로드하고 싶을 때는 다양한 상황(다양한 Job)이 존재한다.

1. 사진을 둘이서만 남기고 싶다. 몇 년 뒤에 이때를 애정 어리게 되돌아볼 수 있으니까.
2. 친구의 사진을 다른 친구에게 보여줘서, 놀리려고.
3. 사진을 온라인에 올려 다른 사람에게도 보여준다.
4. 사진을 출력해서 컴퓨터를 사용하지 않는 할머니에게 드린다.
5. 사진을 흥미 있고 멋지게 만들어서 공유한다.
6. 사진을 편집하고 포트폴리오에 넣어서 미래에 나를 보여줄 수 있게 한다.

이러한 상황에 따라 Instagram, Flickr, iPhoto, 500px 등 앱 중 하나를 사용할 것이다. 또 한 명의 사용자 얼마나 많은 앱을 사용하는지 생각해보면 결국 '개인'이 아니라 다양한 Job에 의해 구분되는 것을 알 수 있다.

Customer Job을 보면, 경쟁상대 또한 달라질 수 있다. 내가 맥도날드 점주라고 가정해보자. 나의 고객은 배고픈 사람일 것이다. 하지만, 그 고객의 상황에 따라서 내 경쟁상대도 달라질 수 있다.

예 1) 점심시간이 5분밖에 남지 않은 사람이라면, 내 경쟁자는 누구일까?
→ 조각 피자 가게일 수 있고, 한국으로 치면 편의점이나 김밥천국일 수 있다.

예 2) 퇴근 후 집에 가는 사람이라면, 내 경쟁자는 누구일까?
→ 패스트푸드나 일반 식당이 아닌 배달업체가 될 수 있을 것이다.

xx일보와 같은 신문사의 경우, 다른 신문사나 잡지사가 경쟁상대라고만 생각할게 아니다. 사용자가 "새로운 정보 획득" vs "시간 때우기"에 따라 페이스북이나, 모바일 게임 등이 경쟁사가 될 수도 있다. 그렇기 때문에 사용자의 Job을 파악하는 게 중요하다.

Job(상황)에 따라 경쟁상대는 달라질 수 있다.

제품의 workflow 이해하기

JTBD는 사용자가 어떤 상황에서, 어떤 문제를 해결하려고 하는지를 파악하는 것에 집중한다. 수학 문제 같이 답이 딱 떨어지지 않을 수 있다. 그러다 보니 하루 종일 이 작업에 시간을 쓸 수도 있다. Intercom에서는 언제 Job을 멈춰야 할지에 대해서도 배웠다고 한다. JTBD를 너무 엄격하게 따르면, 하루 종일 제품을 통해 문제를 해결하려고 노력하게 되기 때문이다. (Job에 대해 너무 깊이 파고들면, 이론적인 접근만 가능하다는 의미인 것 같다. 맺고 끊음을 알기 위해 workflow를 파악하라고 하는 것 같다.)

제품은 Workflow안에서 발생하는 문제를 해결하기 위해 존재한다. 그리고 문제의 시작과 끝은 그 안에 있고, 이런 포인트가 어디 있는지 이해하기 위해서 workflow를 이해해야 한다. 점심시간에 음식을 주문하는 과정을 쪼개 보자.

만약, 점심 식사 주문을 도와주는 앱을 만든다면, workflow는 다음과 같을 것이다.

1. 누군가 배고파진다.
2. 배고파진 누군가는 팀원과 관련해서 얘기를 할 것이다.
3. 나가서 사 먹을지, 주문할지 얘기한다.
4. 주문은 어디서 할지 얘기한다.
5. 다른 식당의 메뉴를 얘기한다.
6. 결정을 빨리 내린다.
7. 한 사람이 다른 사람들의 주문을 모은다.
8. 주문한다.
9. 사람들에게 도착 시간과 금액을 알려준다.
10. 시간이 흐른다.
11. 음식이 도착하고 먹는다.
12. 주문한 사람은 돈 냈는지 점검한다.
13. 돈 계산이 끝나거나, 내일로 미뤄진다.
14. 누군가는 트위터나 페이스북에 글을 쓰고, 인스타그램에 사진을 올린다. 주문자는 리뷰를 남긴다.
15. 모두 일하러 간다.

위와 같이 workflow를 쪼개면, 가장 문제인 곳을 가려내고 집중하기 용이하다. (우리의 앱 중 어딘가를 고쳐야 하는가?라고 막연히 생각한다면 모든 곳을 다 고쳐야 할 것이다. 현실적으로 그건 불가능하고, 이렇게 전체를 나열하고 집중할 곳을 정해야 한다. 는 의미로 이해한다.)

그러면서 "우린 스스로에게 우리의 제품은 비타민인지? 아니면 진통제인지 물어봐 야한다."라고 말한다. 우리가 제품에 추가하는 (혹은 만드려고 하는 제품이) 기능이 사용자한테 정말 필요한 것인가?라는 질문을 항상 해야 하는 것 같다. 그렇지 않으면, 고생만 하고 지표에는 (혹은 정성적으로라도) 큰 영향을 주지 못한다. 그러면 함께 고생한 팀원뿐만 아니라, 회사 입장에서도 아쉬운 소리를 할 수밖에 없다. 매 순간 이 고민을 해야 하는 게 PM의 역할이다.

Customer Job을 제대로 파악해야 하는 이유를 Intercom 사례를 통해 얘기해준다. Intercom에서 지도(고객사의 고객이 전 세계 어디에 있는지 볼 수 있는) 기능을 추가했다. 이는 많은 고객이 좋아하였지만, 그 이유를 정확하게 파악하지 못했었다.

트래픽이 이 기능의 인기를 얘기했지만, 왜 사용자들이 이 기능을 좋아하는지 몰라 마케팅을 진행하기에도 어려웠다. 그리고 고객이 왜 이 기능을 사용했는지 생각해봤다.

당신의 사용자가 어디 있는지 알아내기 위해 (하지만, 많은 제품들이 이미 제공하고 있음.)

특정 도시에 어떤 고객이 있는지 보기 위해 (사용자 리스트가 훨씬 더 잘 보여줌.)

특정 나라에 얼마나 많은 사용자가 보기 위해 (사용자 리스트가 훨씬 더 보기 좋음.)

실제로 고객이 지도 기능을 사용한 이유는 아래와 같다.

사람들은 무역 박람회 및 발표회에서 이걸 보여주길 원한다.

사람들은 트위터에서 이걸 보여주길 원한다.

사람들은 투자자에게 이걸 보여주길 원한다.

지도는 어떤 고객의 Job을 해결한 걸까요? 이 기능은 우리 고객을 더 돋보이게 한다.

실제 사용 이유에 근거한 제품 개선

지도 기능을 개선을 하기 전에 어떻게 사용하고 있는지를 잘 알았다면, 우리는 더 올바른 기능 개선을 위해서 노력했었을 것이다. 사용 이유를 파악하기 전 우리는 아래와 같은 기능 개선을 했다.

지리적 정확성

clustering

나라/도시 경계를 잘 보여주기

드래그해서 지역 만들기

다양한 지도적 개선 관련된 것들

위와 같은 개선을 위해 몇 달씩 시간을 사용했지만, 제품을 악화시키기만 했다. 사용자는 우리가 생각한 것을 사용하지 않았기 때문이다. '지도' 기능은 실제 지도가 아니라, 진열품과 같다. 이러한 Job에서 우리는 어떠한 것들을 했어야 했을까?

지도를 더 좋아 보이고, 최고로 보이게 만들기

민감한 데이터를 숨기고, 공유 가능하게 하기

사용자가 지도를 쉽게 공유하게 만들기

실제로 이후 Intercom에서는 더 예쁘고, 활발한 지도를 개선했고, 고유한 공유 URL을 생성할 수 있는 기능을 추가했다. 특정 기능이 어떻게 쓰이는지에 집중하면 해당 기능이 속한 카테고리 (지도지만 실제 지도 역할을 하지 않는 것처럼), 기능의 타입을 무시하고 어떻게 개선할지 빠르게 파악할 수 있다.

Persona 버리기 : Job story 뒤에 있는 이야기

이 글의 처음에 나와있듯, JTBD는 Persona를 좋아하지 않는다. Intercom에서는 좋은 제품을 만들기 위한 프로세스를 계속 개선한다고 한다. 이때, 고객 리서치를 굉장히 중요시한다. 고객과 꾸준히 얘기하고, 이해하며 그들이 원해야 하는 것을 찾아야 하지만 어떤 툴, 방법론을 써야 할지 명확하지 않다. 제1원칙에 따라 항상 생각하며 사용자와 대화하는 법을 찾았다고 한다.

Sian Townsend, (구글맵의 리서치 리더 출신)는 구글에서 수십 명의 Persona를 만들었다고 한다. 그러다 보니, Persona가 가치 제한적이란 것을 발견했다. 사용자와 단절된 직원들과 공감대 형성하는 데는 도움이 되었지만 '문제'에 대한 좋은 아이디어나 새로운 생각을 이끌어내지는 못했다고 한다. 또한 페이스북에서는 사람들이 제품을 가지고 실제로 하는 일에 대한 데이터를 엄청 많이 모은다. 그리고 Data science team은 그걸 가지고 나에게 설명하면서 한 번도 실패한 적이 없다. 이 데이터에서 놀라움 점은 사람들이 얼마나 비슷한 행동을 하는가이다. Persona는 사람들은 다르고, 다른 목적을 가지고 행동한다고 믿게끔 한다. 하지만, 유사함이 다름보다 크고, 당신이 생각하는 인종, 나이, 성별 등을 넘어선다.

예를 들어, 세 자녀를 둔 미국에 사는 여성이 가족 바베큐 사진을 올린 이유는 한국의 10대가 어제한 홈파티 사진을 올리는 이유와 같다. 목표와 속성은 완전히 다르지만 동기는 동일하다. Persona는 두 사용자를 위해 동일한 제품을 설계하고 만들지 않을 것이다. 가장 잘 만들어진 Persona는 목표(사람의 행동을 유도하는)와 속성에 집중하지만, 현실적으로 대부분의 persona는 속성에만 집중한다. 심지어 Goal driven이어도 말이다. Persona는 부자연스럽게 사람들을 쪼갠다. 그리고 결정적으로 동기와 결과보다는 속성에 집중하도록 제한한다. 이 관찰을 하고 난 다음에 Persona에 대한 나의 믿음은 무너졌다.

2013년 중반 인터콤에서는 사용자 행동의 이유를 찾는 도구(방법론)를 찾고 있었다. Persona를 제외하고, 인기 있는 Tool 중 하나는 User story이다. 이건 Agile 운동에 의해 대중화되었다. 하지만, Intercom에서는 User story를 사용하지 않는다. 이건 고객주도라기보단 기술 주도적이다. 사용자의 동기보단 기능적으로 구현해야 할 것을 설명한다.

이 문제를 우리는 제1원칙에 근거하여 생각했고, 우리는 Job story를 발명했다. 우리는 오랫동안 JTBD을 생각했고 상황, 동기, 결과에 집중하는 우리의 프로세스를 만들어냈다.

[When ___] 상황에 집중하고
[I want to ___] 동기에 집중하고
[so I can ___] 결과에 집중한다.

만약 우리가 사람이 해결해야 하는 문제에 직면한 상황을 잘 이해하고, 이걸 해결하기 위한 동기를 이해하고, 훌륭한 결과가 어떤 형태인지 이해한다면 우리의 고객을 위해 가치 있는 product를 만드는 것에 대한 자신이 있을 것이다.

Intercom에서는 프로젝트 시작 전 1장짜리 짧은 요약 문서를 만든다. A4 한 장에 단순하게 정리되고, 어떤 문제를 해결할지, 기회는 무엇인지 상기시키는데 도움이 된다. 여기에 Job story 섹션도 있다.

출처 : https://s3.amazonaws.com/marketing.intercomcdn.com/assets/Intercom-Job-Story-template.pdf

Persona는 확실한 포지션이 있다. 장/단점이 분명히 존재하고 제대로 된 Persona를 작성하는 것은 어렵다. Persona는 제품 전체 시장을 부자연스럽게 제한하기 때문에 우리는 Job story를 사용한다.

Job story를 이용해서 기능 디자인하기

전통적으로 고객이 누구인지 그리고 그들이 뭘 원하는지는 마케팅, 사업 개발 혹은 세일즈의 책임이었다. 일단 정보가 모여 전달 가능한 포맷이 되면 제품 개발팀으로 전달된다. 이러한 폭포수 방식은 좋은 제품을 만들기 위한 요소(인과관계, 동기, 불안)가 부족하다. JTBD는 이러한 세부사항에 집중한다. 세분화된 사항을 제품에 적용하는 것이 Job story를 이용하여 UI, UX를 디자인하는 것이다.

앞서 계속 다뤘듯, Persona에 정의된 속성은 인과관계와는 아무 상관이 없다. 예를 들어, 나이, 성별, 인종 그리고 주말의 취미 등은 Snikers bar를 먹는 이유를 설명하지 못한다. 30분간 잠시의 허기를 달래주기 위해서 뭔가 사 먹는 것은 30초면 설명이 된다.

다음과 같은 User story가 있다고 가정해보자.

"사용자는 백업하지 않을 폴더를 지정하여, 저장하고 싶지 않은 항목을 백업 드라이브에 저장되지 않게 한다."

위에는 3가지 문제가 있다.

Persona 사용

실행, 동기 그리고 결과(outcome)를 결합한다.

문맥과 상황, 불안감을 무시한다.

기능은 종종 실패한다. 기능이 User story로 정의되면, 왜 이 기능이 실패했는지 찾기 어렵다. 실행에 동기와 결과(outcome)가 섞여있기 때문이다. 무엇이 문제인 지 알 수 없다. 실행이 잘못된 것인가? 동기에 대한 가정이 잘못된 것인가?

Job story 사용하기

Paul Adams에 의해 처음 얘기된 Job story는 여기서 확인 가능하다. (Replacing The User Story With The Job Story) 어떻게 이걸 workflow에 넣어 실행했을까?

1. 상위 레벨 Job에서 시작

2. 상위 레벨 Job을 해결하는데 도움을 주는 하위 레벨 Job을 정의

3. 사용자가 현재 어떻게 문제를 해결하는지 관찰 (지금 어떤 것을 사용하는지)

4. 현재의 인과관계, 불안, 동기를 조사하기 위한 Job story를 제안

5. Job story를 해결하기 위한 해결책을 제안

예를 들어보자, 고객을 위해서 안전한 대출을 도와주는 영업 담당자 프로필을 보여주는 화면 만들어보자. (미국에서는 자동차 구입 비용이 계속 상승해서, 월급 생활자들은 장기 대출에 의지해서 구매를 한다고 한다. 대출이 안 되는 경우도 존재한다.)

Profile을 디자인에 앞서 각 단계를 쪼개서 생각해본다.

프로필 화면을 만든다고 했을 때, 단순히 이름, 사진, 연락처가 존재해야 합니다!라는 식은 팀원을 설득시킬 수 없다. "왜 제품에 프로필 보기가 있어야 하는가?", "왜 한 화면에 있어야 하는가?", "어떤 문제를 해결하려고 하는가?" 등 왜? 해당 항목이 존재해야 하는지를 질문하고 그에 대한 답변을 할 수 있어야 한다. Job story를 이용해서 프로필 기능을 다시 구성해보자.

1. 상위 레벨 Job에서 시작
    - 잠재 고객을 위해 영업 사원이 고객 대출 확보를 도와주는 것이다.
2. 상위 레벨 Job을 해결하는데 도움을 주는 하위 레벨 Job을 정의
    - 대출 신청서 작성을 위해 다양한 개인 정보 항목을 입력해야 한다.
    - 민감한 정보이기 때문에, 고객은 영업사원과 함께 작성하면서 안정감을 느껴야 한다.
3. 사용자가 현재 어떻게 문제를 해결하는지 관찰
    - 현재는 고객이 영업사원을 직접 보며 믿을만한지 판단한다.
    - 작성지를 직접 종이에 작성하여서 영업사원에게 전달한다.
    - 작성지를 제대로 적었는지 확인하고, 작 성지가 타인에게 전달되지 않음을 확신한다.
4. 현재의 인과관계, 불안, 동기를 조사하기 위한 Job story를 제안
    - 제품을 가지고 영업사원과 고객이 상호작용을 할 때
    - 고객은 조직, 절차, 영업사원을 믿을만한 사람이라고 느끼고 싶다
    - 영업사원은 작성 절차 중 고객이 편안함을 느낄 것이란 확신을 갖고 싶다
    - 고객은 작성 절차 중 재정 정보를 입력하는 것에 대한 안전함을 느낀다
5. Job story를 해결하기 위한 해결책을 제안
    - 고객이 제품을 쓸 때 항상 영업사원 프로필이 보인다. (온라인에서 안정감)
    - 프로필에 사진, 직위, 판매한 자동차 수, 근속 연도를 포함한다. (신뢰감 형성)
    - 휴대폰 번호, 이메일 주소, 영업사원과 대화를 프로필 보기에 추가 (안정감 형성)

그리고 아래와 같은 결과물이 나온다.

그리고 각 항목이 어떤 Job과 상황을 해결하는지 UI 분석을 제공한다.

위와 같은 결과물이 나오면 이제 남은 과제는 고객이 자신의 정보가 노출될 수 있음을 안심할 수 있도록 하는 것이다.

성공적인 제품을 디자인하는 것은 실제 사용자가 현재의 문제를 어떻게 해결하는지 관찰하고 그들이 처한 상황의 맥락을 탐구한 후 인과관계, 불안, 동기를 이해하는 것을 의미한다. 추상적인 속성, 동기, 결과가 결합되면 팀은 집중할 포인트를 잃는다. 진행할 과제에 깊이 파고들고 학습하면 해결책을 더 효과적으로 만들 수 있다. Job story는 이를 위한 좋은 방법이다.

올바른 방법으로 '이유(왜)'를 물어보기

JTBD를 찾기 전 제품의 근본적인 원인(root cause)을 찾기 어려웠다. 그래서 문제를 계속 쪼개서 하나의 작은 문장으로 만드는 작업을 했었다. Five whys 같은 기법이 존재하지만, 근본적인 문제보단 중간 단계의 원인을 찾는다. 다음 단계로 빠르게 이동하기 전에 각 단계의 인사이트를 찾는 게 중요하다.

당신이 드릴을 샀다고 가정해보자. 그러면 다음과 같이 물어볼 수 있을 것이다.

Q. 전기를 드릴을 샀나요? 왜죠?
- 사진을 벽에 걸고 싶기 때문입니다.
Q. 왜 벽에 사진을 걸고 싶나요?
- 내 개성(more personal)을 더 보여주고 싶어서요.
Q. 집에 개성 보이는 게 왜 중요한가요?

계속 '왜'만 묻는 것은 직업병이다. 제품 디자인에 있어 근본 원인에 너무 빨리 도달하게 된다. 중요한 것은 각 단계가 '왜?' 발생했는가이다. 목적지인 '근본 원인'을 찾는 것보다 과정에서의 '이유'를 밝히는 게 중요하다. 사용자 인터뷰를 할 때도 각 단계의 '왜?'에 시간을 더 많이 할애해야 한다. 그러면서 다양하고 더 많은 아이디어를 생각하면 더 생산적일 것이다.

어떤 행동이 든 간에 원하는 만큼 깊게 파고들 수 있다. 토론할 수 있는 만큼 많은 단계가 있고, 각각 더 깊은 니즈(needs)와 관련이 있다. "왜?"에 대한 더 깊은 이해가 필요하다. 하지만, 제품의 가치를 탐색할 때, 논의해야 할 생산적인 단계가 너무 많다. (그렇기 때문에 앞서 Workflow를 파악하는 것처럼, 좀 더 효율적인 접근 방법이 필요하다.) 다음은 글쓴이가 찾은 완벽하게 탐색하기에 가장 가치 있는 단계이다.

즉각적인 단계는 유용성(usefulness)과 관련 있다. 그것과 실제로 어떤 일을 하는가?
예) 드릴을 이용하여 벽에 구멍을 만든다.

다음 단계는 사용성(usability)이다. 이걸(벽에 구멍) 이용해서 어떤 결과를 만들 수 있는가?
예) 나는 벽에 사진을 걸 수 있다.

3번째 단계는 만족도(desirability)와 관련 있다. 목표를 달성하고 나서 뭐가 달라졌는가?
예) 나는 사진을 걸어서 내 집에 내 취향을 드러냈다.

이 3가지를 넘어서는 질문을 제품에 다시 연결하는 건 어려워진다. 예를 들어, "왜 당신의 집에 취향을 담고 싶나요?"라고 묻는다면, 드릴 제조업체에게는 의미 있는 답변을 얻기 어려워진다.

1. 사용성(Useful) 단계

전동 드릴을 예로 들자. 이 단계에서는 "사용자가 벽에 구멍을 내는 것"에 집중한다. 그렇다면 구멍을 잘 만들기 위한 것에 초점을 맞춰 개선안을 생각한다. '어디에 구멍을 낼 것인가? 나무? 콘크리트? 나무?', '구멍의 크기는?', '나사는 어떤 게 필요한가?' 이런 생각을 통해 고려되는 개선안은 '출력 변경', '드릴 속도', '속도를 조절하는 방법', '드릴 날 변경' 등 일 것이다. 이런 개선안의 한계는 드릴을 어떻게 쉽게 쓸 수 있을지에 대해선 생각하지 못한다.

2. 유용성(Usable) 단계

이 단계에서는 벽에 사진을 쉽게 걸 수 있게 도와주는 것에 집중한다. (단순히 구멍을 내는 게 아니라, 그다음을 생각한다.) 사용자는 사진을 벽에 걸 때 어떤 행동을 하는가? 의자에 서서 사용하는가? 드릴질은 편하게 하는가? 구멍을 잘못 내는 것에 대한 불안함은 없는가? 벽에 구멍을 잘 뚫기 위해 드릴을 디자인했다면, 얼마나 좋아질 수 있을까? 이런 생각은 드릴의 배터리, 무게를 줄이기 위한 모터의 사이즈, 구멍을 잘 뚫기 위한 가이드 등이 개선안으로 떠오를 것이다. 이런 생각의 한계는 어떻게 하면 드릴이 좀 더 매력적으로 보일지에 대한 것은 없다.

3. 만족도 단계

마지막 단계에서는 사용자가 드릴을 가지고 더 내 집 같이 보이게끔 하려고 한다. 드릴을 사용하여 얻는 결과가 내 취향이 더 묻어나는 거라면, 드릴을 어떻게 개선해야 할까? 드릴을 가지고 사진을 벽에 걸고 난 뒤, 드릴을 어디에 둬야 할까? 보관하기 쉽게 docking station을 만들어야 하나? 벽에 꽂아둘 수 있게 해야 하나? 책상, 선방 등 어딘가에 위치해야 하나? 이런 질문들은 드릴이 사용자를 위해 디자인되었다고 느끼게 할 수 있는 질문들이다. (개인적으로, 이런 부분까지 잘 충족시키는 게 Dyson, Balmuda 같다.)

천천히, 여유를 갖고

만약 당신이 특정 도구에 대해서 얘기하고 있을 때 극적이고, 최종적인 답에 대해 서두르지 마라. 항상 내 앞에 금(좋은 기회, 정답)이 있는 건 아니다. 종종 근본적인 답변은 하나가 아니다. 존재하더라고, 그 자체로 가치가 있는 것은 아니다. 각 계층이 제공할 수 있는 고유한 가치를 탐색해라.

이렇게 글을 종료된다. 다시 읽어도 좋은 글인 것 같다. 매 제품, 기능을 준비하는 순간마다 Customer Job, Root cause를 찾기 위한 시간을 할애해야겠단 다짐을 하며 글을 마친다.

출간 후 업데이트가 된 건 없는지, 글 하단에 있는 메일로 문의를 해보니 바빠서 업데이트하지 못했다고 한다.