53P by xguru 2일전 | ★ favorite | 댓글 3개
  • Max Rozen이 창업한 OnlineOrNot은 이미 200개 이상의 경쟁 제품이 존재하는 시장에서 시작됨
  • 초기에는 많은 제품이 사용하기 불편했으며, 이후 수많은 경쟁 제품이 등장하고 빠르게 사라짐
  • 일부 경쟁 제품은 VC 자금을 받고 대기업에 인수되며 사용자 경험이 점점 악화되는 방향으로 전개됨
  • OnlineOrNot은 자가 자금으로 운영되는 장기 지속 가능한 사업을 목표로 함
  • 저자는 여전히 풀타임 직장을 유지하며 꾸준히 SaaS를 개발함
  • 매년 회고글을 작성하며, 과거에 배운 교훈 중 일부는 시간이 지나며 틀렸음이 드러남

변하지 않은 원칙들

수년간 사업 운영에 대해 많은 것을 배웠지만, 여전히 변하지 않고 유지하고 있는 핵심 원칙들이 있음

매일 근무일마다 2시간씩 투자함

  • OnlineOrNot을 시작하기 전부터 매일 아침 출근 전 2시간 동안 개인 프로젝트에 몰두함
  • 이 시간을 활용해 수백 편의 글, 책 한 권, 여러 소프트웨어 프로젝트를 완성함
  • 하루에 얼마를 투자하느냐보다 매일 꾸준히 노력하는 것 자체가 더 중요함
  • 이 시간을 확보하기 위해 2시간 일찍 기상하고 일과를 조정함

다른 사이드 프로젝트는 하지 않음

  • "두 마리 토끼를 쫓는 자는 하나도 잡지 못한다"는 말처럼, 하나에 집중함
  • 일부 예외적인 인물은 여러 프로젝트를 성공시키지만, 본인은 그와 다름을 인정함
  • $0에서 $500 MRR까지 올리는 과정이 가장 어렵고 반복할 필요가 없다고 판단함
  • 이미 작동하는 모델에 집중하고, 마케팅 방식도 같은 관점에서 선택함

고객의 고통을 해결하는 것이 우선임

  • 사용자가 가입하면 자동 이메일을 통해 "왜 가입하셨나요?"라는 질문을 보냄
  • 이메일을 모두 읽고 직접 답장하며, 이것이 제품 개선의 핵심 인사이트가 됨
  • 사용자가 불편해하는 점을 파악하고, 실제로 그것을 해결함

집요하게 반복하며 개선함

  • 어떤 작업도 2시간 내에 배포하지 못한다면, 범위를 줄여 먼저 배포함
  • 항상 이상적으로 딱 2시간에 맞추진 못하지만, 빠르게 초기 버전을 배포하고 기능을 확장하는 방식을 선호함
  • 모든 기능을 다 만들고 배포하려 하면 오히려 동기부여가 사라지고 집중력이 흐려짐
  • 기능 플래그 뒤에서 점진적으로 기능을 완성하는 방식이 훨씬 효과적임

배운 교훈들

책 몇 권만 읽고 바로 만들어 보기

  • 시작할 때 실수를 줄이기 위해 수십 권의 비즈니스 책을 읽었음
  • 하지만 결국 직접 실수하면서 배우는 것이 가장 효과적이라는 점을 깨달음
  • 예: Hacker News 메인에 올라 6000명이 방문했지만 실제 앱까지 도달한 사용자는 한 자릿수에 불과
  • 가입 폼에서만 75% 이탈 → OAuth 로그인 옵션 하나 추가로 이탈률 50%까지 개선
  • 만약 다시 시작한다면 아래 세 권만 읽고 바로 시작했을 것:
    • The Mom Test (Rob Fitzpatrick)
    • Deploy Empathy (Michele Hansen)
    • Badass: Making Users Awesome (Kathy Sierra)
    • SaaS 운영의 실전 디테일이 필요하다면 The SaaS Playbook (Rob Walling) 추가 추천

구독 판매보다 문제 해결이 먼저임

  • SaaS의 목적은 구독을 파는 것이 아니라 고객의 고통을 해결하는 것
  • "기능을 계속 만들면 언젠가는 사람들이 써주겠지" → "사용자의 업무에서 짜증나는 문제를 해결하자"로 사고 전환 필요
  • SaaS는 문제 해결의 한 방식일 뿐이며, 그 외에도 screencast, 문서, 글쓰기, 책, 워크숍, 코드 샘플 등 다양한 접근 가능

작게 만들고 자주 배포하기

  • 사용자들은 기능 아이디어를 제안하지만 실제로는 거의 사용하지 않음
  • 처음 SaaS를 시작한 사람은 누군가와 대화하는 것만으로도 감격해서 무작정 기능을 만들어버리기 쉬움
  • 그 기능을 어떻게 사용할 건지 물어보고, 다른 사용자들의 문제 해결 방식도 조사한 후,
    • 최소한의 기능으로 먼저 구현해서 반응을 확인해야 함
  • 단 한 명만 사용하는 ‘눈송이 기능’을 만드는 것보다, 다수가 쓰는 기능을 만들기 위한 전략적 접근이 중요
  • 몇 시간 투자한 기능을 제거하는 것은 아프지만, 몇 달 투자한 기능을 제거하는 건 훨씬 더 고통스러움

일단 배포하고, 확장은 나중에 고민하라

  • OnlineOrNot 초기 버전은 아키텍처 최적화 없이 빠르게 출시됨
  • 실제로는 시스템이 처리할 수 있는 체크 수가 약 100개로 제한되는 버그가 있었고,
    • 문제 발생 시 사용자에게 단순히 "Error!"만 보여주는 UI로 매우 미완성된 상태였음
  • 하지만 저자는 불필요한 기능을 만드는 것보다 미완성 UI로 욕먹는 쪽을 선택함
  • 처음부터 수천 명의 사용자가 올 거라는 보장이 없기 때문에, 빠르게 검증하는 것이 더 중요했음
  • 임시로 데이터베이스를 상위 플랜으로 업그레이드하여 체크 수용량을 늘림
  • 몇 시간 내에 수백만 개 체크를 처리할 수 있는 구조로 리팩토링하고, 오류 화면도 개선함

얼리 액세스 프로그램 운영

  • 제품 개발 초기에는 대다수 사용자가 불완전한 기능에 대해 어느 정도 관용적
  • 시간이 지나며 더 성숙한 제품을 기대하는 사용자가 늘어나게 됨
  • 이를 해결하기 위해 각 사용자 계정에 "얼리 액세스 프로그램 참여" 체크박스를 추가함
    • 참여자는 아직 완성되지 않은 최신 기능을 먼저 사용해보고 피드백을 제공함
  • 테스트와 피드백의 균형을 맞추는 방법으로 유용하게 작동함

무료 체험은 가능한 빨리 도입하라

  • 요즘은 "무료 플랜은 맞추기 너무 어려우니 하지 말자"는 조언이 일반적임
  • 그러나 초기에는 무료 플랜이 입소문과 사용자 유입에 효과적이었음
  • 단점은 무료 플랜이 유료 기능과 차이가 클 경우, 좋은 기능을 체험할 방법이 필요하다는 점
  • 시작 11개월 후에야 온보딩 과정에서 "무료 체험을 시작하시겠습니까?"라는 질문을 추가함
    • 실제 의미는 다음과 같음:

      “좋은 기능을 14일간 체험하고 결정하시겠습니까, 아니면 몇 달을 기능이 제한된 상태로 써보다 결국 실망하시겠습니까?”

  • 이후 실험적으로 모든 사용자에게 기본적으로 무료 체험을 제공하게 했고,
    • 이 실험 하나만으로 월간 성장률이 2배 이상 증가함
  • 결론:
    • "이건 유료 서비스입니다. 좋은 기능을 계속 쓰려면 결제 정보가 필요합니다"는 메시지가
    • "이건 무료 서비스예요. 많이 쓰면 유료일지도요"보다 비즈니스적으로 훨씬 효과적

문서 자체가 제품임

  • 과거에는 "개발자는 문서 안 읽는다"는 말이 흔했지만, 완전히 잘못된 말
  • 이상적인 고객 중 일부는 OnlineOrNot의 문서를 칭찬했고, 이를 계기로 문서에 집중 투자함
  • API 문서도 직접 구축해 사용자 경험을 완전히 제어할 수 있도록 설계함
  • 제품 분석 도구로 관찰한 결과:
    1. 사용자가 UI에서 문제를 겪고, 문서를 확인 후 기능을 찾아내면 제품을 계속 사용함
    2. 원하는 정보를 못 찾으면 체크를 생성하지 않고 이탈
  • 문서의 품질이 곧 사용자 유지율에 직결됨

모바일 환경을 고려해 제품을 설계하라

  • 일반적인 생각과는 달리, B2B SaaS 사용자들도 스마트폰으로 업무를 시작함
  • 실제로 전체 사용자의 약 50%가 모바일에서 제품 사용을 시작
    • 계정을 만들고 몇 개의 페이지를 등록한 후, PC에서 다시 확인하는 흐름
  • 처음 6개월 동안 모바일 환경을 고려하지 않았고, 모바일 가입자는 대부분 이탈했음
  • 이후 반응형 UI를 도입한 결과, 모바일 사용자 유지율이 눈에 띄게 증가

사용자에게 유입 경로를 직접 물어보라

  • 1년차 중반에 도입한 가장 가치 있는 코드 변경 중 하나는
    • 가입 시 "어디서 OnlineOrNot을 알게 되었나요?" 라는 질문을 추가한 것
  • 사용자 유입 채널을 파악하는 것은 마케팅 효율 극대화에 매우 중요함
  • 마케팅 채널은 수십 개나 되지만, 집중할 수 있는 자원은 제한적임
  • 잘 작동하는 채널이 확인되면 그 채널에 집중 투자하고, 반응이 줄어들 때까지 지속함

침입적 분석 도구는 사용하지 않음

  • 처음에는 일반 SaaS 제품처럼 세션 추적, 퍼널 분석 도구를 도입했으나, 실효성이 낮았음
  • 대규모 팀에는 유용할 수 있으나, 소규모 서비스에는 랜덤한 결과로 오해할 가능성이 큼
  • 솔로 창업자로서 매일 아침 2시간밖에 없는 상황에서는,
    • 방대한 데이터를 분석하기보다는, 신뢰하는 사용자 그룹(inner-circle)에게 직접 의견을 받는 방식이 더 효과적이었음
  • 기능이나 문제점에 대해 감각적으로 피드백을 받고, 감성 기반 판단으로 제품을 개선함

기능이 없어도 잠재 고객과 대화하라

  • 어느 날 CTO로부터 특정 기능 지원 여부를 문의받았음
  • 원래는 "죄송합니다. 아직 없습니다"라고 끝낼 생각이었지만,
    • 호기심에 그들이 겪고 있는 문제와 해결하고자 하는 목표를 질문
    • inner-circle 사용자에게도 해당 문제를 겪는지 물어봄
    • 기능을 어떻게 설계할지에 대한 아이디어를 공유함
  • 결과적으로 이 CTO는 다음 날 유료 가입자가 되었고, 지금까지도 고객으로 남아 있음
  • 해당 기능은 다른 사용자들도 잘 활용하고 있음

문제 해결보다 플랫폼 구축에 더 많은 시간을 씀

  • 지난 4년간의 개발 시간 중 절반 이상은 SaaS 플랫폼 구축에 사용됨
    • 본래 목표인 “웹사이트 다운 여부 확인 및 알림”은 일부분일 뿐
  • 실제로 필요했던 기능들:
    • 다양한 인증 방식과 사용자 관리
    • 체험판, 온보딩
    • 반복적인 DB 작업, 팀 관리, 인보이스 처리
    • 라이프사이클 이메일 등
  • 일부는 Stripe 같은 서비스로 아웃소싱했지만,
    • 직접 처리하거나 개별화가 필요한 부분도 많아 결국 직접 구현

가격 책정은 정말 어려움

  • 가격이 너무 높으면 기대치가 올라가거나 아예 가입을 꺼림
  • 가격이 너무 낮으면 $9 낸 사용자가 전체 앱을 자기 입맛대로 고쳐달라고 요구하기도 함
  • 해법:
    • 까다로운 고객은 환불해주고 보내줌
    • 가격을 올리고, 다음으로 나아감
    • 특히 초기에 기능을 확장해 나갈수록, 지속적인 가격 실험이 필수적

MRR에만 집착하지 마라

  • MRR(Monthly Recurring Revenue) 는 사업 성과를 측정하기에 부적절한 지표일 수 있음
  • 몇 주 또는 몇 달 전에 했던 일이 지금의 MRR에 영향을 미치므로, 실시간 효과 측정이 어려움
  • 일부 SaaS 제품은 사용자가 가입 후 실제 결제까지 60일 이상 소요될 수 있음
  • 따라서 다른 지표를 통해 실제 사용 여부와 가치 전달 여부를 파악해야 함
    • 예: 생성된 이미지 수, 제출된 폼 수 등 행동 기반 성공 지표 사용 권장

“무제한 제공”은 절대 하지 마라

  • 항상 “무제한”을 최대한 활용할 사용자(whale customer) 는 존재함
  • 예: $250/월만 내고 엄청난 리소스를 사용하는 고객
  • 무제한이 제공하는 단위가 비용이 발생하는 항목이라면, 무조건 손해임
  • 이 조언은 라이프타임 딜에도 해당됨
    • $100에 평생 사용을 약속하면, 이후 수년간 기능 추가 요구를 받을 수 있음
    • 제3자 마켓플레이스를 이용했다면 실제 수익은 이 중 30%만 수령할 수도 있음
  • 결국 진짜 고객이 아닌, 단기적 이익을 원하고 오래 묶이는 사용자를 초대하는 꼴

유료 리소스는 반드시 rate limit 적용

  • AI, SMS, 이메일 전송 등의 유료 API를 사용하는 경우, 사용량 제한이 필수임
  • "유료 고객이니까 무제한으로 써도 되는 거 아닌가요?" → 예외적인 경우는 있을 수 있으나,
    • 대부분의 경우 비용 폭탄 또는 벤더로부터 스팸 레이블 위험 발생
  • 실제 사례:
    • WordPress 사이트 수백 개가 호스팅된 서버가 RAM 부족으로 오류 발생
    • 그 결과 수천 개의 SMS 알림이 자동 발송되어 큰 비용이 발생함
  • 진짜 대량 사용이 필요한 고객이라면 직접 연락을 해올 것임

한 페이지에 모든 걸 설명하려 하지 마라

"모든 사람에게 모든 것을 전달하려 하면, 아무에게도 아무것도 전달하지 못한다"

트래픽 늘리기는 어렵고, 전환율 개선은 지금 당장 가능함

  • 인터넷에서 주목받는 것은 장기전이며 매우 느림
    • 꾸준히 양질의 콘텐츠 마케팅을 해도, 12명의 방문자가 수백 명으로 늘기까지는 수개월수년 소요
  • 트래픽 자체를 늘리는 것은 쉽지 않음
  • 반면, 이미 온 사용자들의 행동은 즉시 바꿀 수 있음
    • 예: 가입 폼에 OAuth 로그인 옵션을 추가하는 것처럼, 오늘 적용 가능한 개선이 전환율을 높임

경쟁자는 그렇게 중요하지 않음

  • 이 글 전체에서 경쟁자 이야기가 거의 없는 이유는 실제로 큰 영향을 미치지 않기 때문임
  • 물론 기본적인 기능은 갖추어야 고객이 고려 대상에 올리지만,
    • 진짜 경쟁자는 사용자가 이 제품의 존재 자체를 모르는 것
  • 기능보다도 인지도와 접근성이 핵심 경쟁 요소임

정말 배울 게 많은 글이네요. 아침에 2시간씩 활용하여 글도 쓰고 여러 프로젝트도 완성하다니...!

혼자서 SaaS를 1년 운영해보고 배운 것
벌써 3년이 지났네요 ㅎ 바뀐 내용을 비교하면서 보세요!

배울 게 많은 글입니다. 결국 SaaS도 고객이 문제를 해결하기 위해 고용하는 제품이라는 사실을 잊지 않아야 합니다.