이 글이 담고 있는 내용은
- 2명으로 구성된 소규모 창업팀이 4주 만에 제품을 출시했던 과정
- MVP 테스트 성공과 실패를 판단하는 기준
- MVP 실패를 통해 얻은 레슨런
개발자 없이 사업 아이템 반응 보기
우리 팀은 2인으로 구성된 소규모 창업 팀이다. 우리는 통신 시장에 있는 문제를 짚었고, 개인 전화번호 사용과 개인 정보 노출에 대한 문제를 풀고자 했다. 사업 아이디어를 빨리 검증해 보고자, 함께할 개발자 멤버 한 분을 찾고 있었다. 하지만 아무것도 가진 것 없는 팀에 당장 조인할 멤버를 찾는 것은 쉽지 않았다.
마냥 기다리기보다는 개발 없이 아이디어에 대한 시장 반응을 테스트해 보기로 했다. 수요 확인용 랜딩 페이지와 페이드 마케팅을 기획해 반응을 살펴보았다. 소재에 대한 CTR이 4% 이상 나왔고, 3일간 130명 정도의 사전 예약 신청자를 모았다. 랜딩 페이지 유입 대비 38% 정도의 이용자들이 사전 신청 예약을 한 것이다. 우리는 이 숫자를 보고 아이템에 대한 궁금증이 생겼다. 더 검증해 볼 만한 문제라고 판단했다.
바퀴가 한 개뿐인 거꾸로 달리는 기차를 만들다
우리는 바로 잠재 고객 인터뷰를 진행해 개인 연락과 비즈니스 연락의 분리가 어려운 사람들을 타겟으로 좁혔다. 손쉽게 새로운 연락 채널을 만들어 전화 번호 공개 없이 통화할 수 있는 솔루션을 만들어보고자 했다.
제품도 없고 개발자도 없지만 사전 예약 페이지에 띄워둔 문구, “2월 초에 출시됩니다.” 여전히 개발자 멤버를 찾고 있었지만 어려웠기에, 노코드 솔루션으로 제품을 개발해 볼 생각도 했었다. 하지만 우리가 필요한 기능을 구현하기 위해선 코드 레벨을 만져야 했다. 결국 비개발자인 동료는 직접 코드를 짜보겠다는(?) 생각에 도달하게 되었고 두명이서 MVP를 만들어 보기로했다.
할만하겠는데? 라는 호기로운 시작은 곧 좌절로 바뀌었다. 통신 기술을 포함한 서비스다 보니 우리의 예상보다 고려해야 할 케이스가 너무나도 많았고 기술 난이도가 우리가 가진 것 대비 매우 높았다.
그렇게 우당탕탕 만든 제품은 QA를 할 때마다 버그가 1,000개씩 나왔다. 바퀴가 하나뿐인 거꾸로 달리는 기차를 만드는 기분이랄까. 퀄리티는 모르겠고요. 아무튼 3주 만에 제품을 만들어 출시했습니다.
빠르게 실패 인정하기
출시 후 마케팅 지표와 제품 지표를 확인해 보았고 결과는 꽤 처참했다. 소규모 팀이기에 우리는 가파르게 성장시킬 수 있는 제품을 찾아야만 했다. 리텐션을 최소 30% 이상 높게 유지할 가능성이 있는 아이템을 찾는 게 목표였다. 이번 아이템은 마케팅 반응에 있어서도 기대보다 낮은 수치와 비용이었고, 제품 지표 또한 목표에 한참 미달한 수치였다.
“우리는 이걸 실패라고 부르기로 했어요.”
물론 제품이 미숙해서 또는 솔루션의 방향성을 잘못 잡아서 등 여러 가지 원인이 있을 수 있지만 이 문제 자체를 더 파본다고 하더라도 우리에게 필요한 “폭발적인 성장”은 만들기 어렵다고 판단했다. 그리고 미련없이 이 프로젝트를 접었다.
4주간의 가설 검증 과정을 통해 얻은 레슨런
한 아이템의 반응을 살펴보고, 제품을 만들어 Go, Stop을 판단하는 데까지 약 4주가 걸렸다. 이 제품은 실패한 제품이 되었지만, 이 프로젝트를 통한 유의미한 수확이 없었냐고 한다면 결코 아니다.
우선 팀의 자신감 차원에서 레벨업이 있었다. 두 명으로도 무엇이든 할 수는 있겠다 라는 자신감이 붙었다. 모든 환경이 갖춰지기만을 기다리지 않고 바로 실행에 옮긴 덕이라고 생각한다. 또 실패를 통해 얻은 두 가지 레슨런도 있다.
첫 번째, 초기 창업팀에서 피해야 할 아이템이 있다는 것. 아래 내용은 내가 이번에 느꼈던 소규모의 창업팀에서 아이템 선정 시 고려해야 할 항목이다.
- 해당 문제가 우리 팀에서 잘 풀 수 있는 문제인가? 우리가 잘 할 수 있는 분야인가?
- 네트워크 효과가 필요한 아이템인가? 네트워크 효과가 일어나기까지 버틸 자원이 있는가?
- 기술 난이도가 얼마나 높은가? 얼마나 쉽게 가설을 검증할 수 있는가?
- 얼마나 확실한 문제인가? 가설 검증에 리소스가 많이 들 것 같다면 그만큼 확신을 가지고 베팅할만한 문제인가?
자원이 부족한 창업팀이라면 아이템에 대한 시장의 반응이외에도 위 내용들을 충분히 검토해 보고 피해야 할 아이템이 있다는 것을 배웠다. 우리는 위 몇 가지 내용에 해당되는 아이템을 선정했었다. 물론 직접 실행해보는 것 만큼 확실한 것은 없지만 검증해야 할 아이템들의 우선순위를 잘 조정하는 것도 중요하다고 생각한다.
두 번째, MVP의 밸런스를 맞추는 것.
MVP는 단순히 최소한의 기능을 구현한 제품이 아니라는 것을 깨달았다. ‘가설 검증이 가능한 상태’의 가장 작은 단위의 제품이어야 한다. 최소한의 기능을 구현한 제품으로 시장에서 가설 검증이 어려운 수준이라면 MVP일까? 반대로 여러 가지 가치와 기능을 제공하는 제품이라면 MVP일까? 두가지 케이스 다 가장 중요한 가설을 검증하는데 방해가 될 것이다.
우리가 이번 프로젝트에서 만든 MVP는 가설을 정확하게 검증하기에 부족한 수준이었다. 물론 이 사실을 감안해서 결정을 내렸지만. 기능적 측면이든 심미적 디자인 측면이든 가설 검증에 방해가 되지 않는 적절한 수준의 MVP를 만드는 것이 굉장히 까다롭고 중요한 과제라는 걸 깨달았다.
끝으로, 실패는 결국 성공의 방향으로 더 다가가는 것이라고 생각한다. 앞으로도 수많은 실패를 향해 가보자고..!