출시 시점에 SaaS MVP에 담아야 할 것과 담지 말아야 할 것

minimum viable product에서 '최소한'이라는 말은 모두가 무시하는 부분입니다. 창업자들은 작게 시작하라는 생각에 고개를 끄덕이고는, 화면 마흔 개, 사용자 권한 세 개, 결제 엔진, 분석 대시보드, 그리고 "아, 그리고 모든 것과 연동돼야 해요"가 담긴 명세서를 건넵니다. 그것은 MVP가 아닙니다. 낙관을 최대치로 끌어올린 완성품 그 자체입니다. 그리고 이것이야말로 첫 출시가 늦어지고 예산을 초과하며, 그러고도 어찌된 일인지 고객이 정말로 원했던 단 하나를 여전히 빠뜨리는 가장 흔한 이유입니다.

저는 꽤 많은 작은 회사와 1인 창업자가 첫 소프트웨어 제품을 세상에 내놓도록 도왔습니다. 사람들이 걸려 넘어지는 것은 기술적인 부분인 경우가 드뭅니다. 어려운 부분은—매번—아직 무엇을 만들지 않을지를 정하는 일입니다. MVP는 꿈꾸던 제품에서 기능을 무작위로 깎아낸 축소판이 아닙니다. 의도적인 베팅입니다. 핵심 아이디어가 당신의 돈과 시간을 더 들일 가치가 있음을 증명할, 진짜 사용자 앞에 내놓을 수 있는 가장 작은 것입니다.

그래서 이것은 더 많은 창업자가 명세서를 쓰기 전에 읽었으면 하는 안내입니다. 전문 용어도, "빠르게 움직이고 부숴라" 식의 연극도 없습니다. 첫 출시에 속하는 것과 기다릴 수 있는—그리고 기다려야 하는—것 사이에 선을 긋는 실용적인 방법뿐입니다.

MVP가 실제로 무엇인가(그리고 무엇이 아닌가)

정의부터 바로잡읍시다. 혼란의 대부분이 여기서 시작되니까요. MVP는 진짜 사람이 당신의 제품이 약속하는 하나의 가치 있는 일을 할 수 있게 해주는, 가장 작고 단순한 버전입니다—그리고 그 사람이 다시 그 일을 하러 돌아올지 배울 수 있게 해줍니다. 그게 전부입니다. 이것은 마침 작동하는 소프트웨어로 만들어진 배움의 도구이지, 완성품을 깎아낸 출시가 아닙니다.

결정적인 단어는 viable(성립 가능한)입니다. 흔한 실수는 '최소한'을 읽고 사용자를 민망하게 할 만큼 헐벗은 것을 내놓는 것입니다—중간에 멈춰버리는 반쪽짜리 흐름, 빈 화면으로 이어지는 가입. 그것은 최소한으로 성립하는 게 아니라 최소한으로 망가진 것입니다. 또 다른 실패는 그 반대입니다. 너무 "완성"되어 만드는 데 1년이 걸리고, 그쯤이면 여덟 주면 검증할 수 있었을 추측을 증명하느라 자금을 다 써버린 제품입니다.

제가 쓰는 머릿속 테스트는 이렇습니다. 목록에 있는 모든 기능에 대해 물어보세요. 이걸 없애도 사용자가 제품이 존재하는 이유인 하나의 핵심 성과를 여전히 얻을 수 있는가? 답이 '그렇다'라면, 그것은 거의 확실히 MVP가 아닙니다. 이 질문 하나만으로도 대부분의 명세서가 절반으로 잘립니다—그리고 잘려 나가는 절반이 바로 당신을 늦게 만들 뻔했던 절반입니다.

당신의 제품이 해내는 하나의 일을 찾으라

무엇을 만들지 정하기 전에, 당신의 제품이 누군가를 위해 해내는 하나의 일에 대해 가차 없이 명확해져야 합니다. 비전이 아닙니다. 로드맵도 아닙니다. 잘 작동하면 누군가의 하루를 낫게 하고 돈을 낼 마음이 들게 하는, 하나의 반복 가능한 행동입니다. 헤매는 명세서 대부분은 바로 여기가 모호합니다—일이 아니라 플랫폼을 묘사하고 있습니다.

이 문장을 소리 내어 완성해 보세요. "사용자는 ______하려고 제 제품에 와서, ______한 채로 떠납니다." 근무표 도구라면, 관리자는 다음 주 근무표를 게시하러 와서, 모든 교대가 채워지고 팀에 알림이 간 채로 떠납니다. 청구 앱이라면, 프리랜서는 고객에게 청구하러 와서, 발송되고 추적 가능한 청구서를 들고 떠납니다. 이 문장을 깔끔하게 채울 수 없다면, 아직 범위를 정할 준비가 안 된 것입니다—아직 생각할 준비가 된 것입니다.

모든 SaaS MVP에 진정으로 필요한 것

어떤 것들은 가장 군더더기 없는 첫 버전에서도 협상의 여지가 없습니다—흥미로워서가 아니라, 그것이 없으면 제품을 쓸 수 없거나 당신에게 아무것도 가르쳐 주지 못하기 때문입니다. 이것들을 천장이 아니라 바닥이라고 생각하세요. 단순하게 만들되, 제대로 만드세요.

• 로그인할 방법. 이메일과 비밀번호로 된 로그인 하나여도 괜찮습니다—다만 진짜이고 안전한 것이어야 합니다. 다른 모든 것이 사용자가 누구인지 아는 데 달려 있으니까요.
• 핵심 워크플로를 처음부터 끝까지. 사용자의 첫 클릭부터 가치 있는 성과를 얻는 순간까지의 하나의 일—막다른 길도, 결정적 경로에 "준비 중" 버튼도 없이.
• 데이터가 실제로 머무는 곳. 일회용 프로토타입이 아니라 진짜 저장소를. 사용자의 작업이 새로고침을 견디고 내일 다시 돌아올 수 있도록.
• 무슨 일이 일어나는지 당신이 볼 방법. 기본적인 로그나 간단한 관리자 화면을. 무언가 망가질 때—반드시 망가집니다—추측 없이 이유를 알아낼 수 있도록.
• 사용자가 당신에게 연락할 방법. 이메일 링크 하나만으로도. 초기 사용자는 당신이 예상 못 한 가장자리에 부딪힙니다. 그들이 조용히 떠나는 게 아니라 당신에게 말해 주길 바랄 겁니다.
• 신뢰의 최소한: 개인정보 안내, 분별 있는 데이터 처리, 그리고 사람들의 정보로 무모한 짓을 하지 않는 것.

이 목록에 없는 것에 주목하세요. 결제, 화려한 온보딩, 설정 페이지, 모바일 앱, 연동입니다. 왜 그런지는 곧 다루겠습니다. 바닥의 요점은, 끝낼 수 있을 만큼 작고 배울 수 있을 만큼 견고하다는 것입니다. 작동하는 로그인, 성과를 전달하는 하나의 워크플로, 진짜 데이터, 그리고 사용자를 관찰하고 대화할 방법. 그것이 성립 가능한 제품입니다.

v1에서 일부러 빼야 할 것

여기는 창업자들이 저항하는 절이니 직설적으로 말하겠습니다. 첫 출시에 필수처럼 느껴지는 것 대부분은 필수가 아닙니다. "진짜 제품"에는 그것이 있으니 필수처럼 느껴지는 것입니다—하지만 당신은 아직 진짜 제품을 만드는 게 아니라 질문을 만드는 중입니다. 이것들을 빼는 것은 대충 하는 게 아닙니다. 그것이 바로 MVP의 규율 그 자체입니다.

자동 결제와 복잡한 가격 체계

버전 1에서 셀프서비스 결제 엔진, 단계별 요금제, 일할 계산, 미납 독촉 로직은 거의 확실히 필요 없습니다. 초기 사용자가 돈을 내고 싶어 하면 수작업으로 받으면 됩니다—청구서, 결제 링크, 짧은 전화 한 통. 첫 열 명의 고객에 대한 수작업 결제는 자동 결제가 알려줄 수 없는 것을 알려줍니다. 애초에 누군가 돈을 낼 것인가입니다. 거둘 돈이 있음을 증명한 다음에 기계를 만드세요.

정교한 역할과 권한

여러 역할의 권한 시스템—관리자, 매니저, 열람자, 세분화된 접근 규칙—은 진짜 엔지니어링 늪이며, 테스트 표면을 엄청나게 늘립니다. 첫 출시에는 한 종류의 사용자면 거의 항상 충분합니다. 진짜 권한 요구는 실제 팀이 그것을 쓰는 모습을 보며 배우게 되는데, 그 요구는 종이 위에서 짐작했을 법한 것과 좀처럼 일치하지 않습니다.

연동, 네이티브 모바일 앱, 그리고 대시보드

"모든 것과 연동돼야 해요"는 일정을 조용히 두 배로 늘리는 말입니다. 연동은 많아야 하나만 고르고, 그것도 핵심 일의 일부일 때만 고르세요. 네이티브 iOS와 안드로이드 앱은 거의 항상 기다릴 수 있습니다—반응형 웹 앱은 오늘도 휴대폰에서 작동합니다. 그리고 모두가 원하는 분석 대시보드는요? 사용자는 아직 만들지도 않은 데이터를 분석할 수 없습니다. 데이터를 만들어 내는 것을 먼저 내놓고, 보여줄 게 생기면 시각화하세요.

선을 긋는 간단한 방법

원칙을 아는 것과, 기능 하나하나가 내 자식처럼 느껴지는 자신의 명세서에 그것을 적용하는 것은 다른 일이며, 후자가 더 어렵습니다. 여기 통하는 방법이 있습니다. 모든 것을 "필수"로 떠내려가게 두지 않고, 각 항목에 결정을 강요하기 때문에 효과가 있습니다.

1. 1
   상상한 기능을 모두 적어 내려라

   일단 전부 쏟아내세요—아직 거르지 말고. 바라는 것 전체 목록을 책상 위에 올려, 말해지지 않은 채 숨어 있다가 구축 도중에 깜짝 등장하는 일이 없게 하세요.
2. 2
   핵심 일에 비추어 각각 표시하라

   각 기능에 대해 물으세요. 사용자가 하나의 핵심 일을 처음부터 끝까지 완료하는 데 이것이 필요한가? 그것을 '핵심', '도움됨', '언젠가'로 표시하세요. 솔직해지세요—대부분은 뒤의 둘에 떨어집니다.
3. 3
   v1에는 '핵심'만 남겨라

   당신의 MVP는 '핵심' 더미이고 그 외에는 없습니다. '도움됨'과 '언젠가' 더미는 거절된 게 아닙니다—제자리에 세워둔 당신의 로드맵입니다.
4. 4
   잘라낸 결과를 상식으로 점검하라

   남은 것을 보고 물으세요. 진짜 사용자가 이것만으로 진짜 가치를 얻을 수 있는가? 그렇다면 MVP의 범위를 정한 것입니다. 무언가 정말로 핵심 흐름을 깨뜨린다면, 딱 그 한 항목만 되돌리세요—그 외에는 아무것도.

규율은 네 번째 단계에 있습니다. "딱 하나만 더 되돌리자"는 유혹이 늘 있고, 그러다 또 하나, 결국 조용히 완성품을 다시 지어 놓습니다. 정말로 핵심 흐름을 깨뜨리는 항목만 구하도록 자신에게 허락하세요—단지 더 낫게 만들 뿐인 항목은 안 됩니다. 더 낫게 만드는 것은 버전 2를 위한 것입니다.

성립 가능하다는 것은 여전히 진짜처럼 느껴져야 한다는 뜻

선의 반대편에도 실패의 형태가 있고, 이름을 붙일 가치가 있습니다. 작게 내놓으려 서두르다가, 일부 창업자는 허름한 것을 내놓고는—그것을 MVP라 부릅니다. 작업을 잃어버리는 핵심 흐름, 404를 띄우는 가입, 자리표시 문구로 가득한 글. 그것은 당신의 아이디어를 공정하게 검증하지 않습니다. 사용자가 망가진 경험을 참아줄지를 검증하는 것이고, 답은 언제나 '아니오'입니다. 사실은 실행이 실패했는데 아이디어가 실패했다고 결론짓게 됩니다.

"최소한"은 범위에 적용되는 것이지, 당신이 남기는 부분의 품질에는 결코 적용되지 않습니다. 기능은 적게, 각각은 견고하게. 당신이 내놓는 하나의 워크플로는 완성된 듯 느껴져야 합니다—빠르고, 명확하고, 믿을 만하게—그것이 제품이 하는 유일한 일이라 해도요. 좁은 제품을 잘 만드는 것이 넓은 제품을 못 만드는 것을 매번 이깁니다. 특히 낯선 이에게 자신의 작업을 당신에게 맡겨 달라고 부탁할 때는요.

MVP는 결승선이 아니다—첫 측정값이다

여기 모든 것을 다시 바라보게 하는 부분이 있습니다. 출시는 목표가 아닙니다. 목표는 그 이후 몇 주 동안 배우는 것입니다. 내놓고 나서 "사용자는 핵심을 좋아하지만 계속 X를 요청한다"고 알려주는 MVP는 굉장한 성공입니다—X가 한 달 더 작업을 뜻하더라도요. 침묵 속으로 출시되어 아무도 돌아오지 않는 MVP 역시 제 역할을 다했습니다. 아무도 원하지 않은 토대 위에 나머지 서른 개의 기능을 짓는 일에서 당신을 구해준 것이니까요.

그러니 첫 몇 주를 구축만큼이나 의도적으로 계획하세요. 사람들이 설문에서 하는 말이 아니라 실제로 무엇을 하는지를 관찰하세요. 돌아온 사람들과 돌아오지 않은 사람들 모두와 이야기하세요. 당신의 원래 명세가 아니라 실제 사용이 버전 2에 무엇이 들어갈지 결정하게 하세요. 앞서 세워둔 로드맵은 약속이 아닙니다. 가설이며, 당신의 사용자들이 곧 그것을 채점하려 합니다.

자주 묻는 질문