기획서에 대한 생각


나는 어떻게 ‘기획서’라는 문서를 작성하게 되었을까?

내가 꼬꼬마 신입 기획자로 입사하게 된 N사는 기획 ? 디자인 ? 개발 ? QA 로 이어지는 일반적인(?) Waterfall 프로세스를 채택하고 있는 곳이었다.

내 명함엔 ‘기획’이라는 글자가 어디에도 없었지만, 사내에서 우리는 ‘기획서’를 쓰는 팀이었다. 아, 정확하게 말하면 ‘상세기획서’를 썼다. 어디에선가(?) ‘상위기획’ 이라는 게 내려오면 팀장님이 그 업무를 나에게 할당하셨고, 나는 열심히 PPT에다가 Flow 그리고 화면 와이어프레임 잡고 어쩌고저쩌고 하면서 수십 페이지(혹은 수백 페이지)짜리 상세기획 문서를 만든다. (팀 내에서 ‘표준기획서’ 양식을 만드는데 엄청난 노력을 쏟아붓지만, 실제 그 ‘표준’을 지키면서 작성된 문서는?단?하나도 없었다.)

?그리고는 담당 디자인부서와 개발부서, QA 부서에 연락해서 미팅을 잡고는 ‘기획 리뷰’라는 걸 한다. ?기획서의 디테일에 대해서 까는 건 우리 팀과 한판 붙자!는 의미로 받아들여졌기 때문에 (심지어 이름에 UX도 들어갔던 부서인데…ㅎㅎ) 회의 참석자들로부터의 불편한 질문들은 ‘기획 의도’ 라는 애매모호한 용어로 피해갔고, 때로는 우리도 본 적 없는 ‘사용자’를 데려와서는 문서의 정당성을 주장하기도 했다. (‘사용자 관점’에서는 이게 맞다니깐!) ?아, 간혹 구현에 이슈가 될 만한 스펙이 있으면 그런 부분은 관대하게(?) 조정하기도 한다. 거기서 고집부리다가는 개발팀과 한판 붙자!고 선전포고를 하게 될 수도 있고…

음 아무튼. 눈에 보이는 수십 장의 문서가 있으니, 뭔가 일을 열심히 하긴 하는 것 같은 느낌을 받을 수 있었다.

‘완벽한(?) 기획서’를 만들어 보겠다고 의욕에 불타던 시절이 있었다. ?

나름대로는 엄청나게 꼼꼼하게(?) 문서를 작성한다고 했지만, 디자인-개발의 실제 구현과정을 거치다 보면 디자이너와 개발자들의 질문이나 피드백을 받으며 (혹은 내가 애초에 잘못 생각했던 부분이 하나둘씩 튀어나오면서) 문서를 엄청나게 고쳐야 했다. 내가 처음에 쓴 문서는 “기획서.ppt” 였지만, QA를 할 때쯤, 아니면 실제 그 기능을 출시할 때쯤 되면 “기획서_검토완료_최종본_수정_v31.ppt” 같은 말도안되는 이름의 파일이 생기곤 했다 -_-;;;

문서를 지속적으로 수정/공유하는 것 자체도 스트레스였지만 (수정해서 보낼때마다, 매번 이게 ‘진짜’ 최종이라고 하면서 동료들에게 미안해하는 게 너무 싫었다 -_-; ?물론 그게 진짜 ‘최종’이라고 믿은 사람은 없었겠지만…) 개인적으로 느낀 더 큰 문제(?)는 어느 시점에선가 기획서와 Product의 속도가 거의 비슷하거나, 때로는 역전된다는 점이었다.

?Waterfall 방식으로 프로젝트를 진행하려면 일단 가이드가 되는 문서가 나오고 그걸 바탕으로 구현이 이루어져야 하는데, 실제로 일을 하다 보면 스펙 변경사항을 메일이나 메신저로 협의하고, 기획서가 나오기 전에 먼저 개발이 진행되는 경우가 비일비재하게 발생했다. 즉, 변경사항들이 쌓여서 기획서를 꾸역꾸역 고쳐서 쓰고 있으면, 디자인이나 개발이 먼저 휘리릭 진행되는 경우였다. 이쯤 되면 도대체 내가 쓰는 기획서라는 문서가 디자인-개발을 가이드하기 위한 문서인지, 그냥 프로젝트 로그를 남기기 위한 문서인지 애매모호해지면서 나는 이토록 ‘실력없는 기획자’인가 -_- 하는 고민에 빠지게 된다.

매번 프로젝트를 새로 진행할 때마다 ‘이번에는 진짜 완벽한 기획서를 써서, 프로젝트 중간에 막 바쁘게 업데이트하고 끊임없이 수정했다고 메일 보내고 이런거 안해야지!’ 라고 굳은 결심을 하지만… N사에서 일하던 4년 내내 단 한번도 그런 ‘완벽한’ 기획서를 쓴 적은 없다.

도구가 ‘완벽한’ 기획서를 쓰는 데 도움을 줄 수 있을까?

나만 그런 고민을 했던 건 아닌 것 같다. 사내에서는 ‘기획 스펙들이 너무 자주 바뀐다’ ?‘기획서가 표준화되어 있지 않다’ ?‘기획서 업데이트를 메일로 커뮤니케이션 하는 게 좋지 않다’ 등등의 이야기가 끊임없이 나왔고, 결국 회사에서는 PPT를 대체할 수 있는 기획서 작성 Tool을 만들기도 했다. 기획서에 들어가는 버튼, 입력폼, 서식들을 표준화했고, 링크 이동이나 탭 변경 같은 간단한 interaction은 해당 Tool 안에서 그대로 구현이 가능했다.

그중에서도 개발자와 PM(기획자 말고, 프로젝트 일정관리를 하던 매니저)들이 특별히 좋아하는 기능이 있었는데, 그건 프로젝트를 ‘기획 완료’ 상태로 만들면 더이상 스펙을 추가하거나 변경할 수 없게 하는 기능이었다 ㅋㅋ (PM이 별도 승인해야지 변경이 가능했었나… 그랬던 걸로) ?어쨌든 기능상으로는 기존의 PPT 기획서가 가진 여러 단점들을 보완할 것처럼 생긴(?) 툴이었다. ?근데 막상 써보니깐, 내 주위의 모든 기획자, 디자이너, 개발자, PM들이 다 그 툴을 싫어했다 -_-;;; ?힘겹게 새로운 툴의 기능을 익히긴 했지만, 결과적으로는 여전히 기획 스펙 변경은 끊임없이 발생했고(이젠 스펙 변경시마다 PM의 컨펌 단계가 있으니 더 귀찮…), 기획-디자인-개발 간 커뮤니케이션 코스트도 변함이 없었고, 기획서 작성과 유지보수에 드는 공수도 줄어들지 않았다. ?뭐가 문제인거지?

‘기획서’의 문제는 단지 그 문서 하나가 아니라, ‘업무 프로세스’의 문제로 수렴한다.

생각해보면, ‘기획서 내 스펙이 자주 바뀌는 게 문제이므로 스펙 변경을 못하게 한다’는 식으로 문제 해결을 하는 게 얼마나 어처구니없는 일인가 싶지만 ㅋㅋㅋ 저 때는 진짜 저런 기능이 있었다 -_-;;; ?결국 해결해야 하는 문제는 이런 거다. ?왜 스펙 변경이 끊임없이 일어나지? ?왜 기획자-개발자-디자이너의 커뮤니케이션 코스트는 안 줄어들지?

‘기획서’를 어떻게 하면 잘 쓸 수 있는가… 하는 문제는 ‘어떻게 일을 해야 하는가’ 라는 문제로 수렴하게 된다. (이젠 지겹고 식상하지만) 과연 Waterfall 형태로 일하는 게 최선인가? 라는, ‘업무 프로세스’에 대한 근본적 질문으로 또 다시 돌아오게 된다는 의미다. 사실 애초에 기획자 한 사람의 머릿속에서 나온 문서가 다른 개발자, 디자이너, 운영자들의 생각과 온전히 일치해서 더이상 수정이 필요없을 정도의 ‘완벽한’ 문서일 가능성은 제로에 가깝기 때문이다.

사실 Waterfall에서의 기획문서는 프로젝트 멤버 간의 커뮤니케이션 material이라기보다는, 기획자가 한 homework에 가깝다고 생각한다. 애초에 커뮤니케이션을 위해 만들어진 문서가 아니다보니 그 문서를 바탕으로 구현을 위한 커뮤니케이션을 하는 게 엄청나게 비효율적일 수밖에 없다.

개인적으로 생각하는 ‘기획자 원맨쇼로 만들어진 기획서의 태생적 문제’를 몇 가지 짚어보면,

“기획자인 내가 생각한다. 너희들은 생각하지 말고 이대로 구현만 해” 에서 오는 시야의 협소함. 나는 이게 기획자가 가질 수 있는 가장 위험하고 멍청한 스탠스라고 생각하는데, 생각보다 이렇게 생각하는 기획자들이 많다 -_-; ?애초에 ‘기획자’라는 이름이 잘못된 선입견을 가져다주는 것 같기도 하고…

위에서 언급한 ‘기획 리뷰’를 한다고 해서 다른 멤버들의 참여가 이루어진다고 볼 수는 없다. 기획자가 어쨌든 PPT 100장 만들어 왔는데-_- 거기다가 대놓고 ‘이건 잘못됐어’ 라고 말하긴 여러모로 쉽지 않다. 기획 리뷰라는 것 자체가 co-work 보다는 criticize에 적합한 프로세스이다. ?“일단 내가 다 했어. ?뭐 의견 있으면 이야기 해봐, 한번 생각은 해 볼께…” 라는 상황에서 건설적인 의견 개진을 통한 논의가 이루어질 확률이 얼마나 되겠는가.

문서에 기반해서 구현과정이 좌지우지되는 환경에서는 ‘기획서 현상유지의 유혹’이 늘 따라다닌다. “이 스펙이 조금 불편하긴 하지만, 이 조그만거 고치자고 문서 수정해서 메일 보내고, 디자인/개발에 스펙 변경되었다고 커뮤니케이션 하면서 욕먹느니… 뭐 큰 것도 아닌데 일단 초기 기획안대로 놔두지 뭐…” 경험담인 것 맞고, 반성한다… -_-;;;

마찬가지로, ‘문서 신봉주의’가 프로젝트 멤버들에게 빠르게 전파될 수 있다. 좀 더 개선할 수 있는 포인트가 눈에 들어오더라도, “나는 하라는 거 다 했는데? ?그건 문서에 없잖아” 라고 한 발 빠져버린다거나.

결과적으로 가장 안좋은 건, ‘분명히 이게 최선이 아닌 걸 알지만, 프로세스에 따라서 그냥 하게 된다’. ?아 이건 말하고나니깐 좀 슬프네. ?진짜 이랬던 적이 있는 것 같아서 -_-;;;

좋은 기획서에 대해 이야기하려면, 결국 ‘기획서라는 문서를 왜 쓰는건가?’ 라는 질문으로 돌아와야 한다.

기획서는 어떤 산출물을 만들어내기 위한 커뮤니케이션 도구로써의 역할을 해야한다고?생각한다.??사실 종이에 연필로 슥슥 그리거나, 혹은 말로 몇마디 이야기하는 것으로 충분히 커뮤니케이션이 된다면, 당연히 수십 장짜리 PPT 문서를 만들 필요가 없는 것 아닐까? ?커뮤니케이션이라는 건 일단 서로의 생각들을 함께 나누고 그것들을 정리하는 과정에서 출발하는건데, ‘생각을?함께 나누는’ 과정이 생략된 상태에서 만들어진 기획서가 좋은 문서가 될 수는 없다고 생각한다.?기획서가 ‘기획자’라는 명함을 가진 사람들의 ‘숙제’처럼 여겨져서는 곤란하다.

간혹, 나중에 참고할만한 ‘로그’를 쌓고 이전 히스토리들을 꾸준히 트래킹하기 위해서 기획서가 필요하다고 보는 입장도 있는데 나는 여기에도 좀 회의적이다. ?훗날 추가 기획이나 아니면 다른 의사결정에 참고할만한 로그로써의 역할을 하려면 기획 의도나 기획 시에 고려했던 원칙에 대한 정리가 훨씬 더 중요하다고 생각하는데… 사실 대부분의 기획서는 화면이나 기능 단위의 description에 초점을 맞추고 있는 경우가 많다. 이건 업데이트때마다 관리하기 힘든 ‘문서’의 형태보다는, 그 결과로 나온 산출물 그 자체가 더 의미있는 로그가 아닐까 싶다. ?로그가 필요하다면, 화면 상세설계서보다는 초기 기획의도나 의사결정의 변곡점들, 그리고 IA와 기능의 우선순위를 정리할 때 고민했던 사항들을 따로 정리한 내용들이 ?‘로그’로서 훨씬 더 가치있는 내용일 것이다.

스타트업에서 기획업무를 진행하면서 스스로 달라졌다고 느꼈던 점은, ‘Product’가 ‘기획서’를 앞질러 갈 때 더이상 초조하거나 그로 인해 스트레스를 받지 않았다는 점이었다. 전에는 어떻게든 ‘기획서를 최신 버전으로 유지하려고’, 이미 멤버들이 다 알고 있고 심지어 Product에 반영되어서 릴리즈 된 내용에 대해서도 어떻게든 상세기획서 혹은 화면설계서 같은 문서에 그 내용을 꾸역꾸역 뒤늦게 업데이트하곤 했었다. 하지만 스타트업에서는 이미 완성된 기능에 대한 기획서 따위는(?) 아무도 보지 않는다는 걸 알았기에 ㅋㅋ 멤버들 간의 커뮤니케이션이 이미 충분히 진행되어서 Product에 반영되었다고 생각되면 화면 단위의 기능기획문서를 남기기보다는, 관련된 의사결정 히스토리나 달라진 로직에 대한 큰 그림만 남겨놓으려고 노력했었다. ?그러다보니 자연스럽게 처음에는 ‘기획서’를 가지고 커뮤니케이션 하다가 어느 순간 기획서보다 Product를 가지고 커뮤니케이션 하는 게 더 효율적이라고 느껴지는 순간이 되면, 기획서는 그냥 골방으로 들어가고…그냥 Product 자체가 커뮤니케이션 material이 되었는데, 그냥 그것으로 충분했다.

그래서 이 긴 이야기의 결론은 ㅎㅎ
호랑이는 죽어서 가죽을 남기고, 사람은 죽어서 이름을 남기는 것처럼,
기획자는 프로젝트가 종료되면 기획서가 아니라 Product를 남겨야 한다고 생각한다.

기왕 집착할거면, 문서 말고 Product에 집착하는 기획자가 될 것.


[TIL] 2017-09-22 (금)


  • 피아노
    • 레슨 + 연습 (2시간)
    • Je te veux 시작
  • 검도
    • 점심시간 백만년만에 검도

데이터를 쪼개서 보기, Simpson’s paradox


코호트 분석, A/B테스트, 퍼널 분석 등 데이터를 통해 유의미한 인사이트를 찾아내는 방법들에는 공통점이 있다. ?바로 데이터를 ‘쪼개서’ 살펴본다는 점이다. ?전체 데이터를 놓고 보면 잘 드러나지 않는 특성들이 ‘쪼개진’ 상태에서는 명확하게 드러나는?경우가 많은데, 이처럼?raw data를 분석 과정에서 어떤 식으로 가공하느냐에 따라 데이터에서 얻는 인사이트는 완전히 달라질 수 있다. ?(‘가공’이라는 용어를 썼는데…?쪼개서?보는 것 이외에, 데이터를?재조합해서?분석하는 방법 – 요인분석이나 주성분분석 등등- 도 데이터에서 유의미한 인사이트를 찾아내는 널리 알려진 방법이다. ?어쨌든 raw data를 그대로 놓고 들여다보는 것 보다는, 쪼개거나 합치거나 재조합하거나… 하는 과정이 필요하다는 게 포인트!)

데이터를 쪼개서 보는 것과 관련해서, 통계학에서 ‘Simpson’s paradox’ 라고 부르는 재미있는 개념이 있다. 심슨 패러독스란 ‘쪼개진’ 데이터에서 성립하는 관계가 ‘합쳐진’ 데이터에서는 다른 형태로 나타나는 현상을 말한다. ?널리 알려진 사례 중 하나는 UC Berkely 의 1973년 대학원 입시와 관련된 해프닝이다.

1973년 가을, UC Berkeley 대학원 입시 결과를 놓고 소송이 제기되었다. ?소송 제기인은?대학?측이?합격자 선발 과정에서 여학생들을 부당하게 차별했다고 주장했는데, 실제 입시 결과를 보면 남학생의 경우 지원자의 44%가 합격 통보를 받았지만 여학생들은 지원자의 35%만이 합격 통보를 받은 것으로 나타났다. ?우연으로 보기에는 큰 차이인데?(실제로 이 데이터를 넣고 카이제곱 검증을 하면 성별에 따른 합격률이 통계적으로 유의미한 차이가 있는 것으로 나온다)?과연 UC Berkeley는 정말로 대학원 입시에서 여학생들을 차별한 것일까?

전체 Admission 데이터

놀랍게도, Admission 데이터를 학과별로 쪼개서 살펴보면 전혀 다른 패턴이 발견된다. ?전체 85개 학과 중 남학생의 합격률이 통계적으로 유의미하게 높은 학과는 4개에 불과했으며, 반대로 여학생의 합격률이 유의미하게 높은 학과가 6개로 더 많았다. (사실 대부분의 학과에서 성별에 따른 합격률은 통계적으로 유의미한 차이를 보이지 않았다.)

모집인원이 많은 주요 학과에 대한 Admission 결과가 아래 표에 나타나 있는데, 여학생들의 합격률이 더 높은 학과가 많음에도 불구하고 (+ 합격률이 낮은 과라고 하더라도 격차가 매우 미미함에도 불구하고) 6개 학과의 결과를 ‘합산해서’ 보게 되면 44% vs. 30% 로 여학생들의 합격률이 현저하게 낮은 것을 확인할 수 있다. 이상하게도…

학과별로 ‘쪼개서’ 본 Admission 데이터

이런 현상이 발생하는 이유는, 경쟁률이 높고 합격률이 낮은 학과에 여학생들이?상대적으로?많이 지원했기 때문이다. (반대로 이야기하면, 합격률이 높은 학과에 지원한 여학생들이 상대적으로 적기 때문이다) ?즉, 합격률이 낮은 과에 지원했다가 불합격한 지원자 수가 전체 여학생 지원자 그룹에서 높은 비율을 차지하면서, 여학생들의 전체적인 합격률을 끌어내리는(!) 효과를 가져온 것으로 볼 수 있다. ?학과별로 합격률이 일정하지 않은 상황에서, 특정 학과로의 지원 쏠림 현상이 발생하는 경우 이와 같이 전체 결과의 경향성이 부분 결과의 경향성과 일치하지 않는 케이스가 발생한다. ?Simpson’s Paradox를 보여주는 대표적인 사례이다.


서비스 데이터를 분석할 때도 이처럼 단순히 ‘전체’ 데이터만 놓고 비교하는 경우 유의미한 결과를 놓치거나, 나아가서는 데이터를 완전히 잘못 해석하는 사례가 얼마든지 발생할 수 있다. ?두 가지 서로 다른 제휴마케팅을 진행하고 해당 마케팅을 통한 가입자와 결제자를 살펴본 결과 아래 표와 같은 데이터를 얻었다고 하자. ?전체 데이터를 놓고 보면,?가입자와?결제자의 절대적인 숫자가 많고 결제비율이 높게 나타나는?제휴마케팅 A가 더 성공적으로 보일 수 있지만, ‘성별’이라는 기준으로 이 데이터를 쪼개서 보면 제휴마케팅 B를 통해서 가입한 여성 사용자가 더 많고, 남여 각각의 결제비율도 더 높은 것을 알 수 있다.

그렇다면 이 경우 어느 쪽이 더 효과적인 마케팅이라고 할 수 있을까? 가입자와 결제자의 절대적인 숫자가 크고 결제비율이 높은 A? 아니면 성별로 쪼개서 봤을 때 결제비율이 높은 B?

지난 포스팅에서 언급한 대로, 이 경우 우리 서비스의 현재 목표(OMTM)가 무엇인가… 에 따라 가치판단이 달라질 수 있다. 가령 아래 예로 든 항목 중 현재 포커싱하고 있는 목표가 무엇인가에 따라서 어떤 경우에는 A가 보다 좋은 마케팅이었다고 판단할 수도 있고, 반대로 B의 마케팅 효과가 더 뛰어났다고 판단할 수도 있다.

  • 우리 서비스는 가입자를 최대한 확보하는 게 중요하다
  • 우리 서비스는 ‘여성’ 가입자를 최대한 확보하는 게 중요하다?(데이팅 서비스 만들다보면 이게 진짜 지상최대의 목표;;;; 쿨럭)
  • 우리 서비스는 매출을 maximize하는 게 중요하다
  • 우리 서비스는 결제비율이 높은 사용자들을 최대한 많이 확보하는 게 중요하다
  • 우리 서비스는 결제하는 고객의 성비를 잘 유지하는 게 중요하다


이처럼 데이터를 살펴볼 때 (특히 단순 descriptive?analysis를?할 때)는 가능한 ‘입체적으로’ 데이터의 구조를 살펴보는 습관이 필요하다.?(데이터를 쪼개서 보든, 재조합해서 보든, 다른 데이터와 합쳐서 보든…)

숫자는 거짓말을 하지 않지만, 숫자의 표면과 이면에서 이야기하는 내용들은 얼마든지 다를 수 있기 때문이다. ?:)


가장 중요한 한 가지 지표, OMTM


지표, 그리고 이를 바탕으로 한 분석의 중요성이 강조되면서, 서비스의 ‘주요’ 지표를 관리하고 트래킹하는 일은 서비스 기획/운영에서 필수적으로 해야 하는 일이 되었다.  이제 Google Analytics나 Flurry 등의 데이터 분석 툴을 연동하지 않은 서비스를 찾기가 힘들고 -_-; 이를 바탕으로 한 코호트 분석이나 퍼널 분석은 서비스 기획자라면 누구나 해야 하는 기본 중의 기본이 된 느낌이다.  특히 서비스에서 중요한(!) 지표들 -가령 매출, DAU, ARPU, 가입전환율, 결제비율, 이탈율, CAC, LTV, ROAS 등등… – 은 당연히 매일매일 체크하면서 이상유무를 점검하고 대응해야 한다.  그렇다면, 주요 지표에 대한 모니터링/관리 체계가 잘 구축되어 있다면 우리 서비스는 ‘지표’를 (혹은 ‘데이터’를) 잘 활용하고 있다고 볼 수 있을까?

린 분석

앨리스테어 크롤과 벤저민 요스코비츠는 ‘린 분석‘에서, 단순히 이런 식으로 중요한 데이터를 나열식으로 관리하는 것에 대한 한계를 이야기한다.  지표(Metric)를 측정하는 가장 중요한 이유는 이를 바탕으로 의사결정/실행 을 하기 위해서인데 (actionable 하지 않은 metric은 절대로 좋은 지표라고 할 수 없다!) 단순히 나열식으로 지표를 관리하는 체계에서는 서비스 방향을 Directing 하거나 일관성있는 의사결정을 할 수 없기 때문이다.  가령, CEO가 운영팀에게는 ‘지금은 결제자 비율을 높이는 데 주력합시다’ 라고 지시하고, 기획팀에게는 ‘ARPPU를 높일 수 있게, 아이템 가격 인상을 검토하세요’ 라고 지시한다면… 멤버들은 어떤 action을 할 수 있을까?   이 경우 단순히 두 지표를 모두 높게 유지해야 한다… 라고만 하면 어떤 action도 하기가 애매하다.  애초에 결제자 비율과 ARPPU는 대부분의 경우 서로 다른 방향으로 움직이는 지표이기 때문이다. (일반적으로 아이템 가격을 인상하면 ARPPU가 높아지지만 결제자 비율은 떨어지고, 아이템 가격을 인하하면 ARPPU는 떨어지지만 결제자 비율은 올라간다.)

그렇다면 결제자 비율과 ARPPU 중 무엇이 더 우선시되어야 하는가? 정답은 그때그때 달라요… 다 -_-;; 우리 서비스가 Activation 단계에 초점을 맞추고 있다면 -사용자들이 서비스의 핵심기능을 최대한 많이 이용해보고, 서비스에 대한 충성도를 가지고, 장기적으로 머무르도록 하는 게 중요한 시기라면- 객단가를 일부 희생하더라도 최대한 많은 사람들이 결제를 하도록 하는 게 더 중요하겠지만, 서비스가 어느정도 성숙기에 접어들어서 Revenue를 극대화하는 게 중요한 시점이라면 ARPPU에 초점을 맞추는 게 더 현명한 선택일 수 있다.  즉, ‘지금 중요한 지표’는 서비스의 성숙도나 외부 환경 등 다양한 요인에 따라서 달라질 수 있다는 말이다.

 

OMTM (One Metric That Matters)

‘린 분석’에서는 이를 설명하기 위한 개념으로 OMTM이라는 용어를 소개한다.  우리말로 하면, ‘지금 가장 중요한 한 가지 지표’라고 할 수 있을텐데, OMTM은 “특정 시점에 운영과 데이터분석을 위해 꼭 집중해야 하는 지표”를 의미한다.  린 분석에서는 아래와 같은 4가지 이유를 들어 OMTM의 중요성을 강조하고 있다.

1) 지금 가지고 있는가장 중요한 질문 대한 답을 해준다.
– 위에서 언급한 예시와 같다.  현재 우리 서비스가 가장 집중해야 하는 부분이 어디인가?  에 대한 명확한 답을 준다  (사용자를 늘리는 것인지, 매출을 늘리는 것인지, 사용자가 A라는 action을 하게 하는 것인지…?)

2) 단기/중기/장기 목표와 밀접하게 연관되어 있으며, ‘지금 하고 있는지 대한 상황 판단을 있게 한다.
– OMTM이 명확하지 않은 상태에서는 지금 우리가 잘 하고 있는지를 알 수 없다.  회원수와 매출이 늘어나면 잘 하고 있는 걸까?  혹은 반대로 회원수와 매출이 정체되어 있다면 잘못하고 있는 걸까?  때로는 회원수를 늘리는 것보다, 우리 서비스 내에서의 ‘어떤 가설’을 검증하는 게 훨씬 더 중요한 시기가 있게 마련이다.

3) 넓은 시야에서 서비스를 바라보고, 서비스 자체에 초점을 맞출 있게 준다.
– 눈에 보이는 단기적인 성과(주로 매출;;;  혹은 사용자수;;;)에 집착하지 않도록 도와준다.

4) 모든 구성원들이 동일한 방향을 바라보도록 하며 과정에서 실험, 측정, 판단의 문화를 가질 있게 한다.
– 우리 서비스에서 지금 검증해야 할 가설이 명확해진다.  목표와 기준을 구체적으로 정할 수 있으므로 의사결정에도 도움이 된다.

OMTM 가능한 선행 지표 중에서 선별하는 좋고, 중의적 의미를 가지지 않는 명확한 지표일수록 좋다.  가령, 우리 서비스 사용자들을 분석한 결과, “가입 후 7일 이내에 Level 3까지 도달한 사용자는 그렇지 않은 사용자에 비해 이탈율이 현저히 떨어진다”는 패턴을 알고 있다면, ‘이탈율’이라는 (후행)지표를 OMTM으로 잡는 것 보다는, ‘가입 후 7일 이내에 Level 3까지 도달하는 사용자 비율’ 이라는 (선행)지표를 OMTM으로 정하는 것이 바람직하다는 뜻이다.  이런 측면에서 ‘DAU’, ‘ARPPU’, ‘가입자수’ 와 같이 후행 지표 + 영향을 미치는 요인들이 너무 많은 지표 + 모호한 의미로 해석될 수 있는 지표들은 OMTM으로 사용하기에 일반적으로 적합하지 않다.

 

출처 datapine.com

 

OMTM KPI

‘목표로 하는 지표’ 라는 측면에서, OMTM과 유사하게(?) 사용되는 ‘KPI’라는 용어가 있다.  과연 OMTM과 KPI는 뭐가 다른걸까?  과연 다르긴 한 걸까?…   그렇다.  많이 다르다(;;;)

1. OMTM은 모두가 공유하는 하나의 목표를 의미한다.  동일한 서비스를 만들고 있는 멤버라면, 개발팀과 디자인팀, 기획팀의 OMTM이 모두 달라서는 안된다.  또한 모두가 같은 방향을 바라보고 있기 때문에 OMTM을 목표한 수준까지 올리기 위해서는 당연히 경쟁이 아닌 협력이 필요하다.
반면, KPI는 조직별로 다르게 셋팅되는 게 일반적이며 (개발팀의 KPI와 마케팅팀의 KPI는 다르다;;;)  대부분 서로 독립적으로 규정되어 있어서 KPI 달성을 위한 팀 간 협력이 발생하기 어렵다 (일반적으로 개발팀이 KPI를 달성하는 거랑, 마케팅팀이 KPI를 달성하는 건 서로 상관이 없다…  안 좋은 케이스에는 이 둘이 서로 충돌하기도 한다 -_-;;;  한 쪽이 달성하려고 노력하면 할 수록 다른 쪽에는 본의아니게 피해를 주는 ㄷㄷㄷ)

2. OMTM은 ‘진짜 잘 하고 있는지’를 알려준다.  이 시점에서 우리 회사와 서비스의 목표가 OMTM에 정확히 Align 되어있기 때문이다.
반면, KPI는 ‘진짜 잘 하고 있는지’와 크게 상관이 없다. (주로 ‘놀지 않았는지’ 혹은 ‘어쨌든 노력했는지’와 상관이 있다)  많은 사람들이 KPI를 ‘달성했느냐, 못했느냐’에는 지대한 관심이 있지만, 그 KPI가 우리 서비스의 ‘진짜 목표’ 혹은 ‘진짜 성공’과 어떤 관계가 있는지에 대해서는 잘 답변하지 못한다.  (그래서, 연말에 개발팀과 마케팅팀과 기획팀, 디자인팀이 모두 KPI를 만족시켰지만…  서비스는 잘 안 되고 있는 사례가 발생할 수 있다…  응?)

3. OMTM은 시간이 지나면서 자연스럽게 바뀐다.  1월의  OMTM은 ‘level 3을 만드는 사용자 비율’ 이었지만, 5월의 OMTM은 ‘친구 초대 수’가 될 수 있다.  OMTM은 ‘지금 이 시점’에 가장 중요한 지표를 이야기하는데, 서비스의 성장 속도나 주변 환경에 따라서 중요한 지표는 당연히(!) 달라질 수 있기 때문이다.
반면, KPI는 한번 설정하고 나면 중간에 바꾸기 쉽지 않다.  KPI는 ‘달성’ 자체가 목표이기 때문에, 중간에 기준점을 바꿔버리는 것 자체가 달성을 위한 꼼수로 보일 수 있기 때문이다. -_-;;;  1월에 설정한 KPI를 5월에 바꾸겠다고 하면?  예상되는 반응은 ‘너 달성 못할 것 같으니깐 그러는 거지?’ (쿨럭)…

OMTM의 성격을 부각시키다 보니 KPI를 좀 과하게 깐(;;;) 감은 있지만, 이렇게 나란히 놓고 비교해보면 OMTM의 특성이 좀 더 잘 드러나는 듯.

 

측정하고 관리하는 지표 중 진짜 중요한 게 무엇인지 나는 잘 알고 있는걸까?
Capture everything, but focus what’s important!

 


[TIL] 2017-09-21 (목)


  • 스타트업 멘토링 (판교 경기문화창조허브)
    • 북이오
    • 키튼플래닛
    • 스닙팟

뭐가 문제인지를 모르는 게 문제


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

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