MVP 테스트
고객과 문제 찾기
MVP 테스트1
이 글은 에릭리스의 린 스타티업 시리즈 중 <Lean Analytics> 를 참고해 만든 글입니다.
https://medium.com/@sgblank/less-is-more-more-or-less-3838bc1c739d
스타트업에에서 기능을 출시할 때 가장 많이 들리는 용어 중 하나가 MVP죠. 솔루션이 맞는지 검증하기 위해 제공하는 최소단위 기능이라고 이론적으로는 익히 들있던 용어였지만, 출시범위를 정하는 상황에서 저 단어는 손에 잡히지 않고 떠다니는 것처럼 모호했습니다.
TF조직에서 이러한 상황들을 직접적으로, 간접적으로 겪게되면서 왜 mvp 기준으로 제품을 테스트하는지, 목적, MVP 과정으로 얻으려는 것이 무엇인지부터 이해하기 위해 에릭리스의 learning lean 을 다시 펼쳐보게 되었습니다.
신규기능일수록 더더욱, 현단계에서 확인해야 하는 행동이 무엇인지 분명하지 않았고, 때문에 한 사이클로 가져갈 스펙을 어디까지 잡아야 하는지 출시범위 기준을 잡는 것이 어려웠습니다.
하지만 언제나 정해진 기한이 있고 스케줄대로 개발이 들어가게 됩니다.
우선순위나 실험기준을 잡는 과정에서 어려움을 겪는 이유가 bm이 설정되지 않았고 최종목표가 모호하기 때문이라고 생각했습니다.매출,최종 구매전환만 집중해 선행지표를 잡는 커머스에 비해, 유틸리티는 유도할 유저 행동이나 해당 기능이 서비스 성장으로 연결되는지 함께 고민이 필요했기 때문입니다.
틀린 말이 아니지만, 이는 주요 성장지표에 대한 선행지표를 고민하는 방법에 가깝습니다. MVP는 이보다 한단계 내려와 고객이 겪는 문제와 해결에 집중합니다.
MVP 기준으로 스펙을 잡는 목적은 제품이 가려는 최종 목표에 맞는 다음단계 목표를 잘 세우기 위함입니다. 목표가 명확해야 달성을 위해 어떤 조건을 만족시키거나 어떤 행동을 유도해야하는지 구체적인 액션 플랜과 현단계에서 집중해야할 선행지표, OMTM이 명확해지기 때문입니다.
목표가 명확하게 정해지면 이러한 커뮤니케이션을 할 수 있습니다.
"우리는00인 유저에게 00가치를 주는 00기능을 주면 사용이 증가할거야 확인하려면 고객의 00행동을 파악해봐야해. 그러려면 일단 MVP로 00 방법으로 먼저 테스트를 해보자."
그러나 최종 목표를 모르는, OMTM이 없는 상태에서 MVP를 고민하게 되면 테스트 목적자체가 사라집니다. 이렇게되면 개발 리소스를 최소화하는 것에 포커스를 잡고 말 그대로 '최소' 제공해야하는 기능만 주게 됩니다. 출시를 하고나서도 목표가 모호하기 때문에 후행지표만 확인하게 되고
이로 인해 다음 스탭에서 집중해야 하는것과 목표나 방향성은 더 흔들릴 수 밖에 없습니다.
목표를 잡는 방법
그렇다면 회사는 왜 MVP 중심으로 개발범위를 잡을까요?
개발 리소스가 한정적이기 때문이라는 너무 당연한 것을 물어보는 것이라 생각할 수 있지만 MVP가 근본적으로 어떤 목적을 가지고 있는지부터 생각해볼 필요가 있습니다.
이 단계는 제품 방향성을 조정하는 단계로, 아직 어떤 제품을 만들지 결정되지 않은 상태입니다.
우리가 정의한 문제와 솔루션이 효과가 있는지는 출시해서 실제 시장의 반응을 볼 수 밖에 없기 때문에 이 제품을 개발하는게 맞는지 확인점검하는 단계입니다.
존재하는 시장인가
= 지불할 의사가 있는 고객집단이 있는가
= 해결해야 하는 문제가 맞는가
스타트업이 망하는 대부분의 케이스는 사용하지 않는 제품을 만들기 때문이라고 합니다.
ChubbyBrain에서 조사된 결과를 보면 창업에 실패요인으로, 제품 개발 기술의 부족, 자금 부족, 나쁜 지역조건, 창업시기가 문제가 아니라 고객 말을 무시, 시장성 없은 아이템이 주된 실패요인으로 나타납니다.
스타트업은 새로운 시장을 찾아내는 조직이고 MVP테스트는 파산을 방지할 수 있는 일종의 사전검증입니다. 더 많은 돈과 리소스가 투여되기 전에 이것을 출시할만 상품인지 사전검증을 하는거죠.
최최최종파일이 완성도가 올라가는 것처럼 사전검증이 반복될수록 시장에서 먹히지 않는 제품을 만든다고 개발리소스를 낭비하는 가능성이 낮아지기 때문입니다.
시장에 뛰어들어보고 제품을 결정한다
이러한 문제 해결을 에릭리스의 스승이라고 잘 알려져 있는 스티븐 브랭크는 고객개발 4단계라는 개념을 만들게 됩니다. 주 요지는 시장 즉, 고객이 원하는 제품인지 아닌지는 출시 이후밖에 알 수 없으니 일단 시장에 출시하고나서 반응을 살핀다 입니다. The 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.
The challenge you face now is turning that idea into a product that people want, and it’s not going to happen all at once.
그래서 린 스타트업의 저자 에릭 리스는 MVP의 목적은 최소한의 리소스로 고객을 이해하는 과정이라고 말합니다. 즉, MVP는 제품이 아닌 개발과정입니다. 일단 출시부터 하고 시장반응을 파악해서 그에 맞게 제품을 만들어나간다 즉 제품에 출시를 하고나서 제품을 만들어나간다는 말이죠.
제품이 시장성이 있으려면,
유저가 사용하는 제품이 되려면
아래 2가지 조건이 모두 충족이 되어야합니다
사용자가 아닌, 돈을 주고 지불할 고객이 있는지 부터 파악해야 하고
우리가 만든 제품이 돈을 지불할 고객들이 원하는 상품인지 2가지를 검증해봐야 합니다.
1. 시장이 있는가 = 유저가 불편을 가지고 있고 이것을 해결할 때 가치를 인식하는가
2. 문제를 해결하고 있는가 = 유저가 해결하고자 하는 것을 제품이 충족시키는가
시장이 원하지 않는 제품을 만들지 않기 위해 MVP테스트는 솔루션 찾기에 앞서 시장찾기, 고객 문제 찾기부터 시작하는 경우가 많습니다.
고객이 존재하는가 / 고객의 문제가 맞는가
일을 해보면서 가장 많이 알게된 부분은 기능을 사용 중인 유저들이 곧 고객은 아닐수 있다는 것이었습니다.
MAU도 높고 앱을 유용하게 잘 쓰고 있지만 실제 구매로 이어지는 비율은 1%도 되지 않는 것을 보면서 많은 유저 중에 실제 고객은 어떤 목표를 가지고 , 어떤 문제를 해결해야하는지 , 현 기능이 목표 달성에 도움이 얼마나 되는지 고민이 많았습니다.
우리 앱을 쓰는 기능을 쓰는 사용자는 많지만 실제 돈을 지불하는 고객이 얼마나 될까요.
1,000명이 쓰는 앱이지만 돈을 내고 쓰는 고객이 100명인 서비스와 100만명이 쓰지만 실제 지불이 일어난 집단은 10명인 서비스 중 어떤게 더 문제를 잘 해결한 서비스일까요
기능을 사용하는 유저들은 다양한 목표를 가지고 다양한 목적으로 기능을 사용합니다. 그중 돈을 내는 지불집단의 목표를 잘 이해해야 합니다. 다시말해 고객집단이 가진 목표를 이해하고 그들의 문제를 좁게 파악하는게
고객의 문제가 맞는지 판단하는 것은 곧 매출을 만들기 위한 판단하기 위함입니다. 제공하려고 하는 가치를 고객들이 인지했을 때, 얼마나 반응하느냐가 곧 시장 크기가 되기 때문입니다.
책에서 저자는 고객의 문제가 맞는지 대해 3가지 기준으로 판단할 수 있다고 합니다.
1. 유저가 돈과 자원을 지불하고 해결할만큼 해결해야 하는 문제로 인식하고 있어야 한다
2. 충분히 많은 사람들이 불편함에 대해 인식하고 있고 중요하게 여긴다 ( = 시장이 존재한다 )
3. 다른 방법으로 해당문제를 해결하려고 노력하고 있다 (= 차선책을 찾거나 대체 서비스가 나와있다 )
위 3가지를 기준으로 가설을 잡고 정량 , 정성조사를 통해서 3가지 조건에 부합해야만 MVP테스트로 문제에 대한 솔루션을 찾아나가는 다음 단계를 나갈 수 있습니다. 부합하지 못한다면 다시 롤백해서 문제를 제대로 찾아야 합니다.
제가 지금까지 현업에서 유저의 문제를 발견하는 방법은 A. 실제 유저 리서치를 진행하거나 실험을 통해 B. 뒷받침할 수 있는 데이터를 찾아내는 것 2가지 방법이 있었습니다.
문제 찾기
A. 가설을 뒷받침하는 팩트 전제 확보하기
현업에서 실패하지 않기 위한 최소한의 방법은 팩트 전제 기반으로 가설을 잡는 것입니다.
가설(기획)에 대한 전제가 무너져버리면 모든 기획을 엎어야 하기 때문입니다.
사전 실험이 이루어지는 이유는 가설을 뒷받침하는 모든 전제들이 참이어야 하기 때문입니다.
전제가 참일 수록 예상밖 오차가 줄어들기 때문입니다. 데이터 기반 기획이 빠지지 않는 주 이유입니다.
데이터는 팩트 사실이라는 것을 증명할 수 있기 때문에 팀원들과 싱크를 맞추고 설득하는 과정에서도 큰 무기가 되는 것 같습니다.
때문에, 전제 조건에 해당하는 근거 데이터를 확인해보는 일은 반드시 필요합니다.
확인해야하는 조건들이 무엇인지, 데이터로 확인이 가능한지, 가능하지 않으면 어떤 조건부터 확인해봐야하는지부터 살펴보아야 합니다.
확인할 데이터가 없으면
전제들을 확인하는 실험부터
그러나 이렇게 전제에 해당하는 실제데이터를 볼 수 있는 여건이 되는 스타트업은 많지 않습니다. 생각보다 필요한 시점에서 데이터를 뽑아보려고 하면 데이터 로그도 심어지지 않아서 데이터 로그 심기부터 시작하는 경우가 대부분입니다. 스타트업에서 아무것도 없는 상태에서, 즉 확인할 수 있는 데이터가 많지 않은 상황이 빈번하게 발생합니다. 때문에, 가설이 맞기위한 전제 조건들에 대한 팩트 체크를 위한 실험부터 진행하게 됩니다. 이렇게 가설을 뒷받침하는 전제조건들이 참인지, 예상대로 데이터가 나오는지 확인하는 작업은 팩트기반 전제들을 확보하는 것으로, 제대로된 가설을 만들기 위한 안정장치를 만들면서 가는 것과 같습니다. 사수는 전제들 하나씩 부러뜨리고 가야한다는 표현을 많이 하셨습니다.
부러뜨린다는 대상은 A라는 문제를 해결하기 위한 기능으로 B를 만든다라고 했을 때 A→ B 이라는 흐름 단계에서 사이에 있는 전제들을 주장들이 팩트인지 아닌지를 실제 실험을 통해 확인하는 것입니다.
현업에서 문제정의 단계는 이전 이론적으로만 알고있던 것보다 조금 더 본질에 가깝고 현실적입니다 개발이 들어가게 되면 다시 돌이킬 수 없는데다가 개발리소스가 한정되어 있기 때문에 이렇게 전제를 확보하는 실험을 할 때에도, 시장을 찾는 실험에서도 유의미한 실험인지, 이를 통해서 무엇을 얻을 수 있는지 여러 부분을 꼼꼼히 따지게 됩니다. 따라서 무엇을 확인하기 위한 MVP, 최소 스펙은 명확하고 논리적이어야 합니다.
MVP = 최소 스펙으로 팩트 체크하기
가설 : 우리는 이 실험으로 어떤 것을 확인하고 싶은가
가설에 대한 MVP : 최소한의 공수로 가설대로 결과가 나오는지 확인하기 위함
MVP는 결국 누가 돈을 쓰는 고객인지 판단하고 그 고객의 불편이 무엇인지, 그리고 그 고객이 쓰게하려면
제품을 어떻게 개발해야하는지 시장 속에서 우리의 제품이 참이라는 것을 확보하기 위한 연속의 과정입니다.
MVP 중심으로 스펙을 잡는 이유는 시장 속에서 판단이 필요하기 때문이고 때문에 정량적인 수치로 기준점을 가지고 다음 방향을 판단하기 위함입니다.
책을 다시 보면서, 제품 개발의 첫단계인 모든 유저가 아닌 우리의 고객의 문제가 맞는지 판단하는 것에 대한 중요성에 대해 조금 더 이해하게 된 것 같습니다.구체적인 테스트 방법은 아니였지만 MVP 테스트에 대한 목적도 결국 전체 유저 중에 실제 지불 집단에 해당되는 고객유형을 구체적으로 파악하고 이들의 문제를 해결하기 위한 초긱 시작 단계라는 것을 알게 되면서 MVP 과정을 통해 결국 달성해야 하는 목표, OKR은 고객의 문제 해결이 되어야 한다는 생각이 들었습니다.
그러나 현업에서. 전제조건들을 테스트해보고 확인하는 실험이 의사결정의 기준이 되어야 한다는 것을 실제로 직면해보니 갭의 차이가 큰 느낌입니다. 적용하는 근육은 따로 키워야 하는 필요성을 많이 느끼게 되는 것 같습니다.
