MVP 범위 자르기 - 기능을 어디까지 빼야 하나

 

MVP(Minimum Viable Product)라는 말은 창업 책을 읽으면 어디서나 나옵니다.
그런데 막상 내 아이디어에 적용하려고 하면, "최소"가 어디까지인지가 가장 어려웠어요.
기획자로 일할 때 범위를 줄이는 일을 자주 해봤다고 생각했는데, 내 아이디어 앞에서는 전혀 다른 문제가 되더라고요.
기능 하나하나가 다 소중해 보이니까요.
이번 글에서는 범위를 자르는 순서와, 제가 여러 번 빠졌던 함정을 적어봅니다.

 

기능 목록을 쓰기 전에 먼저 하는 일이 있습니다.
이 서비스가 고객에게 주는 핵심 가치를 한 문장으로 쓰는 것입니다.

예를 들어 소규모 업장용 예약 서비스를 가정해볼게요.
"전화나 메신저로 받던 예약을 놓치지 않고 한곳에서 확인할 수 있다."
이 정도가 한 문장의 예입니다.

이 문장에는 "놓치지 않는다"와 "한곳에서 확인한다"라는 두 가지 약속이 들어 있습니다.
이후 모든 기능은 이 약속에 기여하는지를 기준으로 판단합니다.
통계 화면이나 쿠폰, 리뷰 기능이 아무리 좋아 보여도 이 문장에 직접 닿지 않으면 첫 버전에서는 후보에서 내려갑니다.

문장이 두세 개로 길어지면 아직 핵심이 정리되지 않은 것입니다.
저는 한 문장이 안 나오는 날에는 기능 얘기를 하지 않고 문장만 다시 다듬습니다.

 

그다음에는 떠오르는 기능을 일단 전부 나열합니다.
예약 접수, 예약 확인 알림, 달력 보기, 고객 정보 관리, 결제, 후기, 쿠폰, 통계, 직원별 일정, 다국어 같은 것들이죠.

그리고 하나씩 이 질문으로 걸러봅니다.
이 기능이 없으면 핵심 가치가 성립하지 않는가.
이 기능이 없으면 고객이 첫 주에 서비스를 쓰지 못하는가.
이 기능을 사람이 대신하거나 다른 도구로 때울 수 있는가.

앞의 두 질문에 "아니오"이고 마지막 질문에 "예"인 기능은 첫 버전에서 뺍니다.
위 예시에서는 예약 접수와 달력 보기, 확인 알림 정도가 남고, 결제와 후기와 통계는 뒤로 갑니다.

여기서 제가 쓰는 팁은 빼는 기능에 "언제 넣을지"를 같이 적어두는 것입니다.
"고객이 N명을 넘으면" 또는 "인터뷰에서 세 번 이상 요청이 나오면" 같은 조건이에요.
조건을 적어두면 빼는 것이 포기가 아니라 보류로 느껴져서 마음이 훨씬 편합니다.

 

범위를 줄이는 가장 강력한 방법은 기능을 만들지 않고 사람이 직접 하는 것이었습니다.
이른바 컨시어지(concierge) 방식의 MVP입니다.

예약 서비스로 예를 들어볼게요.
화면과 시스템을 만들기 전에, 한 업장의 예약을 제가 대신 받아서 스프레드시트에 정리하고 확인 메시지를 직접 보내는 것입니다.
고객은 서비스를 쓴 것처럼 느끼지만, 뒤에서는 제가 손으로 하고 있는 거죠.

이렇게 하면 알 수 있는 것이 많습니다.
어떤 정보를 꼭 받아야 하는지, 예외가 얼마나 자주 생기는지, 업장 분이 정말 확인 메시지를 원하는지 같은 것들입니다.
개발하기 전에 이런 것들이 드러나면, 만들어야 할 기능의 모양이 확 달라집니다.

물론 한계도 있어요.
사람이 대신하는 방식은 규모가 커지면 바로 무너지고, 시스템이 처리하는 속도나 안정성을 검증하지는 못합니다.
그래서 컨시어지는 "고객이 이걸 정말 원하는가"를 확인하는 데 쓰고, "이게 기술적으로 되는가"는 다른 방식으로 확인한다고 구분해서 생각합니다.

 

범위를 자르는 연습을 하면서 몇 번이나 같은 실수를 했습니다.

첫째, "이건 기본인데" 하며 슬쩍 넣는 기능입니다.
로그인 방식, 설정 화면, 비밀번호 찾기 같은 것들은 당연히 필요해 보이지만, 하나하나가 일입니다.
처음에는 가장 단순한 방식(예: 이메일 링크 하나)으로 줄여도 되는지 따져봐야 합니다.

둘째, 완성도에 대한 욕심입니다.
기능은 줄였는데 화면 하나하나를 다듬느라 시간을 쓰는 경우예요.
MVP의 "V"는 쓸 수 있다(viable)는 뜻이지 예쁘다는 뜻이 아니라고 스스로에게 반복해서 말합니다.

셋째, 나를 기준으로 판단하는 것입니다.
내가 필요한 기능과 고객이 첫 주에 필요한 기능은 다를 수 있습니다.
그래서 빼는 기준을 세울 때는 가능하면 인터뷰 메모를 옆에 펼쳐두고 봅니다.

넷째, 측정할 방법 없이 만드는 것입니다.
MVP를 만드는 이유는 배우기 위해서인데, 무엇을 보고 판단할지 정해두지 않으면 만들고 나서도 배울 것이 없어요.
첫 버전을 내기 전에 "이 숫자가 이 정도 나오면 계속, 아니면 방향을 바꾼다"를 적어둡니다.

 

범위를 정하고 나면 마지막으로 두 가지를 확인합니다.
하나는 "이걸 처음 쓰는 사람이 10분 안에 핵심 가치를 경험할 수 있는가"입니다.
가입, 기본 설정, 첫 예약 받기까지 단계가 너무 많으면 기능이 아무리 적어도 MVP로서 쓸모가 줄어요.

다른 하나는 "만드는 데 걸리는 시간이 내가 감당할 수 있는 범위인가"입니다.
예를 들어 첫 버전을 몇 주 안에 확인용으로 내놓겠다고 정했다면, 그 기간을 넘기는 기능은 다시 줄이거나 수동으로 대체합니다.
기한을 먼저 정하고 범위를 맞추는 방식이, 범위를 정하고 기한을 늘리는 방식보다 훨씬 덜 헤매게 해주었습니다.

 

범위를 자르는 일은 기능을 버리는 일이 아니라, 지금 가장 궁금한 것 하나를 가장 빨리 확인하는 일이라고 생각하게 되었습니다.
기획자로서의 습관이 오히려 방해될 때도 있었어요.
빠짐없이 정리하는 것에 익숙하다 보니, 비워두는 것이 불안했거든요.

 

남은 질문은 이런 것입니다.

컨시어지로 확인한 반응이 좋을 때, 언제부터 시스템을 만드는 단계로 넘어가야 하는가.
그 전환 시점의 기준을 아직 못 정했습니다.

지금은 "내가 손으로 하는 것이 부담스러워지는 시점"을 하나의 신호로 적어두고 있습니다.