MVP를 Tangible 하게 정의해봅시다.
(글을 열면서)
매주 화요일 글을 발행하겠다고 결심을 했는데, 이게 얼마나 어려운일인지를 새삼 깨닫고 있습니다. 이번차례에만 해도 아무생각없이 화요일을 지나버렸네요. 새삼 오랜기간 정해진 루틴을 지키시는 분들을 존경하는 마음이 자라납니다.
이번 글에서부터 Ghost.io 에서 뉴스레터 형식으로 발행을 합니다. 링트인과 페이스북에 상단부로 게시를 하고, Subscribe 링크를 게시하도록 하겠습니다. PMF partner의 newsletter는 Product thoughts 만 발송이 되고, PMF investment fund의 monthly report는 열람되지 않습니다.
내마음속의 MVP는 이제그만
린스타트업에서 MVP를 알게 되고, 애자일을 추구하는 우리들은 언제나 “이번 제품/기획은 MVP로 빠르게 내야해!” 라고 얘기를 합니다. 그럼 MVP는 대관절 무엇이길래 빠르게 낼 수 있는 것일까요? 우리는 그럼 왜 MVP를 빠르게 내고 싶어하는 것일까요?
일단 MVP는 어떤 특징을 가지고 있는지를 생각해봐야겠습니다. Minimal Viable Product. 최소한으로 동작하는 제품. 최소한의 검증할 내용만 넣어서, 빠른 배포를 통해 소비자의 반응을 확인하여 가설을 판명하는 용도의 제품입니다. 이건 뭐랄까 너무 아카데믹한 정의라고 할 수 있고, 우리 마음속에서는 사실 가설이 아니라 이미 확인이었을테니, 가장 작게 메인시나리오를 완성하는 제품이라고도 할 수 있겠습니다. 사실 시장과 가설에 대한 확신이 있다면 꼭 MVP라는 단계를 선행해야 할 필요는 없을 수도 있습니다.
그 다음으로는 대체 왜 우리는 MVP를 내는가에 대해서 생각해봐야하겠습니다. 저는 상대적으로 위의 MVP 특징 정의에 대해서는 큰 이견이 없다고 생각합니다. 다만 현실에 대한 적응이 여러 다를 뿐이겠지요. 하지만 두번째 왜 하는가에 대해서는 정말 다양한 이유들을 볼 수 있었습니다. 의외로 너무 많은 분들이 MVP는 빨리 나오는 것이고, 당연히 개발제품이 빨리 나오면 좋겠고, 개발팀에서 툭하면 MVP 수준이라면 빨리 낼 수 있어요 같은 말을 하니까, “이야아……… MVP로 빨리 냅시다!!!!!” 라고 말씀들을 하십니다. (자매품으로….. ‘애자일, 그거 아무때나 막 개발요구사항을 변경해도 되는 그런거라믄서????’ 가 있습니다.)
우리 조직은 왜 MVP를 내야할까요? 당장 꼭 넣어야 할 것과 넣지 말아야 할 것은 무엇일까요? 개발상의 기능추가가 아니더라도 사용자 시나리오와 화면기획에서 MVP를 구성할 수 있을까요? 몇가지 예시를 들어보면서 어떻게 MVP를 설계하는게 좋을지 생각해보기로 합시다.
여기 월 구독제 제품이 있습니다. 월 9900원으로 사용할 수 있는데, 우리는 연요금제를 109,000원으로 팔고 싶습니다. 월 구독제요금을 이용하는 고객에게 연요금제를 오퍼할 때에 어떤 방법을 선택할 수 있을까요? 꽤 많이 선택하는 방법중에 하나는 월요금제 연요금제 모두 해당 월의 1일에서부터 말일까지로 과금을 하는 것입니다. 저는 개인적으로 신용카드 결제대금의 이용범위를 1일-말일로 하는 것을 가장 선호합니다. 그래서 결제일이 매월 13일이 되는 경우가 많습니다. 과거 씨티카드는 결제일 지정과 무관하게 이렇게 범위를 잡기도 했었는데, 개인화/자유도의 대한민국에서는 결제일에 따라 이용내역정산일자가 바뀌는 유연함을 가지고 있죠 ^^
연요금제를 선택하려는 고객에게, 지금 결제하시면 다음달 1일부터 적용됩니다. 라고 안내할 수 있겠습니다. 하지만 만약 연요금제에만 제공되는 기능때문에 선택하는 분이라면 다음달까지 기다려야 하는 것일지도 모릅니다. 연요금제를 만약 오늘 당장 활성화시켜 준다면 어떻게 될까요? 월요금제에서 잔여일수에 대한 일할환불을 제공해야 합니다. 부분취소 기능이 들어가게 되겠죠.
여기에서 최소화를 선택한다면 어떻게 될까요. 당장 오늘부터 연요금제를 적용해주면서, 적용기간을 365일 + 월요금제잔여일수로 더해주는 방법이 있습니다. 결제/정산이 정의롭지는 않지만 소비자에게 혜택을 제공하면서 프로모션 비용으로 처리한다면 충분히 가능할 것 같습니다.
만약 월요금제가 ‘특정일에서부터 익월특정일 전일’ 까지라고 가정을 해보지요. 또는 30일 day count로 처리되어 있는 경우도 상정해 볼수 있습니다. (어느 월 요금제는 이렇게 움직여지고 있더군요….. 매월 반복결제일이 달라집니다. 2월을 지나가면 2일이나 늘어나요…) MVP로 만들어야 할 정도의 제품/조직이라면 잔여일수 카운트가 아주 정확하게 자동화가 안되어 있을수도 있을텐데 이건 좀 운영버든이 걸릴것도 같네요.
제가 추천하는 MVP는 ‘당장 오늘부터 연요금제 적용, 오늘부터 365일 과금’ + ‘직전 월요금제 전부취소’ 입니다. 이런식의 정책을 잡으면 필연적으로 고객의 어뷰징이 따라옵니다. 이런 어뷰징을 막는것은 MVP에 포함되어야 하는 것일까요? 포함되지 말아야 하는 것일까요?
또 다른 사례를 한번 들어보겠습니다. 기존 사업아이템에 새로운 도메인이 추가되었습니다. 이 도메인에 결제기능을 적용시키려고 하는데, 외부공급사 이슈 때문에 결제가 외부 정책에 의존도가 걸려있습니다. 신용카드결제와 같은 일반결제에서는 키펀칭이기 때문에 별다를 것이 없는데, 우리는 포인트 결제기능도 가지고 있는 회사입니다. 포인트를 적용하면 1~10% 수준에서 사용할 수 있는 사용자의 규모가 일정수준 있는 것으로 파악되었습니다. 제품가격이 수십만원대이기 때문에 포인트를 몇천원에서 몇만원까지 사용할 수 있으면 그로스에 도움이 되지 않을까요?
포인트 결제라는 것은 상당한 수준의 정책을 수반합니다. 쉽게말해 개발하는게 어려운게 아니라 결정할게 많다는 뜻입니다. 얼마까지 포인트로 결제할 수 있게 할 것이냐에 따라 인증정책이 수반됩니다. 포인트를 사용했을때에 리워드를 제공하는 것이 달라질수도 있고, 또 포인트를 환불했을때 포인트의 유효기간이 문제가 될 수도 있습니다. 이런 모든 정책들이 일관되게 포인트 라는 테크제품에서 확정되어 있다면야 개발하는 쪽에서는 의심없이 불러서 사용하기만 하면 되지만, 외부결제가 물려있는 상황에서는 포인트의 정산이라는 측면이 확장되기도 합니다.
여러분은 MVP에 포인트 결제를 포함시키시겠습니까? 아니면 제외하시겠습니까?
MVP를 왜 내어야 하는가. 정답은 여러분 마음속에 있을 것입니다만,
저는 MVP를 만드는 이유는 100%, 가장 싸게 실패하기 위해서라고 답하겠습니다. 우리가 포인트 결제가 그로스에 도움이 되는 것에 확신을 가지고 있다고 하더라도, 포인트를 넣었을때와 아닐때의 성과가 10배 차이가 난다는 확신을 가지고 있다손 치더라도, 우리는 그 기능을 넣으면서부터 싸게 실패할 수 없게 됩니다.
왜 우리는 MVP라는 말을 하면서도, 이런저런 많은 것들을 자꾸만 함께 하고 싶어할까요? 이 주제는 다음글에서 다뤄보도록 하겠습니다.
다음편 “우리는 해왔던 그대로 다시 하고 있을 뿐” 은 4월23일 (화)요일에 발행됩니다.
