린 스타트업에서 가장 유명한 개념이 Build-Measure-Learn, 즉 만들고, 재고, 배우는 순환입니다.
책으로 읽을 때는 당연한 이야기처럼 들리는데, 막상 제 아이디어에 적용하려고 하면 "그래서 일주일 동안 뭘 하라는 거지?" 싶었어요.
그래서 이 루프를 1~2주 단위로 잘게 쪼개서 실제로 돌려본다면 어떻게 하는지, 가정 예시와 함께 정리해봤습니다.
이 순환은 Build에서 시작하는 것처럼 보이지만, 책에서도 계획은 거꾸로 세우라는 취지로 설명한다고 이해했습니다.
먼저 배우고 싶은 것(Learn)을 정하고, 그걸 확인하려면 무엇을 재야 하는지(Measure) 정한 다음, 마지막으로 그걸 재기 위해 최소한 무엇을 만들면 되는지(Build)를 정하는 식입니다.
저는 이 순서가 중요하다고 느꼈어요.
만들고 나서 "뭘 재지?" 하고 고민하면, 이미 만든 것에 맞춰 지표를 끼워 맞추게 되거든요.
그러면 어떤 숫자가 나와도 "잘 되고 있는 것 같다"로 해석하기 쉽습니다.
루프의 출발점은 가설 문장입니다.
저는 "만약 [누구]가 [어떤 상황]에서 [이 해결책]을 쓴다면, [이 행동]을 할 것이고, 그걸 [이 수치]로 확인할 수 있다" 형태로 써보고 있어요.
가정 예시를 들어보겠습니다.
동네 소규모 공방을 운영하는 사람들이 수강 신청을 전화나 메신저로 받느라 힘들어한다는 문제가 있다고 해볼게요.
그러면 가설은 이렇게 쓸 수 있어요.
"공방 운영자가 수강 신청 링크 한 장을 만들어 수강생에게 보내면, 메신저로 일정을 주고받는 횟수가 줄어들 것이다. 10곳의 운영자 중 3곳 이상이 두 번째 모임 신청도 링크로 받는다면 가설이 맞다고 본다."
여기서 중요한 건 "맞다고 보는 기준"을 시작 전에 적어두는 거예요.
기준이 없으면 결과가 나온 뒤에 기준이 슬그머니 움직이더라고요.
측정 지표는 가능하면 두세 개로 줄이는 게 좋다고 생각합니다.
많이 두면 그중 좋은 숫자만 골라 보게 되니까요.
책에서 구분해서 설명했던 개념 중에 기억에 남은 게 "허영 지표"입니다.
가입자 수나 방문자 수처럼 누적되기만 해서 좋아 보이는 숫자는 배움을 주지 못한다는 이야기였어요.
대신 "신청 링크를 받은 사람 중 실제로 신청을 완료한 비율"처럼 행동에 가까운 지표를 보라는 거죠.
위의 공방 예시라면 이런 지표가 후보가 됩니다.
링크를 보낸 운영자 수, 링크로 신청이 완료된 건수, 같은 운영자가 두 번째로 링크를 쓰는지 여부입니다.
세 번째가 가장 중요하다고 봅니다.
한 번 해보는 것과 다시 쓰는 것은 다르니까요.
이제 일정으로 옮겨봅니다.
예를 들어 2주짜리 한 바퀴를 이렇게 구성해볼 수 있어요.
첫 주 앞쪽 이틀은 가설과 지표를 문장으로 적고, "맞다고 보는 기준"을 정합니다.
이후 사나흘은 Build 단계로, 코드를 짜는 대신 폼 도구나 간단한 페이지로 신청 링크를 만들어서 운영자 몇 분께 써보게 합니다.
둘째 주에는 실제로 쓰는 걸 지켜보고 숫자를 기록한 다음, 마지막 이틀에 결과를 보고 "계속할지, 방향을 바꿀지, 접을지"를 적습니다.
여기서 제가 놓치기 쉬운 부분은 마지막 Learn 단계를 건너뛰는 거예요.
결과를 보고 바로 다음 기능을 만들러 가버리면 순환이 아니라 그냥 개발이 됩니다.
그래서 한 바퀴가 끝나면 반드시 한 장짜리 메모를 남기기로 했어요.
무엇을 가정했는지, 무엇이 나왔는지, 그래서 무엇이 달라지는지 세 줄이면 충분합니다.
제가 읽고 생각해본 함정은 세 가지입니다.
하나는 Build를 너무 크게 잡는 것입니다.
검증하려는 가설 하나에 비해 만드는 양이 많다면 이미 범위가 넘친 거예요.
둘은 표본이 너무 작은데 확신하는 것입니다.
세 명이 좋다고 했다고 해서 시장이 있다는 건 아니고, 다섯 명 중 세 명이 반복해서 쓰는 것과는 다릅니다.
그래도 아무것도 모를 때보다는 단서가 생긴 거죠.
셋은 칭찬을 데이터로 착각하는 것입니다.
"좋은 아이디어네요"라는 말은 지표가 아니라고 앞으로도 계속 스스로에게 말해주려 합니다.
한 바퀴가 끝난 뒤의 메모가 어떤 모습일지도 가정해서 적어봅니다.
공방 예시에서 10곳 중 2곳만 두 번째 신청을 링크로 받았다고 해볼게요.
기준이 3곳이었으니 가설은 맞지 않은 겁니다.
여기서 바로 포기하는 대신 이유를 살펴봅니다.
사용하지 않은 8곳에 물어보니 "수강생이 링크 누르는 걸 어려워한다"는 답이 많았다면, 문제는 서비스가 아니라 수강생에게 전달하는 방식일 수 있어요.
그러면 다음 바퀴의 가설은 "링크를 메신저 대신 QR 코드로 현장에 붙이면 신청이 늘어난다"처럼 바뀝니다.
이렇게 한 바퀴의 결과가 다음 바퀴의 가설로 이어질 때 비로소 순환이라는 말이 맞아 보였어요.
한 가지 더 적어두면, 한 바퀴에서 가설을 두세 개 동시에 확인하려는 욕심도 조심해야 합니다.
신청 링크의 문구, 가격, 전달 방식을 한꺼번에 바꾸면 결과가 나아졌을 때 무엇 때문인지 알 수가 없어요.
한 바퀴에 바꾸는 건 하나만이라는 규칙이 지루해 보여도, 배움의 질을 지켜주는 규칙이라고 생각합니다.
이 루프를 혼자 돌릴 때 가장 어려운 건 일정이 아니라 기준을 지키는 일 같아요.
스스로 정한 기준을 스스로 바꾸기 쉬우니까요.
그래서 가설과 기준은 블로그나 노트에 날짜와 함께 적어두고, 결과를 본 뒤에는 수정하지 않기로 했습니다.
다음 글에서는 이렇게 돌려보다가 방향을 바꿔야 할 때, 즉 피벗에 대해 읽은 사례들을 정리해보려고 해요.
'Planning · PM > 프로젝트 · PM' 카테고리의 다른 글
| 생성형 AI 도입 후 팀 생산성 변화 체감기 (0) | 2023.10.04 |
|---|---|
| PM의 AI 리터러시, 어디까지 필요한가 (0) | 2023.08.20 |
| 기능 우선순위 프레임워크 비교, 1인 프로젝트에 ICE·RICE·Kano 적용해보기 (0) | 2022.05.10 |
| MVP 범위 자르기 - 기능을 어디까지 빼야 하나 (0) | 2022.04.27 |
| 린 캔버스로 아이디어 검증하기 (0) | 2021.05.23 |