MVP 출시, 그다음은?
극 초기 제품 성장을 위해 해야 할 일
2021년 1월, 기독교인을 대상으로 한 안드로이드 앱 Devout을 출시했습니다. 아직 PMF(Product Market Fit; 제품 시장 궁합)를 찾는 과정이지만, 그간 생각을 정리할 겸 글을 썼습니다. 개인적인 차원의 글이다 보니, 구체적인 사례는 배제했고, 결론은 다소 주관적인 내용이 많이 포함되어 있습니다.
1. 무엇을 만들지 결정하기
지난 경험을 통해 어떤 기준으로 제품을 선택해야 하는지에 대한 생각이 명확해졌습니다.
누가 어떤 문제를 겪고 있는지 명확히 정의
이 문제가 얼마나 고통스러운지 파악
이 문제를 겪는 사람들이 얼마나 많은지 파악
문제가 무엇인지, 그 문제가 얼마나 큰지 판단하고 나니 '왜 이 제품을 만들어야 하는지'가 정리되었습니다. 다음으로 이 '문제를 어떻게 해결할지'에 대한 생각을 정리했습니다. 마지막으로 '무엇을 만들지'를 정리했습니다.
사실 처음에는 너무 큰 그림이 그려져서 당황했습니다. 적어도 1년은 걸릴 것 같은 이 로드맵 앞에서, '이래도 되나..' 하는 생각이 앞섰습니다. 그래도 이미 이 문제를 풀고자 하는 마음이 인생의 목표와 동기화되어버린 저에게 필요한 건, 이 제품을 어떻게든 성공시키기 위한 세부적인 전략이었습니다. 그래서 로드맵을 쪼개서 3개의 마일스톤으로 정의했습니다.
그리고 각 마일스톤에 대해 다시 문제를 정의하고, 크기를 가늠한 뒤, 사용자에게 전달하려는 핵심 가치를 정의했습니다.
2. MVP, 어떻게 만들까?
서당개 3년이면 풍월을 읊는다는데, MVP(Minimum Viable Product)란 단어를 쓴 지 3년이 훨씬 넘었지만, 이 친구는 여전히 늘 어렵습니다. '이게 최소로 기획한 게 맞을까? 이렇게까지 하면 검증이 될까?' 이런 의문에 시달리던 경험 때문에, MVP라는 표현을 쓰기가 꺼려질 때도 있습니다.
개인적으로 MVP를 고민할 때 신경 쓰는 3가지가 있습니다.
이 기능으로 전달하려는 핵심 가치가 명확한가?
핵심 가치를 검증할 수 있는 최소한의 기능 정의가 되었나?
검증을 하는 방법이 명확한가?
위에 3가지를 고민하며, MVP 준비 2주 후, 출시 버튼을 눌렀습니다. 출시 승인이 떨어지고, 다음날 아침 두근거리는 손으로 Amplitude 대시보드를 열어봤습니다. 결과가 처참했습니다. (* Amplitude: 앱 내 사용자의 Behavioral Data의 수집 및 분석을 도와주는 도구) 결과 지표로 보려고 한 D1 Retention이 단 10%밖에 나오지 않았습니다. (* D1 Retention; First_app_open이후 다음날 Critical Event를 경험한 사용자 비율)
이러면 완전히 나가린데.. 눈앞이 캄캄해졌습니다.
3. 처참한 결과를 맞이한 뒤..
생각이 바빠지기 시작했습니다. QA에서 잡지 못한 심각한 버그가 있나 싶어 열심히 파봤지만, 개발에 문제가 있다고 판단하긴 어려웠습니다.
'기획이 잘못되었다'는 결론 이후,
핵심 가치를 적어 놓은 문서를 다시 찬찬히 살펴봤습니다. 그리고 큰 문제를 발견했습니다.
문서에 적어 놓은 핵심 가치가 명확하지 않았다는 점이 비로소 보이기 시작했습니다. 사용자에게 전달하고 싶은 핵심 가치에 욕심이 그득했습니다. (자주 하는 실수입니다 ㅜㅠ) 크게 2가지의 서로 다른 가치 제언이 섞여 있었습니다. 지금이라도 이걸 바로 잡지 않으면 배가 산으로 가버릴 수 있기 때문에 결단을 내려야 했습니다.
이렇게 핵심 가치가 뭉툭할 경우 다음과 같은 문제가 생길 수 있습니다.
1. 결과물이 분명하게 표현되지 않아, 사용자에게 명확함을 전달하지 못한다.
만드는 사람조차 명확하지 않다면, 그 결과물을 받아보는 사용자는 이해 못할 것이라고 봐야 타당합니다. 한 가지 다행인 것은, 보통의 경우 가설이 뾰족하지 않으면, 디자이너와 협업하는 과정에서 어려움을 겪게 됩니다. 어디에 힘주어야 하는지 HOW를 고민하는 디자이너는 표현의 우선순위에서 혼란을 겪게 되기 때문입니다.
2. 결과의 해석이 모호해진다.
우연히 성공적인 결과가 나와도, 이 성공이 무엇 때문에 나온 결과인지 확신을 갖지 못합니다. 실패했더라도, 배움은 있어야 하는데 이 경우 왜 이런 결과가 나왔는지에 대해 해석이 모호해집니다.
사용자들이 뭉뚝하게 설계된 핵심 가치를 주는 제품을 보고, 이게 나에게 어떤 가치가 있을지를 명확히 인지할 거라 기대하는 것은 어불성설입니다. 당장은 마이크로 한 분석을 통해 다음 일감을 찾아내기보다 핵심 가치를 재설정하는 것이 필요하다고 생각했습니다. 이를 팀에 공유하는 과정에서 극초기 제품이 PMF를 찾아가는 과정에 대한 열띤 논의(Big Bat vs Small Bat)가 있었습니다.
4. Small Bat vs Big Bat
MVP를 이제 막 출시한 팀에게, 핵심 가치가 잘못 설정되었으니 이걸 고쳐야 한다는 주장은 굉장히 급진적입니다. 제품을 갈아엎어야 하는 수준의 작업이 필요할 수도 있고, 그러면 결국 한 번 출시에 그만큼 시간을 많이 써야 하기 때문입니다.
저희 팀에도 아래와 같은 논쟁이 시작되었습니다.
새로 정의한 핵심 가치에 맞춰 큰 변화를 주자(Big Bat) vs 작은 실험들을 통해 빠르게 키워보자(Small Bat)
양측 다 목표는 저 높은 산의 정상으로 올라가는 것으로 동일합니다. 다만, 정상으로 가는 갈림길에서 어느 길이 더 빨리 갈 수 있느냐에 대한 의견이 갈리는 상황입니다.
Big Bat을 옹호하는 사람은,
우리가 정상에 빠르게 가려면, 제일 빨리 갈 수 있는 시작 지점을 잘 선택해야 한다는 주장입니다.
Small Bat을 옹호하는 사람은,
어차피 최적점을 찾는 것은 어려우니, 바로 정상을 향해 빨리 달려가는 게 가장 빠르다는 주장입니다.
사실 창업을 시작하기 전 저에게 익숙한 방식은 후자(Small Bat)였습니다. 어느 정도 시장에 존재감을 가지고 있는 제품들만을 담당했다 보니, 이미 PMF를 찾은 제품들을 성장시키는 일을 주로 했었습니다. 따라서 작은 실험들을 통해 최대한 빠르게 많은 배움을 쌓아가며, 실험의 성공 확률을 높여서 지표를 작게, 많이 개선하는 방식으로 일하는 것이 익숙해져 있었습니다. 사실 창업을 하기 전쯤 이렇게 일하는 방식에 문제를 느끼며 Basecamp의 업무 방식을 토론하며 Big bat 위주의 스프린트를 고민하기도 했습니다. (이미 PMF를 찾은 제품에도 Big Bat이 필요한 상황은 여럿 있다고 생각합니다만, 지금은 극초기 제품에 관한 이야기 이므로, 이에 대한 이야기는 다음 기회로 미루겠습니다.)
이제 막 출시한 제품 PO로서, 지금은 Big Bat을 휘둘러야 할 때라는 생각이 들었습니다.
주된 이유는 다음과 같았습니다.
1. 핵심지표가 가치의 전달 여부를 판단해준다
내가 전달하고 싶은 제품의 가치, 즉 사용자가 느끼는 문제를 제품이 해결해 줬다면 사용자는 제품을 분명히 다시 사용할 것이라는 믿음이 있습니다. D1 Retention 10%는 이유 여하를 막론하고, 가치
전달이 명확하지 않았다고 결론 내리는 게 타당하다고 판단했습니다.
2. Local Optimum에 빠질 가능성이 높다
도달하고 싶은 곳은 산의 정상인데, 발을 디딘 시작점에서 올라갈 수 있는 한계가 작은 봉우리일 수 있습니다. Global Optimum으로 가는 확률을 높이려면 시작점의 위치가 매우 중요하다고 생각했습니다.
3. 팀의 텐션 관리가 안된다
1~2%, 많아도 5% 높이는 실험으로는 이미 극단적으로 낮은 베이스라인 하에 성공적인 실험이 텐션을 높여주지 못한다고 생각했습니다. 특히 초기에는 이 제품이 될 것이다는 강력한 시그널이 팀을 하나로 묶어주는데 큰 도움이 됩니다. 이를 위해서도 극초기 제품의 핵심 지표가 특정 수준 이상을 기록하는 게 중요하다고 생각했습니다.
5. 요약
Devout은 출시 2달 만에 드라마틱한 성장을 만들어 냈습니다. 물론 아직 가야 할 길은 많지만, 이런 경험들을 통해 초기 제품의 성장을 위해 해야 할 일들이 머릿속에 많이 정리가 되었습니다.
(TL;DR) 이를 요약하면,
제품의 핵심 가치를 명확하게 1가지로 정의해야 한다.
작게 시작하지 않으면 변화를 감당할 수 없다. MVP..!
핵심 지표가 특정 수준 이상이 될 때까지, 핵심 가치를 전달하기 위한 전략 pivot 수준에서 Big Bat을 휘둘러라 (Big Bat도 MVP 수준 엄수)
