프로덕트를 성공시키는 유일한 방법
Fail fast의 원칙
프로덕트를 성공시키는 유일한 방법, 또는 진리라는 것이 과연 있는가? 타겟 고객도 다를 것이며, 핵심 피쳐도 다를 것인데 그런 것이 어떻게 존재하겠는가?
이러한 질문에 대해, 필자는 과감히 "있다"라고 답하고자 한다.
프로덕트에서 성공이란
PO들이 늘 그렇듯 필자 역시 개념에 대해 정의 내리기를 좋아한다. 프로덕트에서 성공하는 방법을 알기 위해서는 성공이란 것이 무엇인가를 정의해야 한다.
사람마다, 제품마다 쓰는 성공이라는 개념이 다를 것이다. 혹자는 수많은 유저 트래픽을 모은 것을 의미할 수도 있고, 누군가는 매출과 같은 비즈니스 지표로 연결되고 나서야 성공이라 부를 수도 있다. 모두 일리가 있는 내용이다.
필자는 프로덕트에서의 성공을 충분히 많은 사용자들에게 지속적으로 사랑받고 있는 상태에 도달했는지로 정의한다.
프로덕트 성공의 제1조건은 누가 뭐니 해도 사용자다. 제 아무리 좋은 기능들이 있더라도 사용자들이 없다면 의미가 없다. 그렇기 때문에 수많은 제품팀들이 사용자들을 모으려 노력하는 이유이기도 하다.
"충분히 많은 수"의 사용자라 표현하였는데, 그것은 각 제품의 성격에 따라 다른 것이지 일괄적으로 정의할 수 없기 때문이다. 예컨대 유튜브와 같은 영상 플랫폼은 최소 수천~수억 명의 사용자를 타겟해야 하지만 한국의 로컬 의료 시장을 노린 앱 같은 경우는 훨씬 작을 수 있다. B2B 사용자들을 대상으로 하는 서비스라면 사용자가 기업체 단위이므로 해당 시장에 있는 기업체 수 정도만 되어도 충분히 많은 수가 된다.
또 하나의 중요한 조건은 "지속적으로 사랑받는지"의 여부이다. 유저 수를 늘리는 것은 생각보다는 쉽다. 하지만 진짜 어려운 것은 이들이 반복적으로 재방문하여 우리 제품을 사용하고 있는지(즉, 리텐션을 불러일으킬 수 있는지)이다. 일시적인 체급 자체는 마케팅으로 펌핑이 가능하다. 그러나 이렇게 모은 사용자들이 제품에 남는 것은 순전히 이 제품에 충분한 사용자 가치를 반복적으로 느끼지 않다면 어렵다.
이에 대해서는 필자의 지난 글에 자세히 설명해둔 바 있다.
충분히 많은 수의 사용자들이 지속적으로 우리 제품에 들어오는 상태라면, 그 이후부터는 비즈니스의 문제가 된다. 이는 그 제품이 해당 시장에서 어느 정도의 점유율을 확보했다는 뜻이므로, 시점이 어느 정도이냐, 수익화를 얼마나 할 수 있을 분이냐의 문제가 될 뿐 수익화에 있어서도 큰 문제는 없다. 그래서 필자는 이 상태를 성공했다고 표현하는 것이다.(물론 그 다음 성공들을 위한 단계들이 쭉 이어져 있다)
대부분의 제품이 실패하는 이유
대부분의 개발팀에서는 다음과 같은 상태로 제품이 개발된다.
누군가에 의해 '이 상태가 되면 제품이 성공할 거야'라고 생각한 목표점이 발굴되고, 이 목표를 향해 모든 것이 align된다. 킥오프 미팅이 열리고, 기획자는 기획 문서를 만들고, 제품 디자인이 나온다. 개발팀에게 기획 문서를 넘기기 위한 미팅이 만들어지고, 개발 방향을 정리한다. 개발 담당자들이 할당되고 실제 개발이 진행된다. 좀 더 나가자면, 제품이 성공시키기 위한 마케팅 팀이 배정되고, 영업 부서가 배정되는 경우도 많다.
하지만 안타깝게도, 이는 대부분의 제품 개발이 실패하는 이유이기도 하다. 실패에는 여러가지 이유가 있겠으나 실패의 이유 역시 하나로 귀결된다. 고객이 원하지 않는 제품을 만들었기 때문이다.
물론 그들도 고객이 원하는 제품이 무엇인지를 알기 위해 유저 인터뷰나 리서치 등을 최대한 진행하고, 유저의 목소리를 듣는다. 그러나 고객들은 대부분 그들이 진정으로 원하는 것이 무엇인지 말해주지 않는다. 이들이 말하기 싫어서 말을 안하는 것이 아니라, 대부분의 고객 니즈는 '고객 본인들도 모르게' 숨겨져 있는 경우가 많기 때문이다. 따라서 실제 그들이 원하는 제품이었는지 알아내기 위해서는, 그들이 실제 작동하는 것처럼 느껴지는 프로덕트를 써보도록 만드는 것이 최선이다.
대부분의 제품팀이나 개발팀 역시 이러한 내용을 잘 알고 있기 때문에, 대개 MVP(Minimum Viable Product, 최소 기능 제품)이라 불리는 제품 기법을 통해 필수 기능 위주로 스펙을 작게 만들어 제공한다.
하지만 많은 제품팀이 MVP를 너무 크게 만드는 실수를 범하고는 한다. 대부분의 스펙들이 p0급 우선순위로 구현되어 있어서, MVP 개발에 적게는 분기 단위로 투자한다. 즉 MVP라고 주장하는 풀스윙 한 방을 때리면서 (제딴에는)무거운 제품을 출시하게 되고, 대부분 처참한 실패를 맛본다.
이들은 나름 lean하고 agile하게 갔으며, MVP를 만들어 빠르게 시장에 내보내보았다고 주장한다. 하지만 실상은 2-3년 걸릴 제품을 6개월 정도의 스펙으로 축소한 정도일 뿐 여전히 들어간 리소스가 적지 않다는 문제가 있다.(물론 2-3년의 실패 주기를 6개월로 단축한 것만으로도 큰 것이기는 하다.)
유일한 성공방정식: 실패를 마주하는 것
앞서 이야기했던 것처럼, 대부분의 사람들은 제품을 성공시키기 위해서는 다음과 같이 성공점을 향해 나아가는 것을 상상한다.
하지만 실제 성공하는 제품팀들은 프로덕트를 다음과 같은 방식으로 개발한다.
이들 역시 시작은 같다. 성공이라고 믿는 지점을 세우고 대략적인 가설을 세워서 제품을 개발한다. 그러나 결정적으로 다른 것은 바로 실패를 얼마나 빨리 마주치고 개선해나가는지(fail fast)이다.
이들은 그들의 가설이 맞는지를 검증하기 위해 최대한 빠른 시간 내에, 최대한 많은 고객들에게 배포해보고 문제점을 발견해나가는 작업을 반복한다. 물론 첫 배포부터 고객에게 아주 좋은 반응을 얻는 것이 가장 좋다. 하지만 실제 그런 일이 벌어질 확률은 극히 낮고, 대부분 첫 배포들에서는 고객들이 여러 이유로 불만족할 것이다. 중요한 것은 이 때 고객 피드백을 얼마나 잘 획득하고, 이를 개선 사항에 반영해나가는지이다.
이러한 프로세스에 능숙한 제품팀은 배포/개선 주기를 늦어도 2-3주에 한 번씩은 가져간다. 필요하면 1주에 몇 번이라도 배포해나가면서까지 고객 피드백을 듣는 주기를 앞당기려고 노력한다.
이러한 과정을 통해서 처음의 실패들에서의 공통점을 발견하고, 점차 '맞는' 방향으로의 개선점이 생기고, 이윽고 success case가 생긴다. 이 때 고객은 우리가 출시한 제품에 열광하고 우리가 쓰지 말라고 해도 계속 들어와 서비스를 쓴다. 혹 아직 출시되지 않은 서비스라면 출시를 목놓아 기다리기도 한다.
Success case는 그 증거와 고객 반응이 너무나도 명확해서, 개발에 참여한 제품팀 모두는 이 방향이 맞는 방향이라는 것을 확신한다. 그리고 그 제품안을 더 개선시키는 방향으로 몇 번의 더 이터레이션을 거치게 된다. 이 때에도 몇 번의 실수는 발생하겠지만, 제품과 시장에 대한 인사이트를 얻어가는 속도가 압도적으로 빨라지기 때문에 실패의 빈도는 훨씬 줄어든다.
이윽고 몇 번의 배포 끝에 충분히 많은 수의 고객이 지속적으로 방문하는 상태인, 즉 Product-Market Fit(PMF)를 찾는 단계가 된다.
Fail fast: 빠르게 실패하기
앞에서서 살펴보았듯, 우리가 다루는 제품은 어떤 제품이냐에 따라 그 속성이나, 타깃 마켓, 고객이 다를 수 있다. 그러나 필자가 마주한 진리에 가까운 성공 공식은 제품 특성에 관계 없이 딱 하나로 이어진다. 그것은 바로 실패를 얼마나 빨리 마주하고 개선해나가는지이다. 이를 Fail fast라 부른다.
능숙한 제품팀일 수록 이 개념을 공격적으로 사용한다. 기획 문서를 고도화하거나 너무 이른 시점이라 의미조차 없는 마케팅 플랜을 짜는 것에 시간을 쓰는 것보다는, 어떻게 하면 제품을 더 빠르게 시장에 내놓아 가설 검증의 템포를 빠르게 가져갈 것인지를 고민한다. 심지어 기획 문서를 작성하는 시간보다 PoC(Proof of Concept)제품이나 MVP를 출시하는 것이 더 빠른 경우도 많이 보인다.
진짜 MVP라고 불리는 것들은 통상 2주, 길어야 4주 내에 고객 테스트가 가능한 수준이어야 한다. 심지어 경우에 따라서는 제품 자체가 불필요한 PoC도 많다.
- 소개팅 서비스라고 출시한다고 할 때 MVP가 꼭 동작하는 앱일 필요는 없다. 구글폼과 엑셀, 무료 툴로 만들 수 있는 랜딩페이지만 있다면 충분하다.
- AI 맛집 추천 서비스를 넣는다고 했을 때 꼭 AI가 직접 동작할 필요는 없다. 일단 물어볼 수 있는 페이지를 뚫어두고, 사용자들이 그 AI 맛집을 검색하는지부터 검증해보아도 충분하다. 뒤에서는 사람이 직접 맛집을 추천해주어도 된다.
토스 역시 처음부터 송금 서비스를 직접 만들지는 않았다. 사용자가 핸드폰 번호와 송금할 금액을 입력하면, 뒤에서 운영 담당자(지금의 토스 대표)가 직접 인터넷 뱅킹을 이용해 하나하나 계좌번호와 금액을 대신 입력해가며 송금을 대행해주었다는 사실을 잘 기억해보라.