[번역] 문제 해결을 위한 3단계 프레임워크
By Lenny Rachitsky (Airbnb)
본 글은 2019년 4월 11일, Lenny Rachitsky가 쓴 글(A Three-Step Framework For Solving Problems)을 번역/정리하고 코멘트를 더한 글 입니다.
Lenny Rachitsky와 그의 팀은 2012년부터 에어비앤비에 합류하여 Social Travel Experience를 만들어내기 위해 노력했지만, 괄목할만한 성과를 내진 못한 채 몇 달을 흘려보냈다. 그러던 와중 그는 프로젝트 실패를 만드는 가장 큰 원인이 '풀고자 하는 문제를 잘못 정의한 것'에 있다고 보고 제대로 된 문제를 정의하고 구체화 하는 법에 대해 정리했다.
풀고자 하는 문제를 제대로 정의해 못 박는 것이
제대로 된 문제 해결의 가장 중요한 첫 단계이다
그는 문제 해결을 3단계로 정의했다.
1. 풀고자 하는 문제를 구체화하기
2. 팀원 및 이해관계자들과 문제에 대한 컨센서스 맞추기
3. 끊임없이 문제로 복귀하기
이 글은 전략과 비전을 정의한 팀의 '전술' 단계에서 가장 유용함. 1. 풀고자 하는 문제를 구체화하기
지금 맡은 일 대해 다음 질문들을 던져보고 문제를 구체화 하는 작업을 진행한다.
설명 : 이건 무슨 프로젝트인가?
문제 : 어떤 문제를 해결하는 것인가?
이유 : 어떻게 이 문제가 풀어야 하는 '진짜' 문제인지 알 수 있는가?
성공 : 어떻게 이 문제가 해결 되었지 알 수 있는가?
고객 : 어떤 고객의 문제를 해결하는가?
제품 : 어떤 형태의 제품이 만들어져야 하는가?
이건 무슨 프로젝트인가?
우리가 하고 있는 일에 대한 간략한 설명. 사람들이 읽어보고 어떤 일을 하는지 바로 이해할 수 있는 짧은 설명
어떤 문제를 해결하는 것인가?
문제 정의(Problem Statement)는 가장 중요한 부분이니 시간을 가장 많이 할애할 것. 문제를 하나의 가설이라 생각하고 해결하고자 하는 문제에 대한 정의와 그 이유를 적어볼 것
문제 정의는 짧고 간결해야 함
문제 정의의 범위는 좁고 집중되어있어야 함
문제 정의엔 아직 채워지지 않은 필요(Needs)가 담겨 있어야 함
문제 정의엔 무엇(What)과 이유(Why)가 담겨있어야 함
문제 정의가 해결책을 전제하거나 얽매어 있으면 안됨
좋은 문제 정의 사례
리프트(Lyft) 운전사들은 승객이 너무 멀리 떨어져있어 호출을 자주 취소한다.
에어비앤비 호스트들은 더 성장하고 싶지만 성장 할 수 있는 방법을 찾을 수 없어 좌절을 겪는다.
회원가입 단계 마지막 단계에서 유저들의 일탈이 많이 일어난다.
나쁜 문제 정의 사례
유저 성장이 느리다 - 너무 브로드함
고객 충성 프로그램을 만든다 - 솔루션을 전제하고 있음
회원가입 단계에서 유저들이 많이 빠져나간다 - 충분히 좁혀지지 않았음
어떻게 이 문제가 풀어야 하는 '진짜' 문제인지 알 수 있는가?
이 단계에선 정의한 문제에 대한 실증적 증거들을 수집해야 함. 처음 이것이 문제라고 확신한 이유가 무엇이었는지, 왜 이 문제를 해결해야 한다고 생각했는지에 대한 이유를 마련해보기
종종 이 단계에서 '이 문제가 실제로는 지금 당장 해결할 필요가 없거나', '문제에 대한 생각을 다시 해볼 필요가 있다'는 걸 느낄 수 있음. 생각이 계속 뒤바뀌더라도 내가 정말 확신할 수 있는 문제를 찾는 것이 목표.
정량적인 증거와 정성적인 증거들을 동시에 찾아보기
너무 많은 데이터와 논리를 찾으려 하지 말고, 핵심적인 증거 몇가지에 집중하기
자기 자신에게 '악마의 대변인'이 되어 '이건 그렇게 중요하지 않은 문제 아닌가?' 되물어보기
어떻게 이 문제가 해결 되었지 알 수 있는가?
성공했는지, 안했는지는 매우 간단한 문제. 측정가능한 형태의 명확한 지표를 세워 목표를 설정해야 함
성공 여부를 판단할 수 있는 측정 지표 설정하는 방법
가능한 구체적인 숫자 형태로 설정할 것 ( 변수, 시간, 목표치 등)
실현 가능하지만 충분히 담대한 목표를 설정할 것
한번에 와닿기 어려운 목표가 아닌 구체적이고 생생한 목표를 정할 것
어떤 고객의 문제를 해결하는가?
모든 고객을 대상으로할 필요는 없음. 신규/재방문, 웹/앱 등 구체적인 타겟 세그먼트를 잡을 것
어떤 형태의 제품이 만들어져야 하는가?
문제의 해결책(솔루션)이 대부분 설명 되어지는 부분. 최대한 디테일하고 세부적으로 묘사해주어야 함.
디자이너와 함께 그 구체적인 상(프로토타입, mock-up, sketch) 등을 만들어 첨부할 수 있다면 베스트.
2. 팀원 및 이해관계자들과 문제에 대한 컨센서스 맞추기
팀에 있는 모든 구성원들은 문제 정의에 대해 저 마다 머릿속에 각기 다른 버전의 생각을 갖고 있을 것이다. 크고 복잡한 프로젝트일수록 구성원 간 간극이 더 클 것. 이런 불일치를 최대한 초기 단계에, 자주, 조정하고 컨세서스를 맞춰야 한다. 1단계에서 만들었던 문서를 통해 on the same page 하는 것이 중요하다.
1단계에서 만든 문제 정의 문서를 꺼낸다
모든 구성원들에게 공유하고 피드백을 받는다 (Email, 코멘트, 구두로 등등)
모든 구성원이 Align 되어 있다면 OK. 만약 약간의 불일치가 있다면 모두 모아서 컨센서스 맞추기
모든 구성원이 Align 되었다면, 다음은 이 내용을 이해 관계자들에게 공유하기.
** 구성원들이 문제를 본격적으로 해결하러 뛰어들기 전에 Align 되는 것이 매우매우매우 중요하다
3. 끊임없이 문제로 복귀하기
대부분 좋은 의도와 합의 된 마음으로 프로젝트를 시작하지만,
정작 실제로 작업이 완료되는 가장 중요한 시점엔
해결하려고 했던 문제를 까맣게 잊어버리는 경우가 많다
제품을 만들거나, 프로젝트를 진행하다보면 언제나 처음 정의하고 합의했던 문제에서 벗어날 가능성이 있다는 걸 명심해야 함. 우린 다양한 문제를 다양한 방식으로 해결할 수 있지만, 또한 반면, 아무 문제도 해결하지 못하는 제품을 정성스레 만들고 있을 수도 있다는 점을 늘 잊지 말아야 한다.
예쁜 쓰레기 만들기를 피하는 방법
디자인 리뷰 때마다, 디자이너들이 문제 정의를 복기한 후 리뷰를 시작하게 한다.
일이 진척 단계마다 모든 이해관계자를 모아 문제 정의를 복기하고 Align 한다.
디자인 완료 단계에서, 스스로에게 '이 제품이 우리의 문제를 해결할 수 있나?'에 대해 확신을 되묻는다.
우린 늘 문제를 안고 산다. 건강 문제를 해결하기 위해 헬스를 끊는다고 하더라도, 곧바로 새로운 문제가 나타난다. 아침 일찍 일어나 제시간에 운동을 가고, 땀흘려 운동하고, 샤워한 뒤 제시간에 회사로 가야하는 것 처럼. 문제는 결코 사라지지 않는다. 단지 교체되거나 업그레이드 될 뿐이다. - 신경끄기의 기술 중
