0. 어떤 사람들이 참고하면 좋을까요?

• 경영진의 강력한 직관으로 series A단계까지 도달했으나, 이제는 데이터도 활용하면서 의사결정을 할 필요가 있다고 느낀 경영진, PM
• 아직까진 확장보다는 ‘생존’이라는 키워드가 더 중요한 스타트업이지만, (요즘 핫하다는)실험을 통한 제품 개선을 시도해보고 싶은 경영진, PM

초기 스타트업도 실험할 수 있다!

사용자 수도 얼마 없는 초기 스타트업 입장에서, 실험 많이 돌리면서 지표도 개선하고 배움도 꾸준히 누적하고 있는 멋진 스타트업들을 보면 부러울 수밖에 없습니다. 그렇지만 우리에게 실험은 아직 무리.. 지금은 계속해서 고객을 만나면서 정성적 데이터를 쌓는게 최선일지도 모릅니다. (참고 - 클래스101은 어떻게 A/B테스트를 한 달에 100개씩 돌리게 되었나)

하지만 완전 극초기를 넘어 (여전히 초기이긴 하지만) 어느정도의 DAU/MAU 수가 나오는 스타트업이라면! ‘우리도 실험 한 번 해보자’라는 말이 내부에서 스멀스멀 올라오고 있을 수 있습니다.

제가 있는 곳이 그렇습니다. 그래서 이 글은 저와 비슷한 스테이지의 스타트업에 계시면서 어쩌다 실험 담당자로 뽑힌 분(아마 그로스 어쩌구? PM 어쩌구로 불리고 계신 분)과 티타임을 하고 있다는 마음으로 작성했습니다. 이제 막 첫 실험을 준비중이신 분이라면, 이런 관점으로 실험을 보는 사람도 있구나 정도로 참고해주시면 좋을 것 같습니다. 이미 실험 운영 경험이 많거나, 초기가 아닌 series B 단계 이상의 스타트업에 계신 분이라면 이 글을 과감히 스킵해주시면 감사하겠습니다(제가 너무 부끄럽습니다).

💡 주의 : 이 글을 쓴 사람은 극초기 스타트업의 PM이고, 아직 인생에서 한번도 MAU 100만 이상의 서비스를 운영해 본 적 없는 초짜입니다. 따라서 이 글은 지식 또는 지혜가 아닙니다. 어느 초보 PM의 사적인 의견일 뿐입니다. 혹여라도 잘못된 의견을 가지고 있는 것 같다는 생각이 드신다면 글쓴이의 성장을 위해 피드백을 남겨주시면 진심으로 감사드리겠습니다.

1. 우선순위를 정할 마땅한 프레임워크가 없을 때는 ICE 프레임워크를 쓰자.

실험을 집행하려면 우선 ‘가설’이 있어야 합니다. 제품을 사랑하는 팀원들이라면 분명 각각의 팀원들 모두 ‘이렇게 하면 고객이 더 좋아할텐데’라는 가설을 가지고 있을 것입니다. 실험 담당자는 각 구성원의 가설을 수집하는 것부터 시작해야 합니다. 가설 수집을 위한 미팅을 여시고, 자유롭게 머릿 속에 있던 가설을 말씀해달라고 하세요. 아마 처음에 팀원들은 가령 ‘랜딩페이지 CTA 문구를 ‘지금 바로 견적 받기’로 수정하면 더 좋을 것 같아요’라는 식으로 말씀하실 겁니다. 그럴 때마다 실험 담당자님께서는 ‘랜딩 페이지 CTA 문구를 ‘지금 바로 견적 받기’로 수정하면, 어떤 고객(A)의 어떤 문제(B)가 해결되어서, 어떤 지표(X)가 올라갈 것 같으신가요?‘라고 재질문을 해주셔야 합니다. 그러면 그제서야 ‘랜딩 페이지 CTA 문구를 ‘3초만에 견적 받기’로 수정하면, 견적을 빨리 받고 싶은 고객들(A)이 지금 바로 견적을 받을 수 있다는 걸 알게 되어서(B), 견적 신청 전환율(X)이 증가할 것 같아요’라고 말씀해주실 겁니다.

이렇게 가설을 하나하나 수집하다보면 꽤 많은 가설이 쌓이게 될 텐데요. 이 가설들 중에서 뭐가 가장 중요한지를 무작정 토론을 하게 되면 그 토론은 끝이 없을 거에요. 이럴 때 빠르게 우선순위를 정할 수 있도록 도와주는 가장 보편적인 방법이 ICE 프레임워크입니다. 별도의 우선순위 프레임워크가 없다면 ICE 프레임워크를 사용하시면 됩니다 (참고 - ICE 프레임워크 : 빠른 실험을 돌리는 방법)

저희 회사에서는 위와 같은 기준을 가지고 ICE 점수를 메기고 있습니다. ICE 점수는 상대 점수이기 때문에 동일한 기준으로 점수를 메기는 것이 중요합니다.

일반적으로 실험 담당자가 Impact와 Confidence 점수를 우선적으로 메기고, 메이커 역할을 하는 디자이너와 엔지니어와 함께 Ease 점수를 메깁니다. 그리고 최종 가설 선정 미팅에서 메겨진 I, C, E 점수에 대해서 다른 의견을 가지고 있는 사람은 없는지, 있다면 왜 그런지 등을 논의하면서 점수를 조정합니다.

그렇게 점수 조정까지 끝나면, 상위에 있는 가설 중 하나를 선택하여 실험 집행을 준비합니다(꼭 최상단의 가설을 채택할 필요는 없습니다. ICE 점수는 우선순위를 일차적으로 정리할 수 있도록 도와주는 것 뿐입니다).

2. 고객에 대한 배움을 얻을 수 있는 실험부터 하자.

ICE 점수를 메긴 가설 목록이 만들어졌지만 상위 가설들의 점수가 비슷비슷해서 고민이신가요? 그렇다면 저는 그 중에서 ‘고객에 대한 배움을 얻을 수 있는 실험’을 가장 먼저 할 것을 추천드립니다. ‘고객에 대한 배움을 얻을 수 있는 실험과 거리가 먼 실험’은 다음과 같은 실험들입니다.

• FOMO 적용 : 재고 얼마 안 남았다는 표시 노출, 곧 판매 마감된다는 표시 노출 등
• Social proof 적용 : 고객 후기를 상위에 노출, N명이 보고 있다는 표시 노출 등
• 버튼 색깔 바꾸기
• 등등 인간의 인지 편향을 활용한 실험들

이런 실험은 초기 스타트업이 하기에는 시간이 아깝습니다(어쩌면 실험을 안하고 그냥 적용하는게 나을지도 모릅니다). 통계적 유의성을 확보한 실험을 하려면 최소 2주는 필요할 텐데, 2주 후에 얻은 결론이 ‘우리 고객들은 재고가 얼마 안 남았다는 표시를 보면 더 많이 구매하더라’ 뿐이라면 얼마나 아쉽겠어요. 너무 일반적인 상식을 활용한 실험은 초반에는 지양하는 것이 좋습니다. 대신 고객 퍼소나에 기반하여 우리 고객만의 특유의 상황, 특유의 심리를 근거로 한 실험을 해보시길 권장드립니다. 실험 결과에 따라 설정한 퍼소나에 대한 확신이 생기거나, 지금 설정된 퍼소나가 어쩌면 잘못 설정되어 있을 수 있다는 배움을 얻을 수 있으실 겁니다.

3. ‘뭘 더 줄일 수 있을까’를 3번 되묻자.

처음 실험을 세팅할 때 가장 많이 하는 실수 중 하나가 오버 스펙의 실험을 준비하는 것입니다. 실험은 기능 배포가 아닙니다. 실험은 기능 배포의 근거를 쌓기 위해 하는 것입니다. 따라서 근거를 많이 쌓고 싶으시다면 실험은 최대한 ‘싸게, 자주, 많이, 일찍’ 하는 것이 좋습니다. 가설을 선정한 후, 가설을 구체화하는 첫 시작점에 ‘어떻게 하면 딱 가설만 검증하는 수준으로 실험을 설계할 수 있을까?’ 셀프 질문을 던지고 기획을 시작하세요. 디자이너님과 함께 시안을 논의하는 과정에서 이번에는 디자이너님에게 ‘정말 딱 이 가설 때문에 실험이 성공하거나 실패했다고 말하려면, 시안을 어떻게 잡는게 좋을까요?‘를 질문해주세요. 본격적으로 엔지니어님이 개발에 들어가기 전에 정말 마지막으로 ‘정말 이걸 다 개발해야만 가설이 검증될까?‘를 되물어보세요. 이 정도로 질문했다면, 분명 그게 최소 스펙이겠죠? 실험도 MVP로 해야 한다는 것을 꼭 염두에 두세요.

4. ‘가설의 근거’를 위한 UT와 인터뷰

사용자 경험 컨설팅, 연구 집단인 닐슨 노먼 그룹에 따르면, 약 5명의 사용자를 가지고 사용성 테스트(UT)를 했을 때 대략 85% 수준의 사용성 문제를 발견할 수 있다고 합니다. (참고 - Why you only need to test with 5 users)

그런데 저는 닐슨 노먼 그룹의 UX전문가들처럼 정교하게 UT를 설계하고 진행할 자신이 없습니다. 그러다보니, 제가 진행한 UT에서 발견한 개선 인사이트를 곧바로 제품 개선의 근거로 활용하는 것을 경계하는 편입니다. 하지만 ‘가설의 근거’로 활용하는 것은 전혀 경계할 필요가 없죠.

전통적인 사용성 테스트는, 그 결과로 나온 개선안을 제품에 바로 반영하는 것을 목적으로 하기 때문에 테스트 설계가 정교하고 철저해야 하고, 그만큼 시간과 비용이 많이 들여야 합니다. 하지만 UT에서 얻은 근거를 ‘가설의 근거’로만 활용한다면, 더 이상 UT에 과하게 시간과 비용을 쓸 필요가 없습니다.

즉, 실험을 통해서 가설을 검증하고, 그 검증한 결과를 제품 개선의 근거로 쓰는 사이클을 구축할 수만 있다면, 이제부터 중요한 일을 가설을 빠르게, 싸게, 많이 수집하는 것입니다. 보통 크리티컬한 문제는 지인 몇 명한테만 UT를 해봐도 금방 드러납니다. 고객 인터뷰도 가설의 근거를 수집하는 용도라면 괜히 철저히 리쿠르팅하지 말고 지인 중에 잠재 고객과 가까운 사람이 있으면 그 사람을 빨리 인터뷰해보는게 낫습니다. 그리고 그렇게 얻은 인사이트를 가설의 근거로 활용해서 최대한 빠르게 실험해보세요.

5. 실패해도 좋다. 하지만 배움은 꼭 얻어야 한다.

너무 당연한 이야기라 언급하는게 민망한 내용이지만 그래도 너무너무 중요한 내용이니 아는 내용이더라도 한번 언급하고 넘어가죠. 실험은 win or lose가 아니라 win or learn 이어야 합니다. 조직에 실험 결과를 공유할 때는 꼭 성과와 배움을 함께 공유합시다. 설령 지표를 개선시키지 못했더라도, 실험을 통해 배움을 꼭 공유해야 합니다. ‘고객이 이런 걸 좋아할 줄 알았는데, 아니더라’와 같은 배움도 매우 값진 배움입니다. 고객이 안 좋아하는 걸 알게 되었으니 후속 실험은 타율이 조금 더 높아지겠죠?

배움을 공유할 수 없는 실험을 했다면, 그건 반성해야 합니다(자주 반성합니다ㅠ). 그러니 애초에 실험을 설계할 때 ‘이 실험을 실패했다고 가정했을 때, 무엇을 분석하면 배움을 얻을 수 있을까?‘도 미리 생각해두어야 합니다. 실패 시 분석할 지점의 데이터 수집이 잘 되고 있는지 확인하고, 안 되고 있다면 실험 런칭 전에 그 지점에 대한 데이터 수집 세팅도 꼭 해둬야 합니다.

마치며

쓰다보니 점점 제 자신에게 잔소리하는 것처럼 글을 쓰게 된 것 같습니다. 실험을 하다보면, 이번에는 꼭 성공시키고 싶은 욕심이 생기다보니 어느새 저도 모르게 힘을 잔뜩 준 실험을 하게 되더라구요.

• 타율이 낮더라도 임팩트가 크고, 고객에 대한 배움이 큰 실험을 할 것.
• 그리고 타율이 낮은 것을 보완하기 위해 최대한 일찍, 싸게, 자주, 많이 실험을 할 것.

늘 되뇌이지 않으면 깜빡하기 쉬운 부분인 것 같습니다.

본론을 시작하기 전에 언급했듯이, 이 글은 초보 PM의 사적인 의견일 뿐입니다. 혹여라도 제가 잘못된 생각을 가지고 있는 것 같다면 제발 저를 방치하지 마시고 부디 피드백을 통해서 더 나은 PM이 될 수 있도록 도와주시면 감사하겠습니다.

+) 실험에 대해 조금 더 정확한 ‘지식’을 얻고 싶으시다면 아래 자료들을 참고해주세요.

• https://www.minwookim.kr/experiment-hypothesis-for-startups/
• https://brunch.co.kr/@netking77/2
• https://www.youtube.com/watch?v=rdcPGhcH6xQ