MVP개발 100% 실패하는 법 #1
타율 1할, 스타트업 실패 전문가의 이렇게 하면 무조건 실패한다.
Pre-PMF 검증을 제외하고 10개가 넘는 MVP 제품을 출시 검증하면서 경험하고 학습한 MVP개발을 실패하는 엄청난(?) 노하우를 여러분에게만 공유해 드립니다.
성장중독자와 함께 성장, 스타트업, 제품에 대해 이야기하실 분!
첫 번째,
MVP의 범위를 잘못 정의한다.
너무 넓고, 깊으면(디테일) 실패하게 됩니다.
'적어도 이 정도 기능은 있어야...'
'이것도 실험하고 싶고, 이 기능은 이걸 쓰는 사람이라면 또 할 것 같기도..'
'경쟁 서비스에서는 이 기능이랑 이 기능이 있던데 없으면..'
실패할 수밖에 없는 이유.
MVP(Minimum Viable Product)라는 단어는 이미 어떤 관념으로서 스타트업에서 일하는 사람들 머릿속에 자리 잡고 있는 것 같습니다. 하지만 '왜 MVP를 만들어야 할까?'에 대해서 큰 고민 없이 'MVP를 만들어서 검증하는 거야'라고 방법론적으로 받아들이고 있지 않은지 경계해 볼 필요가 있습니다.
: 스타트업(LEAN StartUp을 지향한다는 전제)에서 핵심 가설, 비즈니스를 검증하기 위해서는 최소의 비용(실패했을 경우에 들어가게 되는 기회비용을 포함)으로 많은 후보들을 검증하고자 노력합니다.
일반적으로 투자금이 소진되기 전까지라는 시간 제약이 있고 그것을 실행할 수 있는 실행력(인적 자원에 비례)이 한정적이기 때문에 그렇습니다. 그렇기 때문에 MVP에 Minimum(최소한)이라는 단어가 들어가 있다고 저는 생각합니다.
MVP Spec을 가끔 아티클이나 출시되는 제품으로 보면 넓은 범위의 기능이 포함되어 있어서 상당히 놀랐다가도 기능의 완성도나 depth가 없어서 형태만 갖춘 제품을 보기도 하고, 기능의 범위는 좁은데 너무 디테일한 depth까지 개발이 되어 있어서 뾰족하긴 한데 초반에 이렇게까지 쓰는 사람이 얼마나 있을까라는 생각이 드는 제품도 있습니다.
MVP Spec은 깎아내고 덜어내고 욕심을 버리고 이것을 빼면 안 하는 거랑 같다는 범위 + 품질을 위해 포기할 수 없는 기준을 맞추기 위한 구현이 합쳐진 스펙이 좋다고 생각합니다.
추상적이지 않아야 하는 제품개발 방법을 추상적으로 적을 수밖에 없는 건 제품, 가설, 시장, 만드는 제품팀, PM(PO)에 따라 조금씩 달라지기 때문에 어떤 공식이나 법칙으로 일반화하기 어렵기 때문이라고 생각합니다. 아니면 아직 저의 역량이나 경험이 부족하기 때문일 수도 있겠습니다.
두 번째,
명확한 가치제안, 문제 해결, USP가 없는데 MVP를 개발한다.
심지어 유사 서비스와 큰 차별점이 없는데 유사 제품이 있는지도 모르고 개발하기도 합니다.
'일단 MVP를 개발해서 출시를 해야 검증할 수 있을 것 같아!!'
'이 정도면 MVP를 만들 수 있지 않을까?'
실패할 수밖에 없는 이유.
반드시 AOS, iOS 플랫폼의 애플리케이션으로 제품을 개발해서 출시해야만 MVP인가라고 생각하지는 않지만 잠재고객이 보기에 '제품' 또는 '서비스'로 느껴질 정도의 최소한의 퀄리티를 가진 무엇인가를 만들어야 한다고 생각합니다.
: MVP를 만드는 것에 급급하지 말고 검증하려는 가설이나 가치 제안이 유효한지를 냉철하게 따져볼 필요가 있습니다. 아이디어를 바로 제품화하는 것보다 그 아이디어가 시장이나 사용자(고객)에게 의미가 있는지 한발 물러서서 따져 볼 필요가 있습니다.
프리토타이핑 방법론을 활용해서 그 가설이 PMF 검증이 필요한지를 앞서서 검증해 보는 Pre-PMF Process를 만든다면 성공 확률을 더 높일 수 있습니다.
될 놈을 검증해도 성공보다 실패의 확률이 높은 것이 스타트업, PMF 검증이라고 생각합니다. '될 놈'을 MVP로 개발하세요.
세 번째,
MVP의 의미를 이해하지 못하거나, PM(PO)와 제품팀이 다른 이해를 하고 있다.
그냥 빨리, 적게 만들어서 출시하고 유저의 반응을 확인하는 제품이 아닙니다.
'최소한 이 정도는 개발해야 MVP 지!'
'이걸 다 개발하는 게 Full Spec이랑 뭐가 다르지? MVP가 아니잖아?'
실패할 수밖에 없는 이유.
PM(PO)와 제품팀이 Minimum Viable Product 두 단어를 얼마나 잘 이해하고 있는지에 따라 의미 있는 MVP를 개발하고 출시할 수 있다고 생각합니다.
: Viable을 Visible로 이해한다면 적은 스펙의 제품을 개발하는 것을 지향하게 되지만 사용자(고객)에게 유의미한 범위의 기능을 구성하지 못할 수 있습니다.
Viable을 Valuable로 정의하게 되면 너무 범위가 넓거나 디테일에 비용이 많이 들어가는 제품이 됩니다.
제품은 PM(PO)를 포함한 제품팀이 함께 만들기 때문에 MVP에 대한 이해, 기대, 방향성을 하나로 일치시키는 것이 중요합니다. 그렇기 때문에 제품팀마다 지향하는 MVP의 스펙, 품질의 수준에 차이가 있을 수밖에 없습니다.
네 번째,
MVP 출시 후 바로 성공과 실패를 확인하고 결정할 수 있을 것이라 생각한다.
적어도 충분한 모수의 사용자가 제품의 핵심 경험을 경험해 보기 전까지는 Growth Hacking이 필요합니다.
'MVP를 출시하면 모든 걸 확인할 수 있을 거야!'
'1개의 MVP를 출시하고 검증을 하는 동안 다른 MVP를 개발하면 될 거야!'
실패할 수밖에 없는 이유.
MVP를 출시한 후가 MVP를 개발할 때보다 더 많은 자원이 들어갑니다.
: MVP 출시 스펙에는 들어가지 않았지만 유저가 늘어나면서 추가해야 하는 기능을 추가 개발해야 하고, 사용자 여정을 확인해 보니 기대 했던 모습이 관찰되지 않아 UX Flow를 변경해야 하기도 하죠.
퍼포먼스 마케팅이나 바이럴 마케팅을 위해 추가 개발이 필요할 수도 있습니다.
충분한 모수가 제품을 사용해서 PMF를 검증이 끝날 때까지는 Growth Hacking이 필요합니다.
유저의 정성적, 정량적인 반응을 캐치해서 두세 번 정도 핵심경험을 강화해야 실패하더라도 그 원인이 무엇인지 학습하게 되는 유의미한 출시가 됩니다.
MVP 출시는 끝내고 결과를 기다리는 것이 아니라 막 출발선에서 발을 땐 단거리 육상선수와 같습니다.
다섯 번째,
제품 퀄리티가 구린데 MVP이기 때문에 어쩔 수 없다는 생각을 한다.
당신이 보기에도 어설픈 제품을 사용자(고객)가 왜 사용해야 되나요?
'한 달 만에 이 정도면 충분해, 우리는 최선을 다했어'
'개발자 없이 노코드 툴로 이 정도 만들었으니 난 만족해'
실패할 수밖에 없는 이유.
MVP를 실험을 위한 프로토타입으로 생각하면 안 된다고 생각합니다.
: 그렇게 접근하면 가설이 정확하고 잠재고객이 충분하더라도 절대 PMF 검증을 통과할 수 없습니다.
Product가 아니기 때문입니다.
사용자(고객)는 여러분들이 만들고 출시한 제품이 MVP인지 프로토타입인지 대기업이 만들었는지 1인 스타트업이 만들었는지 크게 상관하지 않습니다. 나에게 필요한지 이 제품을 계속 쓸 가치가 있는지 냉정하게 판단합니다.
퀄리티가 구린 애플리케이션은 '설치'조차 하지 않는 것이 현실입니다. 최소의 비용을 들여서 사용자에게 가치를 전달할 수 있는 유지가능한 제품을 개발하는 것이 MVP를 개발하는 것이라고 생각합니다.
제가 경험했던 다양한 실패의 경험을 공유하는 것을 통해서 다른 분들의 학습 비용이 낮아지거나, 현재 어려운 상황에 처한 Product Manager, Product Owner, CEO 분들이 문제를 해결하는데 도움이 되길 바라며 작성합니다.
경험에 의존한 내용으로 검증된 방법론이나 이론이 아닙니다. 편향된 방향으로 기술된 내용이 일부 포함 될 수 있으며, 이로 인해 불편하시거나 이견이 있으신 분들은 편하게 알려 주시면 저의 성장의 기회로 생각하겠습니다.
성장중독자와 함께 성장, 스타트업, 제품에 대해 이야기하실 분!
사진: Unsplash의Lala Azizli
