MVP는 산출물이 아닌 과정입니다.

지속적으로 성장하는 스타트업에서 MVP에 대한 개념과 이해해야 하는 방향

원문

A Minimum Viable Product Is Not a Product, It's a Process 

By Yevgeniy (Jim) Brikman (January 22, 2016)

RIVISTED

 프로덕트를 만드는 모든 일련의 행위들은 “Assumptions(가정)”에서 시작한다.

"이런 게 있으면 사람들이 많이 쓰지 않을까?" 또는 "이런 걸 만들면 세상에 도움이 되지 않을까?"라는 단순하고 대범한 가정이 프로덕트를 만들 수 있는 근본적인 원동력이 되어 가정들을 “언제”, "무엇을" 그리고 “어떻게” 점검하고 해결할 지에 따라 프로덕트가 실제 출시할 수도, 출시 후 지속적인 성장을 이룰 수도 있다.

 이런 의미에서 프로덕트를 만들어 간다는 것은 가정들의 지속적인 점검과 확인의 과정이고, 린 스타트업 또는 애자일이라는 개념에서는 빠른 확인과 점검을 위해, MVP(Minimal Viable Product)라는 개념을 통해 빠르게 프로덕트를 만들고 배포하고 점검하는 시퀀스를 가져가야 한다고 강조한다. 프로덕트가 시장에 나왔을 때 어떤 가치를 가질지 모르니 빠르게 사용자들에게 프로덕트를 보여주기 위해서.

 오늘 공유하는 Y combinator의 "A Minimum Viable Product Is Not a Product, It’s a Process"에선 Assumption(가정)과 MVP에 대한 설명과, 단지 개념으로만 이해하는 MVP, 애자일, 린이라는 고정관념과 글에서 배우는 것만이 아닌, 실제로 우리가 MVP를 만들어 가는 과정에서 정말 중요하게 생각해야 하는 부분들을 알려준다. 글에서 배운걸 한마디로 정리하자면, MVP는 "한 프로덕트를 배포하기 위한 첫 번째 스코프(Scope)"가 아니라 프로덕트를 만들어 가는 과정으로서, 가장 위험할 수 있는 의사결정과 판단에 대한 가정들(The Riskiest Assumptions)을 빠르게 점검하고 해결해 나가는 전반적이 과정을 칭한다.라는 것이다.

지긋지긋하게 보셨겠지만, 지긋지긋하게 이야기해도 부족한 그림이에요!

즉, MVP라는 개념은

“요기서 이 버튼이 이렇게 돼야 이쁘지 않을까?”

"지금 좀 더 기술적으로 새로운 것들을 마구 시도해 봐야 좋지 않을까?”

"특정한 정책이 조금 더 유저 친화적으로 바꿔야 하지 않을까?”

같은 우리가 가지고 있는 일반적인 가정들에 대한 부분을 최대한 줄이는 부분에 대해선 당연한 이야기고,

"이런 기능은 출시 후에도 작업해도 되니 MVP에서는 뺍시다."

처럼 MVP를 한 번의 릴리즈 되는 프로덕트서 필요하다 필요치 않다를 정리하는 게 아니라, 프로덕트가 제공하고 싶은 가치를 입증할 수 있는 컨셉이라는 것이다.

이를 위해선,

“우리가 이 서비스를 만들면서 가장 위험하다고 생각한 요소는 무엇일까?”

“우리가 이 서비스를 잘 지속하지 못하게 된다면, 가장 큰 이유는 뭐가 있을까?”

“사용자들의 정보를 처리하는데, 문제가 생길 때에는 어떻게 정리해야 할까?”

등에 대한 Risk Accessment를 시작으로 어떤 프로덕트를 만들어가는지, 왜 사용자들이 프로덕트를 사용할 것인지, 사용자들의 니즈가 명확하게 존재하는지, 우리가 너무나 많은 시간을 우리의 가정들을 충족시키기 위해 쓰는 것은 아닌지 확인하지 않는다면,

"성공이 확실(하다고 믿고 있는) 비즈니스 플랜과 타임라인"

"출시하자마자 백만천만의 트래픽을 문제없이 막을 수 있도록 고안된 서비스"

"몇 달에 걸쳐 뽑은 문화적인 핏과 능력이 상상을 초월하는 동료들"

들 같은 성공하는 비즈니스의 요소들이 아무리 많이 존재하더라도 프로덕트를 시장에 내놓기도 전에 물거품이 될 수도 있다.

---

Revisited는 개인적으로 공부하고 있는 분야나 재밋게 본 기사/ 글/ 컨텐츠에 대해서 설명하고 해당 컨텐츠에 대한 개인적인 리뷰를 하는 공간입니다. 언제든지 문의사항이 있으시면 댓글로 남겨주세요!