MVP를 정의하는 기준, 실패에서 배운 것

MVP(Minimum Viable Product)라는 말은 다들 알지만, 실제로 "이게 MVP다"라고 딱 잘라 정의하는 건 생각보다 어려운 일이었습니다.
저희도 한 번 크게 실패한 경험이 있어서, 그때 배운 걸 정리해보려고 해요.

 

작년에 새 기능을 MVP로 빠르게 내보내자는 논의가 있었습니다.
구독형 알림 기능이었는데, 저희가 정의한 "최소 기능"에는 알림 채널 3가지(이메일, 앱푸시, 카카오톡), 세부 설정 화면, 알림 히스토리 조회까지 포함되어 있었어요.
그때는 이게 최소라고 생각했습니다.
"이 정도는 있어야 쓸 만하지 않겠냐"는 논리였죠.

결과적으로 개발 기간이 예상 4주에서 9주로 늘어났습니다.
런칭하고 나서 사용 데이터를 보니 더 충격적이었어요.
카카오톡 알림을 쓰는 사용자는 전체의 4%뿐이었고, 세부 설정 화면에 들어가는 사용자는 1%도 안 됐습니다.
저희가 "최소"라고 정의했던 것 중 절반 이상이 사실은 아무도 안 쓰는 기능이었던 거예요.

 

돌아보면 저희는 MVP를 "기능의 최소 집합"으로 정의했는데, 이게 잘못된 접근이었습니다.
진짜 물어야 할 질문은 "이 문제를 해결하는 데 필요한 최소한의 경험이 뭔가"였는데, 저희는 그 대신 "경쟁사가 가진 기능 중 뭘 빼도 될까"를 고민했던 거죠.
경쟁사 벤치마킹 리스트에서 하나씩 빼는 방식으로 스코프를 줄이다 보니, 결국 "이거 빼면 불안하니까 넣자"는 식으로 다시 기능이 늘어나는 패턴이 반복됐습니다.

또 하나 문제는 가설이 없었다는 거예요.
"이 알림 기능이 있으면 사용자가 서비스에 더 자주 돌아올 것이다"라는 가설만 있었을 뿐, 그 가설을 검증하기 위해 정확히 무엇을 확인해야 하는지가 불명확했습니다.
그래서 기능을 다 만들어놓고서야 "어떤 지표로 이걸 판단하지?"라는 질문이 나왔던 거죠.

 

이 실패 이후로 저희는 MVP를 정의할 때 세 가지 질문을 먼저 던지기로 했습니다.

 

1. 첫째, 검증하려는 가설이 정확히 무엇인가.
   "알림이 리텐션을 높인다"가 아니라 "카카오톡 알림을 받은 사용자의 7일 리텐션이 그렇지 않은 사용자보다 높다"처럼 구체적으로 적어야 했어요.
2. 둘째, 이 가설을 검증하는 데 정말로 필요한 최소 경험은 무엇인가.
   저희는 두 번째 시도에서 알림 채널을 앱푸시 하나로만 제한했고, 세부 설정이나 히스토리 화면 없이 바로 켜고 끄는 토글만 넣었습니다.
   개발 기간은 4주에서 1.5주로 줄었어요.
3. 셋째, 이 결과를 얼마 안에 판단할 것인가.
   저희는 런칭 후 3주 동안의 리텐션 데이터를 보고 다음 단계를 결정하기로 미리 합의했습니다.

 

축소된 MVP로 다시 내보낸 결과, 앱푸시를 켠 사용자의 7일 리텐션이 켜지 않은 사용자보다 12%p 높다는 걸 확인했습니다.
가설이 검증된 거죠.
그래서야 그다음 단계로 이메일 채널을 추가했고, 세부 설정 화면은 사용자 인터뷰에서 실제 요청이 반복적으로 나온 뒤에야 만들었습니다.
결과적으로 카카오톡 알림은 끝내 만들지 않았어요.
첫 시도에서 만들었던 기능 중 상당수가 사실 필요 없었다는 게 이렇게 증명됐습니다.

 

MVP는 "적게 만드는 것"이 아니라 "가설을 검증하는 데 필요한 만큼만 만드는 것"이라는 걸 이 실패를 통해 제대로 배웠어요.
그 이후로 새로운 기능을 기획할 때마다 "이게 검증하려는 가설이 뭐지"를 스스로 먼저 물어보는 습관이 생겼습니다.

아직도 가끔 이 질문을 건너뛰고 바로 기능 목록을 짜다가 스스로 멈추는 경우가 있는데, 그럴 때마다 이 알림 기능 실패 경험을 떠올리게 되네요.