74P by xguru 2달전 | ★ favorite | 댓글 4개
  • 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 알림이 자동 발송되어 큰 비용이 발생함
  • 진짜 대량 사용이 필요한 고객이라면 직접 연락을 해올 것임

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

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

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

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

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

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

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

서비스를 운영하는 입장에서 많은 내용이 공감됩니다.
저도 잠을 줄여가며 개발했었는데, 건강이 안좋아졌어요..

비슷한 경험을 가진 분들께 궁금한점은 이런 시간 투자가 육아를 하면서 가능한지 입니다.
출퇴근 시간과 회사에 머무는 시간, 집에서 아이들과 있는 시간이 하루의 거의 대부분을 차지하기 때문에, 이런 서비스를 만들고 운영하기 위해서는 다른 뭔가를 포기해야 하게 되는데, 그게 가족, 건강이 아니었으면 좋겠어요..

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

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