실패를 계속하는 방법
비즈니스 임팩트를 위해 필요한 기능을 a/b 테스트를 진행했다.
오전 10시쯤 배포 완료를 하고, 그날 오후 3시에 우리는 긴급하게 다시 모였다.
"다들 지표 보셨나요?"
"껄껄. 결과가 확실해서 너무 좋네요. 뭐부터 고치면 될까요?"
"단계를 둬서 UX를 전개했던 게 사용자들을 더 혼란스럽게 만든 거 같아요, 단계를 풀고 처음부터 전체를 노출시키는 UX로 실험을 바꾸시죠!"
그리고 우리는 한 시간 만에 실험을 수정하고 다시 한참을 지켜봤다.
그리고 우리가 이렇게 빠르게 고쳤던 실험은 2주가 지나서 정식 기능으로 전체 사용자들에게 릴리스 됐다.
실패를 하더라도 빠르게 실패하는 게 낫다.
우리는 이걸 '정보'라고 부르는데 실험을 설계할 때,
'어떤 결정이 우리에게 정보를 많이 줄까?'를 가장 최우선으로 생각한다.
실패하더라도 우리는 어떤 정보를 얻게 될까? 를 항상 질문하고 우리의 생각을 정리해 놓는다.
그렇게 ‘빠르게 실패하고 다시 개선하는’ 과정을 반복하다 보면,
어느 순간 우리는 꽤 많은 ‘정보’를 얻게 된다.
사용자는 아는 정보와 모르는 정보가 함께 나왔을 땐 아는 정보도 빠르게 결정하지 못한다는 사실, 시장의 단어보다 직관적인 단어가 더 결정을 쉽게 할 수 있다는 사실 등
가설로 시작했던 이슈가 실험을 통해 증명이 됐을 때 정말 짜릿하다.
이런 디테일들이 쌓여 다음 실험, 그다음 실험에서는 같은 실패를 반복하지 않고 새로운 정보를 얻을 수 있는 결정을 할 수 있게 된다.
물론 빠른 의사결정과 빈번한 실험은 나뿐만 아니라 디자이너, 개발자에게 심리적·체력적 압박을 주기도 한다. 이번에도 실패할까? 이번엔 한 번에 성공인가? 하며 진행 중인 실험을 모니터링하는 믹스패널에 밤이든 낮이든 서로의 이름 옆에 떠있는 < 1 hour ago를 보며 안정감을 느끼기도 하고,
실패를 해서 풀이 죽어있는 팀원이 보이면 시원한 아메리카노를 같이 마시면서
기존 꺼도 우리가 만들었는데 그걸 못 이겨? 껄껄 거리며
우리가 이 실험을 왜 시작했는지, 왜 실패했다고 생각하는지 서로 피드백하며 다시 한번 정보를 찾기 위해 도약해 본다.
아무도 답을 찾지 못했고 사용자만 답을 알고 있는 이곳에서
우리가 이길 수 있는 베팅은 조금 무모해 보여도 빠르게 실패하고 그 실패를 학습하는 것이라고 생각한다.
실패를 두려워하기보단(사실 실패도 많이 해보면 처음보다 크게 두렵지 않다)
그 실패의 기록이 곧 우리 팀의 자산이고 결국엔 답을 찾아가는 길이이다.
오늘도 우리는 답을 찾기 위해 정보가 잔뜩 담긴 실패를 했다.
그리고 그 실패를 통해 생각했던 것보다 빨리 답을 찾았다.
