Startup School Week 2. 제품 구축하기 by Michael Seibel

 

 

Michael Seibel

와이콤비네이터 CEO이자 Justin.tv, Twitch, Socialcam 창업자.

 

Lecture Slides

Lecture Transcript

 

Resources

Sam Altman's Startup Playbook - A Great Product

Building Product, Talking to Users and Growing (SUS 2014) by Adora Cheung

 

Warning!

Headstart Growth 블로그의 (짧은) 역사상 가장 긴 길이의 포스팅입니다. 요약하고자 했으나, 요약할 수 없었습니다. 너무 재밌었거든요... 이제까지 제가 본 어떤 글, 어떤 자료보다도 속이 꽉 찬 멋진 강연이었네요. 길고, 잡다하고, 어디서 들은 얘기가 자꾸 나올 것입니다만 이만큼의 구체성과 명료성을 가지고 스타트업을 이야기한 자료는 처음입니다.

 

나눠서 올릴까 하다가, 정직하게 통째로 올립니다. 이 글은 나눠 읽기보단 한 번의 호흡으로 읽는 게 최고인 것 같아요. 먼저 슬라이드 자료로 대략의 내용을 파악하시고, 필요한 내용이라면 적절한 시간을 확보해 느긋한 마음으로 일독을 권합니다. 사실 그냥 영상만 봐도 돼요...!

 

그리고 해당 강연을 해 주신 Michael Seibel의 이메일 주소는 mmichael@ycombinator.com이며, 모든 이메일에 답변을 해 준다고 하네요. 믿거나 말거나 입니다만, 스타트업 창업을 고민하는 사람이라면 고민을 털어놓지 않을 이유는 없겠죠!

 

그럼, Michael Seibel의 제품 구축 이야기를 시작하겠습니다.

 

---

 

제품 이야기를 시작하기 전에, Justin.tv와 Twitch에서의 경험을 이야기하고자 한다. 두 회사를 창업하고 운영하는 과정에서 우리는 상당히 많은 규칙을 어겼고, 그럼에도 우리가 살아남았던 것에 대한 얘기다. 생존을 가능케 했던 것에는 세 가지 요인이 있었다.

 

첫째, 창업팀의 기술적 역량이 뛰어났다는 점이다. 기본적으로 협업이나 기술적인 측면에서 우리는 어려움을 겪지 않았다. 이것이 우리가 규칙을 어겼음에도 별 문제 없이 살아남을 수 있었던 첫번째 이유다.

 

둘째, 우리는 많은 돈을 쓰지 않았다. 우리는 23세 이하의 창업팀이었고, 월세가 $2,500인 아파트에서 살았다. 우리는 한달에 $500을 월급으로 받았으며, 최저임금 미만으로 위법의 소지가 있긴 했다. 하지만 아무도 신경쓰지 않았고  그뿐인 이야기, 그뿐인 게임이었다. 침실, 거실, 발코니 등 적당한 곳에서 잤다. 그저 돈을 최소한으로 썼고, 그래서 수많은 시행착오를 겪어내면서도 버틸 수 있었다.

 

셋째, 그 당시 우리의 스타트업은 우리의 인생 자체와 매우 긴밀하고 단단하게 연결되어 있었다. 우리는 멋진 이력으로 스타트업을 하고 있지 않았다. 우리에게 스타트업이란 우리가 생계를 위해 하고 있는 단 하나의 것이었다. 따라서 우리의 스타트업이 망해보일 것 같다면 우리의 인생 또한 망한다는 것을 의미했다. 우린 그러한 공감대를 공유하고 있었고, 포기라는 선택지는 존재할 수 없었다. 

 

위의 세 개 중에 하나라도 빠졌다면 우리는 실패했을 것이다. "한두개만 충족한다면 썩 나쁘지 않음"의 이야기가 아니다. 세 개를 모두 충족시키거나 실패하거나의 이야기다. Justin.tv와 Twitch의 초창기 시절, 그리고 YC에서 조언하고 투자했던 Poppy의 경험을 바탕으로 본격적인 제품 이야기를 해 보려 한다.

 

1. What problem are you solving?

• Can you state the problem clearly?
• Have you experienced it yourself?
• Can you define the problem narrowly?
• Is the problem solvable?

의외로 많은 경우, 창업자들은 제품을 왜 만드는지에 대해 모른다. 구체적으로 말하면, 무슨 문제를 해결하기 위해 제품을 개발하려고 하는지에 대해 모른다. 규모가 정말 작거나, 프로젝트를 막 구상 중인 단계라면 정확하게 몰라도 괜찮다. Justin.tv가 해결하고자 하는 문제는 엔터테인먼트였고, 우리는 개인의 24시간을 방송하는 티비 쇼를 만들고자 했다. 이 아이디어가 워킹하는지를 판단하는 것은 쉬운 문제였다 - '보는 사람들이 있는가?' 보는 사람이 없었고 우리는 오픈 플랫폼으로 피봇했다. 이제 우리가 해결해야 할 문제는 '우리가 사람들을 생방송 하도록 만들 수 있는가'가 되었다.

 

누군가 그것을 할 수 있는지 없는지를 판단하는 것은 쉬웠다. 그렇지만 우리의 제품은 오픈 플랫폼이었고, "이걸 사람들이 쓸까?"라는 것은 곧 "우리가 무엇을 하고 있는가"의 핵심이었다. 때때로 내가 창업자들과 얘기를 나눌 때, 세상에서 하고자 하는 무언가가 있고 막연히 관심을 갖는 문제는 있지만, 실제로 해결하고자 하는 문제를 명료하게 설명할 수는 없었는 경우가 있다. 문제를 모른다면 당신이 그것을 해결하고 있는지 아닌지를 알 수 없다.

 

그래서 나는 이런 질문들을 한다.

 

첫째, "해결하려는 문제를 명확하게 2문장으로 말할 수 있는가?" 그걸 할 수 없다면 문제를 모르는 것이다. 사실 문제를 정확히 안다면 단 하나의 문장으로 나와야 한다. 누군가 당신이 해결하려는 문제에 대해 물어볼 때 에세이 한 편 분량으로 설명해야만 한다면, 아직 문제를 모르는 것이다.

 

둘째, "스스로 그 문제를 겪어본 적이 있는가?" 이것은 반드시 필수는 아니지만, 분명 도움이 된다. 나는 만나본 적도, 이야기를 나눈 적도, 그런 사람이 존재하는지조차 알지 못하는 사람들의 문제를 해결하려는 창업자들을 수도 없이 만나봤다. 그래서 다른 조건들이 비슷하다면, 문제를 겪는 사람에 대해 이해하고 있는가 없는가는 제대로 된 팀을 구분하는 중요한 힌트가 된다. 최소한 창업팀에서 한 사람은 제품이 해결하려는 문제를 겪어본 사람이어야 한다.

 

셋째, "작은 고객군에 한정하여 문제를 정의할 수 있는가?" 흥미로운 것은, 초창기 스타트업이 모든 사람들이 겪는 문제를 해결하는 것은 불가능하다는 것이다. Justin.tv 초창기 시절, 우리는 아무 사람이나 생방송을 중계하도록 할 수 없었다. 우리의 제품 사용자는 노트북을 갖고 있어야 했고, 좋은 인터넷 회선을 써야 했고, 웹캠을 갖고 있어야만 했다. 

 

 

2. Who is your Customer?

• Everyone? NO!
• How often do they have the problem?
• How intense is the problem?
• Are they willing to pay?
• How easy are they to find?

팔리는 비즈니스는 고객의 입에서 시작된다, <린 고객 개발>

 

Everyone? NO!

 

모든 사람들을 위한 라이브 방송을 만들고 싶어할 때, 우리가 가장 처음 끌어들일 수 있는 사람들이 누군가를 생각해야 한다. 누가 가장 먼저 필요로 할 것인가? 나는 때때로 창업자들이 이 단계를 건너뛰고서 거대한 문제를 해결하려 한다고 생각한다. 말하자면 이런 거다. "나는 암을 치료하고 싶어. 나는 모든 사람들을 치료하는 것만 생각할래." 하지만 당신은 이렇게 생각해야 한다. "내가 당장 해결할 수 있는 작은 문제는 뭐지? 우리가 해결하고자 하는 커다란 문제를 우리가 실제로 해결할 수 있음을 어떻게 확인할 수 있지?" 이로부터 "그 문제는 해결 가능한 문제인가?"를 답할 수 있어야 한다.

 

Poppy의 사례를 들어보고자 한다. Poppy는 본질적으로 베이비시팅 카테고리의 우버에 해당한다. Popp는 베이비시팅 서비스를 원하는 부모가 베이비시터를 쉽게 구할 수 있도록 한다. Poppy는 매우 흥미로운 회사인데, 왜냐하면 당신은 매우 다양한 요소를 고려하면서 베이비시터를 구하기 때문이다. 어떤 부모들은 출근해 있는 동안 아기를 돌봐줄 주 5일 베이비시터를 필요로 한다. 어떤 사람들은 긴급하게 베이비시터를 구하기도 한다. "나는 갑자기 입원을 해야 해서 아기를 돌봐줄 사람이 필요해." 어떤 사람들은 스케줄링 미스로 베이비시터를 찾는다. "남편이 이 때 아기를 돌봐주기로 했는데, 그럴 수 없게 되었어." 어떤 사람들은 영유아에 대한 베이비시팅을 필요로 한다. 이러한 베이비시터에게는 수많은 기술과 지식이 필요하다. 어떤 사람들은 15세 아이가 집밖으로 나가지 않는지 감시할 베이비시터를 필요로 한다. 다른 기술이 필요하다.

 

흥미로운 점은, 사람들이 베이비시터를 쉽게 구할 수 있게 돕고자 할 때 문제 전체를 이해하려고 하는 것으로는 충분하지 않다는 것이다. 모든 경우의 수 중에서 당신이 먼저 해결하고자 하는 경우는 어떤 것인가? 당신이 더 좁게 문제를 정의했다고 해 보자. 예를 들면 영유아 베이비시팅에서 출발했다고 치자. 우리는 영유아 케어를 원하는 특정 부모를 대상으로 서비스를 제공하고자 한다. 이렇게 되면 우리는 진정으로 이 질문에 답할 수 있게 된다 - "그 문제는 해결가능한가?"

 

서비스 런칭 시점에서 Poppy는 '만나본 적도 없는 사람에게 자신의 영유아를 맡기기 위해 부모들이 요구하는 기술적 레벨은 매우 높다'라는 사실을 알게 되었을 것이다. 그래서 만나본 적도 없는 사람에게 영유아를 맡기는 사람들을 계속 서비스에 유치하겠다는 생각은 매우, 매우, 매우 실현되기 힘들 것이다. 영유아 케어에 적합한 스킬을 지닌 사람들 또한 적을 것이다. 우버 모델은 공통의 기술을 가진 대체가능한 사람들이 수없이 많아야만 성립된다. 자, 영유아 케어에 적합한 기술을 갖고 있으면서 부모를 안심시킬 수 있는 사람들은 베드타운을 중심으로 꽤 괜찮은 보수를 받고 풀타임 보모로 일하는 경향이 있다는 사실이 드러났다고 하자. 우리는 영유아 돌봄 서비스가 필요한 부모들의 문제를 해결하려고 하는데, 그 문제를 해결할 수 있는 인재 풀, 즉 베이비시터의 공급은 충분하지 않을 수 있다. 따라서 우리가 해결하고자 하는 문제는 해결 가능하지 않을 수 있다.

 

제품을 세상에 내놓은 단계에서 당신은 이러한 시나리오들을 생각하고 있어야 한다. 당신은 가장 먼저 해결하고자 하는 "좁은" 문제를 어떻게 정의할 것인가를 생각해야만 한다. 또 언제나 스스로에게 "이것은 실제로 해결 가능한가?"를 물어야 한다. 수많은 창업자들은 이런 종류에 대해 이야기하고 싶어하지 않는데, 왜냐하면 어려운 일이기 때문이다. 당신이 가장 먼저 말 걸어야 할 사람들이 누구일까에 대해 생각하는 것은 어렵다. 이해하는 것이 어렵고, 내가 그 문제를 해결할 수 없을지도 모른다.

 

Avni는 두 아이의 엄마로서 베이비시터를 찾기 힘든 문제 때문에 울화통이 터졌다. 그녀는 한 개인으로서 문제를 직접 겪었고, 해결하기가 매우 매우 어렵다고 느꼈다. 영유아를 돌봐주는 온디맨드 베이비시터가 필요했다. 내가 항상 창업자에게 묻는 다음 질문은 그래서, "당신의 고객은 누구인가?"다. 그리고 당신은 문제를 해결해 줄 고객이 누구인지 알기 전까지는, 해결하고자 하는 문제를 정확하게 알 수 없다. 모든 사람이 고객일 것이기 때문이다. 그리고 '모든 사람'이란 어떤 관점에선 맞는 얘기다. 예를 들면 소셜 네트워크나 검색 엔진을 만들려고 한다면 말이다. 현재 모든 사람이 그런 제품을 사용하고 있으니까.

 

내가 이야기하려는 건 오늘날 대다수의 사람들이 사용하는 제품들이란 한때 거의 아무도 사용하지 않았던 시절이 있었다는 사실이다. 그래서 제품을 만든 사람들은 누가 가장 이상적인 첫 고객인지 파악해야만 했다. 그리고 이 질문에 대한 좋은 답을 찾지 못한다면 길을 잃어버리게 될 것이다. 당신은 누구에게 말을 걸어야 할 지 모르고, 문제가 해결되었는지 물어볼 수도 없으며, 제품이 누구를 위한 것인지를 알 수 없게 된다. 창의적인 소설을 쓰는 것마냥 제품을 개발하는 창업자들은 놀랄만큼 많다. 머릿속 가설만을 바탕으로 제품을 만들고, 현실의 누구와도 대화하지 않으며, 그들이 해결하려는 문제를 직접 경험해 본 것도 아닌 창업자들이다. 이런 창업자가 되어서는 안 된다. 당신은 당신의 제품을 쓰는 사람들과 이야기를 나눌 수 있다. 당신은 그들이 어떤 사람인지 파악해야 한다.

 

How often do they have the problem?

 

내가 묻는 다음 질문은 "당신의 사용자는 문제를 얼마나 자주 겪는가?"다. 사용자에 대한 이해나 문제가 발생하는 빈도를 전혀 파악하지 않고 해결하려는 문제를 정하는 스타트업이 의외로 많다. 예를 들자면, 한 5년 전쯤 온라인 자동차 쇼핑몰을 하려고 YC를 찾은 사람들이 많았는데, 그들이 구상한 제품은 다 형편없었다. 일반적인 고객은 자동차를 구매함에 있어서 거의 테슬라 급의 경험을 기대할 것이지만, 그들 중 누구도 그러한 기대를 고려한 제품을 만들려 하지 않았다. 흥미로운 점은 이 문제를 해결하려는 창업자들이 계속해서 YC에 찾아왔다는 것이다. 그들은 그들의 고객이 자동차를 구매한다는 지점까지만 생각했다. 그러나 현실 고객은 자동차를 단순히 구매만 하는 것이 아니라 약 7년의 구매주기를 갖는다. 정말 대박을 쳐서 고객을 감동시킨다 해도, 그 고객은 7년 뒤 돌아올 것이다. 정말로 어려운 비즈니스다.

 

수많은 자동차 구매 웹사이트는 자동차를 사는 사람을 대상으로 만들어지지 않았는데, 이는 개개인은 자동차 구매라는 문제를 자주 겪지 않기 때문이다. 그래서 자동차 구매 웹사이트는 자동차를 파는 사람을 대상으로 한다. 해당 문제를 매일 겪는 사람 말이다. 매일 자동차 딜러는 매상을 올려야 한다는 문제를 겪는다. 나는 창업자들에게 문제를 자주 겪는 '진짜 고객'이 누구인지 분석하도록 만들고, 그들의 제품으로 최상의 가치를 획득하는 사람들이 누구인지 이해하도록 밀어붙인다. 이것은 당신이 문제를 자주, 반복적으로 겪는 사람을 돕고자 한다면 큰 도움이 될 것이다. 

 

당신이 매일 사용하는 제품을 구상하고 있다면, 반드시 사람들이 핸드폰 첫 화면에 두는 제품이어야만 한다. 거의 생각하지 않고 앱 버튼을 눌러야만 한다. 거의 고객이라는 사람의 일부가 되어야만 한다. 당신의 앱을 핸드폰의 세 번째 화면에 두거나, 두 번째 페이지의 폴더에 처박아 두는 사람들은 그다지 자주 앱을 켜지 않는 사람들일 것이다. 실제로 자주 앱을 실행할 필요가 없다면 다행이지만, 그렇지 않다면 좋은 비즈니스가 아닐 확률이 높다.

 

How intense is the problem?

 

또 내가 묻는 질문은 "얼마나 강력한 문제인가?"이다. 나는 좋은 아이디어를 가졌지만, 문제가 발생하는 빈도와 강도를 분석하지 않는 창업자들을 숱하게 만난다. 당신이 해결하려는 문제가 자주 발생하지도 않고 강렬하지도 않은 문제라면, 당신의 고객들은 그 문제에 대해 당신과 이야기를 나누려고 하지도 않을 것이다. 그래서 문제를 발생빈도와 심각성을 두 축으로 하는 그래프로 그렸을 때, 우상단에 위치한 문제가 좋은 문제다. 예를 들어 우버에 대해 생각해 보자. 대개 당신이 어딘가에 있고 다른 어딘가로 이동하려고 할 때, 그것은 꽤 강력한 문제다. "나는 일하러 가야 해." "나는 의사를 만나러 가야 해." "나는 아이들을 데리러 가야 해." 이런 문제들은 해결을 위해서 $20,000을 기꺼이 투자해 자동차를 사게 할 만큼 강력하다. 그리고 빈도와 관련해서는, 걸어가기 힘든 1마일 이상의 거리를 하루에 몇 번 이동해야 하는지를 생각해 보라. 많다. 이 시점에서 당신은 택시 시장을 떠올리고, "우버 전에 택시가 있었지."라고 생각한다. 시장의 관점에서 택시는 큰 시장이 아니지만, 고객의 문제 측면에서 접근한다면 "매우 자주 발생하고, 강력한 문제. 꽤 좋은 비즈니스가 될 수 있겠어."라고 생각할 수 있는 것이다.

 

Are they willing to pay?

 

다음 질문은 "고객이 기꺼이 비용을 지불할 것인가?"이다. 수많은 창업자 대부분은 이 단계에서부터 잘못된 생각을 갖고 YC를 찾아온다. 그들은 일단 무료로 서비스를 제공하고 보자는 생각을 하는데, 초기 단계에 사용자를 확보할 유일한 방법이라고 생각해서다. 내가 창업자들에게 언제나 요구하는 것들 중 하나는 바로 이 지점이다. 만약 당신이 좋은 제품을 만들었는지 확인하고 싶다면, 사용자들이 서비스를 이용하는 허들을 조금 높게 만드는 것이 좋다. 그럼에도 사람들이 서비스를 이용하는지 보라. 왜냐하면, 내가 정말 강력한 문제를 갖고 있고 당신이 $100을 요구할 때, 극도로 강력한 문제를 가진 사람들은 그것을 "낼 만 하다"고 생각할 것이기 때문이다. 만약 그들이 정말로 강력한 문제를 가진 사람이 아니라면, 한 푼도 내지 않을 것이다.

 

당신은 실제로 제품이 해결하는 문제를 갖지 않은 수많은 사용자들도 일단 확보하고 싶을 것이다. 그러나 그들은 그냥 제품을 시험삼아 써 보는 것임을 명심하라. 제품을 어떻게 개선하면 좋을지 결정하기 위해 그런 고객들을 분석하게 된다면, 당신은 아무짝에도 쓸모없는 결정을 내리게 될 것이다. 이상하게 들리겠지만, 처음부터 유료로 서비스를 하는 것은 무료로 시작하는 것보다 낫다. 그리고 당신이 무료로 시작해 버린다면, 당신은 문제가 실제로 강력한 문제를 겪는 사용자들을 찾아낸 뒤 어떻게 대화해야 하는지를 알아내야 한다. 현실 세계에서 실제적인 목표를 위해 제품을 주기적으로 사용하는 사용자들과 어떻게 대화해야 하는가? 고객들과 대화하는 것은 좋다. 잘못된 고객과 대화하는 것은 정말, 정말, 정말 나쁘다. 나는 나쁜 고객들의 얘기를 듣다가 실패한 수많은 회사들을 봐 왔다. 특히나 고객으로부터 비용을 지불받는 회사에서.

 

예를 들면, 당신이 Poppy같은 회사를 갖고 있다면 다양한 기술을 가진 베이비시터를 모집하고, 관리하고, 함께 일하는 데 실제적인 비용이 들어갈 것이다. 그리고 당신이 가진 고객들이 시스템을 악용하고, 시간을 안 지키고, 비협조적이며 베이비시터에게 무례하다면, 당신의 비즈니스를 운영하는 데 하나도 도움이 되지 않을 것이다. 그리고 당신은 비즈니스를 망가뜨리는 고객이 얼마나 많은지에 대해 놀라게 될 것이다.

 

가격으로 말해요 - 프라이싱(Pricing)

 

How easy are they to find?

 

마지막 질문은 "당신의 고객을 얼마나 찾기 쉬운가?"이다. 왜냐하면 당신은 그들을 반드시 찾아야 하기 때문이다. 지난 YC batch에 들어온 스타트업 중 흥미로운 2개의 B2B 스타트업이 있었다. 하나는 미국에 있었고 고객을 찾는 일이 무척 쉬웠다. 그들은 기본적으로 링크드인에 들어가서 고객을 찾고, 이메일 주소를 확인해서 이메일을 보내면 됐다. 그들은 매주 1,000명의 고객에게 이메일을 보냈다. 다른 하나는 중국에 위치했는데, 중국의 B2B 영업 관행은 이메일과는 거리가 멀었다. 이메일 주소를 수집하는 것은 어렵지 않았지만, 그렇다고 쉽지도 않았다. 그리고 이상하게도, 설명하기 어렵지 않은 심플한 비즈니스와 자주 발생하는 강력한 문제를 모두 가졌지만 고객에게 도달할 수 있는 방법이 없었다. 그들은 새로운 방법을 고안해내야만 했다.

 

당신의 고객을 찾기가 이상할 정도로 어렵다면, 시작 단계에서 그 문제에 대한 솔루션을 확보해 두는 것이 좋다. 당신은 제품만 만들어 놓고서 고객들이 발견해 주기를 기대할 수 없기 때문이다. 또 종종 당신은 제품을 사용하길 원치 않거나 아예 존재하지도 않는 고객을 위한 제품을 만들려고 애쓰는 상황에 처할 수 있다. "나는 사막 한가운데 있는 사람들에게 물을 주려고 해. 그들이 내 앱을 다운받아서 GPS 위치 기능을 켜 주기만 하면, 우리가 물을 배달하면 될 거야." 이건 상식적으로 불가능하다. 그러나 의외로 많은 창업자들이 이런 논리적 사고를 거치지 않고 스타트업을 시작하려 한다. 

 

2-1. Does your MVP really solve the problem you want to solve?

MVP를 만드는 프로세스는 체계보다는 당신의 직감에 의존하며 진행될 수 있다. 어떻게든 당신이 해결 문제를 정의하고, MVP를 만들고, 사용자와 얘기하고 난 뒤에 뭔가를 런칭했다고 하자. 그런데 출시한 제품이 실제로는 당신이 약속한 가치를 전달하기는커녕 당신이 하려고 했던 것조차 아닐 수 있다. 그래서 MVP를 만드는 과정에서 예비 스텝들을 차근차근 검증해 나가는 것은 큰 도움이 된다. 이를 통해 당신은 당신의 직관이 옳은지를 - "나는 정말로 문제를 해결하고 있는가?" - 확인할 수 있다.

 

또한 MVP를 정말로 빠르게 만들어보는 것도 큰 도움이 된다. MVP에 오랜 시간을 들일수록, MVP가 실제 문제를 해결하지 못하거나 고객의 반응을 얻지 못했을 때 더 많이 손해를 보기 때문이다. MVP를 2주 간격으로 만들기로 결정했다면, 검증해야 할 가장 중요한 가설, "그 고객 집단의 그 문제를 실제로 해결하는지"를 더 빠르고 효율적으로 확인할 수 있다. 

 

당신의 가설을 테스트하는 방법은 고객에게 당신의 제품을 주는 것이다. 그렇게 해야 한다. 필요한 일이기 때문이다. 창업자들이 그들의 제품을 마치 전시회의 미술품마냥 감상용 작품 또는 한 명만을 위한 작품으로 착각하는 경우가 있다. 제품은 예술작품이 아니다. 사용자에게 유용하지 않다면 그것은 제품이 아니다. 사람들은 종종 창업으로 예술을 하려고 하지만, 스타트업은 훨씬 더 냉정한 세계에 있음을 알아야 한다.

 

당신은 예술품이 아닌 제품을 만들고자 하는 것이며, 그것을 당신은 고객에게 전달하고 유용한지에 대한 의견을 들어야 한다. 이 과정의 유일한 문제는 고통스럽다는 것이다. 현실 속에서 사람들의 냉정한 평가는 고통스럽다. 그러나 당신은 고객에게 묻지 않으면 문제를 해결하고 있는지조차 알 수 없다.

 

2-2. Which customers should you go after first? = the easy ones!

많은 창업자들은 이 지점에서 혼란을 겪는다. 흥미롭게도, 초기 고객에겐 서비스를 무료로 제공해야 한다는 잘못된 직관과 마찬가지로, 이 부분에 있어서 창업자는 직관적으로 "가장 획득하기 어려운 고객에게 먼저" 서비스를 제공하려고 한다는 것이다. 가장 끌어들이기 어려운 고객을 끌여들였으니, 이후로는 더 쉬울 것이다? 그만큼 내가 제품을 잘 만든 것이다?

 

내 관점은 좀 다르다. 당신은 지금 내놓은 제품이 MVP라는 것을 알고, 그다지 좋은 제품이 아니란 것도 안다. 그게 MVP의 정의다. 그래서 당신이 해야 할 질문은 "제품이 나쁨에도 불구하고 돈까지 지불할 의사가 있는 사람들을 어떻게 찾아야 할까"가 되어야 한다. 가장 제품을 절실하게 원하는 고객들이다. 그래서 나는 창업자들에게, 당신의 제품을 가장 절실히 필요로 하는 사람들이 누구고, 어떻게 이야기를 나눠야 할 지를 먼저 파악하라고 요구한다. 그것이 내가 생각하는 easy의 정의다 - 가장 절실해서 끌여들이기 가장 쉬운 고객들 말이다.

 

무려 6달 동안 사전교섭을 해야만 하는 고객사가 있다면 그들은 결코 절실하지 않다. 특히 당신이 B2B 스타트업을 하고자 한다면, 일반 고객들보다 훨씬 더 절실한 고객사를 찾아야만 한다. 그들에게 제품을 파는 것은 일반 고객들보다 기본적으로 더 오래 걸리기 때문이다. 만약 당신이 썩 절실한 상황이지 않지만 그저 "인상적인" 고객을 얻으려 하고 있다면, 잘못된 길을 가고 있는 것이다. 지인이나 가족이 아님에도 불구하고 당신의 제품을 쓰다가, 하루아침에 제품을 못 쓰게 되면 비명을 지르며 당신을 애타게 찾을 사람들은 누구인가? 그들에게 어떻게 말을 건넬 것인가?

 

지인, 가족, 스타트업 계열 종사자나 투자자들은 당신이 귀 귀울여 의견을 들어야 할 중요한 "제품 사용자"가 아니다. 그들의 의견이 아무리 선의에서 나왔다고 하더라도, 그들의 피드백은 당신을 잘못된 의사결정으로 이끌 가능성이 높다. 제품이 해결하는 문제를 절실하게 겪는 사용자가 아님에도 개인적 경험에서 비롯한 의견들을 쏟아낸다면, 그 자리에서 도망쳐라.

 

2-3. Which customers should you run away from? = the hard ones!

스타트업을 시작하게 된다면, 매우 이른 단계에서부터 나쁜 고객들을 가려내는 노력을 할 것을 권한다. 나쁜 고객들은 전화기에 대고 욕설을 퍼붓는 이들이며, 지속적으로 불만을 늘어놓는 이들이다. 내 공동창업자 Justin은 온디맨드 개인 비서 서비스를 제공하는 기업을 만들었는데, 그는 적극적으로 고객을 "해고"했다. 기상천외한 요구를 하는 고객, 완전히 비현실적인 기대치를 요구하는 고객들 말이다. 한 고객은 4번의 태스크에 대해서 4번 전액 환불을 받고서, 5번째 태스크를 요청했다. 그 고객은 기본적으로 수많은 가치를 무료로 얻고 있었으며, Justin은 그 고객을 영구 이용제한 처리함으로써 고객을 "해고"했다. 이런 사람들을 적극적으로 찾아라. 지불할 만큼의 가치를 느끼지 못하면서 시스템을 악용하는 고객들이 당신의 제품을 망치지 못하도록 말이다.

 

2-4. Should you discount or start with a super low price? = NO!

Zenefits CEO인 Parker가 몇 년 전 YC를 방문해서 기업 영업에 대한 중요한 이야기를 해 줬다. 그의 제품인 Zenefits는 기본적으로 무료인데, 그가 한 이야기 중 내게 굉장히 와닿았던 부분이 있었다. 당신이 어떤 가치를 돌려받을 수 있는지 이해하고 있다면 영업 피치에 할인과 인센티브를 구조적으로 녹여내는 방식으로 고객사를 설득할 수 있다는 부분이었다. 구체적으로 그가 하고자 한 것은 직원 건강관리 솔루션으로서 Zenefits으로 갈아타도록 고객사를 설득하고 제품을 파는 일이었다. 그는 예를 들어 이렇게 영업을 할 것이다.

 

"보세요, 서드파티를 도입함으로써(서드파티를 일단 AWS라고 하자) 전담 인스턴스 구매로 AWS 요금을 40% 절감했고 그 수익의 일부를 귀사에 돌려줄 수 있습니다. 하지만 무료 이용을 시작한 후 30일 내에 구매를 확정했을 때만 가능합니다. 어떻게 들리실지 모르겠지만 저는 귀사가 제품을 사야겠다고 판단하기 전까지 충분한 시간을 갖길 원하기 때문입니다. 전 귀사가 서비스 이용 31일차에 구매를 결정하여 아무런 혜택을 드리지 못하게 된다면 매우 슬플 것입니다."

 

자, 이것은 "일단 공짜로 줄게" 접근이 아니다. 왜냐하면 사람들이 구매하지 않을 수 있음을 염두에 두는 접근이기 때문이다. 이것은 매우 구조적으로 잘 짜여진 프로세스다. 그는 기본적으로 고객사에 혜택을 제공하는 것에 데드라인을 결합시켰다. 또 그는 언제 이것을 고객사에 이야기해야 할 지를 알고 있었다. 그의 이야기를 들은 고객사는 내부 검토를 시작하고, 데드라인과 할인혜택이 테이블 위로 올라갈 것이다. 이 지점에서 Zenefits 영업 프로세스는 "제품이 고객을 끌어당길 수 없을지도 모르니까 일단 공짜로 주자"가 아니라, 고객이 제품에 구매를 결정하는 프로세스를 가속화하는 전략적인 프로세스가 된다. 그는 제품가를 15% 더 높게 책정한 다음 할인 혜택을 녹였다. 이는 "난 고객을 붙잡지 못할지도 몰라, 무서우니까 일단 공짜로 풀자"와는 전혀 다른 접근이 된다.

 

 

3. How to set up metrics

• Google Analytics + Something else
• Pick 5-10 important stats
• Make measurement a part of product spec

Google Analytics + Something else

 

구글 애널리틱스(이하 GA)를 주요한 지표 애널리틱스 툴로 사용하고 있는가? 그렇다면 당신은 잘못하고 있는 것이다. 핵심지표를 설정하는 것은 매우 중요하며, 스타트업 초반에 이루어져야 한다. 제품이 실제로 사용되고 있는지 아닌지를 확인하는 이유뿐 아니라, 새로운 제품 아이디어와 영감을 얻을 수 있는 원친이 되기 때문이다. GA는 얼마나 많은 사람들이 웹사이트를 방문하고 몇 페이지를 보고 어느 경로로 유입되었는지 확인하기 좋은 도구다. 그러나 사용자 행동의 측면에서, 언제 사용하고, 무슨 버튼을 누르고, 어떤 액션을 취하기 전에 어느 화면에서 얼마나 오래 머무르는지, 장바구니에 상품을 남겨두었는지 등을 파악하기 힘들다.

 

이러한 사용자 행동을 추적하기 위해서는 이벤트 기반의 애널리틱스 툴, 예를 들면 Mixpanel, Amplitude, Heap 등을 사용해야만 한다.  지표 추적 도구를 자체적으로 개발할 수 없다면, 거의 필수적으로 이벤트 기반 추적 도구를 선택하고, 익혀라. 기본이다. 이 내용은 내가 맨 처음에 언급했던 "기술 팀 역량"과도 연결된다. 기술을 갖춘 창업팀에게 Mixpanel을 제품과 결합하는 것은 말도 안 되게 쉬운 일이다. 그러나 기술력이 없다면 거의 불가능하다. 따라서 기술 역량을 가졌다면 초반부터 지표 추적 도구를 결합하여 사용자들이 제품을 어떻게 사용하는지, 어떤 행동을 하는지 확인할 수 있다. 이것이 불가능하다면 도통 무슨 일을 해야 할 지 모르는 상태에 놓일 것이다.

 

Pick 5 to 10 important stats

 

Mixpanel의 Suhail은 Mixpanel을 세팅하는 방법과 관련해 좋은 이야기를 들려준 적이 있다. 사용자가 뭘 하는 지 파악하기 위해서 사용자가 제품으로 할 수 있는 액션이 150가지를 모두 추적하려 하지 마라. 처음부터 수많은 지표를 애널리틱스에 띄울 경우 일단 애널리틱스 툴을 사용하는 것이 복잡하고 어려워진다. 당신은 공동창업자와 직원들에게 애널리틱스 툴 사용법을 가르쳐야 하는데, 애널리틱스 툴은 스타트업의 모든 사람이 사용할 줄 알아야 하기 때문이다. 그래야만 사용자들이 제품을 어떻게 사용하고 있는지를 모든 구성원이 파악할 수 있다. 애널리틱스 툴은 CTO만 사용하는 도구가 아니라, 모든 사람들이 쓰는 도구다.

 

구성원의 교육과 사용성을 고려하여 5개에서 10개의 핵심 지표를 선정하라. 인스타그램을 예로 들어보겠다. 인스타그램의 핵심 지표를 고른다면:

1. 앱 실행 횟수
2. 새로 생성된 계정 수
3. 사진 촬영 횟수
4. 사진 효과 적용 횟수
5. 사진 공유 횟수

이 5개가 맨 처음에 확인해야 할 핵심적인 지표가 될 것이다. 인스타그램의 핵심적인 사용 메커니즘은 사진을 찍고 공유하는 것이기 때문이다. 한 가지 짚고 넘어갈 것은 이러한 지표의 이름을 붙이는 규칙을 미리 정해두라는 것이다. 언젠가는 당신이 관리하는 지표가 백 개, 천 개로 가짓수가 늘어나게 될 것이며, 이 시기를 미리 고려하여 이름을 지어야 한다. 당신만 알아볼 수 있는 방식으로 이름을 지어선 안 된다. 회사가 잘 성장했을 때 수많은 직원들이 이름을 보고 지표를 구분할 수 있어야 한다.

 

내가 모른다는 것조차 모르는 것을 찾기 위한 최적화 전략, <린 분석>

What is a North Star Metric?

 

Make measurement a part of product spec

 

제품을 일단 출시하고 지표 측정을 향후 추가하겠다는 창업자들을 종종 본다. 그러나 사람들이 사용하기를 바라는 뭔가를 만들었는데, 그 사용을 측정할 방법을 나중에 강구하겠다는 말은 언어도단이다. 지표 측정은 제품의 기본 스펙의 일부로서 포함되어야만 한다. 첫 출시 전, 제품 스펙을 구상하는 단계에서부터 어느 지표를 추적하여 개선의 기준으로 삼을지 정해야만 한다. justin.tv는 이것을 미리 해두지 않아서 상당한 시간을 낭비하게 되었다.

 

 

4. Product Development

• KPI Goal
• Brainstorm
• Easy/Medium/Hard
• Decide
• Written Spec

KPI Goal

 

Justin.tv와 twitch는 3명의 예일대 재학생과 1명의 MIT 재학생이 만들었다. 당신이 배우게 될 가장 생산적인 기술은 다른 예일대 재학생과 논쟁하는 방법이다. 제품이 개발되도록 하는 최고의 방법은 3명의 예일대생을 논리로 이기는 것이었다. Kyle은 이런 논쟁의 과정을 극도로 싫어한 나머지, 취침 시간을 아예 바꿔서 논쟁에 아예 참여하지 않으려고 했다. 그래서 우리는 아침 8시에 일어나 자정까지 일했는데, 그는 밤 11시쯤 일어나 밤새 코드를 작성하고, 결과가 좋지 않았던 멍청한 짓들에 관해 논쟁하지 않으려고 아침에 자러 갔다. 거의 3달에 걸쳐 지속된 언쟁 중 하나는 웹사이트의 배경색에 대한 것이었다. 오리지널 사이트는 단 하나의 페이지로 구성되어 있었다. Justin은 검정색을 원했다. 나는 녹색 계통의 색을 원했다. 세 달에 걸친 설전 끝에, 우리는 배경색을 변경 가능하도록 하기로 합의를 봤고 옵션은 총 5개 색상이었다. 멍청한 결정이었다. 앞서 말했듯, 우리는 수많은 실수를 저질렀다. 우리는 실제로 5년 정도 실패를 거듭하고 나서야 제품 개발 사이클을 제대로 알 수 있게 되었다.

 

첫째, 우리는 3개월마다 제품을 릴리즈했는데, 웹사이트 프로덕트로서 끔찍한 릴리즈 주기였다. 둘째, 우리는 개발 회의를 해놓고서 아무것도 기록해 두지 않았다. 그래서 서로 기억하는 내용이 달라져서 언쟁을 벌이기도 했다. 그 결과, 개발 주기마다 첫번째 달에는 우리가 원하는 방향과 조금 다른 버전을 개발하게 되었는데, 제품 스펙을 작성하지 않았기 때문이었다. 그리고 첫째 달이 거의 끝나갈 즈음, 우리 중 하나는 "야, 잠깐. 우리는 같은 걸 개발하고 있는 게 아닌 것 같아." 같은 말을 했다. 그러곤 우리는 또 다른 개발 회의를 진행했는데, 물론 아무도 내용을 기록하지 않았고, 두번째 달에 돌입했다. 개발 주기의 2/3, 즉 2개월을 사용한 시점에서 생산성이 유효했던 기간은 3주였고, 나머지 5주는 우리가 내다버린 시간이었다. 그리고 우리는 개발하고 있는 기능에 갑자기 회의감을 느끼고선, "좋아, 이건 그만두자. 그냥 더 똥같은 버전을 만들어보자." 식으로 되었다. 그렇게 개발 주기의 마지막 1달을 썼다. 이러한 3달짜리 개발 주기가 진행되는 동안, 누군가 좋거나, 새롭거나, 흥미로운 아이디어를 떠올려도 "우리는 지금 다른 거 개발하고 있잖아, 그냥 어디다 적어 놔. 일단 지금 하고 있는 것부터 끝내자고."식으로 대응하기 일쑤였다.

 

이렇게 3달짜리 개발 주기가 끝나갈 때쯤, 우리는 세 달에 걸쳐 만든 허접하고 꼴도 보기 싫은 기능에 진절머리가 났고, 그것을 반복적으로 개선하고자 하는 생각은 눈꼽만큼도 없었다. 뭐가 됐든 일단 런칭하고, 올바르게 사람들이 사용하지 않으면 우리는 회사를 구원할 새로운 기능을 브레인스토밍으로 도출했다. 이것은 잘못된 회사 운영이다. 말할 수 없이 끔찍한 방식이다. 나는 Justin.tv를 오늘날의 Twitch로 발전시켰던 핵심적인 제품 의사결정이 무엇이었을까에 대해 Jeff와 이야기를 나눴는데, 그것은 비디오를 화면 좌측에, 채팅창을 우측에 배치한 것이었다. 우리는 2006년에 그 결정을 내렸다. 그리고 2018년 현재까지 이 방식은 변하지 않았다. 제품 의사결정 대부분은 끔찍했고 오늘날 Tiwtch에서 그 흔적조차 찾을 수 없는데, 모두 위와 같은 잘못된 프로세스에서 나온 것들이기 때문이었다. 만약 당신의 프로세스가 언쟁, 제품 스펙을 작성하지 않는 것, 긴 개발 주기를 중심으로 돌아가고 있다면 당신은 100% 잘못하고 있는 것이다.

 

내가 여러분에게 주고자 하는 것은 우리가 어떻게 문제를 해결해야 하는지를 발견해 낸 방법론 모델이다. 당신은 원하는 만큼만 취사선택할 수 있지만, 내가 이야기한 문제 증상을 겪고 있고 그것을 해결하지 않는다면 당신의 조직 생산성은 매우 낮은 상태로 유지될 것이다. 첫째, 당신은 회사가 얼마나 일을 잘 하고 있는지를 반영하는 숫자를 추적 가능하게 하는 숫자가 필요하다. 거의 항상, 당신이 고객에게 요금을 청구하게 된다면 그 숫자는 매출 지표일 것이다. 거의 항상, 당신이 페이스북처럼 고객에게 요금을 청구하지 않는다면 그 숫자는 고객이 얼마나 자주 제품을 사용하는지, DAU와 같은 사용 지표일 것이다. 많은 사람들은 이러한 지표를 비즈니스 생산성을 확인하기 위해서라고 생각하지 않는다. 그들 중 1%는 맞을 수도 있지만 99%의 경우는 틀릴 것이다. KPI가 무엇이 되었든, 당신은 그것을 측정하고 있어야 하며, 회사의 모든 사람들이 매일매일 그 지표를 확인할 수 있도록 해라. 잘 보이는 스크린에 써붙여 두는 것도 좋은 방법이다. 만약 투자자가 당신의 KPI가 무엇인지 묻는다면, 당신은 그것이 무엇이며 측정되는 방식과 기준에 대해서만이 아니라, 우리가 처음 시작할 때 얼마였고 세 달 전엔 얼마였으며 현재는 얼마인지 말할 수 있어야만 한다. 바로 이 내용이 테이블 위에 올라가야만 한다. 

 

다음으로 우리가 해야 하는 것은, 제품 책임자로서 회의에 들어가 "우리가 이번 개발 주기에서 개선하고자 하는 KPI는 이것입니다"라고 말하는 것이다. Socialcam에서 최우선 KPI는 DAU였다. 그리고 DAU에 기여하는 세 가지 지표는 1) 신규 사용자 숫자, 2) 기존 사용자 재방문 횟수, 3) 신규 생성된 컨텐츠 갯수였다. 우리는 반복적으로 진행되는 개발 주기 각각의 목표는 이 세 가지 중 올바른 방향으로 움직이는 것을 목적으로 삼았다.

 

Brainstorm

 

그리고 우리는 매번 개발 주기가 끝날 때마다 약 2시간에 걸친 오픈 브레인스토밍을 진행했다. 이것은 진정한 의미에서의 브레인스토밍이었는데, 일반적으로 생각하는 "이건 어때?" "그 아이디어는 멍청해." 방식의 브레인스토밍이 아니라 떠오르는 모든 것을 일단 보드에 적어나가는 방식이었다. 이러한 진짜 브레인스토밍의 멋진 점이 있었다면, 참여하는 모든 사람들의 노트북에는 Mixpanel이 항상 띄워져 있었다는 사실이다. 그래서 누군가 어떤 아이디어를 떠올리면, Mixpanel에서 지표를 확인해 보고 아이디어의 실현가능성이나 가설의 진위여부를 확인할 수 있었다. 아이디어를 보드에 실제로 적어나가는 것은 놀랄 정도로 가치가 있다. 모든 사람들이 원하는 기능을 개발할 수는 없겠지만, 당신의 아이디어가 일단은 보드 위에 적힌다는 것은 그렇지 않은 경우보다 훨씬 기분을 낫게 만든다. 사람들은 물론 그들의 아이디어가 격추되면 기분이 나빠진다. 직원들이 아이디어의 발상과 검토에 있어 기분이 나빠질 일이 없게 하는 것은 CEO의 일이다. 직원들의 아이디어를 반박하는 것이 CEO가 할 일이라고 착각하는 사람들도 있다. 그렇지 않다. 당신의 비즈니스에 하나도 도움이 되지 않을 것이다.

 

전문가가 말하는 브레인스토밍 기본 원칙 11가지 - Wishket

 

Easy / Medium / Hard

 

우리 회사에서는 모든 임직원이 브레인스토밍에 참여했으며, 초창기엔 고작 4명이었으니 어려울 것이 없었다. 이후 숫자가 늘어나면서 우리는 easy, medium, hard라고 불리는 것을 했다. 우리의 브레인스토밍은 실제로 세 개의 카테고리로 구분하여 진행되었다:

• 새로운 기능 and/or 기존 기능 개선(iterations on existing ones)
• 버그 픽스 and/or 유지보수 관련
• 테스트 (AB 테스트 등)

우리는 떠오르는 아이디어를 세 개 카테고리로 구분하여 보드에 적어나갔다. 모든 아이디어가 적힌 다음에는 easy, medium, hard를 진행했다.

• Hard = 엔지니어 1명이 개발 주기 대부분을 작업해야 함
• Medium = 엔지니어 1명이 1-2일을 작업해야 함
• Easy = 엔지니어 1명이 1일 미만을 작업해야 함

예상 리소스의 측정은 극도로 중요하다. 여기서 교육을 듣는 여러분 중 코드를 작성할 줄 모르는 사람은 얼마나 되는가? 코드를 작성할 줄 모른다면 당신의 아이디어가 구현하기 어려운지 쉬운지를 가늠하는 것은 무척 어렵다. 따라서 개발 리소스를 가늠하는 스킬은 경험적으로 쌓아나가야만 한다. 또 이러한 리소스 측정 프로세스는 당신에게 배움을 주는 것이기도 하다. 일반적으로 쉬운 아이디어는 개발이 빠르고, 어려운 아이디어는 개발이 느리다. 그러나 당신이 가진 가장 어려운 아이디어에서 쓸모없으면서 개발 난이도만 높이는 요소를 걷어낼 수 있다면, 가장 어려운 아이디어를 쉬운 아이디어로 탈바꿈시킬 수 있다. 또한 대부분의 경우 어려운 아이디어에는 쓸모없는데 구현만 어렵게 하는 요소가 반드시 내포되어 있다. 그래서 이것은 팀 전체를 교육하는 과정이면서 동시에 cross functional한 팀이 되어가는 과정이 된다. 그래서 누군가의 아이디어는 비디오 시스템 측면에서 매우 어려운 것일 수 있지만, 다른 팀원이 웹 기능으로 접근하면 매우 쉬운 아이디어로 바꿀 수 있음을 캐치할 수 있게 된다. 이것이 기본적으로 팀 전체에게 easy, medium, hard를 교육하는 과정의 효과다.

 

이것은 또한 새로운 아이디어들을 판단하는 목표 기준을 만들어낸다. 직원 개개인의 논쟁 기술을 바탕으로 하는 것이 아니라, 이런 식으로 진행될 수 있게 된다 - "네 아이디어는 무척 구현하기 어려운 데다가, Mixpanel에서 확인해 보니 그다지 지표를 움직일 수 없을 것으로 보여. 반면, 다른 직원의 아이디어는 엄청 구현하기 쉬우면서도 지표도 크게 움직일 가능성이 있어."처럼 말이다.

 

Decide

 

그 다음으로 하는 것은 "hard부터 결정하기"다. 우리는 일단 모든 hard 카테고리의 아이디어를 보고, "어느 것이 KPI에 가장 큰 임팩트를 만들어낼까?"를 묻는다. 그 다음은 medium, 마지막으로 easy로 넘어간다. 흥미로운 점은 단순히 모든 아이디어를 세 개의 카테고리로 구분하여 보드에 적는 것만으로도 쓸데없는 기싸움을 거의 없앨 수 있다는 것이다. 왜냐하면 첫째, 당신은 당신의 아이디어가 최소한 검토되었음을 알 수 있게 된다. 둘째, 당신은 아이디어가 임팩트와 개발난이도를 기준으로 평가되는 것을 직접 보고 듣는다. 셋째, 좋은 아이디어를 쏟아낼수록 자신의 아이디어 중 하나 정도는 채택될 가능성이 높다. 당신이 마음에 드는 쉬운 아이디어를 찾는 것은 그렇게 어렵지 않으며, 이것이 통과된다면 당신이 낸 어려운 아이디어가 버려진대도 기분은 여전히 괜찮을 것이다.

 

Written spec

 

다음 단계에서 당신은 기능 명세를 작성해야만 한다. 이 단계에서 거의 모든 팀원들이 애를 먹는다. 이 단계 때문에 개발 회의가 4시간까지도 이어지기도 하며, 아무도 좋아하지 않는다. 당신은 Socialcam에 비디오 필터를 추가한다는 것이 무엇을 의미하는지, Justin.tv와 Twitch에서 사람들이 서로 채팅할 수 있게 만드는 것은 무엇을 의미하는지, 그리고 구체적으로 어떻게 목적을 달성하게 되는지를 작성해야 한다. 이것은 너무나도 중요하다. 이 단계가 끝나면, 당신은 팀에게 업무를 할당할 수 있게 된다. 우리는 Socialcam에서 이러한 개발 주기를 2주 단위로 돌렸는데, 그 시절에는 앱스토어에 앱을 배포하려면 지금보다 시간이 더 오래 걸렸기 때문이었다. 앱이 아니라 순수 웹 프로덕트를 만들고 있다면 1주 단위로도 할 수 있을 것이다.

 

우리는 또 팀원 전체가 마라톤 회의에 거부감을 느끼지 않도록 만들어야 했기에, 위의 개발 회의가 우리가 진행했던 유일한 회의였다. 그래서 이 회의는 2시간이 걸릴 수도, 6시간이 걸릴 수도 있었지만, 대신에 2주라는 기간 동안 다른 어떤 회의도 갖지 않았다. 사실, 코딩을 할 줄 모르는 나에게 최선의 행동은 회의를 제외한 나머지 시간 동안 입을 다물고 있는 것이었는데, 왜냐하면 없던 문제까지 만들어낼 수 있었기 때문이었다. 우리는 바쁘게 일했고, 기능 명세를 작성했고, 마라톤 회의 끝에 모두는 자신이 해야 할 일을 알게 되었다. 개발 기간 도중, 내가 천재적인 아이디어를 떠올리게 된다면 회의에서 결정된 모든 내용을 혼돈 속에 빠트릴 수 있었다. 갑자기 고생해서 쓴 기능 명세가 중요성을 잃고, 다시 보드판으로 돌아가거나 뭔가를 변경하고 수정하게 된다. 나는 우리가 이 모든 과정을 2주마다 반복한다는 사실을 깨달았다. 그래서 나는 아무리 획기적인 아이디어가 떠오르더라도 2주 간 입을 다물고 있다가, 다음 회의에서 그것을 이야기했다. 심지어 그 아이디어는 회의 결과 잘못된 것으로 판명될 수도 있다. 그러니 틀릴 수도 있는 아이디어를 팀에게 설득시키는 데 2주라는 시간은 충분히 기다릴 만한 시간이다. 아무 문제 없다.

 

2주를 단위로 하는 지루한 개발주기를 반복하고 반복하면서 우리는 성공을 거뒀다. 2주를 단위로 우리가 결정한 기능들을 실제로 개발해냈을 때마다 우리는 성취감을 느꼈다. 이러한 사이클링을 반복해 나가면서 팀에 마치 케이던스와 같은 리듬이 생겨나고, 같은 2주 동안 더 많은 것을 해낼 수 있게 되었다. 이 케이던스는 정말 정말 중요한데, 왜냐하면 프로덕트 마켓 핏을 달성하는 데에는 오랜 시간이 걸리기 때문이다.

 

중요한 것은 단 하나, 프로덕트 마켓 핏 by Marc Andreessen

당신은 정말로 많은 것들을 시도하게 될 것이다. 정확히 말하자면, 많은 것들을 반복적으로 테스트하고 개선하게 될 것이다. 그리고 이러한 프로세스에서 재미를 느낄 수 없다면, 당신은 매우 지치게 될 것이다. 케이던스를 만들어내는 것은 반복적인 개발 프로세스를 재미있게 만들어 주는데, 왜냐하면 우리는 목표를 설정하고 그것을 달성하기 위해 노력하기 때문이다. 

 

 

5. Pivot vs. Iterate?

• Pivot = changing the customer and/or the problem (rare)
• Iterate = changing the solution (common)

피봇과 이터레이션. 수많은 YC 스타트업들의 창업자들은 일반적으로 이렇게 말한다, "사람들이 우리 제품을 쓰지 않아요. 벌써 2달이 지났습니다. 피봇을 해야 할 것 같아요." 이런 말을 들을 때마다 나는 정신이 아찔해진다. 당신은 당신의 제품을 한 번도 써보지 않았을지도 모르는 고객을 위한 새로운 제품을 만들고 있는 것이다. 당신은 종종 자신의 지식이나 경험을 지나치게 믿는다. 당신이 무언가를 확실하게 알게 되기까지 2달이 충분한 시간이라고 생각하는 근거는 무엇인가? 만약 당신이 해결하려는 문제에 대한 솔루션을 현실에 소개하는 과정이 2년 정도 걸릴 것이라고 생각하지 않는다면, 당신은 잘못 생각하고 있다. 만약 당신이 2년 미만의 기간 동안 이뤄낸 중요한 진전에 대해 만족스러워 하지 않는다면, 당신은 잘못 생각하고 있다. 당신은 어려운 일을 하고 있다. 정말로 쉬운 일이었다면, 누군가 벌써 해버렸을 것이다.

 

나는 피봇을 고객이나 해결하고자 하는 문제를 바꾸는 것으로 정의한다. 그래서 피봇은 자주 일어나서는 안 된다. 아주 가끔 일어나야 하는 것이다. 많은 경우 피봇은 당신이 아예 새로운 스타트업을 시작해야 한다는 의미로 사용된다. 하지만 당신이 올바른 고객과 올바른 문제를 찾아냈으나 MVP가 잘못 만들어져서 사람들이 쓰지 않은 것일 수도 있다. 그러면 우리에게 필요한 건 기존과 다른 새로운 솔루션이다. MVP는 훌륭했지만 문제를 해결하지는 못했을 수 있다. 새로운 솔루션이 필요한 것이다. 매우 강력한 문제를 겪고 있는 고객에게 제품을 보여줬는데, 그들이 사용하지 않았다. 새로운 솔루션이 필요한 것이다. 

 

의외로 자주 나는 이것이 반대로 일어나는 것을 보게 된다. 사람들은 솔루션을 먼저 구상하고, 그들이 생각한 고객들이 제품을 좋아해 주지 않으면, 실제로는 전혀 다른 문제를 겪고 있는 엉뚱한 고객을 무작위로 찾아나선다. 그리고 그들은 솔루션을 한 번 검토하는 시늉만 하는데, 왜냐하면 그들은 그 솔루션이 가장 천재적인 부분이라고 생각하기 때문이다. 나는 바로 그 천재적인 부분이 문제라고 생각한다. 나는 다른 사람들이 발견하지 못했던 문제를 파악해내는 것이 진정 천재적인 부분이라고 생각한다. 그렇지 않은가? 페이스북은 처음엔 소셜 네트워킹 서비스가 아니었고, 구글은 처음엔 검색 엔진이 아니었다. 그들의 천재성은, 그들의 제품이 당시 제품을 써 본 사람들의 문제를 해결하지 못했음을 간파한 것에 있었다. 그들은 문제를 더 잘 해결할 방법을 찾았고, 거대한 기업으로 발돋움했다. 그들의 천재성은 "오, 우리는 이 멋진 제품을 만들었어. 이걸 누가 원할지 한 번 찾아 보자고." 같은 것이 아니었다.

 

5-1. Fake Steve Jobs vs. Real Steve Jobs

위 내용을 요약하기 위해 나는 가짜 스티브 잡스와 진짜 스티브 잡스 이야기를 해 주고 싶다. 많은 사람들은 자신이 따라가고 있는 롤모델이 스티브 잡스라고 생각하지만, 스티브 잡스가 누구인가 자체를 잘못 생각하고 있다. 그들은 스티브 잡스가 머릿속으로 꿈꾸던 완벽한 아이디어를 세상에 실현시켰다고 생각한다. 그러면서 아이폰을 완벽한 예시로 생각하는 것을 보면 헛웃음이 나온다. 그들이 보고 있는 것은 오늘날, 지금 현재의 아이폰이다. 지금 당신이 쥔 아이폰은 마치 마법같은 제품이다. 최초의 아이폰은 거의 모든 측면에서 구데기였다. 그런데 그들은 스티브 잡스를 고된 반복적 개선 작업도 없이 그저 완벽에 가까운 상상을 실현한 사람으로 생각한다. 아니다. 스티브 잡스는 제품의 모든 측면, 모든 단계에서 iteration을 수행했다.

 

그래서 나는 그 사람들에게 최초의 아이폰에 대해 얘기해 주는 것을 좋아한다. 3G가 표준이 되기도 전 시절, 아주 처음의 아이폰 말이다. 예를 들어 당신은 훌륭한 인터넷 브라우저를 갖고 있지만, 그것을 오직 한 종류의 디바이스에서만 사용할 수 있다면 썩 기분이 좋지 않을 것이다. 오, 당신은 이 기기가 없나 보네요. 기기를 바꾸세요. 배터리 수명은 끔찍했고, 화면은 툭하면 금이 갔다. 앱스토어도, 앱도 없었다. 그것이 최초의 아이폰이다. 모든 이들은 그 아이폰을 잊었지만 말이다. 그래서 만약 당신이 "제품은 이렇게 개발되어야 합니다, 왜냐하면 내가 그것을 원하니까요. 고객과 모든 사람들은 엿이나 먹으라고 하세요. 당신도 엿이나 먹으세요. 내가 시키는 대로 제품을 만드세요."라고 소리치는 사람이라면, 당신은 가짜 스티브 잡스인 것이다.

 

진짜 스티브 잡스는 혁신적이지만 전체적으로 허접한 MVP를 출시하고, 당신의 주머니에 있는 "개쩌는" 아이폰의 모습이 되기까지 수없는 개선 작업을 반복했던 사람이다. 진짜 스티브 잡스는 반복적으로 솔루션을 바꾸고, 개선하며 고객과 대화하는 사람이다. 가짜 스티브 잡스는 머릿속으로 꿈만 구고 예술을 하려고 드는 사람이다. 가짜 스티브 잡스가 되지 말기를 바란다.

 

창업가 정신의 9할은 지루한 테스트의 반복이다, 린 스타트업(Lean Startup)

 

자, 다시 내가 처음에 말했던 내용으로 돌아가 보자. 이 모든 규칙들을 알고 있는 유일한 이유는 우리가 그것들을 지키지 않았기 때문이었다. Justin.tv와 Twitch가 가졌던 유일한 장점이란 제품에 인생을 바친 강한 기술 팀과, 낮은 번 레이트(burn rate) 뿐이었다. 우리가 Twitch를 시작했을 때 매우 흥미로운 일이 일어났다. 게이머들이 우리 제품에 거의 하루 종일 머무르고 있었던 것이었다. Justin.tv 초창기부터 게이머들은 스트리밍을 해 왔었다. 그들은 수 년에 걸쳐 일관되게 전체 트래픽의 20% 정도를 차지했다. 우리는 그들을 무시했다. 무시했고, 무시했고, 또 무시했다. 그러나 그들은 계속해서 제품을 이용했다. 매년 끈질기게 제품을 이용하고 있었으니, 정말 말도 못하게 격렬한 문제를 겪고 있었음에 틀림없었다.

 

우리가 게이머들과 대화를 나누기 시작했을 무렵, Twitch 역사상 가장 거대한 변화가 일어났다. 그리고 그것은 우리가 다른 사용자들과 대화하는 방식과는 달랐다. Justin.tv 초창기 우리는 어떤 사용자와도 대화를 나누지 않았다. 우리는 3달짜리 미친 개발 주기를 돌리고 있었고, 그것을 사용자와 대화하면서 진행할 수는 없었다. 그래서 우리가 가장 처음 했던 것은 말 그대로 게이머들에게 "당신이 필요한 게 뭡니까?"를 묻는 것이었다. 재밌는 건, 우리는 그들을 위해 그다지 특별한 것들을 개발하지 않았다는 것이다. 그들이 요구했던 건 사소하고 작은 것들이었다. "오, 랙 걸려서 방송이 안 보이면 정말 짜증나죠." 같은 것들. 그들은 우리가 게이머를 위해 뭔가를 만들려고 한다는 사실에 크게 흥분한 것처럼 보였다. 인터넷 세상의 그 누구도 이 게이머들을 위한 무언가를 만들어주지 않았던 것이다. 당신이 어느 기업에게 기능을 좀 만들어 달라고 말을 건네고 그 기능이 실제로 만들어진 적이 있었는가? 당신이 페이스북에 뭔가를 만들어 달라고 하면 페이스북에 그 기능이 생기는가? 아니, 그런 일은 일어나지 않는다!

 

제품의 열성적인 사용자와 대화하고, 그들이 원하는 것을 만들어주는 것이야말로 스타트업으로서 당신이 제공할 수 있는 가장 마법적인 경험 중 하나다. 그들이 원하는 것을 만들고, 당신은 그냥 "여기요." 하는 것이다. 그러면 그들은 그 기능이 아무리 보잘것 없는 것이라 하더라도 당신의 제품과 사랑에 빠지는 것이다. 지금 현재의 Twitch는 오른쪽에 채팅창에 있고 왼편에 비디오가 나온다. 옛날과 변한 게 없다. 이러한 프로세스의 대단한 점은, 열성적인 고객을 위해 뭔가를 만들면 그들은 친구들에게 제품을 전파한다는 사실이다. 그것이 커다란 변화를 만들어냈다. 우리가 기술적으로 뛰어난 팀이 아니었고, 우리의 번 레이트가 낮지 않았으며, 우리가 제품에 목숨을 건 사람이 아니었다면, 이 지점까지 결코 도달할 수 없었을 것이다. Justin.tv의 첫 5년 간의 여정을 거쳐, 우리의 기업가치는 $0에서 $24,000,000으로 치솟았다. 그리고 그 다음 3년이 지났을 때 기업가치는 십억 달러가 되었다. 이것은 소프트웨어가 올바른 고객을 찾아냈을 때 만들어낼 수 있는 결과다. 

 

---

 

이후 진행된 QnA는 분량의 압박으로, 영문 텍스트를 긁었습니다. 실제 창업자들이 질문한 내용인 만큼, 보다 현실적이고 흥미로운 내용이니 한 번 읽어보시는 것을 추천드립니다.

 

Speaker 3:

So you mentioned that you should try to charge early [inaudible] discounts early, but if  you make or bought a product without having to make it afraid out and monetize  with some premium content, what should you do? 

 

Michael Seibel:

So the question is put it more generally. Should you be going free if your  final idea for a product is to be free? What I would say is this.  If your users are users who you never plan to charge, then it's totally fine  for you to be free. But if you do plan to charge them in some  way, it's really helpful to charge them as soon as possible, because you want to  know whether or not they're willing to pay. And certainly if their business depends on  it, it's especially helpful to charge them. So that's the measure that I would use.  And they're all kinds of little tweaks and so and so forth, but at a  high level, do you ever plan to charge them? I'd charge them. If you never  plan to charge them, you can plan to monetize based on ads, which is really  usually the way you never plan to charge, is you monetize with ads. If you're  not going to monetize with ads, you probably should start charging them. All right, next  question. Front. 

 

Speaker 4:

Thank you for sharing all this. You mentioned that the ... Almost always the best  revenue or the best cake adding cash is revenue. 

 

Michael Seibel:

Yep. 

 

Speaker 4:

Let's say I'm launched. I'm early based and I'm trying to get that first sale.  I know for a few weeks it's going to be hard to get that to  go from zero to anything. Should I still be writing revenue down, or should I  try something- 

 

Michael Seibel:

Revenue. If your metric ... If your KPI is metric. Yeah, yeah, yeah [inaudible] do that. If your KPI is revenue and the number is zero, should you still be tracking that as your top line KPI? The short answer is yes. You should be depressed looking at that number every week and to ... That's the answer. I want  to be clear, like I said with Socialcam, right, there are contributing numbers to that,  right? And so whereas, DAUs was our top line metric, right? We also ... The  things we thought contributed to that: new content, new users, retained users, those numbers we  can move. So if you're in a sales type business, your KPI number one revenue,  if it's zero, that should fuck you in the face. Zero. Zero. Zero. Horrible. But  then you should ask yourself maybe your three other metrics are how many conversations did  we have this week? How many people are in contracting? How many people are in onboarding? Right? And those can be your three numbers that will ... If those numbers  move, you expect the revenue number to move. And they can keep you motivated. But  your top line KPIs, no bullshit. Absolutely no bullshit. Okay. 

 

Speaker 4:

Thank you. 

 

Speaker 5:

We're a hardware company, pre-launch, and so our users, our target market, experience our problem  five to 900 times a day, and the intensity is can we pay our rent  or not? But we'd like to offer pre-sales as a way of getting the product  to market. Do you guys have any tips on doing that? 

 

Michael Seibel:

Do we have any tips on pre-sales? What I would say is that there are  many, many tips on pre-sales. I would email some founders who've done it before. That's  one of my best tip is to email them and ask them what they did.  The number one mistake I see with pre-sales is discounting. The number one mistake is  that basically, especially hardware founders, will misunderstand how much they need to charge, so they  don't lose money. And so their presale becomes their death. So I'd avoid that. All  right, two more quickly. In the way back. 

 

Speaker 6:

Okay, you mentioned having a slow burn. What was the hardest part of that? And  how did you- 

 

Michael Seibel:

What was the hardest part of having a slow burn. Well, we were young, so  it wasn't hard at all. We were living like we lived in dorms. I think  it's a lot harder now, right, I've a kid, I've got a wife, got an  apartment, got a car. It'd be really hard now. And so I think really the  hard part about slow burn is can you adjust your lifestyle if you've already leveled  it up? And if you haven't leveled up your lifestyle yet, and you're still working  ... If you're young and you're still working at a company that's paying you well,  not leveling up your lifestyle is a big way to stay ready to do a  startup. Adding on the mortgages and the cars and the vacations makes it a lot  harder. I just know a lot of people how never could come back from that.  Absolutely never. In the back. 

 

Speaker 7:

Yeah, can you talk a little bit about going from beta to early MVP when  you know you're sort of there? 

 

Michael Seibel:

How do you go from beta to early MVP? I don't really know what those distinctions are. All I know is are people using your product? Yes. No. If people  are not using your product, get to the point where people are using your product  extremely quickly. Once people are using your product, there's all different labels for it, beta,  pre-launch, alpha, blah, blah, blah, who cares. Right? It's just that's the dividing line. Like  are people using your product? The next question is are you actually solving their problem?  That's the next question, not are we following this line of launching things? Most YC companies will launch many, many, many times. So that progression isn't really that important. Are  people using your product? 

 

Speaker 7:

Yeah, they are. 

 

Michael Seibel:

Great. Bam. You're launched. Congratulations. Call it whatever you want. All right, one more. 

 

Speaker 8:

Here you go. 

 

Speaker 9:

Yeah. I have a question regarding how to select [inaudible] . You already mentioned an  app that we should follow the metrics, but I think that we have a pool  of two or three [inaudible] , but each one wants something different. What will it  be [inaudible] which one will in fact [inaudible] ? 

 

Michael Seibel:

This is a great question. And I'll have an unsatisfying answer. The question is basically  how do we figure out what to build next? Here's my answer. The reason why  you have a product development cycle is so that you can work on multiple things.  Usually there isn't a right answer. Usually all of the things that you want to  build won't work. So what you need to do is you need to create a process in your company to build things quickly, so that you can actually see whether  they'll work or not, and then you can iterate them from there. So it's far more important to have a technically talented team that can build MVPs quickly in a  non-frustrating way, and then measure the results, then it is to be a super genius  who can imagine what's going to happen in the future without actually knowing. Now, in  the big picture you have to have that imagination. For your vision for where it's  going to be 10 years from now, you have to have that imagination. For the  little technical, tactical move in the next three months, it's really hard to nail those.  If you have a process that can rip out things quickly, and then only iterate  the things that are working, that'll serve you far better. Our mistake was that at  Justin.tv. It was thinking every time we've got the home run. Let's only swing for  home runs. And of course, it would take three months to do it, because we've  got to make it perfect, right? And then the whole spiral of death.

 

All right,  the last I'll say is my email address is mmichael@ycombinator.com. Strangely I tell people that  I answer every email, and people mostly don't believe me. And the ones who do,  email me, and I reply. And so everyone I talk to, and everyone online, there's  really only two categories of people, the people who don't believe me, in which case great, continue your lives, and the people who will believe me, and if you need help, they'll email, and I will try to help you the best I can. It's really that simple. You don't need to have networked with me. Y Combinator is fairly easy to spell and so is Michael, so you should be able to figure that  out. Thank you.