들어가며

소마 멘토링 중, '아이디에이션(Ideation) & 고객 개발(Customer Development)' 라는 제목의 멘토링을 신청했다.
다른 멘토링과 달리 숙제가 있었는데, 미국 Y Combinator 창업자 Paul Graham이 쓴 'Do Things that Don't Scale'이라는 아티클을 읽고, 소감과 함께 자신의 아이디어에 어떻게 반영할 것인지 남기는 것이다.

원문은 영어지만, 멘토님의 친구이신 신대명 님이 번역해놓은 글이 있어서 해당 글로 읽었다.

읽으며 앞으로 소마에서 프로젝트를 할 때, 기획하고 제품을 개발함에 있어 떠올리면 좋을만한 문장을 기록했다.
그리고 중간중간 느낀 점도 기록했다.

기록하고 싶은 문장들

• 물론 자체적으로 성장하는 스타트업이 몇 있지만, 많은 경우 그들의 비즈니스가 잘 굴러가기까지 계속적인 일종의 노가다 작업이 필요하다.

• 누군가가 Stripe을 한번 사용해본다고 대답하면 “컴퓨터 줘봐” 라고 하며 그 자리에서 서비스를 설치해줬다.

• 창업자가 사용자를 데려오기 위해 손수 나서지 않는 데에는 크게 두 가지 이유가 있다. 첫 번째는 부끄러움과 게으름 때문이다. 이들은 자신의 서비스를 싫어할지도 모르는 낯선 사람들과 많은 이야기를 나누는 것보다 집에 앉아 코딩을 하려 한다. 하지만 스타트업이 성공하기 위해서는 최소 한 명의 창업자가(주로 CEO) 세일즈와 마케팅에 많은 시간을 써야만 한다.

• 또 다른 이유는 바로 데려올 수 있는 사용자 수가 매우 적어보이기 때문이다. 이들이 저지르는 실수는 바로 복리의 힘을 간과한다는 점이다.

• 하지만 만약 시장이 존재한다면, 처음엔 손수 사용자를 데려오는 것으로 시작해서 점점 손이 덜가는 방법으로 바꿀 수 있을 것이다.

• 만약 기자나 아는체하는 사람들이 당신의 스타트업을 가치 없다고 하더라도 그들은 항상 틀리기 때문에 별 문제 되지 않는다. → 타인의 피드백을 듣지 않는 태도가 아닐까 싶은 생각이 순간 들었다. 하지만, 이 글의 요지는 문제를 풀려는 본인도 그런 마인드셋을 가지는 순간 실패할 수밖에 없다는 걸 말하려고 한다. 중요한 것은 반드시 성공한다는 마인드셋과 증명하는 것이라고 생각이 든다.

• 손수 사용자를 모으려고 할 때 어떻게 사용자를 찾는가? 만약 당신이 자신이 겪는 문제점을 해결하기 위해 무언가를 만들었다면, 간단하게 주위에 있는 자신과 비슷한 친구들을 찾기만 하면 된다. 그렇지 않으면, 서비스를 사용할만한 사람이 많은 곳에 홍보하기 위해 더 많은 고생을 해야만 할 것이다.

• 사용자를 데려오는 것 뿐만 아니라 그들을 즐겁게 만드는 것에도 특별한 방법을 사용해야 한다.

• 왜 우리가 이걸 스타트업에게 가르쳐야만 할까? 왜 이것이 창업자들에게 직관직이지 않을까?

• 이유 첫 번째는 많은 스타트업 창업자가 엔지니어로써 훈련을 받아왔고, 고객 응대는 엔지니어 훈련의 일부가 아니기 때문이다.

• 또 다른 이유는 바로 이 일이 학장 가능하지 않다는 걱정 때문이다. 초기 스타트업이 이런 걱정을 하고 있을 때, 나는 어차피 지금 상태에서는 잃을 것도 없다고 지적을 한다. 노가다 작업을 통해 소비자를 만족시키는 일이 당신이 생각한 것보다 더 확장된다는 것을 알 수 있을 것이다. 왜냐하면, 하다 보면 처음 예상했던 것보다 더 잘 확장할 수 있는 방법을 찾게 되고, 그때쯤엔 사용자를 즐겁게 하는 일이 이미 회사 문화에 스며들기 때문이다.

• 창업자들이 얼마나 자신의 사용자들에게 귀를 기울일 수 있는지 깨닫지 못하는 가장 큰 이유는 사용자에게 귀를 기울이는 경험을 해보지 못했기 때문이다.

• 현재 존재하는 관례들이 UX의 상한이 아니란 것을 깨달으면, 사용자들을 얼마나 더 행복하게 해줄 수 있는지에 대해 생각해볼 수 있다.

• 만약 당신이 사용자를 얼마나 신경쓰는지에서 차이를 만든다면 초기에 불완전하고 문제 있는 제품으로도 끝내주는 UX를 줄 수 있다. (아니 줘야만 한다.)

• 초기 사용자와의 과도한 관계는 성장하기 위해 사용할 수 있는 기술 정도가 아니다. 가장 성공적인 스타트업들에게 사용자와의 과도한 관계는 제품을 좋게 만드는 필수적인 피드백 과정의 부분이다.

• 더 나은 제품을 만드는 것은 이와 동시에 할 수 있는 일이다. 만약 당신이 필요한 무언가를 만들며 가장 성공적인 스타트업이 취했던 방법으로 시작한다 하더라도, 당신이 만든 첫 번째 버전은 좋을 수가 없다. 실수했을 때 타격이 큰 영역을 제외하고는, 처음부터 완벽함을 추구하지 않는 것이 보통 더 좋다.

• **특히 소프트웨어 분야에선, 사용할 수 있는 정도가 되는 한 제품을 최대한 빠르게 출시하고 사용자가 어떻게 사용하는지 보는 것이 최고다. **완벽주의는 미루는 것에 대한 변명이다. 심지어 자기 자신을 위해서 만든 제품이라도 항상 초기 버전은 잘못 되어 있기 때문에 빠르게 출시해서 사용자 피드백을 받아라.

• 극초기 사용자들에게 직접적으로 관계를 맺으며 받는 피드백은 당신이 얻을 수 있는 최고의 것이다.

• 확장 가능한 좋은 요령 중 하나로, 일부러 좁은 시장을 타겟하는 것이 있다. 이것이 바로 페이스북이 한 일이다. 처음에 페이스북은 하버드 학생들을 위한 것이었다. 그 형태로는 오직 수 천명의 잠재 사용자가 있는 시장을 가질 수 있었다.

• 큰 시장을 타겟하는 어떠한 스타트업이더라도 대게 작은 시장 타겟부터 시작해야 한다. 자신이 타겟하는 시장에서 빠르게 많은 수의 사용자를 모을 수 있는 부분적인 시장이 있는지 알아보는 것은 항상 가치가 있는 일이다.

• 하드웨어 스타트업에서 확장하지 못하는 일을 하는 것에 대한 한 가지 형태가 있는데, 우리는 이를 “Meraki를 해내라”고 부른다.

• Meraki의 창업자는 정말 확장 가능하지 않은 일을 하며 스타트업을 시작했는데, 바로 자체적으로 라우터를 조립하는 일이었다.

• 초기 사용자는 당신 제품의 틀이 되는 역할을 한다. 계속해서 그들의 요구에 완벽하게 맞추기 위해 변형하다보면, 다른 사용자들도 원하는 제품을 만든 것을 발견할 수 있을 것이다.

• 초기에 미적지근한 반응을 보이는 사용자들을 획득하기 위한 또 다른 컨설팅과 같은 테크닉은 그들을 대신해서 자신이 직접 제품을 사용해보는 것이다. 그 과정에서 사용자가 우리 제품을 사용했을 때 어떤 느낌을 받을지 배울 수 있게 해준다.

• 더 극단적인 경우는 소프트웨어를 사용하는게 아니라, 자신이 소프트웨어가 되는 것이다. 당신이 소수의 사용자만 가지고 있을때, 수작업으로 계획을 실행하며 나중에 자동화할 수 있다. 이것은 서비스 런칭을 더 빠르게 해주며, 수작업의 굴레에서 벗어나 자동화를 해야만 할 때가 오면 그간 해온 경험들이 체화되어 자동화를 위해 정확히 어떤 것들을 만들어야 하는지 알 수 있을 것이다. → 오늘 박순영 멘토님의 ‘0에서 1,000만까지: 뻗지 않는 단계 별 스타트업 실전 아키텍처 A to Z’ 특강을 들었다. 해당 내용에서도 초기(사용자가 0명) 단계에서는 배포를 수작업으로 하라고 하셨다. 지금까지의 나는 관성적으로 GitHub Actions를 이용해 CI/CD를 구축했다. 하지만, 이 또한 사용자 반응을 빠르게 보기 위해서는 병목이다. 물론 AI를 이용하면 매우 빠르게 CI/CD를 구축할 순 있지만, 이번 프로젝트에서는 이 부분을 의식하며 진행해봐야겠다.

• 몇몇 스타트업은 처음에 모든 부분을 수작업으로 할 수 있다. 만약 해결해야만 하는 문제를 가진 누군가를 찾아 그 문제를 수작업으로 해결할 수 있다면, 할 수 있는 한 해결해본 후, 병목이 되는 부분을 점진적으로 자동화해라. → 일론 머스크의 5단계 원칙 중, 마지막 원칙이 ‘자동화해라’이다. 오히려 첫 번째는 ‘설계 요구사항이 정말 맞는 것인지 검증해라’ 이다. 엔지니어 특성 상, 이 부분을 간과하고 바로 개발로 착수하기 쉽다. 나 또한 그렇다. 그리고 아마 대부분의 연수생도 그럴 것이라고 예상된다. 이 내용을 팀이 꾸려진다면 반드시 공유해야겠다.

• 주로 효과가 없는 초기 전략 중 하나에 관해 이야기 해줘야 할 것 같다. 바로 대규모 런칭이다. 처음부터 충분히 준비해서 서비스를 런칭해야만 성공할 수 있다고 믿는다.

• 런칭시 필요한 것은 몇몇 초기 핵심 사용자가 전부다. 몇 달 후에 당신이 얼마나 잘하고 있는지는 처음에 몇 명의 사용자가 있었느냐보다 그들을 얼마나 행복하게 만들었나에 달려있다.

• 파트너쉽 또한 대게 효과가 없다. 일반적으로 파트너쉽은 스타트업에서 효과가 없다. 특히, 파트너쉽은 특히 성장을 시작하는 방법으로써 효과가 없다. 큰 회사와의 파트너쉽이 큰 성공을 불러올 수 있다고 생각하는 것이 일반적으로 경험없는 창업자들이 하는 실수다. → 건강기능식품 관련 앱을 운영하는 스타트업에 재직 당시, 벡셀과 협업하여 비타민 제품을 PB 상품으로 만들어 판매했다. 대표님은 벡셀과의 협업을 통해 인지도가 올라갈 것을 기대했지만, 이미 포화 시장인 비타민 시장에 참신함만으로는 사람들을 설득하기 어렵다는 것을 바로 옆에서 봤다.

• 일반적으로 스타트업을 시작하기 위해서는 확장 불가능한 고된 일을 해야만 하므로, 스타트업을 단순한 수치화만으로 생각하는 것을 멈추는 것이 좋다. 수치적인 것 뿐만 아니라 초기에 회사를 키우기 위해 해야만 하는 확장할 수 없는 것들까지 포함한 하나의 벡터 쌍으로 생각하는 노력을 해야 한다.

• 스타트업을 두 요소를 가진 벡터로 다루는 것은 창업자가 두 요소 모두에서 열심히 해야 하는 것을 상기 시켜주는 이점을 가지고 있다.

• 작은 규모일 때에 사용자 획득에 공격적이라면, 회사가 커져서도 아마 계속 공격적일 것이다.

• 만약 네가 직접 사용할 하드웨어를 제조하거나 개발한 소프트웨어를 사용자로서 직접 사용하게 되면, 그러지 않고는 배울 수 없었던 교훈을 배우게 될 것이다. 그리고 가장 중요한 것은 사용자가 많지 않을 때 그들을 만족시키기 위해 최선을 다했다면, 사용자가 많아져도 계속해서 노력할 것이란 것이다.

느낀 점

글 내내 강조하는 것은 '노가다라도 해서 사용자를 모으고 그들을 즐겁게 하는 데 집중하라' 로 느껴진다.

스타트업에서 10개월 동안 개발자로 근무하면서, 약간의 노가다를 했다. 그런데 사용자를 즐겁게 해주진 못했다.
온갖 VoC와 지표로 봤을 때, 사용자는 건강기능식품 검색을 가장 원했다.
하지만 CEO와 PM은 그들이 원하는 제품을 만드는 데 집중했고, 가용 자원을 투자했다.

구글 창구 프로그램 선정, 지역 축제 참가 등.. 대외적으로는 잘나가보였지만, 리텐션은 0.1% 미만이었다.

덕분에 확실하게 느꼈다.
내가 만들고 싶은 걸 만들면 실패한다. 그들이 원하는 제품을 만들어줘야 한다.
그리고 몇 없는 사용자이더라도 그들의 목소리에 귀 기울이고, 그들과 소통해야 한다.

소마에서의 프로젝트는 반드시 특정 집단의 Pain Point를 찾는 것부터 시작할 것이다.
SNS를 통해 사람을 찾을 것이고, 직접 만나 인터뷰도 할 것이다.
그라고 그들의 고통을 진정시켜줄 수 있는 Pain Killer 같은 제품을 빠르게 만들고 출시하고, 그들의 반응을 토대로 제품을 발전해 나갈 것이다.

그리고 또 한 가지, 개발자가 수작업을 하면 이상하게 보는 분위기가 있다.
하지만 이번 프로젝트에서는 일론 머스크의 5원칙을 생각하여 가장 먼저 요구 사항에 집중하고, 필요없는 기능이나 프로세스를 걷어내고, 가장 단순한 설계를 하고, 생산 속도를 증가시키고, 끝에 가서 자동화를 고려하는 방향으로 의식적인 노력을 해보려고 한다.

결론

내가 만들고 싶은 제품을 만들면 망한다.
타인을 위한 소프트웨어를 만들자.