by
Feb 27. 2022
프로덕트 팀의 딜레마 : 어떤 문제를 풀 것인가?
문제가 많은 게 문제라서요
프로덕트 팀은 문제를 해결한다. 그런데 문제가 많은 게 문제다.
프로덕트는 사용자가 문제를 해결하는 수단이다. 프로덕트 팀은 그래서 사용자가 문제를 해결하는 걸 도움으로써 비즈니스의 문제를 해결한다. 쉽게 말해 프로덕트 팀은 문제를 해결하는 팀이다.
그런데 문제는 늘 다양하다. 하나를 해결하면 다른 하나가 찾아온다. 때론 해결한 줄 알았던 게 해결이 아니기도 하다. 때론 문제가 무엇인지도 모르는 경우도 있다. 문제라고 생각했던 게 문제가 아니기도 하다.
문제는 늘 다양하다. 하나를 해결하면 다른 하나가 찾아온다. 때론 해결한 줄 알았던 게 해결이 아니기도 하다. 때론 문제가 무엇인지도 모르는 경우도 있다. 문제라고 생각했던 게 문제가 아니기도 하다.
그러나 그 사이에도 시간은 흐르고, 팀의 리소스는 늘 한정되어 있기에, 대체 어떤 문제를 어떻게 찾아 무엇부터 어떻게 해결해야 할지 막막하기만 하다. 그래서 주로 아래와 같은 고민을 하게 된다.
1. 문제라고 생각되는 게 진짜 문제가 맞다는 걸 어떻게 알 수 있는가?
2. 현상과 원인을 어떻게 구분할 것인가?
3. 어떤 문제를 해결할 것인가? 누구의 문제를 해결할 것인가?
4. 어떤 문제를 '먼저' 해결할 것인가? '얼마나' 해결할 것인가?
5. 그 문제를 '어떻게' 해결할 것인가?
1. 문제라고 생각되는 게 진짜 문제가 맞다는 걸 어떻게 알 수 있는가?
문제는 어떻게 발견할 수 있을까? 발견한 문제가 진짜로 문제가 맞다는 걸 무엇으로 확신하거나 증명할 수 있을까?
어떤 문제는 직접적으로 나타난다. 주요 지표의 하락, 반복적으로 쏟아지는 고객 문의 등. 그런데 어떤 문제는 단기간에 직접적으로 나타나지 않을 수도 있다. 그래서 지금은 아무런 문제가 없는 것 같지만 언젠가 이자가 쌓여 되돌아올 수도 있다. 나중에 가서야 이게 문제였구나, 뒤늦게 알아차리는 것들.
가령, 서비스의 사용이 불편해도 대체제가 없다면 고객은 해당 서비스를 계속 사용한다. 계속 사용하기 때문에 지표에는 이상이 없다. 그러려니, 싶은 마음에 고객 문의를 남기지도 않는다. 그렇게 '문제없는' 상황이 지속된다.
그러나 그 틈을 타고 경쟁 제품이 나타난다. 궁극적으로 제공하는 가치는 동일한데, 이걸 더 편하게, 직관적으로, 혼선 없이, 빠르게 제공한다. 전환 비용이 낮다면, 이탈은 그렇게 발생한다. 아무런 문제도 없었는데, 없었다고 믿었는데. 마치 자신의 실수를 뒤늦게 깨달은 연애 드라마의 주인공 같은 심정을 겪게 된다.
그래서 모든 문제를 지표의 하락, 직접적인 voc의 발생만으로 발견하는 데엔 한계가 있다.
모든 문제를 지표의 하락, 직접적인 voc의 발생만으로 발견하는 데엔 한계가 있다.
2. 현상과 원인을 어떻게 구분할 것인가?
전환율이 떨어졌다. 매출액이 감소했다. 너무나 중요한 지표인데, 지표의 하락으로 명명백백히 드러났으니 이는 진짜 문제가 맞지 않겠는가?
그러나 이런 숫자들은 어디까지나 현상, 결과일 뿐이다. 진짜 문제는 전환율과 매출액을 감소시키게 한 원인이다. 이 경우 해야 할 일은 '무슨 수를 써서라도 지표를 다시 올린다'가 아니라, '지표를 떨어뜨린 요인을 찾아 개선한다'일 것이다.
너무나 당연한 이야기인가? 그러나 이렇게 당연한 이야기가 때론 적용이 어렵기도 하다.
만약 [네이버 지식in] 서비스에서, 질문을 작성한 이들을 대상으로 고객 조사를 했다고 가정하자. 그리고 고객 조사 결과 이들 중 상당수가 '답변의 퀄리티가 불만족스러워서' 더 이상 질문을 작성하지 않는다거나, 다른 서비스로 이탈했다고 가정해보자. 그러면 이 경우 '질문을 작성하지 않는다'가 아니라, '질문에 달린 답변의 퀄리티가 낮다'는 사실이 해결해야 할 문제에 가깝다.
정말 그럴까? 어쩌면 이 역시 현상, 결과는 아닌가? 애초에 답변을 작성하는 이들은 그럼 왜 퀄리티가 낮은 답변을 작성할까? 퀄리티가 낮으면 채택을 해주지 않을 텐데. 내공을 주지 않을 텐데.
그러면 정말 문제는 답변을 작성하는 과정에서의 UX/UI가 너무 불편하여 일정 수준 이상의 글을 작성하기에 어렵거나, 혹은 오히려 질문자의 질문이 두리뭉실하거나 애매모호한 건 아닐까? 진짜 문제는 거기에 있는 게 아닐까?
이처럼, 숫자로 드러난 사실 이면에도, 현상과 원인을 발라내고 진짜 문제를 찾는 문제가 남아있다.
숫자로 드러난 사실 이면에도, 현상과 원인을 발라내고
진짜 문제를 찾는 문제가 남아있다.
3. 어떤 문제를 해결할 것인가? 누구의 문제를 해결할 것인가?
요즘 대부분의 서비스는 플랫폼 형식이다. 판매자가 있다면 구매자가 있다. 생산자와 공급자가 있다면 소비자가 있다. 이 둘의 관계는 닭과 달걀처럼 상호 유기적이고 순회한다. 그리고 제품에 따라 구매자도 여러 유형의 구매자가 있고, 판매자도 여러 유형의 판매자가 있다. 같은 유형 내에서도 객단가, 빈도, 재방문율 등 서비스에 중요하다고 생각하는 기준에 따라 일종의 등급을 나눈다. 고객이라고 다 같은 고객이 아니고, 사용자라고 다 같은 사용자가 아니다.
이 경우, 우리는 누구의 문제를 해결해야 하는가? 어떤 문제를 해결해야 하는가? 하는 질문을 맞닥뜨린다. 모든 고객은 소중하지만, 모든 고객이 "똑같이" 소중하지는 않다. 한 시점에, 한 장소에서 모든 유형과 등급의 고객과 사용자를 동시에 같은 수준으로 대변할 수는 없다.
모든 고객은 소중하지만, 모든 고객이 "똑같이" 소중하지는 않다.
가령 강사와 학생이 만나 수업을 개설하거나 신청하는 서비스가 있다고 가정해보자.
강사는 서비스에 들어와 수업을 개설한 뒤, 개설한 수업의 목록을 확인하고 학생과 과제, 출석 여부 등을 관리한다. 이들은 전체 유저 중에서 차지하는 비중/숫자는 적지만, 이들이 있어야만 수업이 개설되며 한 번 이용하기 시작하면 몇 년 동안, 수 십 개의 수업을 개설한다.
반면 학생은 시험기간 혹은 취업준비 기간에 들어와 한 두 개의 수업을 수강한다. 이들은 직접적으로 돈을 지불하는 고객인 데다 전체 유저 중 상당수를 차지한다. 수업이 끝난 뒤에는 다시 방문하는 일이 저조하고, 시즌이 지나면 수업을 들을 이유가 사라지기에 대부분은 돌아오지 않는다.
그러면 이 경우, 서비스의 [마이페이지]는 주로 누구의 문제를 해결해야 할 것인가? 당연히 모든 고객을 위한 마이페이지가 되겠지만, 어떤 유형의 고객에게 가장 최적화되어야 하는가? 만약 마이페이지에서 강사와 학생들이 강의 목록을 확인해야 한다면 어떤 이들이 가장 주요하겠는가? 혹은 어떤 이들이 가장 이슈가 되겠는가?
강사
- 진행하고 있는 수업이 여러 개인 강사
- 진행하고 있는 수업이 1~2개인 강사
- 강사는 맞지만 수업을 개설한 적 없는 강사
학생
- 수강하는 수업이 여러 개인 학생
- 수강하는 수업이 1~2개인 학생
- 학생이긴 하지만 수강 내역이 없는 학생
누구의 관여도가 가장 높은가? 누가 가장 문제를 자주, 크게 체감할까? 거꾸로 말해, 문제를 해결했을 때 체감하는/발생하는 가치의 크기가 가장 큰 고객은 누구인가?
누가 가장 문제를 자주, 크게 체감할까? 거꾸로 말해, 문제를 해결했을 때
체감하는/발생하는 가치의 크기가 가장 큰 고객은 누구인가?
4. 어떤 문제를 '먼저' 해결할 것인가? '얼마나' 해결할 것인가?
문제는 이렇게 발견하고 정의한 문제들이 1개가 아니라는 점이다. 아마도 서비스가 클수록, 팀과 조직이 클수록 이렇게 발견하고 정의된 문제들이 백로그로 쌓이고 쌓여있을 것이다. 해야 하는 것과, 해달라는 것과, 하고 싶은 것, 급한 것과 덜 급한 것, 중요한 것과 덜 중요한 것이 뒤섞인다.
그러면 산적한 문제 중 무엇을 먼저 해결할지 고민하게 된다. 쌓아둔 백로그에서 스토리 포인트를 메긴다거나, I.C.E로 평가한다는 식의 프레임워크는 모두 이를 위한 수단이다. 무엇을 먼저 할까. 무엇을 이번에 할까.
또는 프로젝트 관점, 버전 관리 관점에서는 '얼마나' 해결할지 고민하게 된다. 1부터 10까지의 단계에서 이번에 10단계까지 한 번에 가야 하는가? 1단계는 어떠한가? 1단계가 너무 허술하다면 3~4단계까지 가보는 건 어떤가?
모든 문제를 동시에 해결할 수는 없다. 그리고 모든 문제를 마지막 단계까지, 100% 해결할 필요도 없다.
모든 문제를 동시에 해결할 수는 없다.
그리고 모든 문제를 꼭 마지막 단계까지, 100% 해결할 필요도 없다.
5. 그 문제를 '어떻게' 풀 것인가?
이 영역이 대부분이 고민하는 영역이자, 직무 체험 혹은 신입을 상대로 하는 많은 교육 콘텐츠가 다루는 내용이다. 구체적인 UX/UI를 그리고, 레퍼런스를 분석하고, 산출물 템플릿을 제공하고, 이를 잘 정리하여 입사용 포트폴리오로 만들게끔 안내한다.
그런데 앞의 1~4번의 고민이 명확하지 않다면, 사실 '어떻게' 풀 것인가에 대한 답은 무의미하거나 중요치 않게 된다. 기껏 풀었는데 10점짜리 문제 대신 2점짜리 문제를 풀었다면? 혹은 수학 시간에 국어 문제지를 꺼내어 풀었다면? 조악한 비유이긴 하나, 어떤 상황인지는 이해가 될 것이다.
풀 필요가 없었거나, 풀어도 별 효용이 없는 문제를 풀었다면, 잘해봐야 본전이다. 아니, 어쩌면 들인 비용과 놓친 기회비용을 생각하면 본전이 아닌 큰 손해일 지도 모른다.
그래서 '어떻게' 풀 것인가는 우리 눈에 가장 잘 보이는 영역이면서도 한 편으론 가장 나중의, 부차적인 영역이기도 하다. 적어도 PM에게는 그렇다고 생각한다.
'어떻게' 풀 것인가는 우리 눈에 가장 잘 보이는 영역이면서도 한 편으론 가장 나중의, 부차적인 영역이기도 하다. 적어도 PM에게는 그렇다고 생각한다.
