우리 팀이 "문제 중심"으로 이야기하는 방법
"솔루션이 아니라 문제와 사랑에 빠져라" - 인스파이어드 中
솔루션 중심의 사고방식
저희 팀은 프로덕트에 대해서 매일 수 없이 많은 대화를 하는데, 그 과정에서 단 한 번도 빠지지 않고 나오는 내용이 있습니다.
"이런 건 어떨까요? 아니면 저렇게 해보는 건 어때요?"
"그건 이러한 이유에서 좀 별로예요. 대신 이렇게 해볼까요?"
정신없이 이야기하다 보면 어느 순간 본질을 잃고 서로의 의견을 설득하기 위해 애를 쓰는 모습을 발견하게 됩니다. 이미 상당히 흘러간 시간 속에 지쳐 결국 한 가지 방안을 선택하게 되고, 누군가에게는 썩 내키지 않은 결론을 내린 채 우리의 탁상공론을 끝맺곤 합니다.
이런 식의 방식으로 우리는 과연 최선의 결론을 내릴 수 있을까요?
사람은 자신이 고안해 낸 솔루션을 사랑하기 마련입니다. 그 솔루션이 공격을 당하면 이를 보호하고 싶어 하는 것이 본능이지요. 그러다 보니 내가 낸 솔루션 보다 더 나은 가능성이 있음에도 불구하고 한 가지 길로 편향되기 쉽습니다.
여러 가지 솔루션을 제안하며 문제를 해결하려고 하는 자세는 프로덕트 팀에게 꼭 필요한 자세입니다. 하지만, 해당 솔루션이 어떤 문제를 해결하기 위한 것인지 인지하지 못한 채 아이디어를 발산하기만 한다면 결국 본질을 잃어버리게 돼요. 심지어 가끔은 서로 다른 문제를 두고 솔루션에 대한 토의만 하다가 끝나는 경우도 있습니다.
해결책(솔루션)이 아니라 문제와 사랑에 빠져라.
그 문제에 대한 더 나은 해결책(솔루션)이 반드시 존재한다.
- 인스파이어드 中 -
저희 팀이 문제에 집중해야 하는 이유는 명확합니다. 이미 너무 많은 솔루션 중심의 사고와 시행착오들을 겪은 후였고, 점점 PMF로부터 달아나고 있다는 느낌을 받았기 때문입니다. 부끄럽지만 최근까지도 새로운 기능을 기획할 때가 되면 "이런 기능 어때요"라는 말부터 습관적으로 뱉고 있는 모습을 발견했습니다. 그래서 우리 팀의 근본적인 사고방식부터 바꿔야겠다고 다짐을 하게 된 것이죠 �
어떻게 하면 "문제 중심"으로 이야기할 수 있을까?
키블 팀이 생각한 가장 첫 번째 핵심은 "문제와 해결책(솔루션)을 구분하자"입니다. 듣기에는 매우 간단해 보이지만, 사람의 습관이란 게 참 무섭습니다. 한 번은 저희 아이템의 타겟이 가지고 있는 문제(Pain Point ; Needs)에 대해 이야기해 보는 시간을 가졌는데, 어느 순간 모두 다 해결책(솔루션)만 이야기하고 있는 모습이 참 가관이었습니다 �
그래서 저희는 한 가지 팁을 만들었는데요, 주장하고자 하는 내용 앞에 "이건 문제인데요 ... ", "이건 솔루션인데요..."라는 내용을 덧붙이는 것입니다. 그렇게 되면 자신이 주장하고자 하는 내용을 말하기 전에 "문제"인지 "해결책(솔루션)"인지 적어도 한 번쯤은 고민할 수 있으니까요!
두 번째는 "우리 모두가 같은 문제를 바라보고 있는지 확인하기"입니다.
해결책(솔루션)을 제안하고 싶다면, 그 해결책(솔루션)이 고객의 어떤 문제를 해결하기 위한 해결책(솔루션)인지 정확하게 인지하고 공유하는 것이 중요합니다. 그렇게 되면 우리가 적어도 같은 문제에 대해 고민하고 있다는 방향성 설정이 가능해집니다. 이런 구분점이 없었던 시절에는 각자 다른 문제를 두고 토론하느라 시간을 허비한 적도 많았는데, 이런 불상사를 방지해주는 기능도 있습니다.
"어떻게 하면 사용자가 ~ 할 수 있을까?"
저희 팀이 스프린트 회의에서 주제를 정할 때 활용하는 방법입니다. 스프린트 회의에서는 주로 서비스 주요 지표를 개선하기 위한 전략, 새로운 기능 및 서비스, 테스트하고 싶은 가설(백로그)들을 검증하려고 합니다. 이 때도 단순히 여러 가지 아이디어를 나열하는 방법보다는 하나의 포인트를 가지고 커뮤니케이션하려고 노력합니다.
저희 서비스의 콘텐츠 조회 숫자가 유저 유입에 비해 현저히 떨어진다는 점을 깨닫고, 이를 개선하기 위해 스프린트 회의를 진행한 적이 있습니다. 기존 같았다면 아래 예시와 같이 콘텐츠 조회를 올리기 위한 다양한 방법들을 나열하며 회의가 진행되었을 것입니다. 지금 상상하니 끔찍하네요
"콘텐츠 썸네일을 조금 더 매력적으로 바꾸어 볼까요?"
"UI를 조금 개선하고, 폰트를 통일시켜서 가독성을 높여볼까요?"
"다양한 콘텐츠를 더 제작해야 하지 않을까요?"
모두 다 테스트해 볼 만한 좋은 제안이지만, 각 주장들을 쪼개서 생각해보겠습니다.
[주장 1] : 콘텐츠 썸네일을 조금 더 매력적으로 바꾸자
이 주장에 대한 문제는 "콘텐츠 썸네일이 사람들의 집중을 끌지 못한다"겠죠?
[주장 2] : UI를 개선하고 가독성을 높이자
이 주장에 대한 문제는 "UI 및 가독성의 부족으로 사람들이 콘텐츠 소비를 어려워한다"일 것이고요.
[주장 3] : 다양한 콘텐츠를 더 제작하자
이 주장에 대한 문제는 "콘텐츠의 주제 및 다양성이 부족하다"입니다.
여기서 질문을 한 번 던져보겠습니다.
Q. 각 주장들은 문제인가요? 솔루션인가요?
A. 솔루션입니다.
Q. 각 주장들은 모두 같은 사용자 문제를 바라보고 있나요?
A. 아니요.
그렇다면 키블 팀은 이 회의를 어떻게 이끌어나갔을까요?
저희 팀은 "어떻게 하면 사용자가 우리의 콘텐츠를 더 많이 보게 할 수 있을까"라는 문장에서 스프린트 회의를 시작하였고, 이에 해당하는 문제를 찾기 위해서 한 번 더 고민하였습니다. 모든 콘텐츠가 전반적으로 뷰가 낮다는 점, 콘텐츠 탭으로의 유입 자체가 적다는 점을 고려하여 저희 팀이 통일시킨 문제는 "콘텐츠 자체가 노출이 되고 있지 않다"였습니다.
"어떻게 하면 사용자에게 우리의 콘텐츠를 더욱 많이 노출시킬 수 있을까?"
문제가 통일되고 나니 모든 팀원이 "콘텐츠 노출"이라는 하나의 포인트에 집중하여 솔루션을 제안하기 시작하였습니다. 결론적으로 저희 팀은 해당 스프린트에서 다음과 같은 솔루션을 도출하였습니다.
1. 콘텐츠의 일부를 미리 보기 형태로 홈 화면에 노출시키고, 콘텐츠 탭으로 이동 유도하기
2. 콘텐츠 카테고리 내에 숨겨져 있던 콘텐츠 중 일부를 탭 밖으로 빼내어 제목을 미리 노출시키기
하나의 핵심 문제를 함께 결정하고, 솔루션을 도출하고 나니 우리가 검증하고자 하는 가설을 파악하기도 쉬웠고 회의 시간도 많이 단축되었던 것 같습니다.
결론
겉으로 보기에는 굉장히 쉽고 당연한 이야기이지만, 이 부분을 팀원들과 함께 적용해나가야 한다는 부분이 작은 규모의 팀임에도 불구하고 굉장히 어려웠던 것 같습니다.
아직까지도 저는 "이런 건 어때요? 아참, 이건 솔루션이에요."라고 말하곤 합니다. 우리는 단순 솔루션을 나열하기 위해 모인 팀이 아니라, 진짜 문제를 해결하기 위한 팀이기 때문에 앞으로도 함께 "문제 중심"으로 이야기하는 법을 연습해 나가야겠습니다.
