[4월 TIL #1] 이미 알고 있던 문제를 왜 액션으로 이어가지 못했을까?

오늘 문라이트 팀원들과 개밥먹기(Dogfooding)를 하면서, 이미 알고 있던 사이드바의 문제를 다시 강하게 체감했습니다. 유저들이 가장 많이 쓰는 영역인데도 아쉬운 점이 크게 느껴졌고, 이미 알고 있던 문제를 다시 마주하니 죄책감까지 들었습니다. 아마 전혀 몰랐던 문제였다면 이런 감정은 아니었을 것입니다.

1. 우리가 문제를 방치했던 이유
처음에는 자연스럽게 “이걸 왜 아직 안 바꿨지?”라는 생각이 먼저 들었습니다. 그런데 정훈 님이 하신 말씀이 계속 남았습니다.

“우리가 이미 알고 있던 문제라면, 왜 그동안 액션으로 이어지지 못했는지를 돌아봐야 한다.”

이 질문을 붙잡고 생각해보니, 저는 그동안 문제를 너무 ‘측정 가능한 것’ 위주로만 인정하고 있었던 것 같습니다. 사이드바의 불편함이 분명 유저 경험을 해치고 있는데도, 데이터로 또렷하게 설명할 수 있어야만 ‘진짜 문제’라고 받아들이고 있었던 건 아닐까 싶습니다. 그래서 결국 해결해야 할 문제로 다루기보다 우선순위에서 밀어두고 있었습니다.

2. 기능이 아닌 '문제'를 주는 팀
오늘 Marty Cagan의 SVPG 아티클 「Team Objectives – Empowerment」를 읽었습니다. 글에서는 팀에 “무엇을 만들라”는 기능을 주는 대신 “어떤 문제를 풀어야 하는가”를 줘야 한다고 말합니다. 팀 목표의 핵심은 제품팀이 어렵고 중요한 문제에 대한 해결책을 스스로 생각해낼 수 있는 여지를 주는 데 있고, 성공은 활동이나 산출물이 아니라 비즈니스 결과(outcome)로 정의해야 한다고 강조합니다.

그 글을 읽고 다시 보니, 저 역시 문제를 보기 전에 해결책을 더 빨리 붙잡으려 했던 것 같습니다. 예를 들어 처음에는 “사이드바에 확대 버튼을 넣어야 하나?” 같은 식의 해결책을 먼저 떠올렸습니다. 하지만 조금 더 본질적으로 먼저 붙잡아야 할 것은 “유저는 요약을 본문보다 더 깊게 들여다보고 싶어 한다” 같은 문제 혹은 욕구 그 자체였습니다.

3. 앞으로의 다짐
1) 답부터 내놓지 말고, 진짜 붙잡아야 할 문제를 먼저 보기
자꾸 해결책을 먼저 떠올리게 되는데, 앞으로는 그 전에 유저가 어디서 막히고 무엇을 더 원하고 있는지를 우선하는 것을 체화하고 싶습니다.

2) 숫자로 안 잡혀도 분명한 불편은 문제로 인정하기
그동안은 측정되지 않으면 문제라고 부르기 어려웠던 것 같습니다. 이제는 반복해서 느껴지는 유저 불편이라면 일단 문제로 붙잡아보려 합니다. 그리고 나중에 그걸 어떻게 측정 가능한 언어로 바꿀지, 해결됐다는 건 무엇으로 알 수 있을지도 차분히 고민해보고 싶습니다.