실험 조직으로 거듭나기_검증할 '만'한 가설은?
가설의 뼈대를 만드는 방법
목차.
1. 가설 검증, 이런 식으로 진행됩니다.
2. 시간이 없다! 이런 가설'만' 검증하자.
3. 아무개 씨도 할 수 있는 검증 방법.
4. 관련 아티클.
하나라도 해당되면, 재밌게 읽을 수 있어요!
1. 그로스, 실험 문화를 팀에 도입하고 싶다.
2. '무엇'을 '어떻게' 검증해야 할지 모르겠다.
3. 가설 검증 사례가 궁금하다.
가설 검증, 이런 식으로 진행됩니다.
린 스타트업에선 문제와 아이디어를 검증하고 학습하는 과정을 반복해가면서, '진짜 문제'를 찾는다. 이전 아티클에서 실험 환경을 만드는 법에 대해 이야기했다. 이제 실험 환경이 만들어졌으니, 가설을 검증하는 방법에 대해 알아보자!
이전 아티클에서 이어집니다.
가설 검증 프로세스는 크게 아래의 과정을 따른다. 먼저, 어떤 가설을 검증할지 결정하고, 이를 어떤 방식으로 검증할지 결정한다. AB 테스트, FGI 등 다양한 가설 검증 방법이 존재하는데, 이 검증 방식에 따라서 수집 가능한 데이터도 달라진다. 가령, FGI 등 정성적 방식은 정성 데이터를, AB 테스트 등 정량적 방식은 정량 데이터를 얻을 수 있다. 수집 가능한 데이터를 기준으로, 가설의 참/거짓을 평가할 검증 지표와 목표 수치를 정한다. 만약, 실험이 끝나는 날에 검증 지표가 목표 수치에 도달했다면, 가설은 '참'이라고 말할 수 있다. 이제, 이 검증 지표 데이터를 충분히 수집할 수 있는 실험 기간을 정하고, 실험을 진행한다. 실험이 끝나는 날, 데이터를 분석해 가설을 검증하고 학습한다. 실험 환경은 디폴트이므로, 딱히 언급하지 않았다. 세부 순서는 바뀔 수 있으나 큰 결은 비슷하다.
(1) 검증할 가설을 선택한다.
(2) 가설 검증 방식을 결정한다.
(3) 검증 지표와 목표 수치를 결정한다.
(4) 실험 기간을 결정한다.
(5) 기존 실험 환경을 튜닝해 최적의 실험 환경을 만든다.
(6) 실험을 진행하고, 검증 데이터를 모은다.
(7) 데이터를 분석해 가설을 검증한다.
(8) 학습한다.
(1) 시간이 없다! 이런 가설'만' 검증하자
가설을 검증하는 과정은 예상보다 많은 리소스가 소비된다. 어떤 가설을 검증할지 논의하고, 실험 환경을 구축하며, 가설 검증을 위한 데이터가 충분히 모일 때까지 기다려야 한다. 그리고, 이렇게 수집한 데이터를 분석하는 시간도 필요하다. 그렇다고, 여러 개의 가설을 동시에 검증할 수도 없다. 여러 가설을 동시에 검증하다 보면 서로에게 영향을 주어서 실험 변수를 통제할 수 없기 때문이다. 결과적으로, 주어진 시간 동안 검증할 수 있는 가설의 수는 한정됐다.
검증할 수 있는 가설의 수가 한정된 상태에서 아무 가설이나 검증할 수 없는 노릇이다. 여러 가설 사이에서 우선순위를 매기고, 가장 가치가 높아 보이는 가설부터 검증을 해야 한다. 이를 위해, 메이아이는 2가지 기준을 적용해 가설의 임팩트를 평가하고, 우선순위를 결정한다.
1. 현재 상황을 개선하는가?
린 프로세스는 (1) 직면한 상황을 분석해 문제를 찾고 (2) 이 문제를 일으킨 근본 원인을 찾는다. (3) 이와 관련된 아이디어를 구현 및 배포하고, (4) 고객 반응을 통해 문제나 아이디어를 검증한다. (5) 앞선 과정에서 배운 것을 학습하는 과정을 반복한다. 일련의 과정을 보면 알 수 있듯이, 문제를 찾기 전에 상황 분석이 선행된다. 현재 상황을 먼저 되돌아봐야지, 비로소 무엇이 문제인지 알 수 있기 때문이다. 이때, 사용하는 게 OKR이다.
OKR은 크게 2가지 역할을 하는데 (1) 구성원 모두가 따르는 판단 기준이자 (2) 이정표를 제시하는 마일스톤이다. OKR를 구성하는 요소인 KR(Key Result)는 정량적 기준을 제시해 현재의 상태를 객관적으로 되돌아보게 만든다. KR의 목표 수치와 현재 달성치의 비교를 통해 현재 조직이 어떤 상황에 있고, 직면한 문제는 무엇인지 알 수 있다. 가령, 특정 KR의 달성 수치가 목표치보다 훨씬 낮다면, 이는 주목해야 할 상황이자 문제이다.
이렇게 발견한 문제 상황이 바로 가설 대상이 되지는 않는데, 대다수가 '원인'보다 '현상'에 가깝기 때문이다. 5 Whys나 어피니티 다이어그램 등을 활용해 근본 원인을 찾을 수 있다. 최종적으로 발견한 근본 원인은 현재 상황에서 검증해야 할 가설 대상이다.
2. Actionable한가?
<Product Owner>라는 책에서 Actionable 한 데이터를 강조하는데, 여기서 'Actionable'이라 함은 '다음 행동을 제시할 수 있는가?'를 뜻한다. 가설 검증에도 Acitonable이 필요하다. 즉, "이 가설을 검증했을 때, 우리가 다음에 어디로 가야 하는지 알 수 있을까?"를 고민해야 한다. 우리가 반복적으로 가설 검증을 하는 이유는 학습을 통해 올바른 방향을 얻기 위함이다. 마치 꼬리 물기처럼, 이번 가설 검증은 다음번 가설에 인사이트를 줘야 한다. 그렇지 않으면, 이번 가설 검증은 학습의 의미가 없는 셈이다.
(2) 아무개 씨도 할 수 있는 검증 방법
무엇을 검증할지 정의했다면, 이제 어떤 방식으로 검증할지 결정해야 한다. 다양한 가설 검증 방법이 있고, 절대적으로 옳은 가설 검증 방법은 없다. 자신의 취향 혹은, 주어진 상황에 따라 맞는 걸 선택하면 된다.
1. 비교해서 검증하자! AB 테스트
AB 테스트는 서로 다른 시안을 비슷한 사용자 군에게 동시에 노출시켜서 유의미함을 판단하는 실험이다. 쉽게 말하면, 비교를 통한 가설 검증이다. 예를 들어, 구현한 기능이 반영이 안 된 프로덕트(A안)와 반영된 프로덕트(B안)를 유저에게 보여주고, 반응을 비교 분석해서 가설을 검증할 수 있다.
여기서 유의해야 할 점은 '비슷한 사용자군'과 '동 시간의 노출'이다. AB 테스트에서 중요한 건 변수의 통제인데, 시간과 사용자도 통제 변수가 된다. 시간이나 사용자 자체에 따라서도 프로덕트를 이용하는 패턴이 바뀌기 때문이다. 오직 실험에 영향을 주는 건, AB 테스트의 변수밖에 없어야 한다. 그래야지 명확한 가설 검증이 가능하다.
최근 몇 년 동안 그로스 문화가 강조됨에 따라, AB 테스트를 많은 기획자가 사용하기 시작했다. 아직 AB 테스트를 시도해보지 않은 기획자라면 한 번 도전해보길 권유한다. Google Optimize를 도입한다면, 비주얼 편집기로 코딩 없이 AB 테스트를 쉽게 진행할 수 있다.
비주얼 편집기로 코딩 없이 진행한 AB 테스트2. 전후 고객 반응을 비교하자! 실험 전후 검증
실험 전후 검증은 실험이 진행되기 전과 후의 고객 반응을 비교해서 가설을 검증하는 방법이다. 예를 들어 새로운 기능이 구현된다면, 이를 배포하기 전과 후의 고객 데이터를 비교한다. 이 방식은 가설 설정이 매우 쉬운 편이나, 유의미성을 갖기 어렵다. 실험에서 변수가 적절하게 통제되야 하는데, 이 방법은 통제할 수 없는 변수가 많다. 가령 커머스 프로덕트의 경우, 공휴일의 영향을 많이 받는다. 만약 저번 주에 연휴가 껴있고, 이번 주에 없다면 유저의 사용 패턴은 매우 다를 것이다. 이 다른 패턴을 보인 유저를 같은 대상으로 보고, 서로 비교해도 괜찮을까? 따라서, 되도록 AB 테스트를 하는 걸 추천한다.
데이터 툴에서 동일한 기간 동안 포토폴리오에 방문한 유저 수를 비교해주는 모습3. 고객 행동을 말해보자! XYZ 가설 검증
XYZ 가설 검증은 <아이디어 불패의 법칙>에서 소개된 방법이다. 위의 실험 전후 검증과 결은 비슷하지만, 고객 행동을 정량적으로 접근하는 차이가 있다.
X의 Y % 는 Z 할 것이다.
1. X : 우리의 표적은 누구일까?
2. Y : 표적 시장의 몇 퍼센트를 차지할 수 있을까?
3. Z : 표적 시장은 우리 제품에 어떤 식으로, 정확히 어느 범위까지 호응할까?
예를 들어, 어떤 가설로부터 기능을 구현한다고 했을 때, "재방문 유저의 20%는 기능을 5분 동안 사용할 것이다."라는 식으로 정할 수 있다.
XYZ 가설 검증을 사용하는 이유는 애매모호함을 없애기 위함이다. 예를 들어, "기존 유저에게 이 기능을 제공하면, 더 만족할 것이다. "라고 가설을 설정했다고 해보자. 여기서 '만족'은 추상적 단어이기 때문에, 팀원 각자가 지닌 경험과 지식에 의해 다르게 해석할 여지가 있다. 따라서, 이러한 애매모호함을 없애기 위해, 모두가 동일하게 해석할 수 있는 정량적 기준을 적용한다. 가령 "이 기능을 제공하면, 기존 유저의 20%는 이 기능을 2분 이상 사용할 것이다".라는 식으로 바꿀 수 있다.
XYZ 가설 검증 예시. 실험 노트로 노션을 주로 이용한다.'어떤 가설'을 '어떤 방식'으로 검증할지 결정했다면, 가설 설정의 뼈대를 완성한 셈이다. 이제 남은 일은 이 뼈대에 어떻게 살을 붙이느냐다. 참/거짓을 어떤 데이터를 보고 판단할지, 얼마나 실험을 진행해야 하는지 등을 결정한다면, 바로 검증을 위한 실험을 진행할 수 있다. 이 완성된 뼈대에 살을 붙이는 방법을 다음 글에서 알아보자
다음 아티클로 이어집니다.
관련 아티클
https://brunch.co.kr/@famelee/11
https://brunch.co.kr/@famelee/10
https://brunch.co.kr/@famelee/8
https://brunch.co.kr/@carpediem7760/19
https://brunch.co.kr/@positive-kim/41
https://blog.gangnamunni.com/post/AB-test-Baisc/
http://www.yes24.com/Product/Goods/89707566
http://www.yes24.com/Product/Goods/89553345
