빠르게 출시하고 아이디어를 실제로 검증하는 MVP 범위 설정 방법
시드 라운드를 조달하고, 엔지니어 두 명을 채용하며, 출시까지 6개월의 런웨이를 설정합니다. 6개월 후 여러분은 잘 다듬어진 제품을 손에 쥐지만, 그 라운드가 답해야 했던 단 하나의 질문에는 여전히 답하지 못합니다. 과연 이것을 원하는 사람이 실제로 존재하는가? 이것은 초기 단계 소프트웨어에서 가장 흔하고, 가장 값비싼 실수입니다. 여러분이 지은 동네에 주민이 있기나 한지 확인하지도 않은 채, 기초를 붓고, 벽을 세우고, 주방까지 설치하는 것과 다를 바 없습니다.
MVP는 그것을 막기 위해 존재합니다. 그러나 우리가 마주치는 대부분의 "MVP"는 창업자가 이미 상상해 둔 완제품의 축소판일 뿐입니다. 그것은 MVP가 아닙니다. 그것은 작은 V1이며, 대화 일주일과 랜딩 페이지 한 장으로도 배울 수 있었던 것 이상은 거의 가르쳐 주지 않습니다.
MVP는 제품이 아니라 질문입니다
"minimum viable product"라는 표현은 "가능한 한 가장 작은 제품"으로 잘못 읽힙니다. 그렇지 않습니다. 그것은 다른 방법으로는 답할 수 없는 특정 비즈니스 질문에 답하기 위해 실제 사용자 앞에 내놓을 수 있는 가장 작은 것입니다.
여러분의 질문이 "바쁜 레스토랑 사장들이 자동 재고 정합 서비스에 월 $99를 지불할 것인가"라면, MVP는 그것을 증명하거나 반증하는 무엇이든 될 수 있습니다. 흔히 그것은 사람이 직접 운영하는 서비스, 스프레드시트, 혹은 뒤에서 실제 사람이 일을 처리해 주는 조잡한 웹 폼입니다. 인증, 결제, 모바일 반응형 대시보드까지 갖춘 풀스택 앱인 경우는 거의 없습니다.
정의를 다시 쓰면 여러분이 만드는 것도 달라집니다. 질문이 기준점이 되면, 답에 가까이 가는 데 기여하지 않는 기능은 잘려 나갑니다. 남는 범위는 작고, 날카롭고, 방어할 수 있는 것이 됩니다.
런웨이를 태우는 네 가지 범위 설정 실수
수십 건의 MVP 프로젝트를 진행하며 우리는 동일한 값비싼 패턴들을 반복적으로 목격합니다.
제품이 아니라 플랫폼을 짓는 것. 창업자들은 유료 사용자 한 명도 없는 상태에서 관리자 패널, 멀티테넌트 아키텍처, 역할 기반 권한, 분석 대시보드에 몇 주를 투자합니다. 이것들은 실제 제품에는 실제로 필요한 것들입니다. MVP에서 그것들은 여러분이 이미 무엇을 만들고 있는지 안다는 데 거는 도박입니다. 여러분은 알지 못합니다. 알아내려고 하는 중입니다.
"출시에 반드시 필요한 것"과 "질문에 답하기 위해 반드시 필요한 것"을 혼동하는 것. 상점을 출시하려면 결제 흐름이 필요합니다. 그러나 쇼핑객들이 특정 상품을 구매할지 검증하는 데에는 필요하지 않습니다. "알림 받기" 버튼과 수기 청구서만으로도 훨씬 적은 비용으로 구매 의사를 증명할 수 있습니다.
누군가에게 보여 주기 전에 완성도를 기다리는 것. 아무에게도 보여 주지 않은 잘 다듬어진 데모보다, 실제 사용자 손에 들어간 거친 MVP가 낫습니다. 시장은 여러분에게 신호를 주지만, 여러분의 팀은 의견만 줄 뿐입니다.
MVP와 프로토타입을 혼동하는 것. 프로토타입은 버려지는 것입니다. MVP는 얇지만 실제입니다. 뒤에 있는 배관이 청테이프로 이어져 있다 할지라도, MVP는 실제 거래를 처리하거나 실제 가치를 전달합니다. 이 둘을 뒤섞으면 6개월 뒤 후회할 부실한 코드를 얻거나, 아무도 돈을 지불하지 않은 아름다운 클릭 가능한 목업을 얻게 됩니다.
모든 기능에 적용할 단 하나의 검증 질문
MVP 범위에 어떤 기능을 넣기 전에, 단 하나의 질문을 던지십시오. 이것을 제거하면, MVP가 우리가 검증하려던 비즈니스 질문에 여전히 답할 수 있는가? 만약 그렇다면, 잘라 내십시오.
정직하게 적용하면 이 검증은 전형적인 초기 백로그의 60에서 80퍼센트를 없앱니다. 창업자들은 저항합니다. 잘려 나간 각각의 기능이 잃어버린 도박처럼 느껴지기 때문입니다. 그렇지 않습니다. 그것은 여러분이 잘 판단할 수 있는 데이터를 얻은 순간까지 유예된 도박입니다.
다섯 단계 범위 설정 로드맵
실제 MVP의 범위를 설정할 때 우리가 고객과 함께 걷는 순서는 다음과 같습니다.
1. 비즈니스 질문을 한 문장으로 쓰십시오. 제품 비전이 아닙니다. 반증 가능한 질문입니다. "호치민시의 공장 관리자들이 그들의 종이 로그를 대체하는 모바일 다운타임 추적 앱에 월 $200를 지불할 것인가?"는 질문입니다. "다운타임 추적 플랫폼을 만든다"는 질문이 아닙니다.
2. 그 질문에 답하는 가장 작은 산출물을 확인하십시오. 어떤 질문에는 랜딩 페이지와 20건의 사전 주문이 답이 됩니다. 또 어떤 질문에는 사람이 백엔드를 담당하는 두 화면짜리 모바일 앱이 답이 됩니다. 완전한 소프트웨어 제품이 답인 경우는 극히 드뭅니다.
3. 기능 목록을 초안한 뒤, 가차 없이 잘라내십시오. 위의 단 하나의 검증 질문을 모든 항목에 적용하십시오. 그 밖의 모든 것은 "V1.1" 목록으로 밀어 두고, MVP가 질문에 답한 후에만 다시 검토하십시오.
4. 기능 예산이 아니라, 시간 예산을 엄격히 설정하십시오. 정직하게 범위를 설정한다면 대부분의 MVP에는 6주에서 12주면 충분합니다. 계획이 그 이상이라면, 범위가 잘못된 것입니다. 3단계로 돌아가십시오.
5. 성공 기준과 중단 기준을 사전에 정의하십시오. "체험 사용자의 15퍼센트가 30일 안에 유료로 전환되면 계속한다. 그렇지 않으면 방향을 전환하거나 중단한다." 만들기 전에 적어 둔 이 숫자들은 나중에 매몰 비용에 근거한 판단으로부터 여러분을 지켜 줍니다.
이것이 실제로 어떻게 나타나는가
한 물류 고객이 6개월짜리 구축이 필요하다고 확신한 채 우리를 찾아왔습니다. 기사용 앱, 배차 담당자용 웹 앱, 고객 포털, 그리고 경로 최적화 엔진. 그들의 비즈니스 질문은 실제로는 훨씬 좁은 것이었습니다. 소규모 트럭 운영자들이 더 나은 작업 매칭에 월 요금을 지불할 것인가? 우리는 8주짜리 MVP로 범위를 설정했습니다. 단일 배차 담당자용 웹 앱, 네이티브 앱 대신 기사들을 위한 Telegram 봇, 그리고 뒤에서 사람이 직접 진행하는 매칭 프로세스. 출시 10주 후 그들에게는 40명의 유료 운영자가 있었고, 그 모델이 통한다는 명확한 신호가 있었습니다. 완전한 플랫폼은 나중에, 매출로 자금을 조달하고 창업자의 가정이 아니라 실제 사용 데이터에 의해 형태를 갖추면서 만들어졌습니다.
반대 시나리오는 상상하기 쉽습니다. 6개월의 구축, 잘 다듬어진 네 부분짜리 제품, 그리고 그제서야 자신들의 어떤 가정이 틀렸는지 발견하는 것.
이 규율은 복리로 쌓입니다
MVP의 범위를 잘 설정하는 것은 일회성 훈련이 아닙니다. 습관입니다. 이후 2주마다 기능을 출하하는 팀과, 아무도 사용하지 않는 릴리스에 한 분기를 쓰는 팀을 가르는 바로 그 규율입니다. 이것을 일찍 익힌 창업자들은 시장에 밀착한 회사를 만듭니다. 그러지 못한 창업자들은 아이디어가 바닥나기 전에 런웨이가 먼저 바닥나는 경향이 있습니다.
만약 여러분이 지금 이미 무겁게 느껴지는 범위 문서를 바라보고 있다면, 그것이 바로 잘라내야 한다는 신호입니다. 만약 어떤 것을 잘라도 안전한지 확신하지 못한다면, 그것은 경험 있는 파트너와 함께 나눌 만한 대화입니다. MerkTechs에서 우리는 베트남과 동남아시아 전역의 팀들이 분기가 아니라 몇 주 만에 출시되는 MVP, 그리고 더 중요하게는 위시 리스트가 아니라 답을 가지고 돌아오는 MVP의 범위를 설정하도록 도와 왔습니다. 만약 여러분이 지금 그 단계에 있다면, 우리는 언제든 첫 대화를 나눌 준비가 되어 있습니다.