작년 이맘때(2021년 2월), 저는 AWS Lambda 에서 Next.js 를 바탕으로 구축한 시스템 가동 시간 검사기(Uptime checker) 프로토타입을 인터넷에 공개했습니다. 이걸 완성하는 데 일주일이라는 시간이 걸렸습니다.
이 후 일 년 동안 비즈니스가 어떻게 진행되고 있는지에 대한 몇 가지 글을 쓰기도 했습니다:
제가 서비스 개발을 위해 선택한 접근 방식의 요점은 다음과 같습니다:
정적 웹 사이트가 온라인 상태인지 확인하고, 오프라인 상태인 경우 이메일 알림을 추가하고, 인증 기능을 감싸고, Stripe를 통합하고, Lambda 를 통해 출시. 그리고 한 해 동안 계속해서 기능을 추가했습니다.
제가 '동일한' 서비스를 제공하는 200여 개의 경쟁업체가 있는 분야에 제품을 출시 하고도 고객을 확보할 수 있었던 비결은 무엇 일까요?
- 평일 하루 2시간씩 OnlineOrNot에 집중하고 다른 부업은 하지 않습니다. 그 덕분에 올해 약 10개월 동안 이 일을 계속할 수 있었습니다(중간에 2개월 정도 번아웃 시간도 있었지만요).
- 저는 특히 고객의 고통을 해결하는 기능에 집중합니다(그리고 고객에게 그 고통이 무엇인지 묻습니다).
- 저는 끊임없이 반복합니다. 2시간 안에 기능을 완성할 수 없다면 범위를 2시간 단위로 줄이는 방법을 찾아서 출시를 해냅니다. 그런 다음 반복합니다.
1년 후 제가 배운 것은 다음과 같습니다:
SaaS 구독을 판매하는 것이 아니라 문제를 해결하는 것입니다
제품을 구축할 때는 구독 판매라는 목표보다는 고객의 관점에서 생각하는 것이 도움이 됩니다.
이렇게 하면 "기능을 계속 만들면 언젠가는 다 나오겠지!"라는 사고방식에서 "사용자가 이 성가신 문제를 해결하도록 도와야지"라는 사고방식으로 전환할 수 있습니다.
SaaS는 문제를 해결하는 여러 방법 중 하나일 뿐입니다. 스크린캐스트, 문서, 기사, 책, 워크샵, 코드 샘플 또는 소프트웨어 등 도움을 줄 수 있는 모든 방법을 검토해야 합니다.
문서는 사용자 경험의 일부입니다
사람들은 종종 "개발자는 문서를 읽지 않는다"고 말하지만 이는 부분만 맞는 사실 같습니다. 그들은 읽지 않고 제목만 훑어봅니다.
제 경험에 비추어 볼 때, 어떤 사람들은 OnlineOrNot의 UI에서 직접 작업을 수행하는 방법을 알아내려고 하다가 좌절하고 문서를 확인하거나 두 가지 중 하나가 발생하곤 했습니다:
- 원하는 작업을 수행할 수 있는 방법을 찾지 못해 바로 이탈합니다.
- 원하는 페이지를 찾아서 제목으로 이동하여 해당 작업을 수행합니다.
OnlineOrNot의 문서를 성공적으로 사용하면 고객 유지율(Retention) 높아지므로 이제는 문서 기능을 부수적인 것이 아니라 핵심 제품의 일부로 취급하고 있습니다.
모바일용 개발
(B2B SaaS에 대한) 일반적인 믿음과는 달리, 사람들은 실제로 휴대폰으로 작업합니다.
OnlineOrNot.com 트래픽의 약 50%가 모바일을 사용하는 사람들로부터 발생합니다. 이들은 빠르게 계정을 만들고 모니터링할 페이지를 몇 개 추가한 다음 노트북/데스크톱으로 이동하여 수표를 수시로 검토하는 경향이 있습니다.
약 6개월 동안 모바일을 제대로 지원하지 않았기 때문에 휴대폰으로 가입한 사용자들이 빠르게 이탈했습니다. 결국 시간을 들여 모바일용 반응형 보기를 구축 했고, 지금은 새로운 모바일 사용자가 꾸준히 유입되고 있습니다.
사람들에게 우리 서비스를 어떻게 찾았는지 물어보세요
올해 제가 만든 가장 가치 있는 코드 변경 중 하나는 가입할 때 사람들에게 하는 질문을 위한 코드 입니다: "OnlineOrNot을 어떻게 알게 되었나요?"라고요.
사용자가 어디에서 여러분을 찾는지 알아야 합니다.
잠재 고객을 유치하기 위해 사용할 수 있는 채널은 수십 가지가 있으며, 유료 광고, 콘텐츠 마케팅 또는 트위터 포스팅을 통해 사용자를 유치할지 여부를 파악하는데 이런 질문이 유용합니다.
애널리틱스 사용, 퍼널 추적 설정
마케팅 퍼널은 비즈니스의 건전성을 파악하는 데 도움이 됩니다. 얼마나 많은 사람들이 개별 페이지를 방문하는지 확인하는 것도 좋지만, 여러 페이지에 걸쳐 사람들이 어떻게 이동하는지 확인하는 것은 더욱 좋습니다.
마케팅 퍼널이란 홈페이지를 방문한 사람들이 최종적으로 가입 양식으로 이동하여 실제 제품을 구매 하기까지의 흐름을 추적하는 것을 의미합니다. 이를 통해 마케팅 카피, 가입 양식 자체, 그리고 사용자가 실제로 앱을 보기 전에 발생할 수 있는 온보딩 문제를 진단할 수 있습니다.
때로는 스스로 실수를 해야 할 때도 있습니다
저는 다른 사람들이 저지른 실수를 반복하고 싶지 않아서 비즈니스 서적을 꽤 많이 읽었습니다.
하지만 때로는 스스로 실수를 해야 할 때도 있습니다.
예를 들어, 해커 뉴스의 첫 페이지에 올라가고, 6천 명이 랜딩 페이지를 방문하고, 수백 명이 가입을 시도하고, 그 중 한 자릿수의 사람들만이 가입 후 저의 앱으로 이동하는 모습을 관찰한 후에야 무언가 잘못되었다는 것을 깨달았습니다.
가입 양식에서만 75% 정도의 이탈률이 발생 하고 있었던 겁니다. 약간의 A/B 테스트를 통해 OAuth 로그인 공급업체를 추가하는 것만으로 이탈률을 50%로 낮출 수 있었습니다.
적절한 가격 책정은 정말 어렵습니다
가격이 너무 높으면 앱이 모든 것을 다 해줄 것으로 기대하는 고객들이 결국 이탈할 수 있습니다. 너무 낮게 책정하면 9달러를 주었다는 이유만으로 앱을 새롭게 작성해야 하는 상황을 만드는 고객이 생길 것입니다. 어려운 고객에게 환불하고 가격을 인상한 다음 계속 진행하세요.
가격 책정에 대해 많은 실험을 할 준비를 하세요.
MRR에 너무 집중하는 경우
MRR(Monthly Recurring Revenue)을 추적하는 것은 초기에 비즈니스 성과를 측정하는 데 매우 형편없는 방법입니다.
몇 주(몇 달은 아니더라도) 전에 수행한 작업이 현재 MRR 에 영향을 미치므로 이미 고객 여정의 여러 단계를 거치는 상당한 수의 고객을 확보하기 전까지는 가격 변경이 효과가 있는지 알 수 없습니다.
저는 일일 활성 사용자 수 또는 고객에 대한 일종의 '성공 지표'(예: 확인된 페이지 수, 생성된 이미지 수 등)를 측정하는 것이 MRR 보다 더 유용 하다고 생각합니다. 이를 통해 사람들이 실제로 제품을 사용하고 있는지, 그리고 제품이 가치를 제공하고 있는지 파악할 수 있습니다.
여전히 유료 티어를 위해 무료 평가판이 필요합니다
무료 티어는 사람들을 끌어들이고 제품에 대해 이야기하게 만드는 좋은 방법이지만, 무료 티어가 유료 티어보다 고객에게 덜 유용 하다고 판단되면 여러분의 "좋은 제품"을 고객들이 시험해볼 수 있는 더 좋은 방법을 생각해야 합니다.
저는 온보딩 플로우를 구축하고 무료 평가판을 제공하기 시작해야 한다는 사실을 깨닫는 데 11개월이나 걸렸습니다. 무료 티어를 제공 했음에도 불구하고 신규 사용자의 95%가 프로 티어의 무료 평가판을 선택했습니다.
더 많은 트래픽을 유도 하기는 어렵지만, 현재 트래픽의 패턴을 변경 하기는 쉽습니다
인터넷에서 주목받는 것은 길고 느린 게임입니다.
결국 몇 달(몇 년은 아니더라도)에 걸쳐 양질의 콘텐츠 마케팅을 꾸준히 수행하면 하루에 1~2명 정도 였던 콘텐츠 독자 수가 하루에 수백 명으로 늘어날 것입니다.
사이트에 방문하는 사람의 수를 늘리는 것은 그리 쉬운 일이 아닙니다.
반면에 사람들이 사이트에 방문한 후 무엇을 하느냐는 전적으로 회원님의 영향력 안에 있으며, 앞서 언급한 것처럼 가입 양식에 OAuth 로그인 공급업체를 추가하는 등 지금 바로 변경할 수 있는 사항도 있습니다.
콘텐츠 마케팅은 시간을 벌어줍니다
콘텐츠 마케팅에 투자하면 한동안 비즈니스가 저절로 운영되도록 내버려둘 수 있습니다.
한 해 동안 가끔 저의 서비스에 관한 아티클이 입소문을 타서 한 달 동안 수만 명의 방문자를 유치할 때도 있었지만, 아무것도 하지 않아도 약 1,500명의 사람들이 제가 작성한 아티클을 보기 위해 사이트를 방문했습니다.
이 방법은 팬데믹 상황에서 프랑스에 살기 위해 전 세계를 돌아다니며 약간의 지쳐 있을 때 특히 유용했습니다.
작게, 자주 출시하기
사람들이 여러분의 제품을 개선하기 위해 특정 기능을 구축해야 한다고 제안할 겁니다.
하지만 그런 기능을 실제로 사용할 사람은 거의 없을 것입니다.
다른 제품에서 비슷한 기능을 본 적이 있어서 도움을 주려는 말일 수도 있습니다. 아마도 SaaS 를 처음 운영하기 때문에 사람들이 실제로 말을 걸어온다는 사실에 흥분하여 서둘러 해당 기능을 구축하게 될 것입니다.
그 기능을 만들지 말라는 말은 하지 않겠습니다(저도 그렇게 조언을 받았고 어쨌든 사용하지 않는 기능을 만들기도 했습니다). 하지만 고객이 해당 기능을 어떻게 사용할지 물어보고, 다른 고객에게 문제를 어떻게 해결하는지 물어보고, 해당 기능의 가능한 가장 작은 버전을 만든 다음 나머지 고객이 어떻게 사용하는지 확인해야 합니다. 여러분도 분명 한 사람만 사용하는 기능을 만들고 싶지는 않을 겁니다.
아무도 원하지 않는 기능을 몇 달이 아니라 몇 시간만 사용한 후 제거하는 것이 훨씬 덜 고통스럽습니다.
먼저 출시하고 확장성은 나중에 걱정
OnlineOrNot 출시 초기에는 아키텍처를 전혀 최적화하지 않았습니다.
각 uptime check 작업은 자체 데이터베이스 연결을 사용했기 때문에 더 많은 사용자가 서비스를 찾을수록 추가 사용자가 앱을 사용하기가 더 어려웠습니다. 또한 적절한 오류 상태를 만들지 않았기 때문에 데이터베이스가 사용 중일 때 신규 사용자가 이런 오류를 보게 되었습니다:
보기 좋지 않았죠.
동시에 저는 사람들에게 필요 없는 것을 만드는 것보다 불완전한 UI로 인해 당황하는 것을 더 선호 했던것 같습니다. OnlineOrNot이 수백 명의 사용자를 끌어들일 수 있다는 보장은 없었고, 저 혼자만 사용하는 또 다른 SaaS 로 끝날 수도 있었습니다.
결국 가장 작은 AWS RDS 인스턴스에서 매주 수백만 건의 검사를 처리할 수 있도록 아키텍처를 재 설계하고 오류 화면을 정리했습니다:
생각만큼 문제 해결에 많은 시간을 할애하지 않아도 됩니다
올해 프로그래밍에 할애한 시간 중 절반은 제가 해결하고 싶었던 문제(사이트가 다운 되었는지 파악하고 다운 되었면 사람들에게 알림을 보내는 것)를 실제로 해결하는 데 사용했습니다. 그리고 나머지 절반은 그 문제를 중심으로 SaaS 플랫폼을 구축하는 데 사용했습니다.
SaaS 플랫폼이 여러 유형의 인증 및 사용자 관리, 평가판, 온보딩, 팀 관리 및 송장 관리, 라이프사이클 이메일 등 이 필요하다고 생각하지도 못했습니다.
이 중 많은 부분을 아웃소싱 할 수 있습니다(실제로 아웃소싱하고 있습니다! 만약 Stripe 이 없었다면 서비스를 판매하거나 구독 기반 청구를 사용하지 못했을 겁니다.) 하지만 아웃소싱하기 불편하거나 다른 방식으로 처리해야 하는 부분도 항상 있기 때문에 직접 구축해야 합니다.
오늘 주간SaaS 는 "혼자 SaaS를 1년 동안 운영 하는 동안 배운것들" 이라는 제목의 아티클을 한글로 소개했습니다.
저자는 OnlineOrNot 이라는 서비스를 개발 하고 시장에 출시 한 이후 1년 간 배운 내용을 글에 담았습니다. 다양한 SaaS 관련 서적과 아티클에서 말하는 모범 사례들이 저자의 실제 경험과 함께 나오는 좋은 아티클 입니다.
아래는 원문 글입니다. 원문과 함께 저자의 다른 글도 꼭 보시면 좋을것 같습니다. B2B SaaS 서비스를 만들고 있는 많은 분들께 도움이 되길 바라며 오늘 주간 SaaS 는 여기서 마칩니다.
의견을 남겨주세요