기획을 입자가속기에 넣고 쪼개면
좋은 PM의 역량을 알아보기 위해 '기획'을 최소 단위로 쪼개 보자.
저번 글에서 프로덕트 매니저가 하는 업무의 기초는 서비스 기획자가 하는 업무와 다르지 않다고 소개한 바 있다. 프로덕트 매니저 업무의 출발은 결국 기획이라고 생각한다. 그럼 기획은 뭘까?
기획1企劃 : 일을 꾀하여 계획함
기획2奇劃 : 기발한 계획
이 중 프로덕트 매니저의 '기획'에 더 가까운 단어는 아마도, 1번 단어일 것이다. 기획은 결국 어떤 문제를 해결하기 위해 일을 벌이는 것이라고 볼 수 있다. 기획이라는 단어를 쓰는 곳은 비단 IT 업계 뿐만은 아니지만, 결국 어떤 업계에서든 이 단어를 새로운 일을 꾸미고, 그 일을 추진하기 위한 계획을 세우는 일을 . 방송업계에서는 새로운 TV 프로그램을 만들어내는 것을 기획이라고 부르고, 행정학적으로는 막연한 목표만을 담고 있는 정책을 보다 실효성 있는 작은 목표와 계획들로 쪼개는 것을 기획이라고 부른다. IT 업계에서는 보통 어떤 문제를 해결하기 위해 도입하기로 한 시스템(프로그램)을 설계하는 사람들을 기획자라고 부른다. 세 가지 일은 얼핏 보기에는 완전히 다른 일 같이 보일 수 있지만 결국 아래의 두 가지를 포함하는 행위이기 때문에 거의 동일한 행위 -기획을 한다는- 라고 볼 수 있다.
기획 = 목표 + 계획
기획은 결국 두 가지로 이루어져 있다. 일, 목표가 있어야 한다. 성취하고자 하는 뚜렷한 목표가 없으면 기획이 아니다. 이, 그 목표를 달성하기 위한 구체적인 계획 (실행방안)이 있어야 한다. 1박 2일을 기획한 나영석 PD의 목표는 무엇일까? 아마도 주말 오후 6시쯤 온 가족이 둘러앉아 밥 먹으면서 볼 수 있는 재밌는 예능 프로그램을 만드는 것이 1차 목표였을 것이고, 그 프로그램으로 높은 시청률을 달성하는 게 2차 목표였을 것이다. 물론 그 외에도 여러 가지 목표가 내부적으로도, 또 개인적으로도 있었을 수 있다. 목표를 세웠으니 그 다음은 계획을 세워야 한다. 일차적으로는 그 프로그램을 만들기 위한 금전적인 투자를 받기 위해 기획안을 써냈을 거다. 서로 다른 나이, 직업을 가진 연예인들 7명을 모아서 자기네들끼리 여행을 보낼 겁니다. 재미를 위해 여행을 그냥 보내지는 않고 중간 중간 게임을 해서 밥을 먹을 사람과 그렇지 않을 사람을, 따뜻한 숙소에서 잘 사람과 찬 냉바닥에서 잘 사람을 나눌 겁니다. 이런 식으로 목표와 그 목표를 이룰 수 있는 가장 커다란 계획을 세운 다음에는 또 주 단위의 계획을 세웠을 거다. 이번 주에는 여행을 어디로 가지? 밥은 뭘 먹이지? 게임은 뭘 시키지? 어떤 게임을 시켜야, 또 어떤 벌칙을 시켜야 시청률이 높게 나오지? 재밌다는 말을 듣지? 계획은 끝없이 밀려오는 파도처럼 꼬리에 꼬리를 물고 이어진다. 목표를 달성하기 전까지 계획은 스스로 끝없이 발전한다. 계획이 끝나는 날은 곧 목표를 달성하거나, 목표를 포기하는 날 둘 중 하나일 것이다. 물론 이 목표도 끊임없이 진화한다. 나영석 PD의 목표가 어느 날엔 시청률 3% 돌파였다가, 그 목표를 달성한 다음에는 10% 돌파가 되는 것처럼.
이해하기 쉽게 나영석 PD의 예시를 들었지만, 결국 IT 업계에서의 기획도 다르지는 않다. 모든 프로덕트에는 그 프로덕트가 해결하고자 하는 목표가 있다. 카카오톡을 생각해보자. 카카오톡이 생기기 이전 우리는 누군가에게 연락을 하려면 전화 또는 문자를 이용해야 했다. 생각해보면 사실 지금도 우리는 문자를 보내 누군가와 손쉽게 연락을 할 수 있다. 그럼 카카오톡은 대체 무슨 문제를 해결하기 위해 생겨났을까? 답은 간단하다. 문자로 연락하는 데에 돈이 들기 때문이다. 휴대폰 요금제를 사용하다보면 문자가 마치 공짜인 것마냥 느껴질 때가 있는데 사실 그렇지 않다. 우리가 매달 지불하는 휴대폰 요금제에는 문자 발송료가 포함되어 있다. 결국 문자를 보내는 것은 결국 돈을 쓰는 것이다. 문자가 건당 10원이라고 쳐보자, 그럼 우리가 ㅇㅇ, ㅋㅋ, ㅎㅎ 같은 대답을 쉽게 문자로 보낼 수 있었을까? 문자가 단돈 10원만 됐어도 그렇진 않았을 거다. 해외 여행을 가서 한국에 있는 가족에게 문자를 보낸다고 생각해보자. 그 상황에서 카카오톡 쓰듯 문자를 썼다면? 상상만 해도 휴대폰 요금 고지서에 찍혀있을 수많은 0자가 생각나며 등줄기가 서늘해진다. 카카오톡은 이런 문제를 해결하기 위해 등장했다. 카카오톡의 홈페이지에 쓰여진 카피라이트만 봐도 카카오톡이 고객에게 전달하고자 하는 가치는 명확하다.
온라인으로 연결된 곳이라면 지구 안 어디서든 무료입니다.
물론 지금의 카카오톡은 텍스트 뿐만 아니라, 사진, 영상도 보낼 수 있을 뿐더러 보이스톡(음성통화)와 페이스톡(영상통화)도 지원하고, 이모티콘도 쓸 수 있고 선물도 할 수 있고, 등등등... 안 되는 거 빼고는 다 되는 서비스가 되었지만 결국 카카오톡의 첫 시작은 인터넷만 연결되어 있다면 돈 낼 필요 없이 연락을 할 수 있게 하자, 가 전부였을 것이다. 그 이후 나영석 PD가 다음 여행지를 짜고 게임을 짜듯 하나 하나 덧붙여 나갔을 거다. 이왕 연락을 할 수 있는 거 여러 명이 한 채팅방에서 다 같이 이야기를 나눌 수 있게 하면 어떨까? 문자 말고 이번엔 전화통화도 돈 안 내고 쓸 수 있게 해보면 어떨까? 그렇다면 영상통화는? 그렇게 이어진 것들이 결국 지금의 카카오 네트워크를 만든 것이다. 그렇기 때문에 결국 기획의 본질은 '목표를 정하는 데' 있다고 볼 수 있다. 무엇을 목표하느냐에 따라 기획의 내용이 달라지기 때문이다. 만약 나영석 PD가 온가족이 둘러앉아 볼 주말 피크 시간대 프로그램이 아닌 밤 11시에나 방송되는 20~30대를 대상으로 프로그램을 짰다면 아마 또 다른 내용의 프로그램이 나왔을 거다. 카카오톡이 온라인으로 연결된 곳이라면 지구 어디든 무료로 서비스를 제공하겠다가 목표가 아니라, 아주 극소수의 사람들이 은밀하게 비싼 값을 치루고 네트워킹을 할 수 있는 서비스를 만들겠다였다면 당연히 아주 다른 프로그램이 나왔을 것이다. 그렇다면 이제 기획자가 갖추어야 할 능력 중 한 가지는 분명해진다.
기획자는 정확한 목표를 세울 줄 알아야 한다.
정확한 목표를 세우는 일이란 '어떤 문제'를 해결할지 잘 정의하고, '어떻게 문제'를 해결할지를 잘 결정하는 일이다.
위의 문장은 너무도 명확하고 당연한 이야기 같아 보인다. 하지만 종종 어떤 사람들은 이 문장의 함정에 속아 넘어가곤 한다. '어떤 문제를 해결할지 잘 정의하는 것'이 선행되어야 하는데 '어떻게 문제를 해결할지'를 더 중요하게 생각해버리는 것이다. 어떻게 문제를 해결할지, 그 방법이 충분히 논리적이려면 어떤 문제를 해결해야 할지에 대한 정확한 정의가 선행되어야 한다. 결국 프로덕트 매니징의 시작은 '문제를 잘 정의'하는 것에서부터 시작된다.
나는 어렸을 때부터 프로불편러의 기질이 좀 있었다. 뭔가 불편하다 싶은 게 있으면 잘 캐치하기도 했고, 태생적으로 성격이 좀 예민한 탓인지 조금이라도 마음에 거슬리는 게 있으면 그걸 최대한 빨리 고쳐놔야 마음이 편했다. 책꽂이에 꽂혀있는 책의 높이가 일정하지 않고 갑자기 툭 튀어나온 게 있다거나 하는 사소한 것부터, 우리 엄마의 교육 방침까지... 불편한 걸 또 꾹 참는 성격도 아니라 바로 바로 얘기를 하거나 의견이 받아들여지지 않으면 받아들여질 때까지 뻗대기도 했다. 그런 성격은 오랫동안 나를 엄청 힘들게 했다. 좀 참고 넘어가면 되는 거 아냐? 꼭 바꿔야 돼? 대부분은 오랫동안 유지하던 무언가를 쉽게 바꾸고 싶어하지 않기 때문에 그런 걸 자꾸 얘기하다보면 사람들의 미움을 사기 쉽상이었다. 야, 넌 왜 맨날 힘들다 힘들다 말로만 해? 진짜 힘들면 그걸 고치려고 노력이라도 해봐야 하는 거 아니야? 같은 말을 친구한테 참지 않고 한다고 생각해봐라. 우정에 금가는 건 진짜 한순간이다.
하지만 프로덕트 매니저로 일을 하면서부터 나는 이런 나의 프로불편러의 면모가 직업적으로는 꽤나 도움이 된다는 것을 깨달았다. 문제를 해결하려면 문제가 있어야 한다. 그런데 생각보다 '문제가 있다'라는 것을 알아차리는 데 어려움을 느끼는 사람들이 많았다. 내가 들어오기 전부터 이미 오랫동안 그랬던 건데 상관 없지 않을까? 그냥 시간이 좀 걸리는 거지, 해결할만큼 불편한가? 내가 불편한 사항에 대해 이야기를 하면 대부분 그런 식으로 반응했다. 나는 그럴 때마다 깨달았다, 아! 문제를 문제라고 부르지 않으면 문제가 되지 않는 거구나!
첫 회사에서 일을 할 때였다. 당시에 나를 비롯한 PM팀의 모든 기획자들은 기획 문서를 구글 워크스페이스에서 작성했다. 정책 문서는 스프레드시트로 관리하고, 발표를 하거나 타팀에 공유를 할만한 내용이 있을 때에는 구글 슬라이드를 사용했다. 그 외에 리서치 자료 같은 것들을 내부에 공유할 때도 대부분 구글 워드나 슬라이드를 이용했다. 정확한 이유는 모르겠지만 내가 입사했을 때에는 이미 다들 그런 식으로 일을 하고 있었다. 다들 크게 불편함을 느끼지 않는 것 같았다. 아무도, 그 방식의 문제에 대해 이야기하지 않았다. 나도 초반에는 이상함을 느끼지 못했다. 나에게는 그 회사가 첫 회사, 첫 직장이었고 처음으로 PM으로 일을 하는 곳이었기에 한참동안 나는 그냥 다들 으레 그렇게 하려니, 더 좋은 방법은 없으려니 하고 생각했었다.
하지만 문제는 내 사수가 퇴사를 하면서 생겼다. 사수가 하던 일을 인수인계 받게 된 건 당시 크게 이렇다할 프로젝트를 맡고 있지 않던 이제 갓 수습이 끝난 나였다. 사수는 문서 링크가 다닥다닥 붙은 스프레드 시트를 나에게 건네주고 훌쩍 캐나다로 떠났다. 하루 정도 시간을 들여 업무를 인수인계 받는 미팅을 진행하긴 했지만 일을 할 때마다 헷갈리거나 모르는 일이 생겨 사수가 남겨놓고 간 문서를 들여다봐야 할 일이 생겼다. 바쁘다 보니 중요하지 않은 것은 들여다보지 않게 됐다. 그러던 어느 날, 프로젝트를 진행하면서 거의 이야기가 나오지 않던 정책 사항에 대한 히스토리를 확인해봐야 하던 그 때에 클릭한 링크 하나가 나를 절망하게 했다.
'해당 문서에 대한 엑세스 권한이 없습니다. 작성자에게 권한을 요청하세요.'
엑세스 권한을 요청하기를 누르긴 했지만 나에게 시간은 없고 그녀는 캐나다에 있고, 그녀의 업무용 메일 주소는 이미 사라졌고... 결국 그 일을 어떻게 해결했었는지 잘 기억은 안 나지만 그 때 나는 처음으로 그렇게 일을 하는 방식이 문제가 없기 때문에 지금껏 다들 사용하고 있었던 게 아니라는 것을 깨달았다. 그럴 때마다 문제가 있다고 생각은 했겠지만 아무도 그걸 고치자고 얘기하지 않았기 때문에 그게 그냥 그렇게 이어져 온 것이다. 비효율을 못 참는 내 안의 프로불편러는 그 때부터 꿈틀거리기 시작했다. 나는 바로 문서 정리와 관련된 효율적인 업무 툴을 찾아 여행을 떠났다. 어떤 한 부분이 불편하다고 느끼니 다른 불편한 부분들도 속속들이 눈에 보였다. 처음 입사 당시에 문서 하나를 찾으려고 회사의 구글 드라이브를 매일 한참 돌아다녔던 것과, 내가 쓰지 않은 문서들은 도통 뭐라고 검색해야 나오는지를 몰라 결국 작성한 담당자에게 물어봐야 하는 것, 그리고 그 담당자가 퇴사해버리면 쥐도새도 모르게 그 문서가 날아갈 수 있다는 것까지. 그리고 일주일 후 나는 팀 회의에서 정책 및 스펙, 리서치 자료 정리용으로 Confluence를 도입할 것을 제안했다. 아쉽게도 도입 비용이 너무 비싼 탓에 결국은 반려되긴 했지만 나에게 그 기억은 내게 문제를 알아차리는 것이 얼마나 중요한지를 깨닫게 했던 경험으로 남았다. 원래 그랬으니까 그냥 그런 거지 뭐, 잠깐 불편한 건데 이번엔 그냥 넘어가지 뭐, 하는 안일한 생각은 결국 문제가 정말 있어도 그걸 문제라고 인식할 수 없게 만들어버리는구나. 문제는 꼭 꽃과 같아서, 이름을 불러주지 않으면 내 곁으로 와 꽃이 되지 않는구나...
물론 남들보다 조금 더 예민하고 불편한 게 많은 덕분에 나는 내 눈앞에 닥친 문제를 알아차리는 데에는 누구보다 발 빨랐다. 하지만 그렇다고 해서 그게 프로덕트에 무조건적으로 적용된다고 할 수 있냐 하면은 그것은 아니다. 내가 직접 겪는 내 문제는 지금 당장 내가 힘들고 괴로우니까 금방 알아차릴 수 있겠지만 남이 겪는 문제는 좀 다르다. 밖에서 보기에는 너무 불편해보이고, 문제가 많아 보이는데 실제로 내부에 있는 사람은 그렇다고 생각하지 않을 수도 있고 밖에서 보기에는 별 문제 없어보이는데 실상 들여다보면 크고 작은 문제들이 산더미처럼 쌓여있을 수도 있다. 프로덕트 매니저는 결국 그런 부분들을 찾아내고 해결하는 데에 익숙해야 한다. 그럼 그런 문제들은 과연 도대체 어떻게 찾아낼 수 있을까? 3년 간의 지독한 문제 정의와 해결의 루프 속에 내가 발견한 건 결국 지름길은 없다는 것이었다.
대학교 4학년 때 한 전공 수업에서 키오스크의 UI/UX에 대한 발표를 준비했던 적이 있다. 지금은 김밥집에도 키오스크가 있고, 카페에도 키오스크가 있고 온갖 곳에 널려 있는 게 전부 키오스크지만 그 당시만 해도 키오스크는 이제 막 햄버거집을 위주로 퍼져나가고 있던 때였다. 나한테 키오스크란 그저 신기한 신문물이었다. 사장 입장에서는 인건비도 줄일 수 있고, 고객 입장에서는 주문도 빨리 할 수 있고, 사람과 굳이 대화하지 않아도 주문을 할 수 있다는 게 나한테는 오히려 엄청 큰 장점처럼 느껴졌다. 혼밥 하는 걸 별로 좋아하지 않고, 손 들고 주문하는 걸 그닥 좋아하지 않았던 나로써는 하루라도 빨리 모든 곳에 키오스크가 도입되면 좋겠다는 생각을 했었다. 하지만 얼마 지나지 않아 아버지가 요새는 햄버거도 하나 혼자 가서 못 사먹겠다는 말씀을 하셨을 때 나는 내 생각이 얼마나 짧았는지를 깨달았다. 스마트폰 사용에 능숙하다고 생각했던 우리 아빠조차 키오스크를 사용하기 힘들어하시는데 그럼 우리 할아버지는? 이러다 앞으로 키오스크가 오만군데 다 생겨버리면 우리 할아버지는 아무 데서도 밥을 사먹을 수 없게 되는 게 아닐까? 그 생각이 나를 전공 수업 발표 주제로 키오스크의 UI/UX 개선을 선택하게 했다.
그 때부터 본격적으로 내가 아닌 우리 할아버지, 우리 엄마 아빠의 마음으로 키오스크를 분석하기 시작했다. 처음 보는 화면 앞에 섰을 때 낯설고 두려운 감정, 그런데 뒤에 선 젊은 사람들이 왜 이렇게 주문을 늦게 하냐고 궁시렁대기 시작하면 긴장한 탓에 주문하기는 더 어려워지고. 선택을 몇 초 이상 하지 않으면 금세 앞으로 돌아가버리질 않나, 메뉴는 너무 많고 글씨는 너무 작고, 옵션은 너무 많은 데다가 주문은 그래서 뭘 눌러야 할 수 있는 거고, 카드는 어디에다 꽂고. 내가 ATM 앞에서도 버벅대는 90대라고 생각하니 키오스크의 문제점이 그제야 보였다. 또 유튜브를 찾아보니 실제로 어떤 부분에서 키오스크를 어렵다고 느끼시는지가 더 확실하게 와닿았다. 박막례 할머니가 키오스크 앞에서 버벅대는 모습을 보니, 키오스크가 얼마나 디지털이 익숙하지 않은 노년층에게 불친절한지가 보였다. 비단 노년층 뿐일까, 만약 내가 시각 장애인이었다면? 어디를 어떻게 눌러야 무슨 햄버거를 시킬 수 있는지 알 수 있었을까?
그렇게 문제점들을 모두 뽑아내 리스트업 하다 보니 해결해야 할 문제가 한도 끝도 없이 이어졌다. 폰트도 키워야 하고, 키오스크에 있는 시간 제한도 없앴으면 좋겠고, 시각 장애인들을 위해 음성으로 안내해주는 기능도 있어야 할 것 같고, 휠체어를 타고 다니시는 분들에게는 키오스크가 또 너무 높으니 키오스크 화면이 위아래로 움직이는 기능도 있었으면 좋겠고... 결국 해당 발표에서 내가 키오스크의 이상향으로 제안한 키오스크는 이미 키오스크가 아닌 상태가 되어 있었다. 키오스크라고 이름 붙이기엔 너무 트랜스포머 같았다고 해야 할까. 당시에는 내가 엄청난 사실을 발견했다는 사실에 뿌듯했건만 집에 돌아오니 문득 그런 생각이 들었다. 이런 문제를 나만 느낀 건 아닐 텐데, 왜 아직도 반영이 안 되고 있는 걸까? 내가 엄청나게 똑똑해서 아무도 모르는 문제를 혼자 찾아낸 것이 아닐 텐데 왜 키오스크들은 여전히 이들에게 이렇게 불친절한 방식으로 햄버거집에 생기고, 김밥집에 생기고, 카페에 생기고 있는 걸까? 왜 이렇게 불편한 제품이 이렇게나 잘 팔리고 있는 걸까? 왜 키오스크를 생산하는 사람들은 이런 불편을 해결하려고 하지 않고 있는 걸까? 화면을 위 아래로 움직이게 한다는 해결방법이 엄청나게 복잡하고 어려운 방법이 아닌데 말이다. 그리고 그 때, 나는 깨달음을 하나 얻었다. 키오스크를 판매하는 업체의 고객은 키오스크 앞에서 버벅대는 55세 우리 아빠가 아니고, 아르바이트 생을 하나라도 더 줄이고 싶은 버거킹 점장이라는 사실을. 나는 문제를 '관찰'하는 데에만 몰두한 탓에 키오스크가 왜 생겨났는지 그 이유를 간과하고 있었던 것이다.
키오스크는 왜 생겨났을까? 아마도 주문을 받는 아르바이트 생을 한 명 덜 고용하고 싶었던 의도가 반영된 것일 거다. 사람이 주문을 받게 되면 주문을 잘못 받는 경우도 생기고, 그로 인한 로스도 생기기 마련이다. 또 생각보다 주문을 받는 일은 어려운 일이다. 일단, 해당 음식점에 어떤 메뉴가 있는지를 다 알고 있지 않으면 주문을 제대로 받을 수 없기 때문에 아르바이트 생을 고용한다고 하더라도 그 아르바이트 생이 완벽하게 주문을 받는 데에 능숙해지기까지 시간이 걸린다. 그 사이 인건비는 계속 나가고, 잘못 받는 주문은 매일 생기고. 키오스크는 아마 그런 문제점을 해결하기 위한 대책으로 나왔을 것이다. 애초에 타겟이 햄버거를 주문하러 가는 우리가 아니라 햄버거를 빨리 주문 받아 빨리 또 많이 팔면서 인건비를 아끼고 싶은 음식점의 사장님이 타겟인 것이다. 물론 그 사장님에게도 50대 이상의 햄버거 주문, 90대 이상의 햄버거 주문을 아예 받지 못한다는 것은 안타까운 일일 테니 그것 역시 문제이긴 하겠다. 그러니 그 문제 역시 언젠가 키오스크 업체에서 해결해줬으면 싶긴 하겠지만 지금 당장 급한 일은 아닐 거다. 석 달에 한 번, 뭐 반 년에 한 번 정도 햄버거 사 먹는 55세 우리 아빠가 한 명 빠지긴 했지만 일주일에 두 번 햄버거를 사먹던 내가 주문이 편리하다는 이유로 이제는 매일 같이 햄버거를 사 먹으러 오니까. 물론 시각 장애인 분들도 키오스크를 잘 사용할 수 있게 음성 인식 기능이 있으면 좋겠지만 만약 음성 인식 기능이 탑재된 키오스크는 한 대에 1000만원인데 그렇지 않은 키오스크는 500만원이라면? 나 같아도 500만원짜리를 하나 사겠다. 이쯤에서 위에서 언급했던 문장을 다시 한 번 돌아볼 필요가 있다.
기획자는 정확한 목표를 세울 줄 알아야 한다.
정확한 목표를 세우는 일이란 '어떤 문제'를 해결할지 잘 정의하고, '어떻게 문제'를 해결할지를 잘 결정하는 일이다.
정확한 목표를 세우는 건 '모든 문제'를 해결하는 게 아니다. 결국 기획자는 '어떤 문제'를 해결할지를 결정해야 한다. 그럼 그 많은 문제들 중에 어떤 문제를 해결해야 할지 결정을 내릴 때에 과연 기준으로 삼을만한 것은 무엇인가? 공익 사업을 하지 않는 이익 집단에 속한 이상 그 대답은 자명하다. 내가 만든 트랜스포머 키오스크 기획안이 그 어떤 키오스크 업체에도 팔릴 수 없는 이유는 결국 그것에 리소스를 투자한만큼 돈을 벌 수 없기 때문이다. 리소스를 투자해 1000만원짜리 키오스크를 만들어도 결국 여전히 500만원짜리 키오스크가 잘 팔리기 때문이다. 회사는 돈을 벌어서 나에게 월급을 줘야 하는데, 내가 돈이 안 되는 문제들만 해결하겠다고 나선다면 그건 정확한 목표를 세운 것이라고 할 수 있을까? 좋은 문제를 잘 정의한 것이라고 볼 수 있을까? 아마 대답은 1년 안에 돌아올 것이다. 회사가 망하거나 내가 월급을 받지 못하게 되는 방향으로.
이런 경험을 바탕으로 내가 내린 결론은 문제를 잘 정의하는 데 필요한 능력이 딱 두 가지 있다는 것이다. 첫 번째 비즈니스를 '이해'해야 한다. 내가 해결하려고 하는 문제는 회사에 이익을 가져다 주는 문제여야 한다. 회사에 수익을 가져다 주는 타겟이 겪고 있는 문제여야 하고, 그걸 해결했을 때 사용된 리소스 이상으로 수익이 돌아오는 문제여야만 회사도 나도 오래 갈 수 있다. 그렇기 위해서는 회사가 누구한테 뭘 팔아서 이익을 내고 있는지, 그게 왜 잘 팔리고 또 왜 안 팔리는지를 필연적으로 이해하고 있어야 한다. 회사의 비즈니스에 대해 잘 알고 있지 못하면 내가 만든 트랜스포머 키오스크처럼 회사 돈만 줄줄 새는 빛 좋은 개살구 같은 아이디어만 제안하게 된다. 두 번째, 이해를 바탕으로 우리는 실제로 해당 고객들이 어떤 문제를 겪고 있는지를 알아내야 한다. 이 때 필연적으로 필요한 게 '관찰'이다. 내가 만약 햄버거도 못 사먹겠다는 우리 아빠의 말을 듣지 않았더라면, 그 말을 듣고 유튜브에서 박막례 할머니가 키오스크를 통해 햄버거를 주문하는 데 쩔쩔매고 계신 것을 보지 못했더라면 키오스크에 문제가 있다는 것을 인식할 수 있었을까? 아마 아니었을 것이다. 문제를 문제라고 부르기 위해서는 PM은 그것을 사용하는 사람들, 또 문제를 겪고 있을 법한 사람들의 편에서 문제를 바라봐야 하고, 그들이 어떤 문제를 겪고 있는지를 찾아내야 한다.
처음 PM을 시작했던 나에게 '기획'이라는 단어는 너무 추상적이었다. 그래서 일을 잘하려면 뭘 어떻게 해야 하는데? 라는 질문이 끝없이 나를 따라다녔다. 그래서 나는 그 단어를 쪼개어 일상적인 단어로, 혹은 내가 실제로 실천할 수 있는 구체적인 방안으로 치환해보기로 했다. 좋은 PM이 되려면 기획을 잘 해야 한다. 기획을 잘 하려면 정확한 목표를 세울 수 있어야 한다. 정확한 목표를 세우려면 어떤 문제를 해결할 것인지를 잘 정의할 수 있어야 한다. 어떤 문제를 해결할 것인지를 잘 정의하려면 비즈니스를 이해하고, 그걸 바탕으로 고객을 관찰해야 한다. 모호했던 단어들이 구체화되면 될 수록 좋은 PM이 되기 위해 어떤 능력을 향상시켜야 하는지, 또 어떤 노력을 해야 하는지가 분명해지고 있다. 나는 세상의 이치를 이해하기 위해 존재를 쪼개고 쪼개고 쪼개는 물리학자와 비슷한 마음으로 업무를 쪼개고 있다. 다음 편에서는 그래서 '비즈니스를 이해'하는 것이 어떤 것인지를 쪼개 가장 최소의 단위로 만들어 보려고 한다. 그렇게 쪼갠 최소의 단위들을 모두 학습하면 나는 아마 좋은 PM이 될 수 있겠지? 같은 낙관적인 기대와 함께.
오늘의 요약
1. 기획자는 정확한 목표를 세울 줄 알아야 한다. 정확한 목표를 세우는 일이란 '어떤 문제'를 해결할지 잘 정의하고, '어떻게 문제'를 해결할지를 잘 결정하는 일이다.
2. '문제'는 문제라고 누군가가 부르지 않으면 평생 문제가 되지 않는다.
3. 좋은 문제를 정의하기 위해 우리는 '비즈니스를 이해'하고 '고객을 관찰'해야 한다.
