SaaS 제품 PO가 데이터로 일한다는 것

B2B 제품의 data-driven (informed) 결정

트래픽 20만 이하에선 A/B 테스팅 하지 말아라

A/B 테스팅의 세계적인 권위자이자 컨설턴트인 Ron Kohavi가 Airbnb, Amazon, Microsoft와 같은 글로벌 테크 회사에서 "데이터 기반 실험"관련 팀을 수년간 리딩하며 얻은 교훈은 바로 이것이었다고 한다.

트래픽이 20만명 미만일 경우에는, 큰 임팩트를 측정하기 어렵다. 찾아도 1% 인 경우가 많은데, 스타트업은 뚜렷한 성과 지표, 5% 정도는 쫓아야 한다. 트래픽 20만 이하에서는 그런 지표를 찾기 어렵다.

First of all there are some necessary elements of A/B testing. You cannot A/B test M&A, you cannot A/B test if you don't have enough users. If you are too early (...) Unless you have tens and thousands of users, the math does not run. Only when you have enough users you can test magic. Rule of thumb- 200,000 users. Below that start building the culture and platform.
(출처: Lenny's Newsletter, https://www.youtube.com/watch?v=hEzpiDuYFoE)

SaaS 제품에 실시간 트래픽이 20만이 되려면 얼마나 많은 고객사를 유치해야할까? 세계적인 실리콘벨리 SaaS 기업인 Asana의 유료사용자수가 12만명이라고 한다. Figma의 사용자수는 400만. 불가능하진 않지만, 못해도 Asana, 잘하면 Figma 수준으로 제품이 성장해야 Kohavi가 말한 "제대로 된, 의미있는 임팩트를 낼 수 있는" A/B 테스팅을 할 수 있을 것이다.

물론 Kohavi가 말한 규칙이 항상 옳지는 않을 것이다. 한가지 확실한 것은 B2B 에서 데이터를 사용하는 방식과 B2C에서 데이터를 사용하는 방식이 같을 수 없다는 것이다.

B2B는 B2C와 다르다

B2C는 사용자와 구매자 페르소나가 일치해 사용자의 행동과 비즈니스 성과의 상관관계를 직관적으로 이해하기 쉽다. 예를 들어  e-commerce에서는 사업의 성패가 "매출" (상품 판매량)과 직결되기 때문에 장바구니 가격이라는 North Star를 지정하고, 전사가 이에 맞추어 일을 할 수 있을 것이다. 앱 진입부터 결제까지 퍼널을 정의해 각 퍼널별 전환율을 개선하고, 한 달에 n번 구매하러 돌아오는 리텐션을 개선하고, 마케팅을 통해 퍼널 앞단에 진입하는 사용자의 수를 개선하고, 장바구니에 들어가는 금액의 크기, 혹은 재구매를 하러 들어오는 횟수를 늘릴 수 있을 것이다. 그리고 트래픽의 양이 절대적으로 많아, 제품팀이 실험을 하고, 그 성과를 측정하는 것이 유의미한 경우가 많을 것이다.

할인 전략으로 트래픽을 늘려서 주간 장바구니 금액이 늘어나는지 낮아지는지 실험해봐도 좋을 것 같다. B2C에선 흔할 것이다

B2B SaaS 제품은 트래픽량이 B2C 만큼 높을 수 없다. 무엇보다도 사업 특성상 사용자와 구매자가 다른 경우가 많기 때문에 비즈니스 성과 측정시 실제 사용자의 행동이나 사용량도 중요하지만 바이어 페르소나의 만족도 (NPS, PMF score), 사용자 페르소나의 워크플로우 효율화 (ex. 탐색 시간 개선) 등 B2C에서는 잘 보지 않는 지표들로 제품의 성과를 측정하게 된다.

내가 맡고 있는 제품처럼, 다루는 페르소나가 많고 워크플로우가 복잡 다난한 제품일수록 그런 단 하나의 지표를 찾기 어렵다. 월간 재구매율 (MRR)이나 연간 재구매율 (ARR) 같은 사업지표는 후행 지표인 경우가 많아 제품팀이 보고 일하기에는 부적절하다.

B2B의 핵심을 공략하자

입사한 이래 약 16개월간 탐색 끝에 내린 결론은, 워크플로우 별 성공 지표를 찾는 것이었다. 어쨌든 SaaS 사용자는 자신의 워크플로우를 효율화하기 위해 제품을 구매한다. SaaS 제품이 돈을 벌기 위해서는 사용자가 워크플로우 효율화를 체감하고, 제품 구매의 가치를 느껴야한다. 가치를 느끼는 그 순간 (오! 편했다~)를 데이터로 확인할 때, 사용자의 가치를 보다 명확하게 진단하고, 개선점을 찾을 수 있을 것이다.  

예를 들어, 내가 채용 담당자를 위한 SaaS를 만든다고 해보자. 채용 담당자는 후보자 이메일을 아웃바운드를 통해 수집한 이후 아래와 같은 워크플로우를 거친다.

- 이메일을 전송한다.

- 답신이 오지 않는다면 재전송한다.

- 만약 답신이 온다면 커피챗 제안용 문자를 보낸다.

- 답장이 온다면 커피챗을 위한 회사 소개서를 전송한다.

- 커피챗을 진행한다.

SaaS 없이 일하는 채용 담당자는 채용 후보자가 100명이면 100명에 대해 이 작업을 해야한다. 반복적이고 귀찮다.

채용담당자 A씨는 이 과정의 지난함에 지쳐 이메일만 입력하면 이후 과정을 자동화해준다는 SaaS 제품의 무료체험을 신청했다. 이전에는 퍼널의 모든 워크플로우를 지원자 수 만큼 진행해야했다면, 이제는 앞단의 작업만 수행하면 된다. 워크플로우가 크게 단축되었다.

만약 내가 이 기능을 만들었다면, 선행지표로 후보자 이메일을 제품에 입력하는 순간 (Wow를 느낄 수 있는 순간, "이것만 하면 되네"), 그리고 후보자와 커피챗을 하는 순간 (진정한 성공 경험), 그리고 후보자 이메일을 다시 입력하는 순간들을 볼 것 이다. 만약 리서치 결과 채용 담당자들이 주간 평균 10건의 후보자 이메일을 수집하는데, 우리 제품에 수집하는 이메일의 수가 주간 평균 10건 이하거나, 사용자들이 입력 이후 다시는 사용을 하지 않는다면 무언가 문제가 있는 것이다. 아마 사용자가 오류를 겪었거나 이메일을 입력하는 순간이 무척 불편했을 수 있다. 혹은, 해당 워크플로우에서 사용자가 가장 번거로웠던 단계는 이메일 수집 이후 단계가 아니라, 이메일 수집 그 자체였을 수도 있다. 채용담당자 A씨와 같은 무료체험 사용자들의 무료체험 이후 이타률을 후행지표로 관리할 수 있을 것이다.

결국 중요한 건

트래픽이 많지 않고, A/B 테스팅 (흔히 생각하는 "데이터 기반 의사결정"의 예시)를 시도할 수 없더라도 데이터를 봐야하는 이유는 결국 사용자를 더 잘 이해하고, 제품의 성공 여부를 진단하고, 더 나은 제품을 만들기 위해서라고 생각한다. 목적만 명확하게 정해져있다면 트래픽이 많지 않더라도, A/B 테스팅을 하지 않더라도 지표를 정의할 수 있다. Hotjar로 사용자가 어려움을 겪는 부분을 짚어낼 수 있고, 사용 행태를 DB에서 짚어낼 수 있다.

처음 이 회사에 입사했을 때 DB 접근 권한을 요청하고, 아무도 요청하지 않은 쿼리를 짜고, 사용 현황을 공유하는 것이 쉽지는 않았지만 (흑흑) 그래도 지난 18개월을 돌아보았을 때를 생각하면 드디어 제품 조직에 데이터가 중요하다는 의견이 많이 형성된 것 같아 뿌듯하다. 사용자는 실제로 어떻게 사용하고 있나요? 사용자는 가치를 느끼고 있나요? 에 대한 답을 찾는게 PO의 일인 만큼 SaaS든 웹이든 모바일이든, B2B이든 B2C이든 그 답을 찾기 위해 정진해야겠다. 끗.