유료화는 언제 해야할까?
Last updated
Last updated
우여곡절 끝에 타겟 고객을 정의하고, 핵심 기능으로 꼽았던 블랙박스와 로그정보 자동 저장까지 개발을 마무리하게 된 시점이었다. 놀랍게도 또다시 출시만 하면 성공할 아이디어라는 희망을 놓고 있지 않았다.
큐에잉의 핵심 기능이었던 이미지/영상 자동 저장 기능의 경우, 사용자의 기존 작업 플로우와 맞지 않는다는 문제가 있었다. 첫째는 테스트를 시작하기 전에 QAing을 켜야 한다는 점이었고, 두 번째는 이슈를 발견하면 바로 정리를 하는 플로우인데, 우리 제품은 모든 테스트가 끝나면 정리를 할 수 있게 파일이 저장된다는 점이었다. 이 두 문제를 블랙박스 기능이 한 번에 해결할 수 있었다. 블랙박스는 차량 블랙박스처럼 항상 저장할 수 있는 상태를 유지하고 있다가, 사용자가 이슈를 찾고 저장하고자 할 때, 이전 영상을 저장하도록 하는 기능이었다. 즉, 따로 먼저 QAing을 켜둘 필요도 없었고, 바로 파일을 확인하고 정리할 수 있었다.
여기에 더불어, 로그정보 자동저장은 QA 툴이 아닌 캡처툴에서는 제공하지 않는 기능이기 때문에 이 두 기능을 가진 상태에서는 그 전과 다를 것이라는 기대가 있었다.
이제는 우리가 제품의 문제라고 생각했던 것들을 다 해결한 상태였기 때문에, 그럼 시장 위험을 검증해야 하는 때다라는 생각이 들었다. 제품팀이 해결해야할 위험 네 가지 중에서 가치 위험을 확인하려고 했던 것이다.
그동안 수많은 인터뷰에서 이런 기능이 있다면, 이 정도 가격은 전혀 문제가 되지 않을 것 같다 라는 '의견'을 정말 많이 들었었기 때문에, 이제는 진짜로 돈을 내야만 쓸 수 있는 환경을 만들고 수익화가 가능한지를 보고 싶은 마음이 컸던 것 같다. 그래서 여기서도 더 빠르게 검증할 방법을 찾기보다는, 제대로 결제를 붙이겠다는 생각을 하게 된다. 결제를 붙이는 것이 그리 오래 걸리지 않는다는 핑계도 한 몫했다. 그렇게 빠르게(?) 결제까지 일사천리로 붙이게 된다.
결제를 붙인다면 가격 정책이 또한 중요했다. 가격 정책은 다른 경쟁 제품들과, '프라이싱'이라는 책을 참고했다. 우리가 제공하는 서비스는 당시로서는 개인 단위로 사용해야 하는 서비스였다. 따라서 추후에는 팀 단위 결제를 추가할 계획이었지만 당장은 1인당 결제를 할 수 있도록 구성해야 했다. 그리고 이 1인당 결제는 기간 단위 / 사용량 단위 중 기간 단위로 설정했다.
그 이유는 QA를 할 때는 어떤 기능을 테스트한다고 해서 몇 개의 버그를 발견하게 될지, 그리고 그 과정에서 몇 번의 캡처/녹화를 하게 될지 가늠하기가 어렵다는 점이 한 가지였고, 다른 한 가지는 우리가 경쟁하고 있는 제품은 무료이고 기본 툴인 캡처툴인데 매번 캡처/녹화할 때마다 이걸 QAing을 통해서 할 가치가 있을지를 고민하게 만드는 것은 제품의 이탈을 촉진한다고 생각했기 때문이다. 그래서 아래와 같은 월 구독형 가격 정책을 만들게 된다.
글의 제목이 '유료화는 언제 해야할까?'인 만큼, 언제 유료화를 하는 것이 좋은가를 잠시 고민해보려고 한다. 답은 사실 간단하다. ASAP!!!! 'The Mom Test'에서도 말하지만, 인터뷰에서 단순히 의견을 묻는 것은 전혀 도움이 안된다. 오히려 방해가 된다.
'이런 제품이 있으면 사시겠어요?', '가격이 이 정도인데 살 것 같으신가요?'라고 묻고 아무리 '편하게 답변해주셔도 돼요'라고 해도, 사람의 마음이 그렇게 차갑게 현실을 말해줄 수가 없다. 그리고 무엇보다 그들도 모른다!!! 미래에 어떤 결정을 하게 될지, 제품을 보고 실제로 얼만큼의 가치를 느낄지 알 수 없기 때문에 물을 필요가 없는 질문이다.
이에 대해 Mom Test에서는 미래의 의향을 묻지 말고, 현재의 사실을 물으라고 강조한다. 예를 들면, 현재의 문제를 해결하기 위해 어떤 조사를 해봤는지, 다른 대안을 사용하고 있다면 거기에 돈을 얼마나 쓰고 있는지 등의 사실을 물으면 그 문제를 해결하는 새로운 제품에 투자할 지불의사를 유추할 수 있다는 것이다.
하지만 우리가 만약 완전히 새로운 제품을 만들고 있다면, 혹은 우리가 주는 가치는 기존의 문제를 고객이 예상하는 것과 다르게 해결한다면 이런 유추도 적절하지 않을 수 있다. 그렇기 때문에 현재 바로 일정한 기여를 하도록 유도하는 방법이 오히려 더 적합할 수 있다. 이와 관련해서는 '아이디어 불패의 법칙'의 '프리토타입' 기법들을 고려해볼 수 있다.
프리토타입의 주된 목적은 다음과 같은 질문에 답하는 것이다.
내가 이걸 사용할까?
언제 어떻게 얼마나 자주 사용할까?
남들이 사줄까?
사람들은 이 제품에 얼마까지 지불하려고 할까?
사람들은 언제 어떻게 얼마나 자주 이걸 사용할까?
이 질문들에 대한 답은 우리가 다음과 같은 가장 중요한 질문에 답할 수 있게 도와준다. '이걸 만들어야 할까?'
여기서는 정말 기발하고 다양한 여러 적용 사례들을 보여준다. 예를 들면 아래와 같은 방법들이다.
1999년에 우리는 카즈다이렉트를 시작했다. 당시는 사람들이 온라인에서 신용카드 긁기를 꺼리던 때였다. 그런데도 나는 자동차를 온라인으로 팔고 싶었다! 수요일 밤에 사이트를 만들었는데 목요일 아침까지 주문이 4건 들어왔다. 우리는 얼른 사이트를 닫았다(우리는 소매점에서 자동차 4대를 사서 이 4명의 고객에게 손해를 보고 가져다주어야 했다). 하지만 우리의 가설은 증명된 셈이었다. 그제야 우리는 진짜 웹사이트와 회사를 만들기 시작했다.
QAing의 경우에도 웹사이트를 먼저 만들고, 사전신청을 받았지만, 결제를 실제로 받은 건 그로부터 4개월이 지난 시점이었다. 이미 그때부터 먼저 결제까지 일어나는지를 테스트할 방안을 만들고 더 앞단에서, 아예 제품은 1도 만들지 않은 상태에서 테스트를 해봤다면 시간을 훨씬 절약할 수 있었을 것이다.
다시 돌아와서, 우리는 유료화를 OPEN했지만, 일주일 동안 아무도 결제하지 않았다. 왜일까? 왜 결제를 하지 않을까?에 답해야 했다. 나는 고객분들께는 죄송하지만 질척거리는 방안을 선택했다. 이전에 잘 사용하셨던 분, 다른 분들께 추천도 해주셨던 분, 인터뷰에 너무 긍정적으로 임해주셨던 분들을 추려서 냅다 전화를 했다. "왜 사용하지 않으세요? 왜 결제하지 않으세요?" 그 결과 아래와 같은 문제들을 정리할 수 있었다.
즉, QA업무를 하는 PM을 타겟으로 했을 때, PM은 QA 업무가 메인 업무가 아니기 때문에 돈을 내면서까지 쓰기는 어려움이 었었다는 걸 발견했다. 특히 개인으로 쓴다고 했을 때, 이 서비스는 업무에 활용하는 서비스이므로 법인카드로 결제를 해야 맞지만, 이를 설득하기에는 시간이 획기적으로 줄어든다거나, 완전히 QA 정확도가 올라간다거나 하는 명확한 이점이 없었던 것이다.
게다가 1번 문제의 경우, 기술적 한계로 인해 해결할 수 없는 것이었다. 그리고 여기서 느낄 수 있듯, QA는 여러 기기를 테스트하고, 여러 환경을 테스트하는 것이 업무의 본질인 관계로 기능 요구사항이 정말 끝도 없이 늘어난다. 모든 환경과 모든 기기에 대응해야하면서도 기대하는 바를 100%의 확률로 얻을 수 있기를 바라는 분야인 것이다.
그야말로 QA 분야에서 범용으로 이슈 리포팅을 할 수 있는 툴을 만든다는 건 기술적으로 어렵고, 그에 따른 지불의사는 굉장히 증명하기 어려운 분야라고 할 수 있겠다. 그럼에도 여기서도 의지를 굽히지 않았던 큐에잉팀은 2번과 3번 문제를 해결해보자는 마지막 수를 던지게 된다.
지금까지 지나온 시간은 시장 검증 3개월, 인큐베이팅 3개월이었다. 원래는 인큐베이팅은 6개월로 계획되어있었기 때문에 3개월은 더 달려볼 기회가 있었다. 하지만 우리의 옆자리에 있었던 팀이 문을 닫게 되면서, 우리 팀도 자연스레 의심의 눈초리를 받게 된 것이다. '저기도 가망 없는 거 아니야?' 그렇게 갑작스럽게 팀이 문을 닫을 위기에 처하게 된다.
여기서 놓을 수도 있었겠지만, 아직 완전히 검증되진 않았다는 생각이 들었다. 퍼뜩 정신을 차리고 딱 한 달만 시간을 달라고 요청드렸다. 그렇게 마지막으로 '팀스페이스'에 대한 니즈를 검증해볼 수 있는 한 달의 시간이 주어졌다.
