PM의 문제 정의 능력, 어떻게 기르나

 

PM 3년 차쯤 되니까 "이 사람은 문제를 잘 정의하네"라는 평가를 듣는 동료와, 그렇지 않은 동료가 확실히 나뉜다는 걸 느꼈습니다.
둘 다 회의도 열심히 하고, 문서도 열심히 씁니다.
그런데 결과물의 질이 달라요.
저는 한동안 후자에 속했던 사람이라, 이 차이가 어디서 오는지 꽤 오래 고민했습니다.
그 고민을 정리해보려 합니다.

 

입사 초반에 저는 "이탈률이 높다"는 걸 문제라고 정의하고 프로젝트를 시작한 적이 있습니다.
디자이너와 개발자를 모아서 온보딩 화면 UI를 통째로 뜯어고쳤어요.
두 달을 갈아 넣었는데 이탈률은 거의 그대로였습니다.
나중에 데이터를 다시 파보니, 이탈이 몰리는 지점은 온보딩 화면이 아니라 결제 수단 등록 화면이었어요.
"이탈률이 높다"는 증상이었고, 진짜 문제는 결제 수단 등록 단계에서 인증 실패가 반복되는 거였습니다.
그때 배운 게, 사람들이 저에게 들고 오는 문제는 대부분 증상이라는 사실이었습니다.
증상을 그대로 문제라고 받아들이면, 해결책도 증상에만 반응하는 대증치료가 됩니다.

 

이 실패 이후로 저는 "왜"를 다섯 번쯤 반복하는 습관을 들이기 시작했어요.
"이탈률이 높다" → 왜? → "결제 단계에서 많이 나간다" → 왜? → "인증이 자주 실패한다" → 왜? → "SMS 인증 코드가 늦게 온다" → 왜? → "특정 통신사에서 발송 지연이 있다".
다섯 번째 질문에 도달하니 진짜 원인이 나왔고, 해결책도 명확해졌습니다.
통신사 발송 지연 이슈를 알림사에 문의해서 개선했더니, 그 구간 이탈률이 3주 만에 눈에 띄게 줄었어요.
5 Whys가 만능은 아니지만, 적어도 "표면적인 증상에서 멈추지 않는다"는 습관을 몸에 붙여주는 도구로는 확실히 효과가 있었습니다.
저는 이제 누군가 "이거 문제예요"라고 들고 오면, 반사적으로 "왜 그게 문제라고 생각하세요?"를 먼저 묻습니다.

 

 

데이터로 문제를 재정의하기

 

문제 정의를 잘하는 동료들을 보면서 발견한 공통점이 하나 있었어요.
이들은 문제를 말로 정의하기 전에 항상 숫자를 먼저 봅니다.
"사용자들이 불편해한다"가 아니라 "특정 화면에서 평균 체류 시간이 3배 늘었다"는 식으로요.
저도 이후로는 문제를 정의하기 전에 관련 로그나 지표를 먼저 뽑아보는 걸 원칙으로 삼았습니다.
데이터를 먼저 보면 "이게 정말 문제인가"부터 걸러지는 경우가 많더라고요.
회의 시간에 감으로 오갔던 논쟁의 절반은, 데이터 한 장이면 끝나는 경우였습니다.

 

 

문제를 혼자 정의하지 않기

 

문제 정의를 개인의 능력으로만 생각하면 함정에 빠지기 쉽습니다.
저는 한동안 "내가 얼마나 날카롭게 문제를 짚어내는가"에만 집착했는데, 사실 더 중요한 건 다른 관점을 가진 사람과 문제를 같이 재정의하는 과정이었어요.
개발팀은 기술적 제약 관점에서, 디자이너는 사용자 경험 관점에서, CS팀은 실제 문의 내용 관점에서 같은 증상을 다르게 봅니다.
저는 문제를 정의할 때 이 세 관점을 각각 한 번씩 물어보는 걸 체크리스트처럼 씁니다.
혼자 정의한 문제는 나중에 꼭 어딘가 빠진 부분이 나오더라고요.

 

 

마지막으로 배운 건, 문제 정의를 말로만 끝내면 프로젝트 중간에 문제가 슬그머니 바뀐다는 것이었습니다.
회의에서는 "결제 인증 실패율을 낮추는 게 목표"라고 합의했는데, 두 주쯤 지나면 어느새 "결제 UI를 예쁘게 만드는 프로젝트"로 변질되어 있는 경우를 여러 번 봤어요.
그래서 저는 프로젝트 시작 시점에 문제 정의를 한 문단으로 문서화하고, 이걸 매 회의 첫 슬라이드에 그대로 붙여둡니다.
누군가 논의가 딴 길로 새면, 그 슬라이드를 가리키면서 "우리가 원래 풀려던 문제가 이거였죠"라고 되짚어주는 것만으로도 방향이 다시 잡히는 경우가 많았습니다.
별거 아닌 습관인데, 효과는 생각보다 큽니다.

문제 정의 능력이라는 게 타고나는 감각이라고 생각했던 시절도 있었는데, 지금 보면 결국 훈련의 문제였던 것 같습니다.
증상과 원인을 구분하는 습관, 숫자를 먼저 보는 습관, 다른 관점을 물어보는 습관, 정의를 문서로 박아두는 습관 - 이 네 가지를 꾸준히 반복하다 보니 어느 순간부터 "문제를 잘 짚는다"는 말을 듣게 되었어요.

아직도 매번 완벽하게 되지는 않지만, 적어도 이제는 증상만 보고 바로 뛰어드는 실수는 많이 줄었습니다.
다음엔 이렇게 정의한 문제를 어떻게 우선순위로 옮기는지에 대해서도 한번 정리해보려고 해요.