뭐가 문제인지를 모르는 게 문제
서비스는 '기능'이 아닌, '가설'의 조합이다.
새로운 서비스를 만드는 흔한(?) 프로세스는 대강 다음과 같은 순서로 진행된다...;;;
1. (엄청난) 아이디어가 있다.
2. 어렵사리 멤버들을 모은다. (아니, 이렇게 엄청난 아이디어를 왜 다들 이해하지 못하는거지? ;;;) 이리 뛰고 저리 뛰며 함께 할 사람들을 찾는다. 어쨌든 간신히(!) 팀을 꾸려서 Product를 만들기 시작한다.
3. 6개월 후에, 드디어 Product가 보이기 시작한다. 곧 릴리즈 할 수 있을 것 같다는 생각이 든다.
4. 아 그런데 막바지에 소소한(?) 문제가 생긴다. 런칭은 항상 예정된 날짜보다 늦춰진다. 왜인지 잘 모르겠지만, 암튼 다들 그렇다고 하니깐 뭐 그런가보다 한다.
5. 3개월이 더 흘렀다. 예정보다 늦어졌지만, 어쨌든 완성. 드디어 감격의 런칭!
(... 그리고 아무일도 일어나지 않았다.)
6. 음... 사람들이 우리 서비스를 잘 모르나? 일단 홍보를 해보자. 주변에 보니깐 서비스 오픈하면 보도자료도 막 뿌리고, 아는 인맥 동원해서 인터뷰도 하고 그러던데...
7. 오, 홍보 때문인지 유저가 좀 생겼다!
(...근데, 들어온 사람 대부분이 며칠 쓰다가 나가버리네.)
8. 음. 아무래도 마케팅을 좀 해야겠네. 예산이 넉넉하지 않으니, 효과 측정이 확실한 모바일마케팅을 해야지. 인스톨 당 단가를 얼마쯤 잡아야 하나... 암튼 페이스북 광고도 한번 돌려보고, 락스크린 광고도 해보자. 그래, 이참에 바이럴 마케팅도 쎄게 한번 해보자!
9. 오, 마케팅 때문인지 유저가 좀 생겼다!
(...어, 근데 들어온 사람 대부분이 며칠 쓰다가 다 나가버리네.)
음. 이제 뭘 해야하지...ㅠㅜ
"그래, 출시버전에서는 MVP(minimum viable product) 만드는 데 집중하느라, 원래 하려고 했던 기능의 30% 정도만 만들어서 급하게 출시했는데... 이렇게 된 김에, 미뤄뒀던 다른 기능을 추가해서 제품 완성도를 더 높여야겠다!"
개인적인 경험도 일부 녹아있는데-_-;;; 새로운 서비스를 만드는 과정에서 많은 사람들이 위와 같은 함정에 빠지는 것 같다. 오랜 시간 고생해서 야심차게 서비스를 만들었는데 생각보다 반응은 없고, Retention은 나오지 않고, '매출'이라고 말하기에도 민망한 숫자들만 리포팅되고... 결과적으로 뭘 어떻게 해야할지 돌파구가 잘 보이지 않는 상황.
많은 사람들이 이 시점에 '일정에 쫓기느라 생각했던 모든 기능들을 다 구현하지 못했으니 일단 완성도를 높이기 위해, 아직 구현되지 않은 기능들을 (우선순위에 따라) 추가해야겠다' 라고 생각한다. 단언컨데 '기능을 추가해서 완성도를 높이자'는 이 시점에 할 수 있는 가장 나쁜 선택이다.
생각해보면 이 시점에서의 문제는 이거다.
뭐가 문제인지를 모르겠다는 것
이 함정에서 빠져나오는 방법은 의외로 간단(?)하다. "내가 MVP를 만들면서 검증하려고 했던 가설이 뭐였지?" 라는 질문으로 돌아가는 것. (만약 검증하려고 했던 가설 자체가 없거나, 모호했거나, 불명확했다면... 음 그렇다면 지난 9개월간 만든 산출물에 MVP라는 이름을 붙이면 안된다 -_-;;;) 이 시점에는 우리 눈을 현혹시키는(?) 매출, 회원수, DAU... 이런 지표들에서 잠시 벗어나서, 다음과 같은 것들을 고민해 볼 필요가 있다.
우리가 정의한 '문제'가 뭐였지? (진짜 문제가 있긴 한가?)
그 문제의 '어떤 부분'을 이 Product로 해결할 수 있다고 가설을 세웠지? (이걸 만들어야만 했나?)
우리의 가설대로 진짜 그 '어떤 부분'이 해결되었나? (잘 만든 게 맞나?)
많은 사람들이 Product는 '기능의 조합'이라고 생각하는데, 사실 Product는 '(검증해야 할) 가설의 조합'으로 바라봐야 한다. 사소해 보이지만 매우 큰 관점의 차이인데, 프로젝트 멤버 사이에서도 이 '가설'이 명확하게 커뮤니케이션 되지 않아서 어떤 기능에 대해서 서로 다른 기대수준과 방향을 가지는 일이 드물지 않게 발생한다.
신규 서비스 기획 뿐 아니라, 기존 서비스에 대한 개선/업데이트 과정에서도 마찬가지로 '가설 수립과 이를 검증하기 위한 프로세스/지표 셋업' 과정이 늘 고려되어야 한다. 흔히 새로운 디자인이나 기능이 이전에 비해 당연히(!) 좋다고 가정을 하는데, 이 역시 매우 위험한 생각이다. 멀쩡하던 서비스가 리뉴얼 후 폭망의 길로 들어선 사례를 우리는 너무 많이 알고 있지 않는가...
서비스 기획을 하는 입장에서, '이런저런 자료를 다각도로 검토한 결과, 내 논리에는 빈틈이 없어. 이렇게 하는 게 맞아' 라고 확신하는 것 만큼 위험한 게 없다. 마찬가지로, 기획 과정에서 내부 설득(혹은 보고)을 위한 논리를 계속 덧칠하는 것 만큼 부질없는 짓이 없다. 논리적인 기획자가 나쁜 건 절대 아니지만, 논리에 함몰되는 기획자는 분명 서비스에 나쁜 영향을 미친다. 서비스 방향에 대한 확신은 논리와 자료를 통해 얻을 수 있는 게 아니라, MVP에 대한 사용자 반응/행동으로 나타나는 가설 검증 과정을 통해서 얻을 수 있다는 점을 꼭 기억해야 한다.
더 공부하고 싶다면?
