HyperGrowth B2B SaaS 기업의 Scaling Issue - Notes #10

** 이 글은 웹사이트에 최적화된 글입니다. 이메일안의 링크를 클릭하여 웹사이트에서 읽으시면 더 편안히 읽으실 수 있으십니다.

안녕하세요 사스덕후 구독자 여러분, 

마지막 뉴스레터의 성공하는 SaaS 제품이 밟는 11가지 과정 A.k.a 커뮤니티형 성장엔진 이후 정말 오랜만에 인사드립니다. 자주 글 발행하지 못 한 점 정말 죄송하게 생각하고 있습니다... 유료 구독자분들께는 현업에서 배우는 내용을 정리하여 글에 녹이지 못하고 있는 내용들을 Virtual Zoom Session을 진행하며 공유드리고 함께 성장하는 배움의 기회로 삼고 있습니다.

저번 뉴스레터에서 다루어졌던 원래 온보딩에 관해서 이야기를 하려고 했으나 온보딩에 앞서 선행되어야하는 Task인 Customer Journey Map 작업을 시작하기까지 제 머리속을 지나간 생각들에 대해 정리해보고 그 내용을 공유하려고 합니다. 

Onboarding is a subset of the customer experience

제가 온보딩에 집중했던 이유는 "처음 제품/서비스를 사용해보는 경험을 최대한 고객맞춤화하여 제품의 Aha moment의 성공적 랜딩을 하고 제품의 full value를 체험하는 Wow moment을 경검하면 고객들이 Support ticket을 제출하지 않아도 되며 churn (이탈)을 방지할 수 있지 않을까?" 였습니다.

그래서 온보딩을 한참 공부하던 중 동료분과 "온보딩에 집중해야하는 이유"에 관해 이야기하다가 깨닫게 된 것이 있습니다.

어쩌면 onboarding이 아무리 잘 된 고객들도 이전 고객 여정의 stage에서 제대로 완료되었어야할 항목들이 제대로 진행되지 않으면 churn이 될 수 있다는 것입니다. 덧셈을 제대로 할 줄 모르는 상태에서 다음 학년으로 진학한다고 곱셈을 잘 할 수 없는 것과 비슷하다고 볼 수 있습니다. 

아마존, 쿠팡 등의 이커머스 서비스를 이용하여 제품을 구매하고 반품하는 경험

이해를 돕기 위해 저의 경험을 예시로 들어보겠습니다. 
저는 골프를 좋아하여 집 뒷마당에 골프 연습장을 만들어본 경험이 있습니다...(이 돈으로 연습장가셔요ㅎㅎ) 구매 전 저의 뇌 속 상상회로에서 돌아간 모습은 아래의 그림과 같았고 인스타그램의 영상에서 완벽하게 구동되는 모습에 실내 골프 네트의 상품을 보고 단숨에 구매를 해버렸습니다... 

물건이 도착하기 전 기대감과 상상력은 극에 닿았고 매일 같이 문 앞에 배송된 소포가 없는지 확인하는 지경에 이르렀습니다. 드디어 제품이 도착하였고 제품을 받자마자 바로 설치하여 상상만하던 "뒷마당 골프연습장"의 첫 테스트 샷을 해보았습니다.

... 

...

...

네, 네트에는 구멍이 났고 네트 뒤에 있던 나무 담벼락에 공이 맞으며 큰 소리를 내고 반사된 공은 다시 그물의 바깥쪽 뒤쪽에 soft(?!) 랜딩하였습니다... 

네 제가 생각했던 경험과는 너무나도 다른 경험을 준 이 경험에 저의 심정은 당황함으로 시작하여 배신감의 감정구간간을 지나 "내가 잘 알고 샀어야하는데 내 잘못이야 그래.." 라는 자아성찰의 경로로 변하였습니다. 

이 에피소드에서 가장 중요한 부분은 "저는 다시는 이 제품을 구매하지 않을 것이며 주변에 구매하려는 사람들이 있다면 극구 말릴 것이다" 입니다.  정리를 하자면 구매전 기대치 (pre-sales expectation)이 구매 후 가치 (post-sales value)보다 높았기 때문입니다. 즉, 구매하기 전에 기대했던 주요 제품기능, 서비스 경험 등이 구매 후의 그 경험과 너무나도 달랐기 때문에 churn이 됨과 동시에 detractor가 되어버렸습니다. 

Negative WOM (Word of Mouth)

이 경험을 한 후 제가 든 생각은 "우리 회사에서도 누군가에는 이런 경험을 선사하는건 아닌가?" 였습니다.

물론 이커머스에서 판매하는 대부분의 제품은 전세계를 대상으로 한 번 물건을 팔아도 엄청난 매출과 수익이 날 수 있고 재구매 사이클이 길지 않기 때문에 이런 경험을 하여도 크게 문제가 되지 않을수도 있습니다. 어차피 구매자수가 워낙 많고 제가 모든 잠재고객에게 이 제품을 사지 않도록 영향을 끼치는 것은 현실적으로 불가능하기 때문입니다.

하지만 이전 글 SaaS 수익모델의 특징에서 알아본 SaaS의 주요 수익 모델인 "subscription"에 있어 재등록/구매율은 치명적으로 중요합니다.  즉, 한 순간의 제품을 팔기에 급급하여 진행된 over-selling은 순간의 매출 증대에는 도움이 되겠지만 재등록/구매로 이루어지지 않을 것이고 오히려 고객의 신뢰에 큰 상처만 주어 재구매를 넘어 아래 성장 엔진의 5번에 해당되는 Positive WOM(Word of Mouth)가 아니라 나쁜 소문만 내는 Negative WOM로 탈바꿈하는 상황을 만들어버립니다. 

이렇게 한 번 잃어버린 신뢰를 되찾는데는 (Win back) 처음 판매를 했을 때(First win)보다 배수가 되는 노력과 시간이 필요합니다.

Scaling adds another layer of SERIOUS complexity and challenges (Feat. Sales Lifecycle and Team & Roles)

"그렇다면 단순히 over-selling만 하지 않으면 되는거 아닌가요?" 라는 질문을 할 수 있습니다. 

"네, 일단은 그렇습니다" 가 저의 답변이고 pre-sales 구간에서 overselling을 안하는 것만으로도 기대 가치 미스매치 (value mismatch) 로 인한 churn을 어느정도 막을 수 있다고 생각합니다.

하지만 여기서 한가지 알아두어야할 점은 개인의 레벨에서 운영되는 sole 세일즈엔진에서는 혼자서 판매상담 -> 판매완료 -> 고객지원 까지 진행되는 일체형 경험을 제공하는게 logistic한 부분에서 충분히 가능하지만 조금만 인원이 늘어서 다수의 구성원이 생긴 기업의 레벨에서 운영되는 세일즈 엔진은 상당히 분업화되어있다는 것입니다. 

위의 다이어그램에서 살펴보면 알 수 있듯이 B2B SaaS 기업에서의 고객과의 접점 (customer's touchpoint)에 있는 role들은 상당히 세분화 되어있습니다. 

Pre Sales

처음 Marketing 팀이 열심히 땀을 흘려 만든 콘텐츠, 이벤트 등을 통해 고객이 기업/제품에 대해 알게되고 SDR(Sales Developments Representative)팀이 이렇게 awareness/recgonize이 된 고객들 혹은 기업에서 타겟으로 하거나 회사의 제품으로 인해 성장을 할 수 있을 것 같은 잠재고객을 outbound로 initial meeting을 잡습니다.
그리고 AE (Account Executive) 또는 SAE (Strategic Account Executive)팀은 미팅을 진행하며 제품의 business value와 success criteria metrics을 define하고 deal을 close 합니다. 이 과정에서 SE (Sales Engineer)는 우리 회사의 제품/기능이 고객의 Requirement에 기술적으로 충족시킬 수 있는지 feature validation 및 PoC (Proof of Concept) Project management을 합니다.

Post Sales

이렇게 최소한의 기능이 고객사의 시스템에 구현/도입되는 것을 확인하는  PoC가 성공적으로 진행되고 고객이 돈을 지불하는 paying customer가 된 경우 CSM(Customer Success Manager)가 AE/SAE가 고객과 살펴보았던 Business Value가 실제로 회사의 제품을 통해 달성되었는지 Success Criteria Metrics를 살펴보며 Before/After를 분석하고 value assessment 및 value realization을 달성하는 business onboarding을 하고 추가적으로 고객들이 우리 회사의 제품/서비스를 통해 어떻게 하면 더 성공할 수 있을까 같이 고민하고 또 고민하고 도울 수 있는 부분이 있는지 파악한 후 VoC (Voice of Customer)를 통해서 팀 내부로 전달합니다. CSM과 함께 Solutions Engineer는 SE가 구축해두었던 PoC technical plan을 이어받아 최소 검증 단계를 넘어서 실제 고객사의 제품 전체적으로 확장 구현/도입을 통해 production level에서의 launch를 목표로 technical onboarding을 합니다. 그리고 마지막으로 AM(Account Manager)는 성공적으로 런칭을 해서 제품을 사용하는 고객들의 usage growth 모니터 및 신규 기능 런칭 통한 추가 딜을 따냅니다. 

All Stages

고객과 직접적으로 접점을 구축하지는 않지만 Product Engineer 과 Design는 고객이 받고 경험하게될 제품의 기능을 만들고 그 위에 디자인과 인터페이스를 입힙니다. 고객과도 접점도 가지고 가며 전체적인 고객과의 touch points와 공통접점을 가지고 최고의 engineer, design분들과 함께 고객의 문제를 해결해줄 수 있고 시장이 요구하는 필요한 제품을 만들고 고객에게 잘 전달될 수 있도록 연결다리 역할을 하는 PM (Product Manager). 마지막으로 위의 모든 팀이 돈, 건강, 환경 모두 걱정없이 고객의 성공에 집중해서 일할 수 있게 도와주는 반석이 되는 역할을 하는 Foundation team이 있습니다.

Hypergrowth Early Stage 기업의 Scaling Issue

짧게나마 정리해서 적어본 위의 과정만으로도 더 많은 고객들의 수요를 맞춰주기 위해 구조적으로 scaling을 하여 기업화와 분업화가 되면서 어쩔 수 없이 1인 세일즈엔진에서는 없던 hand-off 과정이 상당히 많이 그리고 복잡하게 생겨난다는 것을 알 수 있습니다.

대부분의 초기 기업들이 전체적인 숲을 보지 못하고 나무만 보며 생존을 위한 급하게 성장을 하기 때문에 각 팀의 역할을 정의하고 빠른 하이어링을 통해 volume expansion형의 scale-up을 합니다.  

이 때 기억해야할 중요한 부분은 팀의 volume expansion 은 process 및 output expansion으로 이루어지고 결국 system expansion으로 이어집니다. 즉 각기 다른 나무들이 점점 더 몸집과 수를 넓혀가고 그 나무 그룹만의 생태계와 룰을 만들어간다고 생각하시면 됩니다.  이렇게 빠르게 성장을 하려는 마음이 커지면 volume expansion과 함께 이루어져야할 efficiency(cross-functional communication, process agreement, ownership distribution) 및 density은 그 속도를 못 따라가는 결과가 발생합니다.

즉, 사람은 많아지고 프로젝트도 많아지고 성과도 많아지는데 전체적인 balance와 harmony가 없어지며 프로젝트와 성과가 각기 노는 상황이 발생되며 synergy 효과는 커녕 각 부서가 일을 더 하면 더 할 수록 소통의 갭은 커지고 점점 더 꼬여가는 실타래 혹은 잡종의 나무의 종들이 가득해지고 질서는 없는 숲이 되버립니다.  회사 전체적인 차원에서 실타래를 풀지 않으면 "이건 우리팀에서 해야하는 일인데 왜 저쪽에서 하고 있지? "이건 내가 예전에 조금 작업해놓았던 일인데 왜 저 부서에 처음부터 새로 시작하려고하지?" "저 팀에서 완료한 프로젝트가 우리 팀에게 엄청난 양의 일이 되어버렸는데 왜 이건 사전에 말을 안했지?" 식으로 연관부서/팀원들  (Partner team) 간에 구조상에서 발생되었지만 팀원들은 없는 갈등이 생길수가 있고 이 갈등은 회사 팀원들의 잦은 이탈이라는 모습으로 드러나게 됩니다 .

이를 해결하기 위해서 초기 hyper growth를 하는 기업들에게 있어 생존이 목표였던 시절의 소수를 위한 빠른 제품 생산/출시/수정의 모델에서 더 많은 수의 고객들을 위한 빠르지만 단단하고 디테일이 살아있는 제품 생산/출시/수정이 가능한 큰 톱니바퀴와 작은 톱니바퀴들이 잘 섞여서 돌아가는 시스템을 돌릴 수 있도록 기어들의 재구성 및 변속이 중요해집니다.

특히 투자를 받은 기업들은 투자받은 돈을 이용해서 업계의 전문가들을 수소문하여 모셔오고 모셔온 업계 전문가들은 각 팀의 구성원의 목표를 설정하고 기존에 같이 일을 하며 호흡을 맞추어왔던 전 회사 동료들부터 시작해서 여기저기 수소문하여 팀을 꾸려갑니다. 그리고 리더십 분들같은 경우 회사에 들어올 때 상당히 무거울 수도 있는 임무를 약속하고 들어오기 때문에 밤낮안가리고 죽을 듯이 일하면서 단기간에 성과를 내어 자신의 가치를 증명하려는 경향이 생깁니다.

이게 정말 어려운 이유는 개인/소규모팀에서 의사결정내리고 진행하는 것이 미덕이고 현재까지의 성공의 근간이라고 생각했던 마인드를 가진 과거의 자신을 unlearn 및 re-hire하여 현재 우리가 진행할 프로젝트가 다른 팀들에게 어떤 영향을 미치고 어떻게 해야지 시너지효과를 낼수 있을지 고객의 입장에서 철저하게 꼼꼼하게 생각하며 실행하겠다는 조금 더 시스템적인 사고를 하려는 마인드가 필요합니다.

다음에 기회가 되면 (=회사가 이 문제를 잘 해결해서 제가 그 경험을 하게된다면) 빠른 성장에 맞춰서 스케일링 이슈를 기업구조적으로 어떻게 해결할 수 있었는지 공유하도록하겠습니다
(극복 못 하면 시도해본 노력과 실패담이라도...ㅠㅠ)

글을 마치며

이번 글에서는 customer experience의 한 부분인 Onboarding의 세부사항을 적기에 앞서 SaaS 기업의 팀, 롤 구조를 high level에서 살펴보았으며 회사가 빠르게 성장하며 마주치게되는 Scaling Issue를 알아보았습니다. 다음 글에서는 이 문제들을 해결하기 위해 onboarding을 넘어서 우선적으로 구축되어야하는 Customer Journey Map의 필요성, 세부사항, mapping 의 과정 등을 살펴보려고 합니다. 

추가 공지

추가적으로 제가 다루었으면 하는 소재는 질문지 혹은 코멘트를 남겨주시면 가능한 범위내에서 글을 적어보도록 하겠습니다