만들기만 하면 돼!라는 착각
Last updated
Last updated
그렇게 꾸준한 바이럴 마케팅으로 4주간 150명을 모았고, 인터뷰 때마다 좋은 피드백도 받을 수 있었다. 내부 시연도 잘 마무리해 모든 것은 만사형통할 것처럼 보였다. 그렇게 대망의 베타 클로즈 릴리즈 날에 이르게 된다.
큰 반응이 있을 것이라는 엄청난 기대를 한 것은 아니었지만, 그럼에도 정말 무진장 조용했다! 두 분의 온보딩이 예정되어있었기 때문에 해가 넘어가기 직전인 금요일 저녁 8시까지 온보딩을 진행했던 기억이 난다. 그러나 아직까지는, "예상했던 일이야" 혹은 "이제부터 제대로 해보면 되지!"라는 막연한 희망이 있던 때였다.
베타 클로즈 릴리즈 후, 회원가입자는 꾸준히 들어오고 있었고 매일 가입하시는 분들께 세일즈 콜도 드리고 있었다. 이때까지도 광고를 진행하고 있지 않았고, 온전히 자연 유입으로만 고객분들이 유입되고 있었음에도 하루에 10명 이상이 꾸준히 가입하고 있었다. 하지만, 릴리즈 전과 상황은 크게 다르지 않았다.
인터뷰는 계속해서 진행하고 있었고, 인터뷰의 내용은 비슷하게 흘러갔다. '이런 부분은 좋고 이런 부분은 좀 더 기능이 필요해요' 그리고 이렇게 말씀해주시는 기능들도 이미 준비하고 있는 내용이었다. 그런데, 제품이 있는데도 꾸준히 쓰는 사람이 없었다. 릴리즈 후 4주간 가입 186명, 온보딩 29명을 진행했지만, 4주가 지나고 봤을 때 진짜 제대로 제품을 사용했다고 할 수 있는 고객은 4명뿐이었다.
릴리즈 전에는 제품이 없었고, 후에는 제품이 있는데 왜? 도대체 왜 상황이 비슷했을까? 제품을 사용할 수 있는데 왜 사용하지 않는걸까?
고객분들이 지속적으로 들어오긴 하는데 사용을 꾸준히 안한다를 문제로 좁혔기 때문에, 그럼 저 계속해서 사용하신 4명의 고객은 어떤 분들일까?라는 질문으로 넘어갔다. 즉, 우리가 우리의 제대로된 타겟 고객, use case를 못잡았다고 생각했던 것이다. 다시 린캔버스부터 타겟 정의까지 되돌아간 것을 볼 수 있다.
지금까지 한 인터뷰들을 들여다보아도 우리의 고객은 ~입니다!라고 말하기가 어려웠다. 왜냐하면 정말 다양한 이야기를 하고 있었기 때문이다. 어떤 고객은 노션, 지라와의 연동이 필요하다고 했고, 어떤 고객은 팀 워크스페이스가 필요하다고 했고, 어떤 고객은 편집 기능이 필요하다고 했기 때문이다. 그야말로 고객을 좁혀서 타겟하지 못하고, 여러 그룹이 모두 고객이라고 생각하고 었던 것이었다.
우리는 우리 제품을 꾸준히 사용하고, 나아가 돈도 지불할 고객을 찾기 위해 일종의 법칙을 만들고 싶었다. 아래와 같은 삼단 논법을 찾고자 했던 것이다.
이런 [ 외부 정량 요인 ]을 가진 팀 은 이런 { QA 특성 }을 띈다.
이런 { QA 특성 }을 띄는 팀 은 [ QAing ]을 사용해 QA할 것이다.
우리가 이런 타겟 고객을 찾아낸다면, 이 그룹은 밖에서도 식별할 수 있는 특정한 '외부 정량 요인'을 가지고 있으므로 그와 비슷한 고객에게 다시 찾아가서 또 사용자로 전환하는 것이 가능할 것이라고 봤기 때문이다. 지금까지 인터뷰한 고객분들의 특성을 기반으로 1차적으로는 다음과 같은 고객군을 설정했다.
타겟 고객을 구체화했으니, 우리가 정한 타겟 고객이 정말 타겟 고객이 맞는지 검증할 단계였다. 기존에는 인바운드로 들어오신 고객 분들께 세일즈콜을 했었다면, 처음으로 아웃바운드를 시도하게 된다. 왜 많은 세일즈 전문가 분들께서 아웃바운드가 100배는 더 어렵다고 하셨는지 몸소 이해할 수 있었는데, 아웃바운드를 할 때도 고객 분들이 니즈를 느끼고 액션을 하게끔하는 게 필요하다는 걸 배웠다.
그렇게 타겟 고객 인터뷰를 19분 진행하며, 기존에 잡았던 타겟 고객에서 B2B SaaS 중에서도 프로덕트를 좁히고, 플랫폼과, 외주개발까지 추가해 리스트업을 하게 된다. 여기서도 분명 타겟을 좁히겠다고 했는데 아직도 5개나 적어둘 정도로 정신을 못차린 상태라는 걸 알 수 있다.
여기서 또 하나의 잘못된 생각을 하게 되는데 그건 바로 서비스의 어떤 점이 부족해서 사용을 못하는 것이라는 생각이었다. 제품을 온보딩해드리고 나면, 항상 'A, B, C 기능이 없어서 못쓰겠어요'라는 대답을 듣곤 했는데, 이것이 제품의 문제인지, 시장이 없는 것인지를 헷갈렸던 것이다. 물론 제품에 고객분들이 계속해서 유입되고 있었으니, 제품 문제라고 생각하게 된다. 다시 한번 우리 팀의 손을 들어준 것이다.
그럼 A, B, C가 다 문제면, 우리는 뭐부터 해야할까? 지금까지 고객 유형은 각각 다르지만, 니즈는 크게 두 가지로 구분할 수 있었다. 일명 유지파와 개혁파였다. 팀 전체가 QAing을 사용하게 하기까지는 전환까지 시간이 더 오래걸릴 것이라고 생각해, 개인 단위의 QA 문제를 더 확실하게 푸는 것으로 결정하게 된다.
진짜 이런 말을 린스타트업이나, 인스파이어드 등의 제품팀을 위한 책에서 읽으면 '진짜 저렇게 생각한다고?', '바보다' 라고 생각했던 것 같은데, 이 말을 내가 한 적이 있었다. 위에서 이야기한 기존 QA 시트 유지파를 위한 기능을 우리는 아래와 같이 정리했다.
이 기능을 만들겠다고 했을 때, 대표님이 오셔서 왜? 그거 말고 더 빠른 방법은 없어?라고 하셨을 때, 이렇게 말했다. "기술적으로도 구현 가능하고, 개발에도 시간이 그리 오래 걸리지 않습니다. 이거 되면 다 쓸거에요." 그러자 대표님이 "그거 어디서 많이 들어본 말인데"하고 가셨다. 우리 바로 옆에 있는 팀도 신사업 팀이었는데, 그 팀이 우리보다 6개월 가량 먼저 시작하면서 거쳐왔던 길이었기 때문이었다. 참, 이렇게 바로 옆에 선례가 있는데도 '나는 아닐거야' '우리 제품은 아닐거야'라고 생각했던 걸 보면 신기하다.
그렇게 야심차게 준비했던 블랙박스와 로그정보 자동 저장 기능은 생각보다 빠르게 이 세상에 나오게 된다. 글 시작에 '출시만 하면 성공할 아이디어'라고 적어두었던 것이 엊그제 같은데, 또다시 '출시만 하면 성공할 아이디어'라고 생각하고 출시를 하는 모습을 보니, 제품 개발에서 문제를 제대로 찾고, 가장 위험한 + 검증이 필요한 문제부터 검증하는 것이 얼마나 중요한지를 다시 깨닫게 된다.
그럼 이번에는 우리의 계획처럼 '출시만 하면 성공'이 이뤄졌을까? (예상했겠지만 물론 아닐 것이다!)
