빌드-측정-학습

제품을 만드는 순서가 오래도록 한 방향이었습니다. 무엇을 만들지 정하고, 문서로 적고, 몇 달에 걸쳐 만들고, 다 된 다음에 내보냈습니다. 내보내기 전까지는 아무도 그 제품을 쓰지 않았으니 맞는지 틀렸는지 알 방법도 없었습니다. 판단은 회의실에서 가장 확신에 찬 사람의 몫이었습니다.

그래서 실패가 늘 늦게 발견됐습니다. 여덟 달을 들여 만든 기능을 내보내고 한 달을 기다렸는데 쓰는 사람이 서른 명이면, 그때부터 회의는 왜 안 쓰는지를 추측하는 자리가 됐습니다. 화면이 어려워서인지, 필요가 없어서인지, 알리지 못해서인지 아무도 몰랐습니다. 여덟 달 동안 배운 것이 하나도 남지 않았다는 점이 더 큰 손해였습니다.

린은 가치를 만들지 않는 작업과 기다림을 낭비로 보고 걷어 내는 접근인데, 여기서 가장 큰 낭비는 아무도 안 쓸 것을 여덟 달 동안 만든 시간입니다. 빌드-측정-학습은 그 낭비를 줄이려고 순서를 잘게 자른 것입니다. 작게 만들어 일단 내보내고, 반응을 재고, 거기서 알게 된 것으로 다음 한 바퀴를 정합니다. 목표는 바퀴를 크게 도는 것이 아니라 한 바퀴에 걸리는 시간을 줄이는 데 있습니다. 여섯 달에 한 바퀴 도는 팀은 1년에 두 번 배우고, 3주에 한 바퀴 도는 팀은 열일곱 번 배웁니다.

한 바퀴는 만들기 전에 무엇을 확인할지 적는 데서 시작합니다. 이름은 세 단계지만 실제로는 그 앞에 한 단계가 더 붙습니다.

1. 가설을 적습니다. 가설은 참인지 거짓인지 가릴 수 있게 적은 추측을 말합니다. "초대 기능이 있으면 좋겠다" 는 가릴 수 없고, "초대 화면을 본 사람의 10퍼센트가 팀원을 실제로 초대한다" 는 가릴 수 있습니다. 숫자와 기준을 미리 적어 두어야 나중에 결과를 두고 다투지 않습니다.
2. 만듭니다. 가설을 확인할 수 있는 가장 작은 형태까지만 만듭니다. 이 단계에서 나오는 것이 MVP인데, 제품의 축소판이 아니라 그 가설 하나를 재기 위한 물건입니다. 초대가 일어나는지 보려는 것이라면 초대 화면과 메일 한 통이면 되고, 권한 설정이나 관리자 화면은 이번 바퀴에 들어가지 않습니다.
3. 잽니다. 내보낸 뒤 정해 둔 숫자를 모읍니다. 여기서 재는 대상은 만족도 같은 인상이 아니라 실제 행동입니다. 화면을 본 사람 수와 초대 버튼을 누른 사람 수, 초대를 받은 사람이 들어온 수를 셉니다.
4. 배웁니다. 숫자를 가설 옆에 놓고 맞았는지 틀렸는지 적습니다. 10퍼센트를 기대했는데 8퍼센트가 나왔으면 가설은 대체로 맞은 것이고, 0.5퍼센트면 틀린 것입니다. 틀린 경우에도 배움은 남습니다. 다음 바퀴에서 무엇을 바꿔 볼지가 그 배움에서 나옵니다.

한 바퀴가 끝나면 셋 중 하나를 고릅니다. 가설이 맞았으면 같은 방향으로 더 나아가고, 애매하면 조건을 바꿔 한 바퀴 더 돌고, 틀렸으면 피벗을 고려합니다. 피벗은 배운 것을 들고 가면서 가설 하나를 바꾸는 결정입니다. 파는 물건은 그대로 두고 파는 대상을 개인에서 팀으로 바꾸는 식이라, 사업을 접는 일과는 다릅니다.

이 방식이 잘 듣는 자리는 모르는 것이 많은 초기입니다. 누가 쓸지, 무엇 때문에 돈을 낼지, 어떤 화면이 통할지가 정해지지 않았을 때는 토론보다 한 바퀴 도는 쪽이 빠릅니다. 만들 것이 정해져 있고 잘 만들기만 하면 되는 일에는 이 틀을 쓸 이유가 없습니다.

한계는 세 가지입니다. 첫째, 잴 수 없는 영역에서는 바퀴가 돌지 않습니다. 사용자가 하루에 스무 명 들어오는 제품에서는 8퍼센트와 12퍼센트를 가를 수 없어서, 숫자가 나와도 우연인지 아닌지 알 수 없습니다. 이럴 때는 숫자 대신 사용자 다섯 명을 앉혀 두고 쓰는 모습을 보는 쪽이 낫습니다.

둘째, 한 번에 되돌릴 수 없는 일에는 못 씁니다. 결제 금액을 잘못 걷거나 개인정보를 잘못 다루는 일은 실험으로 확인하고 되돌릴 수 있는 종류가 아닙니다. 의료나 금융처럼 규제가 걸린 영역도 마찬가지입니다.

셋째, 바퀴를 빨리 도는 데 익숙해지면 눈앞의 숫자만 올리게 됩니다. 버튼 색을 바꿔 전환율을 1퍼센트 올리는 바퀴는 돌리기 쉽고 결과도 빨리 나오지만, 그 바퀴를 서른 번 돌려도 제품이 향하는 방향은 바뀌지 않습니다. 작은 바퀴를 돌리는 동안에도 어느 쪽으로 가고 있는지는 따로 확인해야 합니다.

"이번 스프린트에 다 만들지 말고 한 바퀴만 돌려 봅시다."

기능 전체를 완성하는 대신 가설 하나를 확인할 만큼만 만들어 내보내자는 제안입니다.

"그거 측정은 어떻게 하실 거예요?"

만들기 전에 재는 방법과 기준을 정해 두라는 요구이고, 대개 지표를 심는 작업이 뒤따릅니다.

"학습이 안 남았어요. 다음 바퀴를 어디로 돌릴지 모르겠는데요."

숫자는 모였지만 그 숫자로 가설을 가리지 못했다는 뜻입니다.

페이지덱이 팀 초대 기능을 붙일 때의 장면입니다. 지현이 가설을 한 줄로 적었습니다. 문서를 세 개 이상 만든 사용자의 10퍼센트가 팀원을 초대한다는 가설이었습니다. 개발은 2주만 썼습니다. 초대 화면과 메일 한 통이 전부였고, 초대받은 사람이 어느 문서로 들어오는지는 이번 바퀴에서 빼기로 했습니다.

3주 뒤 숫자는 3퍼센트였습니다. 기대의 3분의 1이라 가설은 틀린 쪽이었지만, 초대 화면까지 온 사람 가운데 절반이 메일 주소를 입력하다 멈춘 것이 같이 보였습니다. 다음 바퀴의 가설은 여기서 나왔습니다. 주소를 하나씩 치는 대신 링크 하나를 복사해 보내게 하면 초대가 늘어난다는 가설이었습니다.

빨리 많이 만드는 방식으로 읽는 경우가 가장 많습니다. 이름의 첫 단어가 만들기이고 바퀴를 자주 돌자고 하니 그렇게 들립니다. 하지만 이 틀에서 만들기는 배우기 위한 수단이라, 배울 것이 없는 만들기는 바퀴를 돌린 것이 아니라 그냥 일한 것입니다. 만드는 속도만 올리면 다음 달에 확인할 수 없는 기능 스무 개가 쌓이고, 무엇이 통했는지 물었을 때 답할 근거가 없습니다.

세 번째 단계를 건너뛰는 것도 흔합니다. 만들고 재는 데까지는 눈에 보이는 일이 있지만 학습은 회의 한 번이면 끝나는 일처럼 보여서 밀리기 쉽습니다. 밀린 결과 대시보드에 숫자만 쌓이고 그 숫자로 무엇을 정했는지는 아무도 모르게 됩니다. 그러면 반년 뒤에 같은 질문을 다시 논의하게 됩니다. 한 바퀴를 닫는 것은 배포가 아니라 배운 것을 한 줄로 적어 남기는 일입니다.