에릭 리스의 [린 스타트업]을 처음 읽은 건 몇 년 전이었는데, 그때는 "그냥 스타트업 성공담 모음집이구나" 정도로 넘겼습니다.
그런데 올해 저희 팀이 신규 서비스 하나를 새로 기획하게 되면서, 이 책의 방법론을 실제로 적용해볼 기회가 생겼어요.
이론으로만 알던 것과 실제로 팀에 적용해보는 건 완전히 다른 경험이었습니다.
린스타트업의 핵심은 "만들기-측정-학습(Build-Measure-Learn)" 루프를 빠르게 돌리는 것입니다.
그런데 첫 단계인 MVP(최소기능제품)를 정의하는 것부터 팀 내에서 의견이 갈렸어요.
개발팀은 "핵심 기능 하나만 완벽하게 만들자"고 했고, 저는 "여러 기능을 다 얕게라도 넣어서 전체 흐름을 보여주자"는 입장이었습니다.
결국 저희가 검증하고 싶은 가설이 뭔지부터 다시 정리했어요.
"사용자가 이 서비스에 돈을 낼 것인가"를 검증하고 싶었던 거였는데, 그렇다면 굳이 여러 기능을 다 넣을 필요가 없었습니다.
결제 직전까지 가는 흐름 하나만 최소한으로 만들어서 테스트하는 걸로 방향을 좁혔습니다.
린스타트업을 팀에 적용하면서 제일 유용했던 실천은 "가설을 문장으로 명시해두는 것"이었습니다.
"우리는 [어떤 사용자]가 [어떤 문제] 때문에 불편함을 겪고 있고, [이 기능]이 있으면 [이런 행동]을 할 것이라고 믿는다"라는 형식으로 매 실험마다 문장을 써놨어요.
처음엔 이게 좀 형식적인 요식행위 같았습니다.
그런데 실제로 실험 결과가 애매하게 나왔을 때, 이 문장이 있으면 "그래서 가설이 맞았나 틀렸나"를 명확하게 판단할 수 있더라고요.
가설 문장 없이 실험했던 초기에는 결과가 나와도 "음, 그럭저럭 괜찮은 듯"이라는 애매한 결론으로 끝나는 경우가 많았습니다.
이 부분은 저희가 크게 실패했다가 배운 내용입니다.
초기 실험 하나에서 지표를 미리 정해두지 않고 실험을 진행했는데, 결과가 나오고 나서 "이 숫자면 성공이라고 볼 수 있지 않을까요"라는 식으로 사후에 기준을 맞춰버린 적이 있었어요.
객관적으로 보면 명백한 실패였는데, 팀 내에서 이미 투자한 시간과 노력이 아까워서 억지로 긍정적인 해석을 만들어낸 거였습니다.
이 일을 겪은 뒤로는 실험을 시작하기 전에 "성공 기준 숫자"를 반드시 문서에 박아두고, 실험이 끝난 뒤에는 그 숫자를 절대 수정하지 않는다는 규칙을 세웠습니다.
MVP 테스트 결과, 저희가 처음 생각했던 방향은 결국 피벗하게 됐습니다.
원래는 개인 사용자를 대상으로 구독형 서비스를 생각했는데, 실험 데이터를 보니 오히려 소규모 팀 단위 사용자들의 반응이 훨씬 좋았어요.
개인 사용자 전환율은 2% 남짓이었는데, 팀 단위로 초대해서 쓰는 흐름을 넣었더니 팀 하나가 들어오면 평균 4~5명이 같이 가입하는 패턴이 보였습니다.
이 데이터를 보고 나서 팀 전체가 크게 흔들렸어요.
반년 가까이 준비했던 개인용 구독 모델을 접어야 하는 상황이었으니까요.
그런데 데이터가 이렇게 명확하게 다른 방향을 가리키는데 원래 계획을 고집하는 게 더 위험하다고 판단했고, 팀 단위 온보딩 흐름으로 방향을 틀었습니다.
린스타트업을 실제로 돌리면서 가장 크게 바뀐 건 팀의 분위기였습니다.
예전엔 "이번 프로젝트는 반드시 성공해야 한다"는 압박이 컸는데, 지금은 "이번 실험에서 뭘 배웠는가"를 더 중요하게 보는 분위기가 자리 잡았어요.
물론 이게 하루아침에 된 건 아닙니다.
초반에는 실험이 실패로 나오면 팀원들이 위축되는 게 눈에 보였고, 저도 "이번에도 실패면 어쩌지"라는 걱정을 안고 회의에 들어간 적이 많았습니다.
그런데 매 실험 결과를 "실패"가 아니라 "가설 검증 결과"라는 언어로 바꿔서 공유하기 시작하면서, 팀 분위기가 조금씩 달라지더라고요.
린스타트업 방법론을 책으로 읽을 때는 "당연한 이야기 아닌가"라고 생각했는데, 실제로 팀에 적용해보니 그 당연한 걸 지키는 게 훨씬 어렵다는 걸 알게 됐습니다.
특히 사후에 기준을 끼워맞추고 싶은 유혹을 참는 게 생각보다 힘들었어요.
이번 신규 서비스는 아직 완성 단계는 아니지만, 최소한 방향이 틀렸을 때 빨리 알아차릴 수 있는 팀이 됐다는 것만으로도 이 방법론을 도입한 값어치는 충분했다고 생각합니다.
'Planning · PM > 프로젝트 · PM' 카테고리의 다른 글
| PM의 AI 리터러시, 어디까지 필요한가 (0) | 2023.08.20 |
|---|---|
| 2023년 가트너 전략 기술과 우리 팀 로드맵 (0) | 2023.02.11 |
| 요구사항 우선순위 정하는 법 (RICE, MoSCoW) (0) | 2020.08.04 |
| 서비스 정책 문서, 왜 자꾸 누락되나 (0) | 2020.07.26 |
| 디자이너·개발자와 협업할 때 기획자의 역할 (0) | 2020.07.19 |