스타트업에게 MVP만 개발하여 출시하라고 하는데요. 해보시면 아시겠지만 현장에서 이 MVP의 범주를 정하는 것은 생각보다 쉽지가 않습니다.
높은 분 한마디에 기능이 추가되고 여러 사람 의견 듣다보면 전체 덩어리는 눈덩어리처럼 커지죠.
대체 MVP를 어떻게 정리하면 좋을까요?
이제 막 사업을 시작하는 분들을 기반으로 생각해봤습니다.
전 딱 3가지를 말씀드렸습니다.
얼마 전에 미취학 유아동 과외 플랫폼을 만들려고 하는 A님이 저에게 도움을 요청하셨어요. A님은 관련 업계에서 오랫동안 일해와서 좋은 선생님들에 대한 인프라를 많이 가지고 계셨지만 개발 지식은 하나도 없으셨죠.
그래서 상상력을 발휘해서 가상의 서비스 UI를 요렇게 조렇게 그려서 개발을 할 수 있는 사람들을 찾아갔대요.
외주개발사를 운영하는 B는 전달한 내용을 보고 카페24기반의 사이트 구축에 필요한 비용을 알려주고 포기해야할 것들을 짚어줬고요. 경험이 많은 개발자 C는 전체 구축에 필요한 기능들을 개발하기위해 필요한 인원수에 대해서 말하고 조인할 경우의 연봉과 스톡옵션을 이야기했다고 해요.
신생 창업자 A님에게 어떤 판단이 현명한 것일까요? B? C?
저는 주어진 옵션중에 선택을 하지마시라고 조언을 했어요.
사실 지금 시점에 필요한 건 '검증'입니다. 아직 이 사업이 얼마나 시장성이 있는지 모르는 상태에서 어떤 방식으로도 최종적인 형태로 구축할 하는 것은 비용리스크가 커지죠. 엔젤투자비용을 전부 개발에 투자해야할 수도 있었죠.
지금은 사업을 좀 더 날카롭게 다듬어야할 때죠. 지금 성인 교육시장에서 가장 알아주는 회사중 하나인 패스트캠퍼스에서는 처음에 모든 것을 구축하지 않았어요. 오히려 시장에 뿌려진 솔루션들을 활용하여 시장성부터 검증하고 많은 비용은 그로스마케팅에 쏟아서 시장을 키웠죠. 바로 작년에 사이트 재구축하기 전까지도 말이에요!
사실 A님은 본인이 MVP를 위해 이미 많은 기능을 포기했다고 생각해왔어요. 이미 포기한 기능이 이렇게나 많은데 더이상 어떻게 줄여야 될지 몰랐죠.
오른쪽의 표는 대부분의 온라인 서비스가 가지고 있는 최대치 구조에요. 플랫폼인 경우 판매자 사이드와 구매자 사이드에서 가입과 등록, 결제와 정산 그리고 클레임, 배송 등의 모듈들이 존재하죠.
처음부터 모든 것을 만들 필요는 없어요. 외부로 돌리거나 오프라인으로 대체할 수 있는 것은 사용해서 비즈니스 검증부터 하시길 추천드려요. 매몰비용이 커지면 시장성이 없다고 판단해도 사업을 접는 것도 어려워지고 사업이 수익이 없을 때는 계속 유지하기도 어려워지니까요. 대신에 이익을 키워서 서비스도 점차 발전시킬 수 있어요.
이번에는 기존에 존재하는 시장에 진입할 때의 이야기입니다. 이 세상에 완전히 새로운 없기때문에 분명 시장에 비슷하거나 완전히 같은 경쟁자가 존재하죠. 후발주자로 서비스를 기획할 때 주의해야할 포인트가 있습니다.
앞서 나온 A님의 신사업에 대해서 계속 이야기해볼께요. 해당 시장의 가상의 ㄱ사, ㄴ사, ㄷ사가 있었다고 치고 A님이 조사를 했다고 해보시죠. 각자 서비스는 아롱이 다롱이죠. 비슷하지만 좋아보이는 것들이 달라요.
가장 하기쉬운 실수는 이 경쟁사들의 서비스들에서 좋아보이는 것들을 다 조합하고 차별화 포인트라며 알파를 추가하여 설계하는 것입니다. 겉으로는 약점없이 강점만 있어 그럴듯해 보이죠?
하지만 사실 이런 접근은 강약중강약이 없는 '기능 프랑켄슈타인'이 되고 마는 것이죠. 기능 프랑켄슈타인은 만드는 기간도 엄청나게 늘어나지만 손발이 따로 놀아서 가야할 방향대로 안움직여요.
사실 스타트업의 장점은 '파괴적 혁신'을 꿈꾸는 것이 가능한 유연한 구조에 있잖아요?기능 프랑켄슈타인은
인력도 돈도 많고 무조건 성공해야하는 대기업의 방식이에요.
파괴적혁신을 위해서는 고객의 TASK와 적절한 우리만의 문제해결방법을 정해서 벤치마킹된 내용에서 취사선택할 수 있어야겠죠. 물론 앞으로의 방향성과 비전이 이러한 선택에 기반이 되어야할 것 같고요.
지금까지 기능을 줄이는 이야기를 해왔는데요. 마지막 파트는 남겨야할 것에 대한 기준이었어요. 이래저래 빼면서도 꼭 남겨야하는 것에는 무엇이 있을까요?
과거의 서비스들은 왼쪽에 있는 예쁜 단독주택 같았어요. 단독주택처럼 구조와 외관까지 모두 처음 만들어놓은 큰 기반때문에 바꾸기가 어렵죠.
이 때문에 뭔가 서비스를 업그레이드하기 위해서는 전체를 부수고 다시 새로 증축하여 지어야했어요. 흔히 차세대라고 하는 방식이죠. 그런데 이 때 연결고리가 없으면 분명 같은 서비스라고해도 이질적으로 느껴져서 고객이탈이 생기게 되죠.
요즘은 그래서 오른쪽처럼 애초에 고층건물 쌓을 수 있는 기반을 만들어놓고 계속 서비스를 확대하거나 변화시킵니다. 여기서 기반은 인프라가 아니에요. 바로 데이터죠.
그러면 어떤 데이터가 필요할까요? 2가지 종류의 데이터를 기획시점부터 고민해야해요.
첫번째 종류는 비즈니스 효과성 분석용 데이터입니다.
GA든 내부 로그이든 어쨌든 목표한 비즈니스가 제대로 작동하는지 보는 데이터에요.
만약 서비스 시작하고 매출이 100만원이 나왔어요. 이 서비스에 대해서 시장에서 의미있게 작동한다고 판단할 수 있을까요??
100만원은 서비스 종류에 따라 크기도 하지만 작기도 해요. 중요한건 고객이 지인은 아닌지 분석하고 트래픽이 제대로 구매로 전환되는지 혹은 리텐션과 재구매가 일어나는지에 대한 확실한 지표죠. 요즘 그로스해킹 유행덕에 많이들 챙기시는 것이긴 한데 GA설치한다고 해도 세팅이 없다면 맨땅에 데이터 안나온답니다.
두번째 데이터 종류는 서비스를 고도화시키기 위한 데이터에요.
요즘 많은 서비스들이 개인화 추천이나 AI엔진에 대해서 이야기를 해요. 하지만 학습시킬 원천 데이터가 없으면 굉장히 공허한 소리에 해당하죠. 처음부터 추천 서비스를 구현할 수 없다면 나중을 위해 가급적 정제된 데이터를 수집하는 것은 중요해요. 미리 계획하여 정제된 데이터를 쌓아주면 뒤죽박죽 데이터를 전처리하는데 필요한 많은 비용을 줄일 수 있고 적절하게 데이터가 적재되지 않는다는 것을 깨달았을 때 피봇팅 의사결정에 적절하니까요.
맨앞에서 기능을 최대한 줄이라는 이야기와 상충되는 것으로 보일 수도 있어요. 하지만 중요도는 어떤 가치를 중요시하냐에 따라 달라집니다. 정말 핵심 기술이 AI라면, 기반데이터를 쌓기위해 좀 더 구현과정이 필요하겠죠?
네, 여기까지 내용을 정리해보면요.
신규서비스를 만드실 때는 구현 전에 비즈니스 검증 수준의 MVP를 설정하고 첫 런칭품은 POC라고 생각하세요. 그리고 기존 시장에 진입할 때는 기능 프랑케슈타인을 피하고 본인 서비스에 맞게 취사선택하고 마지막으로 데이터자산을 고려한 서비스기획을 해야한다는 이야기였습니다.
어떻게 보면 '맞는 소리' 덩어리같으실 텐데요. 진리는 모르는 것이 아니라 잊혀지는게 아닐까요? 부디 기본기에 충실한 즐거운 시작이 되시길 바랍니다:)
더 자세한 내용은, 서비스 정책 기획 강의에서 더 설명 드릴께요.
이상 도그냥이었습니다:)