일 잘하는 팀 만들기
만들고, 측정하고, 배우기
수요(Demand)를 만드는 사람들
파리에는 1년에 2번 패션위크가 열린다. 소위 명품 브랜드들은 이때 새로운 시즌에 대한 컨셉을 선보인다. 지난 9월 패션위크의 최대 관심사는 ‘CELINE’이라는 브랜드였다. “Hedi Slimane”이라는 디자이너가, CELINE의 디렉터로 합류하며 큰 변화를 예고했기 때문이다. (참고: Hedi Slimane은 Christian Dior, Yves Saint-Laurent을 각각 Dior, Saint-Laurent으로 성공적으로 리브랜딩 했다)
나폴레옹 무덤에서 진행된 CELINE의 쇼안타깝게도, Show가 마무리되기 전부터 소셜 미디어의 반응은 차가웠다. “RIP, CELINE” 등 실망한 고객들의 분노가 피드를 도배했다. 갑자기 확 바뀐 컨셉이 기존 이미지를 기억하는 팬들에게 거부감이 컸을 것이다. (패션 까막눈인 내가 보기에도 큰 변화였다...)
(Digital Product이긴 하지만) 제품 관련 업무를 하다 보니, Celine은 왜 이런 결정을 내리게 되었는지 관심이 갔다. 같이 Celine의 패션쇼 현장에 갔었던 국내 모 브랜드 디렉터님의 설명에 의하면, Celine은 Hedi Slimane 영입과 동시에 New Generation에 어필하는 방향의 리브랜딩 및 남성복 라인 확장이라는 계획을 발표했다고 한다. 앱이던, 옷이던 제품이 시장에서 살아남기 위해서는 꾸준한 개선이 필요하다. 시간에 따라 사용자들의 수요도 달라지기 때문이다. 하지만, 변화는 항상 Risk를 수반하기에, 의사결정을 어렵게 만든다. 꾸준히 소비자의 수요가 발생하는 방향 혹은 견인하는 방향으로 제품을 ‘잘’ 개선해 나가는 조직을 우리는 '일 잘하는 팀'이라고 한다.
일 잘하는 팀을 만들기 위한 노력
매 시즌 새로운 트렌드를 창조해야 하는 패션 브랜드는 패션쇼라는 특별한 하루를 통해 결과물을 평가받는다. 수많은 바이어와 vip 앞에서 펼쳐지는 쇼에서 좋은 반응을 얻지 못하면, 한 시즌 농사가 실패로 돌아갈 수 있다. 의류제품에 비해 '알라미'같은 디지털 제품은, 변화에 대한 부담이 훨씬 작은 것 같다.
AB test라는 무기가 있기 때문이다(패션업계에도 비슷한 프로세스가 있는지 모르겠지만.. 아마도 유명 디자이너들의 자존심상 이런 테스트를 받아들이지 않을 것 같다.)
패션 쪽에서는 디자이너의 Creativity가 실력을 좌우한다면, 요즘 IT 쪽에서는 얼마나 빠르게, 많은 테스트를 제대로 돌려서 프로덕트 개선 방향을 잡아가느냐로 팀의 능력을 판가름한다. 듣기엔 그럴듯하고 쉬워 보이지만, 실행은 훨씬 어렵다. 딜라이트 룸도 테스트를 더 잘하기 위해 많은 시도와 노력을 하고 있다. "일 잘하는 팀"이 되기 위해 우리는 어떤 노력을 하고 있는지 비교적 간단하지만 성공했던 실험인 '알람 반복 설정' 관련 경험을 토대로 이야기해보려 한다.
'알람 반복 설정' 실험은, 사용자가 알람을 추가할 때 '반복 설정'의 기본 값으로 '주중'에 모두 울리는 옵션을 제공한 실험으로, 대조군은 '반복 없음'이다.
첫 번째, 가설을 세울 수 있는 능력을 키우려 한다.
가설이 없다는 것은, 무엇을 검증해야 할지 모른다는 이야기와 같다.
즉, 가설 없이는 실험을 진행할 수 없다.
예컨대, 에어비엔비의 창업자들이 "샌프란시스코는 숙소가 부족하다"는 문제를 인식하는데만 그쳤다면 Airbnb는 탄생하지 않았을 것이다. 그들이 깨달은 문제로부터 "우리 집(air bed를 제공해주는..)에서도 돈 주고 숙박할 사람이 있을까?"라는 가설을 세웠고, 빠르게 테스트하여 사업기회가 있음을 입증했다.
'알람 반복 설정' 실험은 사용자들이 생각보다 '반복' 버튼을 누르지 않는다는 발견에서 시작되었다.(이 발견은 딜라이트 룸에 문화로 자리 잡은 'Daily Data Analysis; DDA' [링크]에서 나왔다; 분석에 대한 자세한 내용은 생략) 이 발견으로부터 "기본으로 제공하는 값을 <주중 반복>으로 바꿔도 설정을 잘 안 바꿔서, Retention이 올라갈 것"이라는 가설을 세웠다.
두 번째, 가설을 검증할 수 있는 최소 기능 제품을 만들 수 있는 능력을 키우려고 한다.
핵심 가설을 검증하기 위한 제품 개발에 몇 개월이 필요하다면.. 다시 한번 생각해봐야 한다.
최소한의 노력으로 가설을 검증할 수 있는 방법을 찾아야 한다. 구현 난이도에 압도되면 시작하기가 꺼려지고, 결과가 "실패"로 결론 날 때 기회비용이 너무 커진다. '알람 반복 설정' 실험은 개발에 필요한 코스트가 크지 않았다. 따라서 이 부분에 대해서는 위에서 예로 들었던 airbnb 사례를 다시 인용하는 게 좋을 것 같다. airbnb 창업자들은 실 수요를 체크할 수단이 필요했다. 그리고 가설을 검증할 제품에 시간과 노력을 투자해 예쁘고, 견고한 웹사이트를 만드는 대신 핵심 기능만을 최소화하여 만들었다. 그 결과로 그들의 집을 돈 주고 빌릴 사람들이 있다는 것을 빠르게 검증해 낼 수 있었다.
세 번째, 어떤 데이터를 볼 것이고 어떤 기준으로 판단할지에 대한 통찰을 키우려고 한다.
실험을 하는 이유는 ‘결과를 보고 제품에 어떤 기능을 어떻게 추가할지 등에 대한 의사결정을 내리기 위해서’이다. 의사결정을 잘하기 위해 해당 실험에서 어떤 데이터를, 어떤 기준으로 볼지에 대한 결론을 가지고 시작해야 한다. 이른바, 핵심지표에 대한 설정과 판단 기준이 필요한 것이다. 그리고 실험에서 원하는 데이터가 잘 수집될 수 있도록 관리해야 한다. '알람 반복 실험'의 경우 핵심지표는 Day 1-3 Retention이었다. '알람 추가' 버튼을 누르는 사람들을 대상자로 구분하여 실험그룹에게는 <주중>을, 대조군에게는 <반복 안 함>을 기본 값으로 제공했다. 그리고 그들의 Retention을 비교하여 실험의 성공 여부를 가늠했다.
마지막으로, 모든 실험에서 배울 점을 찾으려 한다.
어쩌다 보니 실험에 성공해서 지표는 개선됐지만, 거기서 그친다면 팀에 실력 향상은 제한적일 것이다. 반대로 실험이 실패했더라도, '왜 실패했는지'를 배운다면, 제품 개선을 위한 다음 실험의 자양분이 된다. 그리고 그 배움이 조직에 쌓여 더욱 실력 있는 팀을 만들 수 있다. '반복 알람' 실험에서 우리가 배운 점은 결과의 해석에 있었다. 전체 사용자를 대상으로 한 실험인 만큼, 신규 사용자를 대상으로 한 일반적인 Day 1-3 Retention을 기준값으로 해석하기가 애매했다. 이것을 실험 종료 후 분석 단계에서 깨달았다. (아마 Firebase에서 제공하는 결과를 보고 섣부르게 '성공한 실험'으로 단정했다면 이 부분을 놓쳤을지도 모른다.) 이 배움을 통해, 전체 사용자를 대상으로 하는 추후 실험에서 Retention 지표를 어떻게 활용할지에 대한 내부 기준을 세울 수 있었다.
Build-Measure-Learn Loop
흔히 스타트업은 불확실성 속에서 길을 찾아가는 것이라는 비유를 한다.
그리고 옳은 길을 찾는 방법으로 Build-Measure-Learn Feedback Loop을 이야기한다.
딜라이트 룸은 가능하면 모든 기획안을 AB test 하여 의사 결정하는 것을 원칙으로 한다.
또한 결과가 성공이던 실패던, 과정에서 구성원 모두가 배움을 하나라도 얻을 수 있어야 한다고 생각한다.
따라서, 실패한 실험은 곧 "배움이 없는 실험"으로 규정하고 있다.
서비스가 안정적으로 운영되다 보면, 서비스에 대한 아이디어보다 여러 가지 궁금증들이 많이 생길 때가 있다. 이 경우 무엇을 만들지 결정하는 것이 무엇을 배울지를 결정한 이후가 되어도 된다. 예컨대, 알라미의 경우 '미션 알람'을 사용하는 사람들이 Retention 될 가능성이 높다는 가정이 있었고, 이 가정에 대해서 더 깊이 있는 배움이 필요하다고 생각했다. 그래서 이를 배울 수 있는 여러 가지 기능적 tweak들을 실험했고 그 결과로 알라미를 다운로드할 때 '미션 알람'을 인지했는지, 안 했는지에 따라 Retention이 다를 것이다라는 새로운 가설을 세울 수 있었다.
마치며
브랜드, 제품을 다루는 사람들은 새로운 수요를 창출해야 한다는 부담감을 늘 가지고 있다. 그리고 이를 더 잘하기 위해 알려진 많은 방법들이 있지만, IT 쪽은 특히 Build-Measure-Learn Feedback Loop을 잘 활용하는 것이 도움된다고 생각한다. 즉, 우리에게 필요한 것은 부담감을 이길 용기보단 당장 실행하고, 배우고 다시 한번 실행해보는 Lean 한 태도라고 생각한다.
