문제 해결을 위한 3단계 프레임워크 가이드

(lennysnewsletter.com)

50P by quarter 5달전 | favorite | 댓글 3개

문제 해결을 위한 3단계 프레임워크

에어비앤비에 입사해 배운 점 중 하나는 무엇보다도 문제 정의를 올바르게 하는 것이 중요하다는 것입니다.
프로젝트를 실패로 이끄는 많은 요인이 있지만 해결 중인 문제를 오해하는 것보다 더 확실한 건 없습니다.
에어비엔비에서 저와 팀이 해결해야 할 진짜 문제는 "여행자가 다른 여행자와 어울리고 싶어한다"가 아니라 "여행자는 관광지가 아닌 양질의 일을 찾고 싶어한다"라는 사실을 너무 늦게 깨달았습니다.
다른 여행자들과 어울리는 것은 실제 문제가 아니라 이에 대한 한 가지 해결책이었을 뿐입니다.
문제를 해결하는 가장 중요한 단계는 문제 정의를 완성하는 것입니다. 문제 정의를 위해선 세 가지 간단한 단계만 거치면 됩니다. 이 프레임워크는 새로운 제품이나 새로운 기능을 염두에 두고 프로젝트를 구상할 때 가장 효과적이며, 엔지니어링 전에 수행해야 합니다.
1단계: 해결하려는 문제 구체화
2단계: 팀 및 이해관계자와 문제 조율
3단계: 다시 문제로 돌아오기

1단계: 해결하려는 문제 구체화

먼저 다음 질문에 답해 보세요.

설명: 무엇인가요?
문제: 어떤 문제를 해결하려 하나요?
왜: 이것이 진짜 문제이고 해결할 가치가 있는지 어떻게 알 수 있나요?
성공: 이 문제를 해결했는지 어떻게 알 수 있나요?
청중: 누구를 위한 것인가요?
대상: 제품에서 어떤 모습으로 보여줄 건가요?

설명: 무엇인가요?

이 프로젝트가 무엇에 관한 것인지 빠르게 파악할 수 있도록 간략하게 작성하세요.

문제: 어떤 문제를 해결하려 하나요?

문제를 가설처럼 생각하세요. 해결하려는 문제가 무엇이며 해결하려는 이유는 무엇인가요? 이후에도 추가적으로 더 많은 컨텍스트를 추가하세요.

[효과적인 문제 정의의 특징]

짧다 : 실제 문제를 설명하는 한 문장을 찾으세요. 설명해야 할 것이 많을수록 문제는 불명확해집니다.
집중 : 우리 팀이 갖고 있고, 합리적인 시간 내에 해결할 수 있는 단 하나의 명확한 문제만 포함하세요.
필요 : 사용자 요구 사항에만 초점을 맞추되, 필요한 경우 비즈니스 요구 사항도 포함할 수 있습니다. Jobs-To-Be-Done 프레임워크를 사용하세요.
'무엇'과 '왜' : 무엇이 잘못되고 있으며 왜 문제가 되는 지 기술하세요.
해결책 : 반드시 해결책을 포함해야 하는 건 아닙니다. 너무 일찍 해결책을 찾으려 하지 마세요.

[좋은 문제 정의의 예]

Lyft의 드라이버가 승객이 너무 멀리 떨어져 있다는 이유로 콜을 너무 자주 취소하고 있다.
에어비앤비 호스트는 개선을 원하지만 방법을 못 찾고 있다.
사용자가 가입의 마지막 단계에서 너무 높은 비율로 이탈하고 있다.

[잘못된 문제 정의의 예]

사용자 증가가 둔화되고 있다.

(문제가 너무 광범위합니다. 또한 사용자 중심적이지 않습니다.)
로열티 프로그램 구축하기

(너무 빨리 해결책을 가정하고 있습니다. 로열티 프로그램이 해결하고자 하는 문제는 무엇인가요?)
사용자가 가입 흐름에서 이탈하고 있습니다.

(문제가 날카롭지 않고, 이유에 대한 가설이 없습니다.)

왜: 이것이 진짜 문제이고 해결할 가치가 있는지 어떻게 알 수 있나요?

문제 정의(가설)을 뒷받침하는 증거를 수집하세요. 처음에 이것이 문제라고 확신한 이유는 무엇인가요? 이 문제를 해결해야 하는 이유는 무엇인가요?
어쩌면 이 단계에서 문제가 지금 당장 해결해야 할 가치가 없거나 문제에 대한 의견을 조정해야 한다는 것을 깨닫게 될 수 있습니다. 그렇게 되더라도 거부감을 갖지 마세요.
해결해야 할 문제들은 무궁무진하고, 여러분의 목표는 어디까지나 이 문제가 지금 당장 팀의 시간을 할애할 가치가 있다는 확신을 갖는 것입니다.

[팁]

양적/질적 증거를 모두 확인하세요
양보다 질

의미있는 3~5개의 데이터가 여러개의 관련성 낮은 데이터보다 훨씬 낫습니다. 종종 많은 증거를 보여주기 위해 사소하고 관련 없는 데이터로 채우는 경우가 있습니다.
악마의 대변인이 되어보세요 (의도적으로 반론을 제기하는 전략)

이 문제가 심각하거나 큰 문제가 아니라고 스스로를 설득해 보세요. 찾은 증거에 빈틈이 있나요? 증거가 정말로 여러분의 가설을 증명하고 있나요?

성공: 이 문제를 해결했는지 어떻게 알 수 있나요?

기능 X가 설정한 목표에 기여하나요? 그렇지 않은 경우 과감히 배제하세요.
먼저 목표가 정의되어 있고 쉽게 측정할 수 있는 구체적인 지표가 있어야 합니다.
팀의 KPI와 직결되는 것이 가장 좋으며, 기회 규모나 투자 규모 혹은 과거 실험에서 얻은 휴리스틱 등에 관한 하드 데이터를 기반으로 하는 것이 가장 이상적입니다.

[팁]

‘3개월 이내에 X 10% 증가, Y 50% 감소, Z 기능 채택률 20%’ 처럼 구체적인 숫자로 만드세요.
실현 가능하되 큰 목표를 정하세요.
목표에 맞는 구체적인 메트릭이 없다면, 이 기능이 크게 성공했을 때 세상이 구체적으로 어떻게 바뀔지를 기준으로 하세요.

청중: 누구를 위한 것인가요?

당연히 모든 사용자는 아니어야 합니다. 그렇다면 신규 또는 재사용자를 위한 것인가요? 혹은 일반 사용자용인가요? 그것도 아니면 paid 사용자용인가요?

무엇을: 제품에서 어떤 모습으로 보여줄 건가요?

여기에서 문제에 대한 해결책을 설명하세요.
제 경험에 비추어 볼 때, 여기서 핵심은 디자이너와 조율하는 일입니다. 디자이너가 얼마나 많은 세부 사항을 원하며, 그리고 그 과정에서 가장 도움이 되는 것이 무엇인지 파악해야 합니다.

2단계: 팀 및 이해관계자와 문제 조율

팀원 모두의 머릿속에는 각자 버전의 문제가 있습니다. 때로는 거의 동일하지만, 때로는 매우 다릅니다.
프로젝트가 크고 복잡할수록 다를 가능성이 높습니다. 2 단계에선 이러한 불일치를 조기에 근절하는 것입니다. 1단계를 수행했다면 10배는 쉬울 것입니다.

[접근법]

1 단계를 수행합니다.
이 프로젝트에 참여할 전체 팀과 초안을 공유하고 피드백을 요청하세요. 이후 피드백을 통합하고 다시 공유합니다.
피드백이 모아지고 의견이 일치한다면 넘어가세요. 그러나 그렇지 않다면 모든 사람을 한데 모아 의견 불일치를 직접 논의해야 합니다.
팀이 조율되면 이해관계자와 공유하세요. 디자인이나 엔지니어링 단계에 너무 깊게 들어가기 전에 팀 그리고 프로젝트의 성공 유무를 판단하는 사람들과 해결하려는 문제를 조율해야 합니다.
대면으로 문제 정의를 다시 검토하고, 질문을 받고, 팀이 해당 업무를 수행하는 데 필요한 것들을 갖추고 있는지 확인하세요.

3단계: 다시 문제로 돌아오기

제품 개발에서 생기는 고전적인 함정은 ‘시작은 원활하지만 가장 중요한 순간, 즉 작업이 실제로 수행될 땐 해결하고자 하는 문제를 고수하지 않는 경우가 많다.’는 것입니다.
몇 년 전, 전 에어비앤비 호스트를 위한 대시보드를 만드는 프로젝트를 진행했습니다.
저희가 정의하고 해결한 초기 문제는 호스트가 게스트의 메시지에 응답하는 평균 시간을 줄이는 것이었습니다. 우리의 가설은 ‘읽지 않은 메시지가 더 두드러지고, 응답 시간이 검색 순위에 영향을 미친다는 것을 상기시키면 호스트가 더 빨리 응답할 것이다’ 였습니다.
결국에는 우리의 가설이 옳았지만, 프로젝트 전반에 걸쳐 복잡성이 증가하고 문제의 범위가 점점 넓어졌습니다.
따라서 저는 팀원들에게 우리가 해결하고자 하는 문제가 무엇인지 반복해서 상기시켜야 한다는 것을 알게 되었습니다.
문제 정의와 성공 지표로 돌아가는 것만큼 프로젝트를 성고적으로 수행하는 데 도움이 되는 것은 없습니다.
여러 가지 방법으로 많은 문제를 해결할 수 있지만, 오히려 어떤 문제도 해결하지 못하는 멋지기만 한 제품을 만들 수도 있습니다.

[제품 개발의 함정 방지하기]

디자인 리뷰는 디자이너가 문제 정의를 검토하는 것에서부터 시작하세요. 만약 그게 명확하지 않다면 "우리가 어떤 문제를 해결하려고 하지?"라고 질문하세요.
이해관계자에게 진행 상황을 업데이트할 때마다 문제 정의를 검토하여 모든 사람이 결과에 동의하고 있는지 확인하세요
디자인을 마무리하기 전에 스스로에게 물어보세요 "이것이 우리가 해결하고자 하는 문제를 해결할 수 있을 것이라고 확신하는가?"

출처 : A Three-Step Framework For Solving Problems 👌 (lennysnewsletter.com)