문제 해결을 위한 3단계 프레임워크
A 3 Steps Framework For Solving Problems
Localmind의 창업자이며 Airbnb에 매각 후 프로덕트 매니저로서 활동하고 있는 Lenny Rachitsky의 글을 번역한 글입니다. (원문)
A Three-Step Framework For Solving Problems �
2012년이 되어 우리 팀은 에어비앤비(Airbnb)에 합류했다. 우리가 해야 할 일은 에어비앤비 여행자를 위한 "소셜 여행(Social Travel)" 경험을 구축해야 하는 일이었다. 에어비앤비 여행자들은 도시 전역에 흩어져있으며 게스트가 더 쉽게 만나 함께 무언가를 할 수 있도록 한다면 에어비앤비 여행이 훨씬 더 의미가 있을 거라 생각했다. 우리는 여행자가 다른 여행자와 함께 할 수 있는 재미있는 지역 기반 경험을 디자인하기 위해 오랫동안 노력했다.
6개월 후 샌프란시스코에서 V1을 출시하게 된다. 제품은 아름다웠고 그 경험은 순조로웠다. 그러나 적용하는 건 끔찍했다 �. 적은 수의 여행자가 일시적으로 사용하기에는 괜찮았지만 우리가 기대했던 반응과는 거리가 멀었다. 우리는 약간 반복하고 점진적으로 개선했지만 몇 달 후에 서비스를 종료하게 되었고 다음 일을 진행했다.
제품 초기 디자인으로 Airbnb 여행자가 다른 여행자와 함께 할 수 있는 방법을 제공한다 - designed by Shaun Modi나는 이 경험에서 많은 것을 배웠지만 무엇보다도 문제를 올바르게 정의하는 것에 대한 중요성을 일깨우게 되었다. 많은 요인이 프로젝트의 실패 원인이 되었지만 문제에 대해 잘못 이해한 것보다 확실한 실패 원인은 없었다. 위의 예에서 우리는 해결해야 할 실제 문제가 "여행자들이 다른 여행자와 어울리고 싶어"가 아니라 "여행자들이 관광지 같지 않으면서도 고품질의 경험을 누리고 싶어 한다"는 것을 너무 늦게 인식했다. 다른 여행자와 어울리는 것은 실제 문제가 아니라 이에 대한 하나의 해결책이었던 것이다. 다행히 다른 팀이 이를 인식하고 몇 년 후 훨씬 더 나은 솔루션인 Airbnb Experience를 출시했다.
지난 게시물에서 언급했듯이, 나는 문제 정의 확인하는 것이 문제를 해결하는 가장 중요한 단계라고 굳게 믿는다. 문제 정의를 잘 못하기는 너무 쉬우며, 잘 수행만 한다면 최고의 리더들에게 최고의 힘이 된다. 다행히 다음과 같은 세 단계만 거치면 문제 정의를 잘할 수 있다.
1단계 : 풀고자 하는 문제를 구체화하기 (Crystallize the problem you are solving)
2단계 : 팀원 및 이해관계자들과 문제에 대한 눈높이 맞추기 (Align on the problem with your team and stakeholders)
3단계 : 끊임없이 문제로 돌아오기 (Keep coming back to the problem)
"진정한 행복은 자신이 즐기고 있는 문제를 발견하고 해결하는 것을 즐길 때 발생한다." - 마크 맨슨 (신경 끄기의 기술)
A little bit of context first
이 프레임워크는 새 제품이나 새 기능 중 하나를 염두에 두고 있는 프로젝트가 있을 때 가장 효과적이다. 기획 또는 개발에 뛰어들기 전에 다음 단계를 수행하여 프로젝트를 성공적으로 이끌길 바란다. 팀이 명확한 비전(i.e. 어디로 가는지)이나 전체적인 전략(i.e. 도달 방법)이 없는 경우 여기에서 잠시 멈추고 먼저 다음과 같은 상황을 파악하라. 분명 도움이 될 것이다.
이 가이드는 전술 레벨에서 가장 유용하다1단계 : 풀고자 하는 문제를 구체화하기
프로젝트에 대한 다음 질문을 하라 :
Description (설명) : 무엇인가?
Problem (문제) : 어떤 문제가 해결되나?
Why (이유) : 이것이 실제 문제이고 해결할 가치가 있다는 것을 어떻게 알 수 있나?
Success (성공) : 이 문제가 해결되었는지 어떻게 알 수 있나?
Audience (청중) : 우리는 누구를 위해 문제를 해결하려고 하나?
What (무엇) : 제품에서 이것은 어떻게 생겼는가?
이 편리한 1-Pager 템플릿을 사용할 수도 있다 (여기에서 복사). 한 사람이 첫 번째 패스(일반적으로 PM이지만 반드시 그럴 필요는 없음)를 받는 것이 가장 효과적이라고 생각한다. 아래는 질문에 대한 자세한 내용이다.
Description (설명) : 무엇인가?
디 부분은 당신이 생각하는 것에 대한 간단한 설명일 뿐이므로 문서를 읽는 사람들이 해당 프로젝트의 모든 내용을 빠르게 이해할 수 있어야 한다. 그러므로 짧게 유지하라.
Problem (문제) : 어떤 문제가 해결되나?
문제 정의 자체는 기초적이므로 거기에서 추가 시간을 보내라. 문제를 가설처럼 생각해라. 해결 중인 문제가 무엇이며 그 이유는 무엇인가? 나중에 더 많은 콘텍스트(context)를 추가할 것이다. 강력한 문제 정의의 주요 속성은 다음과 같다.
1. 짧다. 실제 문제를 설명하는 문장을 목표로 한다. 더 많이 설명해야 할수록 문제가 덜 명확해진다.
2. 집중되어 있다. 여기에는 단일팀이 소유할 수 있고 합리적인 시간 내에 해결할 수 있는 하나의 명확한 문제만 포함된다. 해결하지 *못하는* 문제에 대한 몇 가지 예를 추가하는 것은 종종 매우 유용하다.
3. 충족되지 않은 "필요"를 나타낸다. 사용자 요구에 초점을 맞추고 필요한 경우 비즈니스 요구가 될 수도 있다. 여기서는 Jobs-To-Be-Done(JTBD) 프레임워크가 특히 유용하다.
4. 무엇과 이유를 포함한다. 무엇이 잘못되고 왜 문제가 될까? 다음 섹션에서 이에 대해 백업해야 한다.
5. 솔루션에 구애받지 않는다. 일찍부터 해결책으로 넘어가고 싶은 충동을 물리쳐라.
좋은 문제 설명의 예 :
Lyft 드라이버는 승객이 너무 멀리 떨어져 있어 라이드를 너무 자주 취소한다.
에어비앤비 호스트는 개선을 원하기 때문에 좌절감을 느끼지만 그 방법을 파악하기 어려워한다.
사용자가 가입 과정의 마지막 단계에서 너무 높은 비율로 이탈한다.
잘못된 문제 설명의 예 :
사용자 증가가 느려지고 있다. (문제 : 너무 광범위하다. 여기와 여기에서 큰 그림 전략에 접근하는 방법에 대한 조언을 참조하라. 또한 사용자 중심이 아니다.)
로열티 프로그램을 구축하라. (문제 : 해결책을 가정하고 있다. 이것이 해결해야 하는 문제일까?)
사용자가 가일 절차에서 바운싱 되고 있다. (문제 : 무엇이 문제인지에 대한 집중력이 부족하고 이유에 대한 가설이 누락되어있다. 한 단계 더 깊이 생각하라.)
Why (이유) : 이것이 실제 문제이고 해결할 가치가 있다는 것을 어떻게 알 수 있나?
이 단계에서 문제 정의(가설)를 뒷받침하는 증거를 수집한다. 처음에 이것을 문제라고 확신한 것은 무엇인가? 이 문제를 해결해야 한다는 것을 명확하게 하는 것은 무엇인가?
때때로 이 단계에서 해당 문제가 지금 당장 우선순위를 정할 가치가 없거나 문제에 대한 생각을 조정해야 한다는 사실을 깨닫게 된다. 이것이 이 연습의 요점이므로 감내해라. 해결할 수 있는 무한한 문제가 있다. 당신의 목표는 이 문제가 현재 팀이 해결해야 하는 시간에 가치가 있다고 확신하는 것이다.
이 단계에 대한 몇 가지 팁 :
1. 양적 증거와 질적 증거를 모두 살펴보라. 당신은 현실적이고 중요한 문제임을 가리키는 모든 데이터 포인트를 수집해야 한다.
2. 양보다는 질을 생각하라. 3~5개의 강력한 데이터 포인트가 12개의 간접적 관련 포인트보다 훨씬 낫다. 연관성이 적은 포인트로 채워지는 데이터는 종종 많은 증거처럼 보이지만 오히려 너무 데이터의 양이 많아 신빙성이 약해진다. 케이스가 완벽하거나 감춰질 필요가 없다.
3. 의도적으로 반대의 의견을 말하라 (Play devil's advocate with yourself). 해당 문제가 실제 문제가 아니거나 충분히 큰 문제가 아니라는 것을 스스로 확신하라. 증거에 어떤 차이가 있는가? 증거가 진정 장신의 생각을 말해주는가? 자신을 믿어라.
결국 많은 트레이드오프(tradeoff) 중에서 판단이 중요하다. 당신의 임무는 당신이 가지고 있는 데이터로 최선의 경우를 만드는 것이다. 자세히 알아보면서 문제 설명을 계속 수정하라.
Success (성공) : 이 문제가 해결되었는지 어떻게 알 수 있나?
설정한 목적을 달성했는가? 그 질문에 답하고 이 단계에 적으라.
내가 그렇게 했는가? 아니면 하지 않았는가? Yes? No? 단순하다. - 앤디 그로브
이 기준(단계)은 결정을 내리고 우선순위를 정하는데 도움이 되므로 프로젝트 전체에서 매우 중요하다. 기능 X가 설정한 목표를 달성할 가능성이 높은가? 그렇지 않다면 잘라내라.
이상적으로 이 방법은 쉽게 측정할 수 있는 정의된 목표가 있는 특정 메트릭이다. 이상적으로는 팀의 KPI에 직접 연결된다. 이상적으로는 기회 규모, 투자 규모, 과거 실험의 휴리스틱에 대한 하드 데이터를 기반으로 한다. 드물게 이 방법은 이상적이다. 다음은 성공 기준을 정의하기 위한 몇 가지 조언이다.
3개월 이내에 X 10% 증가, Y 50% 감소, 기능 Z 20% 채택과 같이 구체적인 숫자를 만들기 위해 노력하라.
믿을 수 있지만 야심찬 목표를 선택하라. 만약 당신이 채택했다면 당신의 리더들이 기대할 수 있는 목표는 무언인가?
측정 항목이 목표에 맞지 않는다고 생각한다면 (길고 열심히 생각하라) 이것이 큰 성공을 거두었다면 세상이 어떻게 보일지 구체적으로 적으라. 그리고 그것을 성공 기준으로 삼으라.
Audience (청중) : 우리는 누구를 위해 문제를 해결하려고 하나?
모든 사용자에게 해당되는 경우는 거의 없지만 꾀 자명한 부분이다. 신규 또는 재방문 사용자를 위한 것인가? 일반 사용자 또는 전문가를 위한 것인가? 모바일 또는 웹 사용자를 위한 것인가? 등 을 고려하라.
What (무엇) : 제품에서 이것은 어떻게 생겼는가?
여기서 문제에 대한 해결책을 설명할 수 있어야 한다. 팀 운영 방식과 이미 알려진 정도에 따라 매우 높은 수준이거나 매우 상세하게 할 수 있다. 내 경험상 여기서 핵심은 디자이너와 협력하여 그들이 원하는 세부 사항과 프로세스에서 가장 도움이 되는 것이 무엇인지 파악하는 것이다.
2단계 : 팀원 및 이해관계자들과 문제에 대한 눈높이 맞추기
고속도로를 지나가다 Chipotle(치폴레) 광고판을 본 적이 있는가? 몇 년 전 내 동료인 Peter가 이 광고의 비법을 지적했다. 그것은 우리 각자는 은색 부리토 안에 있는 가장 이상적이고 맛있는 이상적인 부리토를 내 안에 그려내고 있다는 사실이다. 즉 우리 모두는 우리가 보고 싶은 것을 본다는 말이다.
https://imgur.com/gallery/LGLSn문제 정의는 위와 같은 은색 부리토와 같다. 팀원 모두 머릿속에 고유한 버전의 문제가 있다. 때로는 거의 동일하거나 때로는 매우 다르다. 프로젝트가 더 크고 복잡할수록 서로 다를 가능성이 더 크다. 당신의 임무는 이러한 불일치를 조기에 자주 근절하는 것이다. 포장지를 열고 모두가 내부의 부리토에 동의하는지 확인하라. 다행스럽게도 1단계의 훌륭한 문서가 있으면 작업을 10배 더 쉽게 할 수 있다.
나는 보통 다음과 같은 방법으로 이 단계를 접근한다 :
1. 1단계를 시작한다 (하지만 특정 문제에 대해 열정적인 팀원은 누구나 가능하다).
2. 해당 프로젝트에 참여할 전체 팀과 초안을 공유한다. 피드백을 요청하고 (댓글, 이메일, 혹은 직접) 피드백을 통합하고 다시 공유하라.
3. 피드백이 수렴되고 팀이 정렬된 것처럼 보인다면 좋다. 그렇지 않다면 모든 사람을 모아서 의견 차이를 통해 직접 대화하라.
4. 팀이 조정되면 이해관계자와 공유하라. 당신의 팀과 당신의 성공을 판단하는 사람들이 당신이 디자인 혹은 개발에 너무 깊이 들어가기 전에 당신이 해결하고 있는 문제와 일치하는 것이 매우 중요하다.
5. 문제 정의를 다시 검토하고, 미해결 질문에 답하고, 팀이 시작하는데 필요한 모든 것을 갖추고 있는지 확인하는 킥오프를 위해 팀을 모아라.
3단계 : 끊임없이 문제로 돌아오기
Jerry와 Elaine이 이전에 예약한 자동차를 얻으려고 시도하는 아래의 고전적인 Seinfeld 클립은 제품 개발의 고전적인 함정에 대한 훌륭한 은유다.
https://www.youtube.com/watch?v=PaPxSsK6ZQA당신은 예약하는 방법을 알고 예약을 유지하는 방법을 모를 뿐이에요.
그리고 예약을 유지하는 건 예약에서 제일 중요하죠.
유지!!! 누구나 예약은 할 수 있습니다.
우리는 종종 큰 의도와 조율로 시작하지만 가장 중요한 시점 (실제로 작업이 완료될 때)은 해결하려고 설정한 문제를 붙잡지 않는 경우가 많다. 이것이 문제의 가장 중요한 부분이다.
몇 년 전 에어비앤비 호스트를 위한 대시보드를 구축하던 프로젝트에서 작업했던 것을 기억한다. 우리가 정의하고 조정한 초기 문제는 호스트가 게스트의 메시지에 응답하는데 걸리는 평균 시간을 단축하는 것이었다. 우리의 가설은 읽지 않은 메시지가 더 두드러지면 호스트가 더 빨리 응답하고 응답 시간이 검색 순위에 영향을 미친다는 사실을 상기시켰다. 결국 우리는 옳았지만 프로젝트 전반에 걸쳐 범위와 복잡성이 커짐에 따라 (프로 팁 : 대시 보드는 고전적인 "실버 부리 토"문제다) 팀에게 해당 문제를 해결하기 위해 반복적으로 상시 시켜야 한다는 것을 알게 되었다. 문제 설명과 성공 지표로 돌아가는 것보다 범위 이동을 줄이는데 도움이 되는 것은 없다. 여러 가지 방법으로 많은 문제를 해결할 수 있지만 문제를 해결하지 않아도 되는 아름다운 제품을 만들 수도 있다.
몇 가지 함정을 피하기 위한 좋은 습관 :
1. 모든 설계 검토에서 설계자가 문제 설명을 검토하여 시작하는지 확인하라. 명확하지 않은 경우 "해결하려는 문제가 무엇입니까?"라고 질문하라.
2. 모든 진행 상황이 이해관계자에게 업데이트 될 때마다 문제 설명을 검토하여 모든 사람이 계속해서 결과에 부합하는지 확인하라.
3. 디자인을 마무리하기 전에 다음과 같이 자문하라. "이것이 우리가 해결하려고 했던 문제를 해결할 것이라고 확신한가?"
A final note
우리는 모두 기술 문제, 대인 관계 문제, 조직 문제 등 전문적인 문제 해결사다. 문제 해결에서 벗어날 수는 없다.
"문제는 삶에서 끊임없이 발생한다. 헬스장 회원권을 구매하여 건강 문제를 해결할 때, 제시간에 헬스장에 가기 위해 일찍 일어나야 하고, 타원형으로 30분 동안 필로폰처럼 땀을 흘린 다음 사무실 전체에 악취를 내지 않도록 일을 위해 샤워하고 갈아입는 것과 같은 새로운 문제가 발생한다. 수요일 밤을 "데이트 밤"으로 지정하여 파트너와 충분한 시간을 보내지 않는 문제를 해결하면 매주 수요일에 해야 할 일을 파악하는 등 두 사람이 싫어하지 않는 문제가 발생한다. 문제는 멈추지 않는다. 단순히 대체되거나 업그레이드 될 뿐이다." - 마크 맨슨 (신경 끄기의 기술)
자신과 팀에서 문제 해결 기술을 다듬는데 보낸 시간은 모두 잘 보낸 시간이다. 더 나아가고 싶다면 내가 강력히 추천하는 5권의 책이 있다.
1. 딥워크
2. 신경 끄기의 기술
4. OKR
5. 린 분석
문제를 보다 효과적으로 해결하는데 도움이 되는 추가 습관, 도구, 문서 등을 찾았다면 듣고 싶습니다. 제게 트윗해주세요.
Sincerely,
Big thank you to Sean, Brett, and Yelena for reviewing early drafts.
