MVP를 만드는 사람들을 위한 짧은 아티클
회사에 아직 실제 제품이 없는 메이커들은 복잡한 마음이 들 수 있습니다. 지금 우리가 제대로 된 길을 가고 있는 걸까? 왜 우리 제품은 MVP를 위한 기능이 이렇게 많은 걸까? 우리가 만드는 기능들이 정말로 사용자에게 필요한 기능일까? 이번 글은 조바심이 들 때 꺼내 읽을 수 있는 내용들로 채웠습니다.
MVP는 특히 오해가 많은 개념입니다. 누군가는 정해진 시간 내 만들 수 있는 최소한의 기능이라고 하고, 또 누군가는 한 두 개의 핵심 기능을 말하기도 합니다. 사실 모두 맞는 말이지만 핵심에는 조금씩 비켜나 있습니다. MVP의 핵심은 '최적화'가 아닌 '학습'에 있기 때문입니다. 우리가 세운 가설을 빠르게 데모로 만들어 사용자 피드백을 받아 ‘학습’할 수 있는 구조를 만드는 것이 MVP의 핵심입니다. 즉, 처음부터 실패에서 무언가를 배울 수 있는 기획이 필요합니다. 때문에 처음부터 완벽한 최적화를 염두에 두지 않습니다. 근미래를 섣불리 예측하지도 않습니다.
하지만 우리가 스타트업에서 만나는 동료들은 대부분 자신의 업에 욕심이 많습니다. 개발자들은 처음부터 최적의 코드를 만들고 싶어 하고, 프로덕트 디자이너들은 완벽한 사용자 경험을 만들고 싶어 합니다. 프로로 만났으니 당연한 생각입니다. 팀의 방향성도 중요하지만 자신의 일에 결함을 남기고 싶지 않은 마음도 있습니다. 하지만 이러한 생각은 프로덕트의 성공 가능성에는 큰 영향을 미치지 못합니다.
MVP의 핵심은 출시 후 사용자에게 ‘실제로’ 받는 피드백을 통한 빠른 개선에 있기 때문입니다. 이 부분에 관해 진지하게 생각해볼 필요가 있습니다. 기계적으로 요구사항을 정리하고, 개발을 진행하고, 내부에서 QA 하는 시간을 너무 많이 가지고 있지는 않은지 말입니다. 사실 이 과정에서 일어나는 진짜 학습은 '0'에 가깝습니다. 실제로 피드백을 줄 사용자는 아직 존재하지 않습니다. 제품을 진짜 사용할 사람은 만드는 사람과 우리 주변 사람이 아닌데, 내부 QA 평가가 높으면 대부분 만족합니다. 이러한 심리적 안전감에서 벗어나야 합니다. 제품을 개선시킬 수 있는 근거는 “사용자의 실제 목소리와 그들이 남긴 숫자”에서 찾아야 합니다.
스타트업은 대부분 아이디어가 풍부합니다. 저는 몇 번의 스타트업을 거쳤습니다. 항상 자신의 아이디어를 자랑하는 사람들로 가득했습니다. 그런데 역설적으로 아이디어가 팀 내 부족했을 때 성공한 경우가 더 많았습니다. 무슨 소리일까요? MVP가 성공하기 위해서는 창의적인 아이디어가 핵심이 아니라는 것입니다.
핵심은 우리 프로덕트를 성공시키기 위해 '꼭 필요한 기능'과 '있으면 좋은 기능'을 구별하는 것에 있습니다. 팀 내 흐르는 아이디어들은 백로그에 '있으면 좋은 기능'같은 공간을 만들어 모으는 것을 추천합니다. 이 공간은 팀 내 역동적인 아이디어를 제어하는 심리적 잠금쇠 역할로 두는 편이 맞습니다. 아이디어를 내는 사람이 상심하지 않게 말입니다.
우리가 MVP 단계에서 진짜 집중해야 하는 것은 '꼭 필요한 기능'입니다. 에릭 리스의 [린 스타트업]에서는 MVP를 만들 때 "텅 빈 기능 목록을 가지고 시작해서 기능을 추가할 때마다 그 타당성을 검사하라"라고 조언합니다. 지금 어떤 기능을 추가하고 있다면 이 기능이 내부의 욕심인지, 실제로 사용자가 원하는 개선인지를 반드시 따져봐야 합니다. MVP에 붙은 수많은 기능들은 진짜 검증해보고 싶은 기능을 흐리게 만듭니다.
MVP를 만드는 핵심은 실제 고객 목소리에 귀 기울이는 것에 있습니다. 출시 후 실제 사람들과 우리 제품에 관해 이야기를 나누러 오피스 바깥으로 나갑시다. 저는 이 단계에서 사용자들이 실제로 필요한 기능과 내가 제안하는 것의 차이를 극심히 느끼게 됐습니다. 이때 내부의 가설들 역시 와르르 무너졌습니다. 디자인의 완성도나 개발 품질의 뛰어남 보다 고객의 실제 목소리가 반영되었나를 눈여겨봐야 합니다. 우리가 0부터 1로 만든 새로운 프로덕트가 시장에 오롯이 받아들여지는 과정은 그 누구도 예측할 수 없습니다. 그야말로 섭리에 가깝습니다.
이렇게 만들어진 MVP에서 가장 중요한 곳은 어디일까요? 바로 첫 페이지입니다. 웹사이트라면 히어로 배너가 될 수 있고, 앱이라면 온보딩 과정이나 뷰포트가 될 수 있습니다. 이때 우리 서비스가 전하고자 하는 UVP(unique value proposition)를 충분히 전달해야 합니다. 더불어 우리 서비스의 핵심 기능이 어디 있는지를 쉽게 전달할 수 있어야 합니다.
사용자는 세상에 갓 나온 서비스를 디자인이 화려해서, 인터랙션이 유려해서, 로딩 속도가 빨라서 쓰는 것이 아닙니다. 내가 겪고 있는 문제를 해결해줄 수 있을 것 같아서입니다. 제품의 질적 개선은 이 조건이 사용자에게 받아들여지고 난 뒤 해도 늦지 않습니다.
'MVP는 최적화가 아닌 학습을 위해 존재하는 것' 끝
[린 스타트업]