새로운 서비스를 만드는 흔한(?) 프로세스는 대강 다음과 같은 순서로 진행된다…;;;

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에 대한?사용자?반응/행동으로 나타나는 가설 검증 과정을 통해서 얻을 수 있다는 점을 꼭 기억해야 한다.


Leave Comment

이메일은 공개되지 않습니다. 필수 입력창은 * 로 표시되어 있습니다