기획
좋은 PM을 위한 MVP프라이머
11분
2021.01.08.3.3K
"좋은 PM을 위한 MVP프라이머"
지금은 컴퓨터의 사용과 데이터의 중요성을 인식하면서 많이 줄어들었지만, 예전에는 의사들이 손으로 쓴 처방전을 일반인이 읽고, 해독해 내는 것은 거의 불가능했습니다. 2020년 오늘도 법조인들의 문서는 왠만한 전문가가 아직도 이해하기 어렵습니다. 아직도 방송이나 건축현장에서 날아다니는 일본어 전문(?) 용어는 외계어 같기도 합니다. 이런 전문가 그룹이 그런 용어를 쓰는 데는 전문성을 강조하는 이유도 있겠지만, 무엇보다 타 그룹과의'다름과 드러남'을 추구하고 같은 그룹원과의'동료 의식'을 갖기 위함도 한 몫을 하고 있는 것이 사실입니다.
일반인이라면 절대 읽을 수 없는 처방전
이런 경우는 컴퓨터, 소프트웨어 산업에서도 예외는 아닙니다. 물론 산업자체가 서양에서 부터 들어오다 보니 그럴수는 있지만, 수많은 신조어와 약어를 섞어 사용하는 대화를 다른 산업종사자들이 이해하기는 쉽지 않을겁니다. 오늘 소개할 MVP (Minimum Viable Product)만 해도 실제 스포츠에서 사용하는 같은 단어 (Most Valuable Player)가 훨씬 더 실생활에 널리 퍼져 있습니다. 우리가 대화에 전문용어를 사용하는 이유는 남과의 다름을 은연중 나타내기 함이 아니라, 그 용어가 의미하고 포함하는 정확한 뜻을 전달하기 위함이 되어야 합니다. 제가 예전 글 <POC,Prototype, MVP를 구별하여 사용하자!> 에서 소개했듯 각각의 용어를 잘 구별하여 사용하는것이 그 정의를 구체적으로 이해하는데 중요하듯, 그 용어를 구현한 제품/서비스 역시 그 의미를 정확히 포함하고 있지 않으면 안됩니다. MVP라고 만들었지만, POC수준이라던지, MVP의 기준점이 명확하게 달성되어 있지 않는다면, 그 용어를 정확히 이해했다고 하기엔 무리가 있습니다. 그래서 오늘은 MVP란 무엇이고, 그것을 만드는 목적, 올바른 개념과 좋은 MVP에 접근하기 위한 방법을 나누어 볼까 합니다.1. MVP를 만드는 목적
아이디어를 소프트웨어 프로덕트/서비스로 실현 해 내는 작업은 비용, 시간, 노력, 지식이 총동원되는 위험한 투자입니다. 이 위험한 투자가 최종적으로 '실패'라는 곳으로 향할것이라는것을 예상하고 그 일을 시작하는 사람은 아무도 없을 것이지만, 현실은 매우 잔인합니다. 미국의 실리콘밸리나 유럽의 스타트업 스테이션에서 아주 빈번하게 발견되는 모델이 있습니다.
소문난 개발자들을 모아 팀을 만들고, 애자일프로세스로 개발을 하고, 린스타트업방법론을 적용해서 프로덕트 관리를 하고, 모든 사용자층을 대상으로 하는 프로덕트를 자신있게 출시합니다. 예상했던것보다 반응이 저조합니다. 비슷한 분야의 프로덕트들과의 경쟁 탓일까요? 생각에는 제품의 품질 보다는 홍보와 마케팅이 부족한듯 하여 모든 여력을 쏟아 붓습니다. 또 하나의 완벽한 '실패'입니다.
과연 '왜' 일까요?
대부분의 프로덕트는 사용자가필요로하지않는제품을제공하기때문에 관심을받지 못하고 시장에서 빠르게 사라집니다. 이것이 바로 MVP의 기본 목적을 설명하게 합니다.
Eric Ries의 책 The Lean Startup 에 나오는 MVP의핵심메시지는 " 초기 사용자들이 관심을갖고피드백을제공하거나, 정식제품 출하시에 구매의사가 있는 (핵심적인문제를해결한) 기능을 가진 제품/서비스"를 말합니다. 여기에서 가장중요한키워드는 '피드백제공'이라고 할 수 있습니다. 당신이제품에넣은아이디어가고객들에게관심을받을수있는지를빨리학습해야 합니다. 그리고 그것이 아니라면 신속하게 방향 전환을 해야 하죠. 즉 MVP을만드는유일무이한목적은고객과시장을빨리이해하기위함그이상이하도아닙니다.
여기에서 MVP를왜만들고이접근법을사용하는지에대한목적을 명확히 해야 합니다.
-
- 여러분이 빠른 시간안에 최소의 비용으로 프로덕트/서비스를 내놓고 실험을 해 볼 수 있습니다.
- 대상 사용자와 타겟 마켓을 찾아내는 연습을 할 수 있습니다.
- 프로덕트가 제공할 기능과 고객의 요구사항의 밸런스를 찾아 시장에서 생존가능 확률을 높입니다.
- 대상 사용자에게서 품질이 좋은 피드백을 받아내 고객과 시장을 더욱 더 잘 이해합니다.
- 크리티컬한 문제점을 걸러내어, 메인 릴리즈에 반영합니다.
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의 프로덕트 프레임워크' 를 사용해 보겠습니다. Eric 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가 아니라고 'Not Like this...'라고 하는 윗부분의 그림은 볼 필요도 없습니다. 2번째 바퀴 휠 만 제공하는 단계부터 코어 기능뿐만 아니라 어떤 가치도 제공하지 못합니다. 'Like this!' 라고 설명한 부분을 보면서 이제부터 하나하나 설명해 보겠습니다.
최종 프로덕트가 멋진 모습의 자동차입니다. 그렇다면, 이 제품은 '교통수단으로 서의 어떤 문제점을 해결하려는 프로덕션의 과정’으로 해석됩니다. 파워가 좋은 혁신적인 전기 자동차일 수도 있습니다. 최종 프로덕트로 가는 과정에서 스케이트보드, 킥보드, 자전거, 모터바이크 과정을 거쳐갑니다.
A. 잘못된 대상- 사용자와 마켓
위에서 여러 번 강조했던 MVP의 가장 중요한 점이 대상 사용자와 마켓을 알기 위해, 그리고 그곳에서 의미 있는 피드백을 받는 것인데, 이 그림은 최종 프로덕트가 되는 '자동차' 사용자 그룹을 '스케이트보드' 사용자 그룹과 동일시 합니다.
- 최소 20대 이상이 사용자 타겟이 되는 자동차 시장을 10대가 많이 이용하는 스케이트보드로 맞춥니다.
- 복수의 이용자가 동시에 이용할 수 있는 자동차인데 반해, 스케이트보드, 킥보드 자전거, 모터바이크 모두 1인만이 사용가능한 수단입니다.
- 교통수단이란 프로덕트 전제하에 스케이트보드는 교통수단에 해당하지 않습니다.
- 또한 기본 2천만원 이상이 구매비용 마켓과 10만원 내외의 마켓과는 타겟 자체가 다릅니다.
2) 핵심가치 전달이 최우선입니다
두번째는 잘못됐다고는 할 수 없지만, 좀 더 설명이 필요하고 개선이 필요한 다이어그램의 예입니다. 이 그림 역시 MVP를 설명하는 수많은 아티클과 소셜미디어에서 인용이 됩니다. 이 그림은 소프트웨어 프로덕트/서비스를 타겟 시장에 릴리즈 할 때 그 품질 평가에 대한 일반적인 기준4가지-기능성,안정성,편의성에 가치(Design을Value로 해석)- 를 예로 들면서 MVP가 어디에 얼마만큼의 중점을 두어야 하는지를 설명하고 있습니다.
위의 다이어그램의 왼쪽은 물론 개발자위주의 스타트업에서 초기에 발생하게 되는 기능위주의 MVP에서 많이 보여지는 매우 나쁜 예입니다. 오른쪽 그림은 그 부분을 충분히 개선하여 4가지 모든 부분에 골고루 역량을 투하여 MVP의 본뜻에 충실 하려고 했습니다. MVP의 본 목적을 마지막으로 한번 더 반복해 봅니다. 우리가 최종적으로 제공한 프로덕트/서비스의 가치를 고객으로부터 확인하는 과정입니다. 그렇다면 4가지 기준에 동등한 양의 역량을 분배하기 보다는 가치를 전달하는 역량에 더욱 더 많이 분배를 해야 합니다. 위의 다이어그램을 제가 좀더 확장해서 아래와 같이 MVP의 성숙도로 4개의 모델로 나누어 보았습니다.
MVP가 초기 과정을 지나면서는 나머지 짙은 부분의 삼각형에 해당하는 기준을 점진적으로 충족시켜야 하지만, 초기 MVP는 반드시 가치전달이 최우선이 되어야 합니다. 그러기에 동등한 양만큼이 아닌 역삼각형의 포커스가 이루어 져야 한다는 점을 말씀드리고 싶습니다. 삼각형 밑의 적은 질문의 내용도 주의 깊게 보시기 바랍니다. MVP에 대해서 어떤 질문을 던질 때 어떻게 방향이 결정되는지 말입니다. 현재 여러분이 계획하시는 MVP는 어떤 상태인가요? 가치전달 부분은 충분히 고려되고, 전략적으로 접근되고 있나요? 위에서 설명 드린 드롭박스의 예를 다시한번 잘 생각해 보셨으면 합니다.
이번 글에서는 MVP를 만드는 목적, 올바른 이해와 좋은 MVP에 접근하기 위한 방법에 대해서 이야기해보았습니다. 마지막으로 이 글을 마무리 지으면서 여러분들이 다음의 3가지는 꼭 기억하셨으면 합니다.
MVP는- 비즈니스의 가치를 테스트 할 수있는 방법으로 최소한이 아닌, 핵심가치에 집중하는것입니다.
- 기술적 가능성을 테스트하는것이 아닌, 고객이 이 프로덕트의 가치 제안에 반응하는지를 테스트하는것입니다.
- 실제로는 프로덕트로 부른다 해도, 좋은 PM이라면 이것을 프로덕트라고 부르기 보다는 경험experiences이라 부르고 쌓아가는 과정으로 생각해야 합니다.
로그인하고 자유롭게 의견을 남겨주세요.
