이번 이야기는 최근에 경험한 실패담에서 시작하겠습니다. 이 실패는 병원을 대상으로 하는 SaaS 서비스 개발 과정에서 발생했습니다.

병원처럼 오프라인 경험이 중요하고, 실시간으로 업무를 처리해야 하는 고객들의 문제를 해결하는 건 저의 기존 제품개발과 문제발견 경험으로는 쉽게 풀 수 없는 문제였습니다. 저는 고객을 만나고, 그들의 이야기를 듣고, 자주 소통한다고 생각했습니다. 하지만 그것은 제 착각이었습니다. 저는 고객의 목소리에 귀 기울이고 있다고 자부했지만, 실제로는 그들의 진짜 문제나 그들조차 모르는 그들의 실상을 이해하지 못하고 있었습니다.

결과적으로 나름 인터뷰도 많이 하며 만들었지만 특정 기능은 그들의 현실을 더 낫게 만들어주지 못함을 깨달았습니다. 그렇게… 슬프지만 재개발을 하게 되었죠. 덕분에 저희 팀원들을 1달 더 고생하게 만든 뼈아픈 실패였습니다.

이 경험은 저희에게 많은 것을 가르쳐 주었습니다. 크게 실패와 교훈 4가지로 정리해 보자면 아래와 같습니다.

실패 → 교훈

1. 고객이 가장 궁극적으로 바라는 것을 모른채로 모든 우물을 전부 열심히 팠던 실패

   → 고객이 가장 중요하게 원하는것, 그것만 해내도 된다!

2. 고객이 해달라는 그대로 작업했다가 제대로된 해결은 안되고 일만 많아진 실패

   → 꼬리에 꼬리를 무는 질문으로 고객의 요청, 그 너머에 있는 근원적 문제를 파고들어야 한다!

3. 고객 스스로도 인지 못하는 디테일한 프로세스를 빠뜨려서 겪은 실패!

   → 고객 여정의 매순간, 아주 작은 과정이라도 집요하게 발굴해야 함!

4. 고객이 제품을 사용하는 실제 상황을 모른채로 만들어서 겪은 실패!

   → 실제 환경은 더 복잡해서 철저히 이해해야함!

1)을 못하면 덜 중요한 문제만 해결하는 제품이 나옵니다. 2)를 못하면 근본적인 해결 없는 땜질 같은 제품이 돼버리죠. 3)을 하지 못하면 결국 실제 상황과 미묘한 괴리로 인해 불편한 UX가 만들어지고 4)를 못하면 테스트할 때만 완벽하고 실상에선 욕먹는 제품이 됩니다.

위 문제를 해결하기 위해선 어떤 고민과 액션이 필요한지 논의해서 저희 팀은 아래와 같은 내용들을 정리했습니다.

깨달은 것들

교훈 → 액션

1. 고객이 가장 중요하게 원하는 것을 찾기 - 핵심문제 선택과 집중

“상담선생님, 저는 요즘 밥도 별로 안 먹고 싶고, 운동도 안 하고 싶고, 회사도 안 다니고 싶고, 삶에 대한 의욕이 별로 없습니다”

누군가 상담센터에 찾아와 이렇게 이야기한다면, 어떤 설루션이 필요할까요? 밥을 잘 먹기 위한 맛집 추천과 운동을 재미있게 할 수 있는 좋은 PT 코치님을 소개해드리고, 회사를 의욕적으로 다니기 위해 연봉 협상하기를 권유하고, 문제로 보이는 모든 것을 해결해드려야 할까요?

물론 존재하는 이슈들을 해결하면 좋겠지만, 사실 이 사람에게 가장 중요한 것은 삶에 대한 의욕이 없는 문제입니다. 회사이슈, 운동이슈 다 해결하지 않고 삶에 대한 의욕만 해결해 드려도 이 사람은 이 상담센터를 최고라고 소문내고 다닐 것입니다. 여전히 회사는 좀 안 다니고 싶어도 훨씬 중요한 문제가 해결됐으니까요.

제품을 통해 해결하는 고객의 문제도 마찬가지입니다. 제품이 커버하는 영역이 넓을수록 고객은 다양한 문제들을 이야기합니다. 그래서 그 모든 것을 다 잘하려는 착오에 빠지는 경우가 생기죠.

작년 제품 초기 기획안을 들고 가서 어떤 의사분을 만났을 때였습니다.

나 : “저희가 예약도 이렇게 편하게 만들었고, 저 기능도 좋게 만들었고, 이 기능은 훨씬 간소화했고, 어쩌고 저쩌고~(중략),보시기에 어떤가요?” 
고객 : “좋네요.. 좋은데.. 사실 솔직히 말하면, 예약이나 뭐 다른 기능보다 저는 OO기능에 관심이 많습니다. 이 부분 해결하는 것이 개원 후 최대 고민이어서요”

이때 정말 망치로 머리를 맞은 기분이었죠. 각각의 세부 영역을 담당하는 고객들 목소리를 하나하나 들어가며 좋은 제품을 만든다 생각했는데, 그것은 우선순위 개념이 옅어진 액션이었을 뿐이었습니다. 특정 기능은 경쟁사와 비슷하거나 약간 부족할지라도, 가장 중요한 기능을 획기적으로 개선한다면 그것이 고객이 가장 중요하게 생각하는 목적을 달성하고 그래서 우리 제품을 쓰게 만드는 이유가 되는 것이었죠. (곧바로 회사에 돌아가 다시 OO기능을 파고들기 시작했습니다)

이를 알아내려면 고객이 속한 비즈니스를 이해하고, 고객의 현재 사정을 알아야 합니다. 그러기 위해 나부터 이 도메인의 전문가가 되어야 합니다. 도메인의 이해가 없다면 계속 국소적인 부분들만 보게 될 테니까요. 이 시장, 그 안에 있는 플레이어들, 그들의 공통적인 고민, 현재의 트렌드 등 을 아느냐 모르느냐가 궁극적인 문제를 찾아가는 관건이 됩니다. 깊이 이해하기 위해선 직접 시간과 에너지를 쓰는 수밖에 없습니다. 나가서 고객들을 만나세요.

그리고 단순히 제품을 만들기 위한 인터뷰가 아니라 이 고객을 성공으로 이끌 컨설팅을 한다는 생각으로 ‘나무보다 숲’의 이야기를 들어보세요. 그리고 그 과정에서 적절한 질문(아래 소개할 5Whys 방법론)을 통해 ‘숲 속 모든 나무 중에서 가장 중요한 나무, 핵심 문제를 찾아낼 수 있습니다.

2. 꼬리를 물며 근원적 문제를 파고들기 - 5 Whys

고객집착, 고객만족이라는 단어를 얘기하면 가끔 고객이 바라는 것을 다 해줘야 한다, 고객의 목소리가 최우선이다,라고 단편적으로 생각될 때가 있습니다. 하지만 고객이 해달라는 것을 그대로 해주는 것이 고객만족, 고객집착이 아닙니다. 우리는 고객이 내는 목소리 그 너머에 있는 진짜 문제를 찾아내야 합니다. 때론 고객 자신조차도 인지하지 못하는 문제를 우리가 알아내서 해결해야 하는 거죠. 마치 정신과 전문의가 환자조차 기억 못 하던 어린 시절의 트라우마등의 근원적 이유를 찾아내는 과정과 비슷하달까요.

이런 방식으로 숨겨져 있는 진짜 문제를 알아내기 위한 좋은 접근법이 바로 5 Whys입니다. 고객이 어떤 요구를 할 때 “왜 그런 요구를 하시나요?” 라는 질문으로부터 시작하는 방법이죠.

꽤 유명한 제퍼슨 기념관의 사례를 통해 5 Whys를 소개해봅니다.

사례: 제퍼슨 기념관의 대리석 손상 문제

문제: 워싱턴 D.C.에 위치한 제퍼슨 기념관의 대리석이 손상되고 있었습니다. 이때 그저 대리석이 손상되고 있으니 빨리 대리석을 교체해야지~ 같은 솔루션이 아니라 진짜 이유를 파악하기 위해 파고들었다고 합니다.

1차 Why? - 왜 제퍼슨 기념관의 대리석이 손상되고 있나요?
- 답변: 대리석을 빠르게 침식시키는 새의 배설물이 문제였습니다.

2차 Why? - 왜 새의 배설물이 그렇게 많이 있나요?
- 답변: 기념관 주변에 새들이 집단으로 모여들기 때문입니다.

3차 Why? - 왜 새들이 기념관 주변에 집단으로 모이나요?
- 답변: 새들이 모여드는 곤충이 많기 때문입니다.

4차 Why? - 왜 그곳에 곤충이 많은가요?
- 답변: 밤에 불을 밝히면 곤충들이 그 빛에 이끌려 모여듭니다.

5차 Why? - 왜 밤에 불을 그렇게 밝히나요?
- 답변 : 퇴근시간에 맞춰 불을 켜두고 가는데, 그 시간이 다른 건물들보다 가장 이른 편이라서.

자칫 잘못하면 대리석 교체만 자주하면서 비용만 엄청 쓸뻔한 상황을 근본적으로 해결할 수 있게 된 사례로 유명합니다.

이것을 저희 제품의 사례에 대입해보자면..

고객 : “이 시점에 이 환자 알림카드를 빨간색으로 바꿔주세요”
우리 : “네!.. 가 아니라 왜 그렇게 바꾸는게 좋다고 생각하시죠?”

고객 : “그래야 의사들이 이걸 놓치지 않고 볼테니까요.”
우리 : “ 왜 의사들이 그걸 그 시점에 꼭 봐야하나요? 또 왜 놓친다고 느끼실까요?”

고객 : “의사들이 빠르게 환자분들에게 응대를 하러 가야하니까요. 그런데 가끔 의사를 기다리는 경우가 생기게 되는걸 보면 의사가 그 상황을 모르는것 같아요”
우리 : “(빠른 응대는 필수니 이해) 대기 시간이 의사가 화면에서 무언가를 놓쳐서 발생하는걸까요? 의사가 화면을 계속 보는데도 놓치는걸까요? 아니면 다른 이유가 있을까요?“

고객 : “흠.. 여러가지 이유가 있는데~~ 여러 의사가 한 PC를 통해 알림을 확인하고~ 의사들이 돌아다니고~ (중략) “
우리 : “그렇다면 오히려 PC에서 색깔로 무언가 알려주기보다 의사들이 돌아다닐때도 개별로 쉽게 체크 가능하게 하면 어떨까요?” 

고객 : “아…!! 그게 더 좋을것 같아요”
우리 : “(의사들이 핸드폰을 소지하고 다닌다고 하기에) 그럼 의사가 언제 어디서든 빠른 환자대응을 위한 실시간모바일 알림을 만들어볼게요” 
 → 부분적인 UI를 바꾸는것보다 더 궁극적인 솔루션을 찾아냄.

실제로 이런 식으로 첫 요구사항과 궁극적인 해결책이 달라진 적이 한두 번이 아니었고, 결과는 오히려 고객들이 더 만족하는 방향으로 나오게 되었습니다. 이 방법은 이미 교과서적인 것임에도 불구하고 무수히 많은 인터뷰를 하다 보면 점점 관성에 의해 수박겉핧기식의 조사를 할 때가 생깁니다. 이 점을 경계하고 늘 근원을 파고들어야 합니다.

3. 고객 여정의 작은 과정마저 집요하게 발굴해내기 - 프로세스 시뮬레이션

“핸드폰으로 친구와 전화하는 과정을 설명해 주세요”

이런 요청을 받으면 어떻게 설명하실 건가요? 누군가는 “친구 이름을 검색해서 전화를 겁니다”라고 할 것이고, 더 디테일한 분은 “친구이름을 타이핑하고 검색 결과에 나온 친구를 선택한 다음 전화 걸기 버튼을 누릅니다”라고 할 수도 있습니다. 이걸 제가 정말 자세하게 적어볼까요?

- 핸드폰을 손에 듭니다
- 대부분의 경우 사용자보호기능이 걸려있기에 페이스아이디나 여러 방법으로 잠금을 해제합니다
- 전화 어플을 누릅니다
- 주소록 검색기능에 들어갑니다
- 주소록 검색바를 터치하고 키보드로 원하는 이름을 입력합니다
- 매 입력마다 필터되는 이름중에 원하는 이름이 나오면 선택합니다
- 전화걸기 버튼을 누릅니다
- 핸드폰을 들어 귀에 가져가거나 이어폰등의 장치가 있으면 그걸 통해 이야기나눕니다

매일 같이 전화기능을 쓰는 사람들마저도 이 과정을 그냥 설명하라고 하면 이만큼 자세하게 나오지 않는 경우가 대부분일 겁니다. 왜냐하면 자신이 이런 과정을 거치고 있는지조차 모를 정도로 무의식적으로 하는 행동이기 때문이죠.

고객의 과정을 탐색하는 과정도 마찬가지입니다. 고객은 하루에도 수십 수백 번씩 하는 프로세스이기에 우리에게 그냥 설명할 때는 많은 부분들이 빠져있거나 당연해서 설명하지 않았을 수 있습니다. 그런 상태로 그 프로세스를 대체할 새로운 제품을 만든다면? 당연히 실패하게 될 겁니다.

그래서 프로세스를 이해할 때는 A부터 Z까지! 모든 단계를! 디테일하게! Step-by-Step으로 파고들어야 합니다. 단순히 질문만 세세하게 하는 게 아니라 그 과정을 하나하나 머릿속으로 그려가면서 집요하게 시뮬레이션합니다.

고객 : “그 다음에 해당 환자분 시술이 끝났다면 밖으로 모십니다. 끝났다고 데스크에 얘기하고 나서...”
우리 : “잠시만요! 환자분이 시술이 끝났는지는 어떻게 아시는건가요? 
그걸 아셨을때 당신은 어떤 행동을 하시나요? 그 행동을 할때 손에는 뭘 들고 계신가요? 
밖으로 모실때는 직접 하시나요? 데스크에는 무전기로 얘기하시나요? 
무전기로는 그 외에 어떤 이야기를 하시나요? 그걸 듣고 행동하는 사람은 누구인가요? 
다같이 들을텐데 그 중 누가 응대할지는 어떻게 정하나요?“

고객 여정에 약간의 변화가 있을 때마다 고객의 눈, 입, 손 등이 어디를 보고, 어떤 말을 하고, 어떤 작업을 해야 하는지를 집요하게 질문하세요. 당신의 머릿속에서 하나라도 모호한 부분이 있다면 그 과정을 밝혀내야만 완벽하게 프로세스를 파악할 수 있습니다. 심지어 여러 예외사항이나 변수에 따라 달라지는 프로세스도 파악해야 정말 온전한 제품을 만들 수 있습니다.

4. 고객의 복잡한 실제 환경 파악 - 리얼월드 시뮬레이션

아무리 열심히 고객의 문제와 프로세스를 깔끔하게 파악해도 현실은 그 이상의 복잡성을 가지고 있습니다. (실제로 1번의 제퍼슨 기념관 사례도 결국 불 좀 늦게 끄는 걸로는 확실히 해결되지 않았고 그 이유는 굉장히 복합적이라는 글이 있더라는… )

현실세계(이하 리얼월드)는 복잡성의 세계입니다. 사람이 일을 하기에 매번 다르고, 또 매번 다른 사람이 일하기도 하고, 매번 다른 고객들이 찾아오고, 매번 다른 상황이 벌어집니다.

특히 온라인뿐만 아니라 온오프라인이 혼합된 병원 같은 환경에서는 이 복잡성이 더 커집니다. 이번에 저희가 겪은 실패 중 하나는 이러한 복잡성과 실제 케이스에 대한 충분한 고민이 부족했다는 점입니다.

예를 들어, 저희는 예약용 소프트웨어를 개발하고 예약건을 20개 정도 넣어두고 테스트했습니다. 하지만 실제 병원에서는 하루에 예약이 300개에 달했고, 그런 데이터를 생성하자 소프트웨어가 현저히 느려져 테스트하기 어려운 상황이 되었습니다. 또 20개일 땐 괜찮았지만 300개가 되니 UI 복잡성이 너무 커져서 눈을 어디에 둬야 할지 모르겠더군요.

또한 네트워크 속도는 저희 회사보다 훨씬 느렸고, 사용하는 컴퓨터의 성능도 개발자들의 맥북보다 현저히 낮았습니다. 사용자들이 대부분 윈도 PC를 사용한다는 것까지는 예상했지만, 더 디테일한 부분은 놓쳤습니다. 각자 계정으로 소프트웨어를 사용한다는 가정하에 UX를 최적화를 해두었는데, 어떤 부서의 근무자들은 한 PC에서 여러 명이 작업하면서 그 전제가 무너지는 경우도 발생했습니다.

그 과정을 통해 깨달았습니다. 온오프라인 경험을 이어주는 소프트웨어라면 더욱 더 리얼월드에 대한 철저한 이해와 시뮬레이션이 필요하다는 것을. B2C 제품을 만들면서 성능이 비슷한 스마트폰과 속도가 균등한 통신사를 사용하는 사람들의 모바일 앱 내 경험만 고려하던 저에게는 아주 쓴맛을 느끼게 한 경험이었습니다.

덕분에 이제는 아래와 같은 체크리스트등을 기반으로 개발할 때마다 해당 요소들을 체크하고 시뮬레이션해보려고 합니다.

시스템 환경

• 운영체제(OS)
• 브라우저
• 네트워크 속도
• PC 사양

고객의 사용 환경

• PC를 쓰는 경험 (1인 1대인지, 여러 명이 돌아가며 사용하는지)
• 사용자의 IT 친숙도
• 사용자가 인이어나 헤드셋을 착용하는지, 소리를 켜두는지
• 사용자가 어떤 상황에서 어떻게 소프트웨어를 사용하는지(서있나 앉아있나 한 손 쓰나 양손 쓰나 등등)
• 사용자의 바쁜 정도 (소프트웨어를 보거나 쓰거나 할 타이밍)
• 소프트웨어가 항상 화면에 띄워져 있는지
• 컴퓨터가 매일 재부팅되는지, 아니면 꺼지지 않는지

데이터 환경

• 특정 기능에 데이터가 얼마나 많이 노출되거나 색인되는지, 혹은 아예 없을 수도 있는지
• 특정 기능에 데이터가 얼마나 실시간으로 처리되어야 하는지
  
  

마무리

위의 실패와 교훈, 그리고 새로운 액션을 통해 많은 것들이 달라졌습니다.

1. 다른 기능보다 핵심기능 하나를 집요하게 파고들어 고객의 만족을 이끌어냈고 (그랬더니 다른 기능들 좀 부족해도 빨리 도입하고 싶어함)
2. 고객이 처음 제안한것보다 더 적게 개발하고 더 큰 만족을 이끌어 냈으며
3. 고객조차 인지못한 작은 프로세스도 제품에 빠짐없이 반영하고
4. 고객의 오프라인경험에 맞춰 제품을 만들어내서 테스트때 큰 호응을 이끌어내기도 했습니다.

제품 개발의 여정은 복잡하고 어렵고 예측 불가능한 순간들로 가득 차 있습니다.
그래서 우리는 고객의 핵심니즈, 근원적 문제를 파악하고, 리얼월드의 복잡한 프로세스와 변수를 이해하는 최선의 방법을 찾아가려고 합니다.

앞으로도 아마 이번과 같은 실패를 많이 하겠지만, 그를 통해 배우고 끊임없이 성장할것입니다. 천천히 하지만 분명하게.

💡 제가 좋아하는 배우, 덴젤워싱턴이 했던 연설중 이런 메시지가 있습니다.
“Fall Forward”

살다 보면 넘어지는 것은 당연합니다. 대신 넘어지더라도 앞으로, 도전하면서, 전진하면서 넘어지라는, 그리고 다시 일어나 나아가라는 의미가 여기 담겨있습니다.
넘어지세요. 뒤로 피하지 말고 꼭 앞으로 넘어지세요. 그러면 일어났을 때 그만큼 더 전진해 있을 겁니다. 저의 ‘앞으로 넘어지는 실패이야기’는 앞으로도 계속됩니다.