좋은 PM을 위한 MVP 프라이머
MVP의 목적, 올바른 개념과 좋은 MVP를 만드는 방법을 이야기합니다.
지금은 컴퓨터의 사용과 데이터의 중요성을 인식하면서 많이 줄어들었지만, 예전에는 의사들이 손으로 쓴 처방전을 일반인이 읽고, 해독해 내는 것은 거의 불가능했습니다. 2020년 오늘도 법조인들의 문서는 왠만한 전문가가 아니면 이해하기 어렵습니다. 아직도 방송이나 건축현장에서 날아다니는 일본어 전문(?) 용어는 외계어 같기도 합니다. 이런 전문가 그룹이 그런 용어를 쓰는 데는 전문성을 강조하는 이유도 있겠지만, 무엇보다 타 그룹과의 '다름과 드러남'을 추구하고 같은 그룹원과의 '동료 의식'을 갖기 위함도 한 몫을 하고 있는 것이 사실입니다.
일반인이라면 절대 읽을수없는 처방전이런 경우는 컴퓨터, 소프트웨어 산업에서도 예외는 아닙니다. 물론 산업자체가 서양에서 부터 들어오다 보니 그럴수는 있지만, 수많은 신조어와 약어를 섞어 사용하는 대화를 다른 산업종사자들이 이해하기는 쉽지 않을겁니다. 오늘 소개할 MVP (Minimum Viable Product)만 해도 실제 스포츠에서 사용하는 같은 단어 MVP (Most Valuable Player)가 훨씬 더 많이 실생활에 널리 퍼져 있습니다. 우리가 대화에 전문용어를 사용하는 이유는 남과의 다름을 은연중 나타내기 함이 아니라, 그 용어가 의미하고 포함하는 정확한 뜻을 전달하기 위함이 되어야 합니다. 제가 예전 글 <POC,Prototype, MVP를 구별하여 사용하자!> 에서 소개했듯 각각의 용어를 잘 구별하여 사용하는것이 그 정의를 구체적으로 이해하는데 중요하듯, 그 용어를 구현한 제품/서비스 역시 그 의미를 정확히 포함하고 있지 않으면 안됩니다. MVP라고 만들었지만, POC수준이라던지, MVP의 기준점이 명확하게 달성되어 있지 않는다면, 그 용어를 정확히 이해했다고 하기엔 무리가 있습니다. 그래서 오늘은 MVP란 무엇이고, 그것을 만드는 목적, 올바른 개념과 좋은 MVP에 접근하기 위한 방법을 나누어 볼까 합니다.
1. MVP를 만드는 목적
아이디어를 소프트웨어 프로덕트/서비스로 실현 해 내는 작업은 비용, 시간, 노력, 지식이 총동원되는 위험한 투자입니다. 이 위험한 투자가 최종적으로 '실패'라는곳으로 향할것이라는것을 예상하고 그 일을 시작하는 사람은 아무도 없을것이지만, 현실은 매우 잔인합니다. 미국의 실리콘밸리나 유럽의 스타트업 스테이션에서 아주 빈번하게 발견되는 모델이 있습니다.
소문난 개발자들을 모아 팀을 만들고, 애자일프로세스로 개발을 하고, 린스타트업방법론을 적용해서 프로덕트 관리를 하고, 모든 사용자층을 대상으로 하는 프로덕트를 자신있게 출시합니다. 예상했던것보다 반응이 저조합니다. 비슷한 분야의 프로덕트들과의 경쟁 탓일까요? 생각에는 제품의 품질 보다는 홍보와 마케팅이 부족한듯 하여 모든 여력을 쏟아 붓습니다. 또 하나의 완벽한 '실패'입니다.
과연 '왜' 일까요?
대부분의 프로덕트는 사용자가 필요로하지 않는 제품을 제공하기 때문에 관심을받지 못하고 시장에서 빠르게 사라집니다. 이것이 바로 MVP의 기본 목적을 설명하게 합니다.
Eric Ries의 책 The Lean Startup 에 나오는 MVP의 핵심 메시지는 " 초기 사용자들이 관심을 갖고 피드백을 제공하거나, 정식제품 출하시에 구매의사가 있는 (핵심적인 문제를 해결한) 기능을 가진 제품/서비스"를 말합니다. 여기에서 가장 중요한 키워드는 '피드백 제공'이라고 할 수 있습니다. 당신이 제품에 넣은 아이디어가 고객들에게 관심을 받을 수 있는 지를 빨리 학습해야 합니다. 그리고 그것이 아니라면 신속하게 방향 전환을 해야 하죠. 즉 MVP을 만드는 유일무이한 목적은 고객과 시장을 빨리 이해하기 위함 그 이상 이하도 아닙니다.
여기에서 MVP를 왜 만들고 이 접근법을 사용하는지에 대한 목적을 명확히 해야 합니다.
1. 여러분이 빠른 시간안에 최소의 비용으로 프로덕트/서비스를 내놓고 실험을 해 볼 수 있습니다.
2. 대상 사용자와 타겟 마켓을 찾아내는 연습을 할 수 있습니다.
3. 프로덕트가 제공할 기능과 고객의 요구사항의 밸런스를 찾아 시장에서 생존가능 확률을 높입니다.
4. 대상 사용자에게서 품질이 좋은 피드백을 받아내 고객과 시장을 더욱 더 잘 이해합니다.
5. 크리티컬한 문제점을 걸러내어, 메인 릴리즈에 반영합니다.
2. MVP의 핵심 개념
MVP를 만드는 목적이 상대적으로 명확한 정의임에도 불구하고, 많은 PM, 개발자, 디자이너 혹은 매니지먼트 그룹이 정확한 이해를 하고 있는 경우는 많이 드뭅니다. 그 이유는 다음의 3가지 정도로 나누어 볼 수 있는데, 그 주 원인은 MVP를 단어 그대로 해석하면서 오해가 생기기 때문입니다.
1) Minimum의 의미는 '최소한의 기능 세트'가 아닌, '핵심 가치' 를 의미합니다.
이 최소한 Minimum이란 단어 뜻 때문에 MVP의 기본 의미를 잘 이해하지 못하는 사용자나 고객들도 오해를 할 수 있습니다. 고객들은 MVP의 'P' Product라는 단어로 '완성도 있는 제품'이라고 이해하기 때문입니다. 하지만 그런 혼란스런 고객의 반응 때문에, 여러분의 아이디어가 최소한으로 쪼그라들 필요는 없습니다. MVP의 목적은 최대한 빨리 배우는 것입니다. 따라서 프로덕트의 "최소한의 기능 세트는 무엇인가"가 아니라 "좋은 프로덕트인지 확인할 수있는 가장 빠른 방법은 무엇인가"라는 생각에 포커스를 맞추어야 합니다. 다시 강조하지만, 최소 실행 가능한 제품 (MVP)이 항상 최종 제품의 작거나 저렴한 버전은 아닙니다. 특별한 기능이나 디자인을 테스트하는것이 아닌 핵심가치를 검증하기 위해 필요한 최소한의 버전인것입니다.
MVP중 '최소한 minimum'을 설명할때 Dropbox의 MVP가 교과서처럼 자주 언급됩니다. Dropbox의 창업자는 사용자들이 제품을 사용할지 여부를 확인하기 위해 제품의 기능을 설명하고 보여주는 영상를 만들었습니다. 이 영상를 내놓았을 때 실제 Dropbox 기능이 동작하는 소스코드와 프로덕트는 이 세상에 존재하지 않았던 순수한 의미의 베이퍼웨어 vaporware 였습니다. 그러다 기능 설명 영상이 소위 입소문을 나면서 며칠만에 7만5천명의 구독자를 확보했고, 그 중에는 스티브 잡스가 있었습니다. 그를 통해 약 3000억원 (250 M USD)의 투자를 받을 수 있었습니다. Dropbox의 창업팀은 제품/서비스를 만들기 전에 프로덕트의 핵심가치를 충분히 잘 배울 수 있었습니다.(Dropbox의 MVP이야기)
2) 학습 목적으로만 'viable-실행 가능, 생존 가능'합니다.
아마도 가장 이해하기 어렵고 헷갈리는 단어가 viable이 아닐까 합니다. 이 viable이란 뜻을 쉽게 설명드리기 위해 아래 그림의 'IDEO의 프로덕트 프레임워크'를 사용해 보겠습니다.
IDEO Design Thinking FrameworkEric Ries가 viable이란 단어를 택한 이유는 'business(마케팅, 파이넌스)'라는 개념을 대표로 사용했기 때문입니다. 여러분이 준비하고 있는 제품에 따라서 위의 그림을 이렇게 이해하면 쉽습니다. 준비하는 제품/서비스의 성격상 그것이 진정한 기술 주도적인 프로덕트라면, Minimum Feasible Product( 차별화 핵심 기술이 구현된 최소 완성품)로 이해하시면 되고, 최종사용자를 위한 디자인이나 특정 서비스 프로덕트라면 Minimum Desirable Product (고객이 희망하는 기능이 구현된 최소 완성품)라고 이해하면 됩니다. 제가 개인적으로 선호하는 워딩은 'Desirability'인데, 이렇게 치환해 놓으면, MVP의 실제 목적을 조금 더 피부에 닿게 이해하게 됩니다. 내가 제공하고자 하는 제품/서비스의 가치가 초기 사용자를 참여시킬 수있을만큼 매력적인지(desirable) 테스트하는 것입니다.
실행 가능이라는 viable이라는 단어를 사용한 탓에 많은 분들이 기업이 초기에 세운 제품/서비스의 비즈니스 모델과는 어떤 상관점을 갖는지 궁금해 하십니다. 이 MVP의 목적이 바로, MVP 자체 뿐만이 아닌, 비즈니스 모델을 검증하고 실험하는데 쓰이는 것이지, 하나를 고정시키고, 다른 하나를 그것에 맞추는데 있지 않습니다.
즉 MVP는 미리 정해놓은 비즈니스모델을 테스트 하는것이 아니라, 이 제품/서비스의 가치value를 제안하고 확인하는 과정가운데, 비즈니스모델을 탄력적으로 함께 수정하는것입니다.
예를 들어, 내가 기획하고 있는 '데이팅 앱'이 있는데, 초기의 비즈니스 모델은 10대부터 60대까지의 모든 연령이 타겟 대상으로 정하고, 그 모델에 따라서 MVP를 만든 후에 타겟 고객층과 실험과 학습을 했더니, 젊은층이 아닌 중장년층에서 더 효과적인 결과가 나왔다면, 그것에 따라서 비즈니스 모델을 수정하는 것이 제품을 전 연령층에 맞게 다시 수정하는 전략적접근법입니다.
3) 'Product-제품/서비스' 가 아닐 수 있습니다.
MVP의 P가 '프로덕트'라는 말때문에 많은 오해가 생길 수 있습니다. 우리는 일반적으로 '프로덕트/제품'이라고 할때 그것을 판매용으로 제조 또는 준비된 것으로 이해합니다. 이를 서비스로 확장하더라도 실제 고객을 위한 서비스의 작은 버전쯤으로 이해를 합니다. MVP의 목적은 판매가 아니라 학습입니다. MVP는 고객과 시장이 우리가 실험하고, 가정을 한대로 실제로 행동하는지 알아 내기 위해 사용하는 도구입니다. 물론 우리가 검증해야하는 가정의 일부 중에는 나중에 고객들이 우리 제품에 대해 비용을 지불 할 것인지 여부도 포함되지만 접근 방법은 완전히 다릅니다. 후에, 고객들이 분명히 비용을 지불 할 것이라는 가정하에 만든 기능들 중에는 어쩌면 많은 기능들이 최종 제품에 포함되지 않을 수도 있기 때문입니다.
"프로덕트/제품"이라는 단어를 사용하면 사람들은 이미 최종 제품처럼 보이는 것을 만들어야한다고 생각하게되지만 그렇지 않을 수도 있습니다. 나중에 MVP는 실제로 제품 (또는 제품 모양으로 발전) 이 될 것이지만 초기 MVP는 그렇지 않을 가능성이 높습니다. 그렇기에 MVP는 제품이라고 부르기 보다는 '실험 또는 경험'이라고 부르는것이 맞을듯 합니다.
3. 좋은 PM의 옳은 MVP 접근법
1)정확한 개념에 집중하세요
약 1년전부터 소셜미디어나 아티클을 통해서 MVP의 개념을 설명할때 수 많은곳에서 인용되는 그림이 있습니다. 많은 분들이 아래 그림을 보면서 "아하~ MVP의 개념이 이런것이구나"라고 이해했을 수 있습니다. 저 역시 처음 이 그림을 접했을때 "참 쉽게 설명했구나"하곤 좀 더 들여다 보니, 이 그림은 아주 치명적인 오류를 갖고 사용자에게 잘못된 개념을 전달 할 수 있음을 발견했습니다. 그 다음날 동료 PM들과 이 그림에 대해서 함께 리뷰를 하였고, 그 오류를 다시 한번 검증 확인하였습니다. 또한 기쁘게도 저와 같은 생각을 하는 PM들이 인터넷세상에서 비슷한 의견을 내고 있더군요.
잘못된 MVP 설명 다이어그램여러분께서는 오류점을 발견하셨나요?
MVP가 아니라고 'Not Like this...'라고 하는 윗부분의 그림은 볼 필요도 없습니다. 2번째 바퀴 휠만 제공하는 단계부터 코어기능뿐만 아니라 어떤 가치도 제공하지 못합니다.
'Like this!' 라고 설명한 부분을 보면서 이제부터 하나하나 설명해 보겠습니다.
최종프로덕트가 멋진 모습의 자동차입니다. 그렇다면, 이 제품은 '교통수단으로서의 어떤 문제점을 해결하려는 프로덕션의 과정' 으로 해석됩니다. 파워가 좋은 혁신적인 전기 자동차일 수도 있습다. 최종 프로덕트로 가는 과정에서 스케이트보드, 킥보드, 자전거, 모터바이크 과정을 거쳐갑니다.
A. 잘못된 대상- 사용자와 마켓
위에서 여러번 강조했던 MVP의 가장 중요한 점이 대상 사용자와 마켓을 알기 위해, 그리고 그곳에서 의미있는 피드백을 받는것인데, 이 그림은 최종 프로덕트가 되는 '자동차' 사용자 그룹을 '스케이트보드' 사용자 그룹과 동일시 합니다.
최소 20대 이상이 사용자 타겟이 되는 자동차 시장을 10대가 많이 이용하는 스케이트보드로 맞춥니다.
복수의 이용자가 동시에 이용할 수 있는 자동차인데 반해, 스케이트보드, 킥보드 자전거, 모터바이트 모두 1인만이 사용가능한 수단입니다.
교통수단이란 프로덕트 전제하에 스케이트보드는 교통수단에 해당하지 않습니다.
또한 기본 2천만원 이상이 구매비용 마켓과 10만원 내외의 마켓과는 타겟자체가 다릅니다.
B. 잘못된 밸런스 -프로덕트 기능과 고객의 요구사항
킥보드를 테스트하는 사용자에게서 자동차를 사용할 목적 사용자의 요구사항을 올바르게 들을 수 없습니다. 예를 들어 킥보드의 뒷바퀴의 발 브레이크를 패드를 좀 더 크게 만들어 달라는 요구사항은 자전거나 모터바이크로 전달되어 적용되기는 어렵습니다.
C. 무의미한 피드백
잘못된 대상 사용자에게서 품질이 좋은 피드백은 기대할 수 없습니다. 모터바이크와 자동차는 사용자가 면허와 보험이라는 법적 요건을 갖추어야 하는 기본적인 조건인데, 그 전 단계인 스케이트보드와 킥보드는 그 조건이 만족되지 않습니다. 자전거를 타는 사이클리스트를 대상으로 한 연구와 피드백은 자동차 운전자에 대해서는 아무것도 알려주지 않습니다.
D. 기술과 경험 축적 오류
위의 1~3번의 과정이 대상 선정에 문제가 있는 부분었다고 모든것을 양보하고 이해한다고 해도, 여전히 근본적인 문제가 있습니다. 다음 단계로 넘어가기 위한 기술과 경험은 축적되었나요? 자전거를 만드는 기술과 경험의 축적이 자동차를 만드는 데 얼마가 기여를 하나요?
지금까지 4가지의 오류에 대해서 설명을 드렸는데, 그렇다면 이 예가 되는 MVP의 올바른 모습은 어떻게 되어야 할까요? 자동차가 최종 프로덕트의 형태라면, MVP 역시 자동차가 가지는 핵심가치를 포함하고 있어야 합니다. 그렇다면 형태는 그 가치를 시험해 볼 수 있는 자동차의 형태가 되어야 합니다. 이렇게 말입니다.
MVP를 설명하는 옳은 다이어그램2) 핵심가치 전달이 최우선입니다
두번째는 잘못됬다고는 할 수없지만, 좀 더 설명이 필요하고 개선이 필요한 다이어그램의 예입니다. 이 그림 역시 MVP를 설명하는 수많은 아티클과 소셜미디어에서 인용이 됩니다. 이 그림은 소프트웨어 프로덕트/서비스를 타겟 시장에 릴리즈 할때 그 품질 평가에 대한 일반적인 기준 4가지 -기능성, 안정성, 편의성에 가치(Design을 Value로 해석)- 를 예로 들면서 MVP가 어디에 얼마만큼의 중점을 두어야 하는지를 설명하고 있습니다.
과도하게 일반화된 가치제안 value proposition위의 다이어그램의 왼쪽은 물론 개발자위주의 스타트업에서 초기에 발생하게 되는 기능위주의 MVP에서 많이 보여지는 매우 나쁜 예입니다. 오른쪽 그림은 그 부분을 충분히 개선하여 4가지 모든 부분에 골고루 역량을 투하여 MVP의 본뜻에 충실하려고 했습니다. MVP의 본 목적을 마지막으로 힌번 더 반복해 봅니다. 우리가 최종적으로 제공한 프로덕트/서비스의 가치를 고객으로 부터 확인하는 과정입니다. 그렇다면 4가지 기준에 동등한 양의 역량을 분배하기 보다는 가치를 전달하는 역량에 더욱 더 많이 분배를 해야 합니다. 위의 다이어그램을 제가 좀더 확장해서 아래와 같이 MVP의 성숙도로 4개의 모델로 나누어 보았습니다.
최선의 MVP로의 접근 방법MVP가 초기 과정을 지나면서는 나머지 짙은 부분의 삼각형에 해당하는 기준을 점진적으로 충족시켜야 하지만, 초기 MVP는 반드시 가치전달이 최우선이 되어야 합니다. 그러기에 동등한 양만큼이 아닌 역삼각형의 포커스가 이루어 져야 한다는 점을 말씀드리고 싶습니다. 삼각형 밑의 적은 질문의 내용도 주의 깊게 보시기 바랍니다. MVP에 대해서 어떤 질문을 던질때 어떻게 방향이 결정되는지 말입니다. 현재 여러분이 계획하시는 MVP는 어떤 상태인가요? 가치전달 부분은 충분히 고려되고, 전략적으로 접근되고 있나요? 위에서 설명드린 드롭박스의 예를 다시한번 잘 생각해 보셨으면 합니다.
다음글에서는 드롭박스 이외의 다른 에어비엔비나 우버같은 유니콘들이 어떻게 MVP를 접근했는지에 대한 예를 설명합니다.
이번 글에서는 MVP를 만드는 목적, 올바른 이해와 좋은 MVP에 접근하기 위한 방법에 대해서 이야기 해보았습니다. 마지막으로 이 글을 마무리 지으면서 여러분들이 다음의 3가지는 꼭 기억하셨으면 합니다.
MVP는
1. 비즈니스의 가치를 테스트 할 수있는 방법으로 최소한이 아닌, 핵심가치에 집중하는것입니다.
2. 기술적 가능성을 테스트하는것이 아닌, 고객이 이 프로덕트의 가치 제안에 반응하는지를 테스트하는것입니다.
3. 실제로는 프로덕트로 부른다 해도, 좋은 PM이라면 이것을 프로덕트라고 부르기 보다는 경험experiences이라 부르고 쌓아가는 과정으로 생각해야 합니다.
여러분의 노력으로 세상은 점점 더 올바르고 좋은 방향으로 움직입니다. 늘 응원 드립니다.
