사이드프로젝트로 시작한 디스콰이엇이 4월에 시드투자 텀싯을 받고 지난달 마무리를 하였습니다. 이 글은 그 과정에서 배운 것에 대한 회고입니다.

목차

1편 - 아이디어 검증

1. 사이드프로젝트에서 시작하는 것의 이점: 순수한 호기심에서 시작
2. MVP는 사람들이 사용하지 않는 프로덕트를 개발하는 리스크를 줄이기 위한 것
3. 프로덕트 개발 여정을 기록하고 공유하는 것이 최고의 홍보

2편 - 제품 개발

4. Product-market-fit(PMF)을 찾지 못하는 가장 큰 이유: 선택과 집중의 실패
5. 의사결정이 빠르다는 것은 팀원들간의 R&R이 잘 나눠져있다는 뜻
6. 제품 개발 프로세스는 PMF(Prouct-Market-Fit)를 찾아가기 위한 알고리즘
7. 추상적인 미션을 어떻게 달성할지 최대한 구체적으로 계획

3편 - 투자 & 팀

8. 자금 유치는 우선 프로덕트를 만들고 나서
9. 투자는 필요 없을때 받는 것이 최고
10. 팀원은 반드시 마음이 맞는 사람으로

4) Product-market-fit(PMF)을 찾지 못하는 가장 큰 이유: 선택과 집중의 실패

스타트업, 중견기업, 대기업 상관없이 프로덕트를 만들어본 사람들은 다 공감할 것 같아요. 프로덕트를 만들때 선택과 집중이 중요한 것은 알지만 이를 막상 실행하는 것은 쉽지 않죠. 선택과 집중이 안되면 팀원들간의 의견 차이가 생기고 이게 갈등으로 이어지기도 해요. 혹은 데이터를 쌓아나가면서 PMF을 향해 점진적으로 발전하기 보다는 중구난방으로 이것도 해보고 저것도 해보다 지치는 상황이 나오기도 해요.

저희 또한 처음에 디스콰이엇을 사이드프로젝트로 시작할때부터 선택과 집중에 대해 고민을 많이 했어요. 어떻게 하면 선택과 집중을 잘할 수 있을까라고 생각하기보다는 선택과 집중이 어려운 이유를 생각해봤어요.[1]

프로덕트 개발할때 선택과 집중은 다음과 같은 이유들 때문에 힘들어요:

• 팀원들 간의 R&R(특히 누가 프로덕트 리드이고 최고 결정권을 갖고 있는지)이 명확히 정해져 있지 않아요.
• 프로덕트 개발 프로세스가 정해져 있지 않아요.
• 비전과 미션이 명확하지 않아요. (what, why)
• 비전과 미션을 달성하기 위한 로드맵이 불명확해요. (how)
• KPI가 제대로 세팅되어 있지 않아요. (how 측정이 안되고 있음)
• 문제에 대한 이해도가 불충분한 상태에서 아이디어(솔루션)에 집중해요.

디스콰이엇은 위의 문제들이 없도록 신경을 많이 쓰고 있어요.

Notes

[1] "우리는 무엇이 옳은지 보다 무엇이 그른지를 더 쉽게 판단할 수 있다. 그래서 황금률보다는 은율이 더 명확하고 더 구체적으로 다가온다." - 나심탈레브의 스킨인더게임 -

5) 의사결정이 빠르다는 것은 팀원들간의 R&R이 잘 나눠져있다는 뜻

보통 제품 개발 팀에서 합의가 잘 안이루어지는 경우를 보면 다음과 관련된 것들인 경우가 많아요:

1. 어떤 기능을 개발할지
2. 어떤 우선순위를 갖고 개발할지

합의가 잘 안이루어지는 이유는 서로 살아오면서 경험한 데이터가 다르고 그에 따라 관점차이가 있기 때문이에요.

예를 들면 '콰이엇'이라는 서비스를 만들고 있는 팀이 있어요. 이 팀에는 A, B, C로 이루어져있어요. 팀원A는 대학을 졸업하고 6년 동안 제조쪽 대기업에서 일을 해왔어요. 제조업 특성상 허술한 제품을 빠르게 런칭해서 피드백을 얻기에는 초기 투자 비용이 너무 많기도 하고 대기업일 경우 브랜드 인지도가 깎이면서 잃을 손해가 너무 크기 때문에 제품을 빠르게 런칭해서 피드백을 얻는 방식은 오히려 금기시 되어 있는 방식이고 이렇게 해서 성공적으로 제품을 출시한 경험이 없어요. 반대로 B와 C는 빠르게 성장하는 소프트웨어 스타트업에서 일을 한 경험이 있어요. 린스타트업이라는 책도 읽고 MVP의 중요성도 귀에서 피가날 정도로 많이 들었어요.

팀 구성이 이렇게 셋팅되어 있을 경우에는 A가 아무리 훌륭하고 똑똑한 사람이라 하더라도 A에게는 빠르게 런칭해서 피드백을 얻는 방식이 비직관적일 수 밖에 없어요. 팀원 B, C가 잘 설명해서 머리로 이해를 했다고 하더라도 몸이 안따라주는 경우가 많이 생겨요. 6년 동안 그 반대로 일하고 사고하는 방법을 훈련했기 때문이에요.

이럴 경우를 대비해 반드시 사전에 팀원들끼리 앞으로 이렇게 관점차이로 인해 합의가 안 이루어질때를 대비해서 프로토콜을 만들어 놓는게 중요해요.

팀마다 하는 사업이 다르고 성향과 문화가 다르기 때문에 모든 팀에게 적합한 하나의 절대적인 프로토콜은 없다고 생각해요. 대신 이 프로토콜을 만들때 중요한건 이 프로토콜이 팀의 리소스(시간, 에너지)낭비를 최소화하고 빠른 의사결정을 이루어지게 하는지를 평가해야되요. 위에서도 말한 것처럼 관점차이가 생기는 이유는 명확한 데이터가 불충분하기 때문이에요. 이런건 아무리 회의를 많이 한다고 해도 합의를 이루기가 어려워요. 마치 한평생 육회를 먹어본 적이 없는 외국인에게 말로 익히지 않은 소고기가 맛있다고 설득하는 것과 똑같아요. 이럴때는 그냥 눈을 감기고 먹어보게 하는게 제일 좋아요. 논쟁을 할 시간에 차라리 빠르게 결정을 내려 실행을 하고 데이터를 확보하는게 더 효율적이에요.

“결정을 내릴 때 가장 좋은 선택은 올바른 선택을 하는 것, 그 다음으로 좋은 선택은 잘못된 선택을 하는 것, 가장 안 좋은 선택은 아무것도 하지 않는 것” -시어도어 루즈벨트

빠른 의사결정에 효과적인 방법은 한명에게 프로덕트 리드의 롤을 줘서 합의가 안이루어지는 경우 프로덕트 리드가 빠른 의사결정을 하도록 하는거에요. 여기서 프로덕트 리드가 빠른 의사결정을 하도록 한다는 뜻이 프로덕트 리드가 만들고 싶은대로 만들어라라는 뜻은 아니에요. 그보다는 프로덕트 리드가 팀이 의사 결정을 빨리하게 하는데 책임이 있다는 뜻이에요.

구글이 크롬을 만들때 구글의 공동창업자인 래리 페이지와 세르게이 브린 사이에서 html5를 채용할지에 대한 의견 갈등이 있었고 결정이 자꾸 늦춰졌다고 해요. 당시 구글의 CEO였던 에릭 슈미트는 이렇게 이야기를 해서 이 문제를 해결했습니다. "내일 까지 둘이 합의를 해서 결정을 안 내리면 그냥 내가 결정을 하겠다". [1]

저희는 팀에서 회의를 너무 많이 하고 있는건 아닌지를 수시로 체크하려해요. 회의가 많다는건 의사결정이 빠르게 이루어지지 않고 있다는 뜻이고 의사결정이 빠르게 이루어지지 않고 있다는건 R&R이 명확하지 않다는 뜻이에요.

Notes

[1] Blitzscaling 08: Eric Schmidt on Structuring Teams and Scaling Google (39:00 ~)

6) 프로덕트 개발 프로세스는 PMF(Prouct-Market-Fit)를 찾아가기 위한 알고리즘

팀원들간의 R&R을 확실히하고 나서 제품 개발 프로세스를 잘 정리하는게 중요해요.

간혹가다 아이디어가 중요한지 아니면 실행이 중요한지에 대한 논쟁을 봐요. 저는 개인적으로 아이디어보다 실행이 훨씬 중요하다고 생각해요. 프로덕트 개발에서 아이디어란 문제에 대한 해결책을 뜻해요. 아이디어에만 집중하는건 마치 수학문제를 풀때 풀이과정을 모르고 대충 찍어서 답만 맞추려는 것과 비슷하다고 생각해요. 풀이과정을 숙지하면 문제가 변형되어도 그 문제를 풀 수 있는 확률이 기하급수적으로 높아지죠. 프로덕트 개발 프로세스도 이런 풀이과정과 비슷하다고 생각해요. PMF를 찾을 확률을 기하급수적으로 높여줘요.

좋은 프로덕트 개발 프로세스는 반복적으로 자주 런칭할 수 있게 해줘요. 반복적으로 자주 런칭하는게 중요한 이유는 우리가 실제 사용자들이 가치를 느끼는 기능을 개발하고 있는지에 대한 피드백을 최대한 작은 단위로 빠르게 얻어 사용자가 원하지 않는 기능을 개발하는 리스크를 줄이기 위해서에요.

최대한 작은 단위

MVP테스트 이후 디스콰이엇 2.0 또한 가장 작은 단위를 개발한 후 출시를 했어요. 오히려 MVP 테스트 할때보다 기능을 더 줄여 런칭했던 것 같아요. MVP 버전에서는 검색 기능, 관련 프로덕트를 보여주는 기능이 있었지만 이또한 뺐어요. 저희의 목표는 기능이 너무 간소해 사이트 사용자가 많지 않아도 되니 디스콰이엇의 가장 핵심 기능만 정해서 최대한 빠른 시간 안에 배포하는 것이였어요. MVP에서 정식버전으로 넘어오면서 핵심 기능을 정할때 유용한 프레임워크는 서비스에 대해서 엘레베이터 피치한다고 했을때 그 안에서 설명할 수 있는 기능 외에는 최대한 다 빼는거에요.

디스콰이엇의 엘레베이터 피치:

• 디스콰이엇은 IT 프로덕트를 만드는 개발자, 디자이너, PM들이 프로덕트를 공유하고 이에 대해 피드백을 나누는 사이트입니다. 프로덕트를 공유하는 사람은 로그인 후 우측 상단에 있는 프로덕트 공유하기를 클릭해 간단한 설명, 로고, 카테고리들을 기입하면 프로덕트를 공유할 수 있습니다. 사이트 방문자들은 마음에 드는 프로덕트가 있으면 투표를 하고 프로덕트를 공유한 사람에게 댓글을 달 수 있습니다.

이렇게 3문장 안에 표현할 수 있을 정도의 기능만 우선 개발을 한다고 생각하면 본질적인 부분 외에는 다 뺄 수 밖에 없어요.

아래 시안들을 보면 저희가 얼마나 많이 뺐는지 알 수 있어요.  이 시안들은 MVP테스트 이후 처음에 그렸던 시안이에요. 검색 기능도 있고 팔로우 기능도 있고 포인트 시스템도 있죠. 그리고 프로덕트 상세 페이지도 보면 지금의 저희 사이트보다 좀 더 프로덕트 헌트와 유사해요.

하지만 이를 다 개발하기에는 시간이 너무 오래 걸릴 것 같았어요. 그래서 위의 시안에서 표현된 기능들을 마일스톤별로 나눠서 분리를 했어요. 아래 표를 보면 M1, M2, M3의 3단계로 나눴고 각 마일스톤마다 해결하고자 하는 KPI, 가설, 가설 검증 방법을 적고 그에 해당되는 기능들을 분리했어요. 이렇게 정리를 한 내용을 바탕으로 피그마에서도 페이지를 각 마일스톤별로 만들어 화면을 분리했고 각 마일스톤 별로 쪼개서 개발을 해나가고 있어요.

반복적으로 자주

이렇게 작게 쪼갠 것을 반복적으로 자주 개발하려면 프로세스가 심플해야 되요.

저희는 기본적으로 문제파악 → 해결책 개발 → 측정의 과정을 따르고 있어요.

1. 문제파악

사용자가 겪고 있는 문제를 정성적으로는 인터뷰를 통해, 정량적으로는 데이터를 보면서 사용자들이 어떤 문제를 겪고 있고 우리가 세운 KPI를 달성하는데 현재 겪고 있는 문제가 무엇인지 파악해요.

2. 해결책 개발

각각의 문제에 대한 해결책을 생각한다음 각각의 해결책이 어떤 지표를 늘리는지 고민해본 후 개발 난이도와 지표 영향력에 점수를 매겨봐요. 그렇게 해서 개발이 쉬우면서 KPI 지표를 늘리는데 가장 도움이 많이 되는 것부터 해나가고 있어요.

3) 측정

기능을 개발한 후 데이터 분석을 통해 정량적 측정을 하고 사용자 인터뷰, 피드백 수집을 통해 정성적 측정을 해요.

정량적 측정은 구글 아날리틱과 Mixpanel을 연동해서 하고 있어요. 구글 아날리틱은 트래픽을 파악하는데 사용하고 Mixpanel은 Engagement를 측정하는데 정말 유용해요.

디스콰이엇의 한주는 이렇게 흘러가요.

월요일 아침

지난 한주를 회고하고 이번 주는 어떤 일을 할지 계획을 세워요. 한주 회고는 다음과 같은 내용이 들어가요:

• 지난주 KPI 지표 변화
• 지난주에 어떤 목표를 달성했는지
• 배운 점(정량적, 정성적)
• 현재 해결해야 될 문제와 문제 해결 방안
• 다음주 할일
• 백로그 체크와 개발 우선 순위 세우기

월요일 ~ 금요일

• 월요일 아침에 정한 할일들을 각자 해나가요.

2주에 한번 월요일

• 개발한 기능을 배포해요.

7) 추상적인 미션을 어떻게 달성할지 최대한 구체적으로 계획

흔히 미션을 북극성이나 이정표에 많이 비유해요. 프로덕트 개발 여정에서 갈림길을 마주 했을때 어디로 가야될지 알려주기 때문이에요. 간혹가다가 미션은 뜬구름이다라고 생각하고 무시하는 경우가 있어요. 이는 미션의 역할을 정확히 이해하지 못했기 때문이라고 생각해요. 내가 지금 당장 오늘 뭘해야 되는지를 알려주는 것이 미션이에요.

미션을 구체화하지 않으면 프로덕트 개발 과정에서 정말 많은 비효율이 생긴다고 생각해요. 특히 팀원들과 소통을 하고 다양한 아이디어 중 최종 결정을 내릴때 어떤 방향이 맞는지 판단하기가 어려워 시간과 에너지 낭비가 심해요.

미션은 Why에 대한 것이고 비전은 What에 대한 것이에요. 그리고 이를 어떻게 달성할지에 대한 계획은 How에 대한 것이에요. 이 Why, What, How를 잘 연결하는 것이 추상적인 미션을 어떻게 달성할지 구체화하는 것이에요.

디스콰이엇의 경우에는 다음과 같아요.

미션: '메이커들을 연결해 영감을 주는 프로덕트가 세상에 더 많아지게 하자'

비전: 프로덕트 메이커들을 위한 소셜네트워크

이를 어떻게 달성할 것인지:

• 알고리즘 적으로 연결
• 참여도가 높고 서로 돕는 문화의 커뮤니티 빌드
• 메이커들이 효율적으로 프로덕트 개발 여정을 스토리텔링 할 수 있는 툴 제공

위의 3가지를 하기 위해 필요한 것:

• 알고리즘 적으로 연결 → 많은 engagement 데이터가 필요
• 참여도가 높고 서로 돕는 문화의 커뮤니티 빌드 → 메이커모임 운영
• 메이커들이 효율적으로 프로덕트 개발 여정을 스토리텔링할 수 있는 툴 제공 → 사용자 인터뷰와 프로덕트 개발

위의 3가지를 잘하고 있는지 측정하는 방법:

• engagement 데이터: engagement rate
• 메이커모임: NPS, K-factor
• 툴 제공: cohort retention

위 3가지 지표를 늘리는데 현재 겪고 있는 문제:

• engagement rate: 기능 부족, Critical mass를 아직 넘지 않음
• 메이커 모임: 인력 부족, 기획 부족
• 툴 제공: 개발자 부족

그래서 지금 당장 이번주에 해야 될것:

• 컨텐츠 마케팅으로 사용자 늘리기, 사용자 인터뷰, 기능 개발
• 커뮤니티 매니저 채용
• 개발자 채용, 개발

미션은 보통 개인이 세상에 느끼는 갈증과 연결되어 있다고 생각해요. 개인의 선천적 성향과 연결되어 있는 굉장히 내재적인 동기인거죠. 저같은 경우에는 장인 정신을 갖고 정말 고심해서 만들어진 창작물, 소위 말하는 영혼이 담긴 창작물을 좋아하고 제가 매일 살아가는 환경이 그런 창작물과 이를 만드는 창작자들로 둘러쌓여 영감이 충만한 하루하루를 보내면 얼마나 좋을까라는 갈증을 느껴요. 하루를 보내면서 단순히 빠르게 돈을 벌기 위해서 고안된 것들(시끄러운 광고, 전단지, 어설픈 제품들, 자극적인 컨텐츠들)을 마주하면 스트레스를 받아요. 이런 저희 갈증에서 나온것이 디스콰이엇의 미션인 '메이커들을 연결해 영감을 주는 프로덕트가 세상에 더 많아지게 하자'에요.

좋은 사업 기회처럼 보여도 그 활동이 어떻게 메이커들이 영감을 주는 프로덕트를 만드는데 도움이 되는지 설명할 수 없으면 과감히 포기해요.

3편 - 투자&팀 계속 읽으러 가기