우리의 프로젝트 관리 시스템이 진행 중인 오픈 베타를 갖고 있는 이유를 알아보세요.
많은 B2B SaaS 스타트업들이 베타 버전으로 출시하며, 그럴만한 이유가 있습니다. 이는 전통적인 실리콘 밸리의 모토인 *“빠르게 움직이고, 문제를 일으켜라”*의 일환입니다.
제품에 “베타” 스티커를 붙이면 기대치가 낮아집니다.
무언가가 고장났다고요? 아, 그건 그냥 베타입니다.
시스템이 느리다고요? 아, 그건 그냥 베타입니다.
문서가 존재하지 않나요? 아, 그건… 당신이 이해했겠죠.
그리고 이것은 실제로 좋은 일입니다. LinkedIn의 창립자인 리드 호프먼은 유명하게 말했습니다:
제품의 첫 번째 버전이 부끄럽지 않다면, 당신은 너무 늦게 출시한 것입니다.
그리고 베타 스티커는 고객에게도 좋습니다. 고객들이 스스로 선택할 수 있도록 도와줍니다.
베타 제품을 시도하는 고객들은 기술 수용 주기의 초기 단계에 있는 사람들로, 제품 수용 곡선이라고도 알려져 있습니다.
기술 수용 주기는 일반적으로 다섯 개의 주요 세그먼트로 나뉩니다:
- 혁신가
- 초기 수용자
- 초기 다수
- 후기 다수
- 지체자
하지만 결국 제품은 성숙해야 하며, 고객들은 안정적이고 작동하는 제품을 기대합니다. 그들은 문제가 발생하는 “베타” 환경에 접근하고 싶어하지 않습니다.
그렇다면 그들은 정말로 원하지 않을까요?
이것이 우리가 스스로에게 던진 질문입니다.
우리는 블루가 처음 구축된 방식 때문에 이 질문을 던졌다고 믿습니다. 블루는 바쁜 디자인 에이전시의 분파로 시작되었습니다, 그래서 우리는 블루를 사용하여 모든 프로젝트를 운영하는 비즈니스의 사무실 내부에서 일했습니다.
이는 수년 동안 우리가 진짜 인간들이 — 바로 옆에 앉아 있는! — 블루를 일상에서 어떻게 사용하는지를 관찰할 수 있었음을 의미합니다.
그리고 그들이 초기부터 블루를 사용했기 때문에, 이 팀은 항상 블루 베타를 사용했습니다!
그래서 모든 다른 고객들도 사용할 수 있도록 허용하는 것이 자연스러웠습니다.
이것이 우리가 전담 테스트 팀을 두지 않는 이유입니다.
맞습니다.
블루의 누구도 우리의 플랫폼이 잘 작동하고 안정적이라는 것을 보장하는 단독 책임을 지고 있지 않습니다.
이는 여러 가지 이유 때문입니다.
첫 번째는 낮은 비용 구조입니다.
전담 테스트 팀이 없으면 비용이 크게 줄어들고, 우리는 이러한 절감을 고객에게 업계에서 가장 낮은 가격으로 전달할 수 있습니다.
이를 관점에서 보면, 우리는 경쟁사가 사용자당 월 $30-$55를 청구하는 기업 수준의 기능 세트를 단 $7/월에 제공합니다.
이것은 우연히 발생하는 것이 아니라, 계획된 것입니다.
하지만 작동하지 않는 저렴한 제품을 판매하는 것은 좋은 전략이 아닙니다.
그래서 진짜 질문은, 어떻게 우리는 전담 테스트 팀 없이 수천 명의 고객이 사용할 수 있는 안정적인 플랫폼을 만들 수 있을까요?
물론, 우리의 오픈 베타 접근 방식이 이에 결정적이지만, 이에 대해 논의하기 전에 개발자의 책임에 대해 이야기하고 싶습니다.
우리는 블루에서 프론트엔드와 백엔드 기술의 책임을 나누지 않겠다는 조기 결정을 내렸습니다. 우리는 오직 풀 스택 개발자만을 고용하거나 교육할 것입니다.
우리가 이 결정을 내린 이유는 개발자가 자신이 작업하는 기능을 완전히 소유하도록 보장하기 위해서였습니다. 그래서 기능에 대한 공동 책임이 있을 때 종종 발생하는 “문제를 정원 울타리 너머로 던져버리는” 사고방식이 없도록 하기 위함입니다.
그리고 이것은 기능의 테스트, 고객 사용 사례와 요청을 이해하는 것, 사양을 읽고 의견을 제시하는 것에도 적용됩니다.
다시 말해, 각 개발자는 자신이 구축하는 기능에 대한 깊고 직관적인 이해를 쌓습니다.
이제 우리의 오픈 베타에 대해 이야기해 보겠습니다.
우리가 “오픈”이라고 말할 때 — 우리는 진심입니다. 어떤 고객이든 웹 애플리케이션 URL 앞에 “beta”를 추가하기만 하면 시도할 수 있습니다.
그래서 “app.blue.cc”는 “beta.app.blue.cc”가 됩니다.
이렇게 하면 고객은 일반적인 데이터를 볼 수 있으며, 베타와 프로덕션 환경이 동일한 데이터베이스를 공유하기 때문에 새로운 기능도 볼 수 있습니다.
고객들은 프로덕션에 있는 팀원과 베타에 호기심이 있는 팀원이 있어도 쉽게 작업할 수 있습니다.
우리는 일반적으로 수백 명의 고객이 베타를 사용하고 있으며, 커뮤니티 포럼에 기능 미리보기를 게시하여 그들이 새로운 것을 확인하고 시도할 수 있도록 합니다.
그리고 이것이 핵심입니다: 우리는 수백 명의 테스터가 있습니다!
이 모든 고객들은 그들의 작업 흐름에서 기능을 시도하고, 무언가가 잘못되면 꽤 목소리를 높입니다. 왜냐하면 그들은 이미 그 기능을 자신의 비즈니스에 구현하고 있기 때문입니다!
가장 일반적인 피드백은 우리가 고려하지 않은 엣지 케이스를 해결하는 작지만 매우 유용한 변경 사항입니다.
우리는 새로운 기능을 베타에서 2-4주 동안 유지합니다. 안정적이라고 느낄 때 프로덕션으로 출시합니다.
우리는 또한 필요할 경우 빠른 경로 플래그를 사용하여 베타를 우회할 수 있는 능력이 있습니다. 이는 일반적으로 프로덕션으로 배송하기 전에 2-4주 동안 기다리고 싶지 않은 버그 수정에 대해 수행됩니다.
결과는?
프로덕션으로 푸시하는 것은… 음, 지루하게 느껴집니다! 아무것도 아닌 것처럼 — 우리에게는 큰 일이 아닙니다.
그리고 이는 우리의 릴리스 일정을 원활하게 하여, 지난 6년 동안 매달 시계처럼 기능을 배송할 수 있게 해주었습니다..
하지만 어떤 선택이든 몇 가지 트레이드오프가 있습니다.
고객 지원은 약간 더 복잡해집니다. 두 가지 버전의 플랫폼에서 고객을 지원해야 하기 때문입니다. 때때로 이는 두 가지 다른 버전을 사용하는 팀원이 있는 고객에게 혼란을 초래할 수 있습니다.
또 다른 문제는 이 접근 방식이 프로덕션으로의 전체 릴리스 일정을 가끔 지연시킬 수 있다는 것입니다. 이는 특히 문제가 있는 다른 관련 기능이 있을 경우 베타에서 “갇힐” 수 있는 더 큰 기능에 해당됩니다.
하지만 전반적으로 우리는 이러한 트레이드오프가 낮은 비용 구조와 더 큰 고객 참여의 이점에 가치가 있다고 생각합니다.
우리는 이러한 접근 방식을 수용하는 몇 안 되는 소프트웨어 회사 중 하나이지만, 이제 이는 우리의 제품 개발 접근 방식의 기본적인 부분이 되었습니다.