뒤로
곽근봉
곽근봉 ·

MVP를 설정하는 현실적인 방법

MVP(Minimum Viable Product)에 대해서는 많은 사람들이 알고있다

하지만 MVP를 제대로 설정하고 활용하는 팀은 많이 보지못했다.

오늘은 MVP를 활용하는 팁에 대해서 몇가지 소개하겠다.


MVP는 쉽게 말하면 "짧게 끊어서 가자"는 거다.

예를 들어서 1년에 52가지의 기능을 만들어서 한 번에 런칭한 팀과, 매 주 릴리즈를 하면서 52번의 릴리즈를 한 팀이 있다고 한다면, 어떤 팀이 더 성공적으로 프로젝트를 진행할 수 있었을까?

매 주 릴리즈 한 팀일 확률이 높다.

매 주 유저의 반응을 보면서 다음 기능을 위한 피드백을 받을 수 있기 때문이다. 그리고 제대로 된 리뷰와 회고만 한다면 팀이 매 주 배움을 얻어갈 수 있다.


MVP는 이렇게 유용한데, 막상 적용하자고 하면 막막한 것들이 많다

"우리는 B2B 서비스라서 어려워요"

"파편적으로 기능이 출시되면 유저들이 싫어할거에요"

"이미 MVP를 잘 설정했는데, 개발자가 코딩이 느려요"

"어디서부터 어디까지를 MVP로 설정해야할지 잘 모르겠어요"

이런 이야기들이 자주 나오는데, 그건 다 PM이 MVP를 설정하는 역량이 부족해서 나오는 이야기다.

사실 MVP를 잘 설정하는건 굉장히 어렵다. "유저들이 느낄 수 있는 최소기능요건을 선택해보세요" 라는 교과서적인 가이드는 도움이 전혀 되지 않는다. 내가 생각하는 유용한 팁들을 알려주겠다.


1) 릴리즈 날짜를 고정시켜라 (Iteration)

어디서부터 어디까지 기능을 잘라야할지 모르겠다면, 기간을 고정시키고 그 안에서 할 수 있는 가장 중요한일을 해보라. 이러한 Iteration이 반복되면 배움이 쌓이고 점점 더 좋은 MVP를 설정할 가능성이 높아진다. 개인적으로는 DAU 1만 이하, 연매출 10억 이하면 Iteration을 1주로 설정하고 매 주 릴리즈 하는걸 추천한다. 대부분 우리가 하는 프로젝트는 로켓 사이언스가 아니다. 매 주 릴리즈하지 못한다면 기술 스택, 팀 빌딩, 신뢰 관계 등 무언가 문제가 있는거다.


2) 팀원들이랑 따로 MVP를 설정해보라

팀원들이랑 각각 MVP를 설정한다음에 서로 어떻게 MVP를 설정했는지 맞춰보라 (모여서 한꺼번에 작성하지말고 각자 MVP를 작성하라고 하고 모여서 맞춰보는 방식으로 해야한다) 개발자, 디자이너, 기획자, PM이 생각하는 MVP가 각각 다 다르게 나올 가능성이 높다. 서로 이야기를 하고 조율하면 좋은 MVP를 설정할 가능성이 높아지고 서로의 이해도도 높일 수 있다.


3) 개발자가 꼭 투입되어야 하는 기능을 선택하라

간단한 랜딩페이지, Lead 확보 페이지, 설문 페이지 등은 개발자 도움 없이도 꽤 높은 퀄리티로 만들 수 있는 솔루션이 많이 있다. 이런 것들은 그냥 PM이나 디자이너가 직접해도 된다. 반드시 개발자가 투입되어야만 하는 기능을 MVP로 설정하는 것이 좋다. 개발자의 시간은 프로젝트에서 가장 중요한 리소스다.


4) 가장 리스크가 높은 것을 선택하라

현재 프로젝트에서 가장 자신이 없는 것이 무엇인지 골라야한다. 유저 행동이 예측되지 않을 수도있고, 구현난이도가 높을수도 있다. 무엇이 되었건 프로젝트에서 가장 리스크가 높다고 생각하는 것을 골라서 MVP로 만들어야한다. 그리고 그렇게 고른 MVP가 릴리즈된 이후에는 남아있는 백로그가 크게 바뀔 가능성이 높다.


5) 리뷰와 회고는 필수

리뷰는 지표를 보면서 릴리즈전에 수립한 가설이 맞았는지 확인하는 과정이다. 회고는 우리가 이번 Iteration을 돌아보면서 어떻게하면 더 잘 일할 수 있었는지 논의나누는 과정이다. 두 가지를 섞어서 해도 상관없다. 핵심은 다음 번 Iteration에 대한 액션아이템을 찾는 것이다. "이번에 유저 지표가 이렇게 나왔으니깐 다음번에 이 기능을 우선 릴리즈 해보자", "이번에 MVP 설정에서 이런 부분이 아쉬웠으니깐 다음번 MVP 설정을 이렇게 해보자" 라는 이야기가 나온다면 완벽하다.


MVP는 비지니스 도메인, 제품의 단계, 팀원의 역량, 신뢰관계 등에 따라서 고려해야할 것이 달라진다. 그러다보니 생각보다 MVP를 제대로 설정하고 프로젝트에 반영하기가 어려운 것이다.

오늘 이야기한 것들은 MVP를 설정하는 역량을 키우는 방법에 가깝다. 우리 팀에 맞는 MVP를 설정하기 위해서는 계속 연습해보는 것이 필요하다.


29

댓글

로그인 후 댓글을 남길 수 있습니다.

여태건우
여태건우

너무 좋은글이네요 자주 이런글 올려주세요. 감사합니다 !

유승학
유승학

‘리스크가 가장 높은 것을 선택하라’ 가 도출된 경험이 있으신가요? 왜 가런 건지 좀 더 알고 싶어요.

곽근봉
곽근봉

제가 경험한 것도 있지만 프로젝트 매니징에서 정석처럼 나오는 이야기이기도 합니다. 예를 들어서, 가시성이 높고 리스크가 낮은 작업을 우선으로 하고 리스크가 높은 작업을 가장 마지막에 한다고하면, 그 리스크가 높은 작업이 '구현불가', '제휴불가' 등 진행이 불가능한 상황이 되었을 때, 앞서 작업했던 모든 것들은 굳이 하지 않아도 될 작업이 되어버리거든요. 그리고 프로젝트 초반에 리스크가 높은 작업을 하면 기획을 바꾸거나 프로젝트 전체를 피벗하는 의사결정을 할 수도 있습니다. 그래서 프로젝트가 시간과 돈을 낭비하는걸 줄여줄 수 있죠. 그렇기 때문에 리스크가 높은 작업들은 최대한 빨리 찾고, 진행하는게 좋습니다.

곽근봉
곽근봉

좋은 질문 감사드려요!

유승학
유승학

한 덩어리로서 MVP는 최대한 작게 시작하는 것이지만, 그 MVP안에서 가장 리스크가 큰 일을 먼저 해치워야 한다가 되겠네요. MVP만드는 과정을 돌이켜보면서 근봉님 답변을 보니까 더 와닿네요.

Doeon Kwon 권도언
Doeon Kwon 권도언

근봉님 메이커로그가 Must Reads 182에 선정 되었어요 :) https://stib.ee/19l7

이도준
이도준

1번의 이야기는 개발하는 입장에서 너무 공감가는 내용입니다. 우리가 하는건 로켓사이언스가 아니잖아요. 비슷한 이야기로 완벽함을 이유로 들면서, 출시나 의사결정을 미루는 대표들도 있지요.