[Lean] MVP의 5가지 함정과 탈출법
MVP를 올바르게 이해하고 실행하기 위해
MVP의 탄생과 유행
MVP는 "Minimum Viable Product"의 약자로, 린스타트업 방법론에서 제품을 어떻게 정의하는지에 대한 용어이다. 스타트업의 바이블을 넘어 이제 전 산업계로 유행하고 있는 "린스타트업"이 2011년 발행되기 전에, Eric Ries는 MVP라는 Term을 2009년에 그의 블로그에 처음 선보였다.
"A Minimum Viable Product is that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort."
"MVP는 팀이 최소한의 노력으로 최대한의 고객 검증을 할 수 있는 버전의 새로운 제품."
혹 MVP라는 용어에 익숙하지 않은 분은 위키피디아 일독을 먼저 해보셔요.
린 방법론을 적용한 조직, 더 넓게는 불확실한 환경에서 더 빠르고 가볍게 실행하고 싶은 조직의 입장에서 MVP를 만나는 것은 "구세주"가 탄생한 것이나 마찬가지다. MVP라는 용어의 인기는 그 단어 자체의 Fancy함도 한 몫하는 것 같다 : )
이렇게 (말로는) 명확하고 간단해 보이지만, 막상 업무 적용 해보면 상당한 실행의 어려움에 부딪히게 된다.(혹시 쉬웠다는 분이 있으면 알려주세요...)
"LEAN 방법론을 적용하긴 하지만 MVP는 솔직히 제대로 적용하지 못하고 있다." "MVP 중심으로 커뮤니케이션을 하다보니 업무가 더 어렵고 복잡해졌다"
개인적으로도 MVP의 개념을 제대로 이해하고 업무에 적용하기가 참 쉽지 않은 것 같다. 많은 오해와 시행착오도 겪어 왔고 지금도 그러고 있다. 린 방법론을 기반으로 제품을 개발하고 있는 조직, 혹은 MVP를 이해하고 적용하고 있는 조직에서 자주 빠지는 5가지 함정을 개인의 경험과 레퍼런스 자료들을 통해 정리해보았다. 무엇보다 스스로 함정에 빠지지 않기 위해 : )
(광고)
No.1 화장품 플랫폼을 만들어가고 있는 화해에서 Product Manager 동료를 찾아요!
MVP의 5가지 함정
#1. "Minimum"에 대한 환상
MVP에서 가장 쉬운 단어, 가장 매력적인 단어, 속시원한 단어는 바로 Minimum이 아닐까 한다. 이는 지극히 자연스러운 현상이다. 엄청난 시간과 Cost를 낭비로 실패해봤다면, 현재 업무속도가 답답하다고 느껴진다면, 가볍게 성과와 결과를 알고 싶다면, Minimum Product는 참 반가운 용어이다. Director들 입장에서 MVP를 기반으로 일을 한다고 하면 얼마나 달콤한 제안인가. 특히 제품 개발 중심 조직에서는 마치 MVP를 적용하면 모든 제품과 과제가 Minimum해지고 더 빠게 Output이 나올 것만 같은 기대감에 가득차게 된다.
Love Minimum하지만 "Minimum Product"라는 환상에 집착하는 것은 매우 위험하다. MVP는 "검증"을 하기위해 최소한의 노력을 지향하는 것이지 제품 자체를 Minimum으로 만들자는 관점은 아니다. "과제 진행을 위해 Feature를 최대한으로 줄인 것이 맞냐?"라는 Product에 기반한 질문은 우리 모두를 매우 곤혹스럽게 한다. 결국은 제품의 Minimum에만 집착하다가 부랴부랴 어중간한 Product가 출시되고 본질은 잊은채 저품질의 제품을 고객에게 소개하고 뒷수습하기 바쁘게 된다. 마치 아래 그림에서 상단 3번의 핸들없는 탈것 처럼.
http://blog.crisp.se/2016/01/25/henrikkniberg/making-sense-of-mvpLean 방법론은 가설과 아이디어를 구현하고 측정하고 학습하는 실험이다. 여기서 Minimum은 이러한 실험을 최소한으로 할 수 있는 "최소한의 노력"은 무엇인가?라는 관점에서 고민해야한다. 결국 실험을 어떻게 확실하게 검증할 것인가가 "핵심"이며, 그것을 가능하면 Minimum하게 진행해보자는 "의지"가 보완되는 것이맞지 않을까.
#2. 근시안적인 Product 관점
음..MVP가 Product가 아니라는 얘기인가? 물론 MVP에는 Product라는 용어가 들어가 있다. 하지만 제품은 수단이지 목적이 아니다. 수단에만 집착하면 목적을 달성하기 위한 방향성을 잊어버린채 제대로된 솔루션을 도출하지 못한다. MVP를 지향하는 이유는 "최소한의 노력"으로 "최대의 학습과 검증"을 하기 위함이다. 그렇다면,
1) MVP는 "Product"라기보다는 최대의 학습과 검증을 위한 "솔루션"이라고 보는 것이 맞겠다.
- 우선 Lean에서 얘기하는 Build 단계를 "제품개발"이라는 미시적인 관점으로 바라보면 실제 측정과 학습을 효과적으로 해낼 수 없다. 고객에게 \\최대한의 학습을 얻어내려면, 그에 적합한 release 아이디어, 데이터 수집방법, 분석 Frame 등이 함께 필요하다. 따라서 MVP는 실제 "Feature Set"이라기보다 최대의 학습 효과를 얻어내기 위한 고객 Delivery, 데이터 수집, 측정방안을 포괄하는 전략적인 솔루션이어야 한다고 본다.
실제 실리콘밸리의 기업가 Jon Radoff는 MVP를 아래와 같이 정의하기도 했다.
An MVP is not a minimal product, it is a strategy and process directed toward making and selling a product to customers. It is an iterative process of idea generation, prototyping, presentation, data collection, analysis and learning.
2) 더 극단적으로 MVP는 제품일 필요도 없다.
이 것에 대해 논란의 여지가 많긴 하지만, 대표적인 성공 사례로 거론되는 Dropbox MVP의 사례를 살펴보면 많이 와닫는 포인트가 있다.
Dropbox는 "파일 동기화"를 핵심적인 고객 문제 해결의 포인트로 잡았고, 고객 검증을 원했다. 완벽한 데모를 준비하기 어려웠던 그들은 실제 데모 대신에, 실제 데모처럼 보이는 영상을 만들어 보여주고 베타 고객을 성공적으로 모집하여 그 들의 가설을 검증해냈다. 이에 대해 아래와 같이 평가된다.
In this case, the video was the minimum viable product. The MVP validated Drew’s leap- of- faith assumption that customers wanted the product he was developing not because they said so in a focus group or because of a hopeful analogy to another business, but because they actually signed up.
Dropbox 유튜브 화면 https://www.youtube.com/watch?v=7QmCUDHpNzE#3. UX라는 암초에 부딪히다
Agile, Lean 방법론에 있어 UX를 어떻게 효과적으로 Align할 것인가는 항상 까다로운 이슈다. 특히 조직적으로 UX팀/디자인팀이 분리되어있다면 더더욱 그러할 것이다. 이런 이슈를 분석하고 해결하고자 가이드라인을 제시한 아티클도 여럿 볼 수 있다. "Lean UX"라는 도서도 별도로 있다.
MVP에서 사용자경험(UX)을 제대로 해결을 하지 못하면 마치 "암초"에 부딪히는 것과 같다. "효과적으로 새로운 서비스를 검증하기 위해 그럴싸한 사용자 경험은 일단 무시되는 것이냐?"라는 관점. 혹은 반대로, "사용자 경험 고려하다가 실험은 언제하냐"라는 관점도 있다. 이러한 UX에 대한 고려는 명확한 솔루션은 없다고 생각한다. 결국 조직과 Product의 상황에 맞게 효과적으로 균형을 맞추려는 시각이 필요하다. Role의 특성, 의사결정 및 협업 매커니즘에 따른 솔루션은 모두 다르겠지만 제시할 수 있는 일반적인 솔루션은 아래와 같다.
의사결정의 명확화: 우선순위와 가치판단에 대한 의사결정을 명확히하라. 빠른 실험 검증과 사용자 경험을 어떻게 Align 시킬지는, 두 가지 관점을 충분히 고려할 수 있는 Product manager나 이에 준하는 Director가 명확히 의사결정해야한다.
Process 관점: MVP는 마지막 버전의 제품이 아니다. 효과적으로 검증하기 위한 "첫" 제품의 버전이며 학습 결과에 따라 제품은 다음 스텝으로 넘어가게 된다. 이러한 Lean한 프로세스에서 MVP의 역할을 UX/디자인이 충분히 이해하고 Plan을 함께 세울 수 있는 협업 모드를 만들어내야 할 것이다. 아래와 같이 Minimum Viable UX라고 시도해보는건 어떨까.
출처: http://uxmag.com/articles/balancing-product-ux-and-lean-execution툴의 지원: MVP는 검증을 하기위한 사용자를 대상으로 원하는 분석결과를 얻으면 된다. 따라서 이미 성장한 서비스라면 모든 사용자에게 Risk를 높여 실험/분석할 필요가 없다. 따라서 A/B테스트 툴을 활용하거나 단계적 릴리즈 등의 프로세스를 잘 활용한다면 UX의 비용과 Risk를 적절히 레버리지하면서 원하는 실험을 효과적으로 진행할 수 있을 것이다.
#4. 결국 혼란에 빠지다
MVP를 만들고 출시를 하면 그 다음에 어떻게 되는것인가? 처음 아이디어에 대한 분석을 할때는 그 결과에 대해 열띤 논의를 하겠지만 제품을 열심히 만들다보면 개발과 출시에 매몰되어 출시 이후에 벌어질 상황을 잊어버리곤 한다. MVP는 측정을 통한 의사결정이 발생하므로 의사결정의 혼란에 빠지지 않기 위해 아래와 같은 요소들이 필수적으로 고려해야한다.
1) 측정을 위해 적절한 대상에게 노출할 수 있는 기능: 위에 언급했듯이 기본적으로는 "실험 검증"에 필요한 고객에게 효과적으로 노출하기 위한 방안으로, A/B테스팅 환경 등이 필요하다. 또한 Business Partner와 같이 외부 이해관계자가 연관되어있다면 이들을 위한 측정 환경도 추가로 필요할 수 있다.
2) 데이터 수집 환경: 정량적으로 분석하고자 한다면 특히 MVP에 데이터 수집/분석환경이 중요하게 고려되어야 한다.(가장 놓치는 케이스가 많다) 분석과정에서 꼭 필요한 데이터가 누락되어있거나, 신뢰할 수 없는 데이터가 수집되어있다면 그 다음 의사결정이 대혼란에 빠지게 된다. "Minumum Product"에 집착한다거나 "어떻게든 분석되겠지"라는 근시안적인 판단은 추후 의미없는 MVP를 통해 아무것도 결정할 수 없는 상황을 만들어낼 수 있다.
3) Viable MVP인가?: 가장 난감한 상황은 MVP 출시 후 분석 결과를 해석할때 "혹시 MVP가 적절하지 않은 것이 아닐까? 다시 실험해봐야하지 않는가?"라는 질문이 나오는 경우라고 생각된다. MVP가 잘못된 방향으로 설계되었거나, 실험하기에 충분하지 않은 Feature로 구성되었을때 주로 발생할 것이다. 결국 MVP에 대해서 의사결정자의 관점에서 Viable MVP인가? 라는 질문을 던지고, 가능한 시점에 Stakeholder들과 점검하는 과정이 꼭 필요하겠다.
#5. 섣부른 MVP의 착수
Lean 방법론의 장점은 "Why"에 대한 압박이 적은 것이다. 소프트웨어개발에서 Waterfall 방법론이나 일반 기업에서 신사업을 진행할때, 전통적으로는 엄청난 Fact와 논리로 무장하여 "이 것을 해야만 하는 이유"를 만들고 설득하는데 집중한다. 하지만 Lean에서는 아이디어와 가설을 기반으로 고객 반응을 빠르게 검즘 할 수 있고, 그결과에 따라 학습하고 Pivot할 수 있다는 유연함이 있다. 이에 따라 수백장의 시장조사자료와 또 수십장의 기획안을 만들지 않아도 탄탄한 비지니스 모델에 대한 가설만 있다면 첫 발을 내딛을 수 있다.
하지만 이러한 장점의 이면에 부작용도 발생하게 된다. 해결하고자 하는 고객의 문제에 대한 철저한 조사와 시장에 대한 이해 없이 프로젝트를 착수해버리는 것이다. 가설과 아이디어를 빠르게 검증한다는 말이 시장조사가 필요없다는 말은 아니다. 물론 기존처럼 "출시되지도 않은 제품"에 대해 지나치게 준비하고, 예측하는 기획을 할 필요는 당연히 없다. 하지만 올바른 고객 문제를 정의하고 핵심 가설을 뽑아내기 위한 "치열한 고민"은 절대적으로 필요하다. 그리고 이러한 치열한 고민의 바탕에 고객과 시장에 대한 기본적인 이해는 필수적이다. 단단한 논리와 시장에 대한 이해가 있어야만 올바른 방향으로 집중할 수 있고, 흔들림없이 자신감있게 MVP를 설계하고 진행할 수 있을 것이다. 그렇지 않으면 MVP 단계에서 중심을 잡지 못하고 갈대처럼 흔들리게 된다.
함정에 쉽게 빠지지 않고 MVP를 잘 실행하는 법
MVP의 딜레마에 빠지지 않고, 순풍에 돛 단 배처럼 나아가기 위해서는 어떻게 해야할까?
#1. 결자해지: Eric Ries가 알려주는 비법
MVP는 Eric Ries에 의해 2009년 처음 소개되었고 2011년 린스타트업 발간 이후 엄청난 흥행 가도를 달리게 된다. 하지만 식을 줄 모르는 인기에는 "안티"도 그만큼 생기는 법. 특히 정답없는 비지니스의 세계에서 "방법론"들은 늘 도전과 변화에 직면하게 된다. 아마 MVP라는 개념도 상당한 비판을 함께 받은 모양이다. Eric Ries의 블로그를 찾다보니, 1년전쯤에 MVP에 대한 새로운 포스팅이 있었다.
먼저 그는 "MVP는 탁월함을 만들어내는 하나의 실험이다"라고 소개하고 있다.(진작에 좀 소개했으면 좋았을 걸) 다소 포괄적인 내용이긴 하지만 그 동안의 Lessons Learned를 기반으로 맹목적인 MVP 적용에 대한 가이드를 나름 제시한다.
An MVP is an experiment on the way to excellence.
그리고 그는 올바르게 MVP를 적용하면서 탁월한 성과를 내는 조직으로 만드는 비법을 4가지 밝혔다.
1. Clarify what MVPs are and why they’re important. Remember, MVPs are just one part of an iterative Build-Measure-Learn process.
MVP가 무엇인지, 그것이 왜 중요한지부터 곱씹어보아라. Build-Measure-Learn이라는 전체적인 관점에서 MVP를 바라보고 실행하라.
2. Building a culture of excellence is our job as leaders.
리더들이 탁월함을 추구하는 문화를 만들어야 한다.
3. Cross-functional teams are key to delighting the customer.
MVP를 통해 고객에게 가치를 제대로 전달하기 위해서는 각 역할별 담당자 모인 팀이 핵심이다.
4. If a customer doesn’t like what you’ve made, that’s a discovery, not a failure.
MVP에 대한 고객 반응이 시큰둥하더라도 좌절하지마라. 나쁜 결과는 "학습"이지, "실패"가 아니다.
요약하면, MVP를 Lean 전체 Process의 관점에서 잘 이해하고, 조직적인 환경과 문화를 잘 뒷받침해라. 정도로 할 수 있겠다.
#2. 내 몸에 맞게 적용하자.
MVP에 대해 각자의 활용도에 맞게 수정하여 사용하는 Case들이다. 말장난으로 보일수도 있지만 MVP의 함정에 대한 각자의 고민과 해법들을 꽤나 읽을 수 있다.
MVB(Minimum Viable Business)
결국 MVP는 Business Model을 검증하기 위한것 아니냐?는 관점이다. 위의 5가지 함정에서도 언급했듯이 MVP가 Product관점에 매몰되고 "Business Model" 검증이라는 본질에서 어긋나는 경우가 많기 때문에 이런 용어를 사용한다고 본다.
MVPP(Minimum Viable Product we’re Proud of)
A/B testing tool로 유명한 Optimizely의 블로그에서 본 글인데, 센스도 있고 철학도 느껴진다. 정확한 문맥을 다 파악하기는 어렵지만 결국 Eric Ries가 얘기한데로 MVP를 한다고 "Excellence"를 추구하지 않는 것이 아니다 라는 강한 표현이 아닌가 싶다. B2B 업체로서 제품 품질에 대한 "강한 자부심"이 느껴지고 이를 포기하지 않고 Lean하게 가겠다는 도전정신이 멋있다.
MVE(Minimum Viable Experiment)
일단 제목이 상당히 자극적이다.(원문을 보면 "사실 비판할려고 쓴거지 MVP가 없어져야한다는 의미는 아니다"라는 애교섞인 언급이 있다) 이 글은 결국 MVP의 역할이 "가설을 검증하기 위한 실험"이라는 근본에 집중해야한다는 주장이다. Eric Ries의 새로운 표현 "MVP is an experiment..."과도 일치한다. 글쓴이는 MVE가 MVP만큼 섹시하지는 않지만 Viral이 될만하지 않냐고 주장한다;;
"Dude, will the MVE go Viral?"
개인적으로는 MVE라는 개념이 매력적이다. 이전 포스팅에서도 언급했듯이 Lean 실행에 있어 "Product"보다는 "Experiment" 관점이 더 적합하다고 본다.
모든 환경과 상황에 적합한 절대적인 솔루션은 없다. MVP도 마찬가지인 것 같다. Fancy함 이면에는 치열한 고민과 실행환경의 뒷받침이 필요하다. MVP의 함정을 넘어 MVP가 되어보자!(헛..)
[주요 참고사이트]
MVP에 대한 개요: https://en.wikipedia.org/wiki/Minimum_viable_product
Eric Ries의 첫 MVP 소개글: http://www.startuplessonslearned.com/2009/08/minimum-viable-product-guide.html
Drop Box의 MVP Case: http://techcrunch.com/2011/10/19/dropbox-minimal-viable-product/
Eric Ries의 Excellence에 대한 강조: http://www.startuplessonslearned.com/2015/01/mvps-and-excellence.html
