*잠깐, 이 글을 소개해드리는 위시켓은 2019년 시밀러웹 방문자 수 기준, 국내 1위 IT아웃소싱 플랫폼입니다.
현재 8만 이상의 개발업체, 개발 프리랜서들이 활동하고 있으며, 무료로 프로젝트 등록이 가능합니다. 프로젝트 등록 한 번으로 여러 개발업체의 견적, 포트폴리오, 예상기간을 한 번에 비교해보세요:)

* 이번 글은 2부작으로 구성되어 있습니다. 저번 1부에서는 MVP의 한계에 따른 MLP의 필요성과 MLP의 중요 개념인 사용자의 애정이 어떻게 구성되는지 알아보았습니다. 이번 2부에서는 MLP를 만드는 4원칙과 각각의 사례를 살펴봅니다.

저번 1부에서 MLP는 MVP가 갖는 UX 상의 한계를 극복하고 장점(신속성, 정확성, 경제성)을 활용하기 위해 개발된 방법론이라고 정의했습니다. MLP의 목표는 수용 가능할 뿐만 아니라 애정 받는 제품, 그리고 초기 제품의 팬을 만드는 것입니다. MLP가 뭔지는 알겠는데, 어떤 방식으로 실무에 적용할 수 있을지 두루뭉술하지 않나요? 이제 MLP를 적용하는 기준과 사례에 대해 알아보겠습니다.

일은 최소로, 효과는 최대로. MLP 4원칙

에어비앤비(Airbnb), 위워크(WeWork), 드롭박스(Dropbox), 웹플로우(Webflow) 등 쟁쟁한 스타트업에서 제품 개발을 이끈 PM Jiaona Zhang는 한 인터뷰1)에서 MLP 4원칙을 설명한 바 있습니다.

1. 비즈니스가 아닌 사용자의 ‘필요’에서 시작할 것

2. 문제와 솔루션을 ‘분리’할 것(성급하게 솔루션에서 시작하지 않을 것)

3. 사용자에게 귀 기울이되 맹목적으로 ‘판단’하지 말 것

4. 가장 가치 있는 문제와 솔루션을 ‘선택’할 것

독립적으로 효력을 갖는 원칙이기도 하지만, MLP를 처음 시도한다면 순서대로 따라 볼만한 지침이기도 합니다.

아래는 원칙별 세부 설명과 실제 제품에서 작동한 예시입니다.

비즈니스가 아닌 사용자의 ‘필요’에서 시작할 것 – 뉴욕타임즈

제품이 사용자의 필요에 부응해야 한다는 말에 동의하지 않을 사람은 없습니다. 하지만 실무에 들어가게 되면 많은 시도를 하는 것에 서두르는 일이 빈번하기에 숭고한 대전제는 금방 잊히고는 합니다. 이런 일은 특히 스타트업에서 자주 발생합니다. 아이디어는 여기저기서 터져 나오고 시간과 자원을 완전히 활용한다는 미명 아래 당장 할 수 있는 일부터 빽빽하게 우선순위가 짜입니다. 숨 가쁘게 프로세스가 돌아갑니다. 반응은 심심하고 처음의 의도에서도 멀어지는 것 같지만, 아무튼 계속 일하고 있기 때문에 제품의 실패는 귀중한 학습으로 둔갑하고 시험할 가설은 점점 엉뚱한 곳으로 갑니다. 무엇이라도 하는 것이 중요한 게 아닙니다. 덜 하더라도 잘 설계된 방향성을 갖추고 하는 것이 중요합니다. 모두가 알고 있듯이 그 방향은 사용자가 정해줍니다.

뉴욕타임스는 가라앉는 신문 시장에서 탈출하고 디지털 포메이션에 성공한 대표적인 언론사입니다. 뉴욕타임스의 성공에는 인사이트를 얻을 이야기가 수십 개는 되지만 그중에서 특히 요리와 십자말풀이 앱의 사례는 ‘사용자의 필요에서 시작하기’ 원칙에 어울리는 부분이 있습니다. 십자말풀이와 요리 같은 기사 외 콘텐츠는 신문에서 ‘덤’입니다. 누구도 십자말풀이 때문에 신문을 구독하지는 않습니다. 이런 부가적 특성이 디지털 포메이션 이후에는 더욱 두드러집니다. 뉴스와 십자말풀이는 완전히 다른 카테고리입니다. 인터넷에는 이미 수많은 무료 요리 레시피와 게임이 마련되어 있습니다.

하지만 뉴욕타임스는 흥미로운 인사이트를 발견하고 십자말풀이와 요리 콘텐츠를 별도 앱으로 출시합니다. 그 인사이트란 십자말풀이 때문에 신문을 구독할 사람은 없어도, 십자말풀이를 구독할 사람은 있다는 것. 뉴욕타임스는 이 두 콘텐츠를 보다 전문화된 형태로 발행했고 결과 연간 40달러의 구독료를 내는 구독자 130만 명(2020년 기준)을 만들었습니다. 이 사용자들은 십자말풀이와 요리 콘텐츠로 유입돼서 역으로 뉴욕타임스 구독자가 되기도 합니다.2) 기존에 있던 제품의 구조, 산업의 경계까지 무시하면서 사용자의 필요를 좇은 끝에 뉴욕타임스는 백만 명이 넘는 새로운 수요층을 발굴해냈습니다.

문제와 솔루션을 ‘분리’할 것 – 디스코드(Discord)

우버, 쿠팡, 쏘카, 토스, 배달의 민족…. 우리 곁에는 레퍼런스로 삼을 만한 성공한 제품이 참 많습니다. 하지만 제품을 만들고자 마음먹었다면 이것에서 멀어질 필요가 있습니다. 이런 제품이 아이디어를 샘솟게 하는 것처럼 보이지만 실상은 반대입니다. 자신이 예상하는 사용자의 필요와 실제 사용자의 필요가 다르다는 걸 인지하는 게 제품 기획의 첫 단계입니다. 우리는 ‘OO계의 우버’를 만들 이유가 없습니다. 문제 파악이 우선이고 항상 기준이 되어야 합니다.

이 원칙에는 디스코드 이야기를 해볼 수 있을 것 같습니다. 얼마 전에 100억 달러 매각설까지 나왔죠. 디스코드는 가입 사용자가 3억 명, MAU(월 활성 사용자)는 1억 4천만 명에 달하는 거대 음성 채팅 플랫폼입니다. 디스코드는 결코 최초가 아닙니다. 스카이프(Skype), TeamSpeak, IRC 등 경쟁 제품도 많습니다. 디스코드가 이들과 달랐던 것은 경험의 수준입니다. 디스코드는 타사 제품과 달리 클릭 두 번으로 채널을 개설할 수 있고 링크 공유만으로 다른 사람을 초대할 수 있습니다. 이는 전화를 건다는 느낌보다는, 옆자리 친구에게 말을 거는 것에 가깝습니다. 다른 제품이 오프라인 전화 경험을 단순히 디지털화하는 차원에 머무르고 여타 제품처럼 보안적 제약을 복잡한 상태로 내버려 두었을 때 디스코드는 둘 중 어느 것에도 기원을 두지 않고 오로지 사용자의 문제만을 제품 개발의 기준으로 삼았습니다. 이는 디스코드의 비즈니스 모델에서도 드러납니다. 디스코드는 기본적인 기능이 전부 무료입니다. 대신 유료 구독 기능 Nitro가 있습니다. Nitro 구독자는 본인의 제품 품질 개선 혜택을 받을 뿐만 아니라 자신이 참여한 채널의 기능을 향상하는 부스트(Boost) 기능을 사용할 수 있습니다. 이 사용자의 ID는 채널 내에서 눈에 띄게 표기됩니다. 디스코드 상위 14개 채널에서 발생한 부스트 수익만 해도 25만 달러입니다.3) 디스코드가 인터넷 커뮤니티를 잘 이해하고 모든 일을 오직 이들의 문제에서 시작했기에 이런 결과를 낼 수 있었습니다.

사용자에게 귀 기울이되 맹목적으로 ‘판단’하지 말 것 – 클래스패스(ClassPass)

MLP의 모든 일은 사용자의 피드백에서 시작됩니다. 그러나 모든 피드백에 반응해서는 안 됩니다. MLP에 필요한 것은 사용자의 문제, 실제적이고 솔직하고 해결했을 때의 가치가 높은 고충입니다. 수 십 명 인터뷰하기도 힘든 소규모 조직일수록 이 원칙은 중요합니다. 하나의 사용자군을 설정해서 해당 사용자군에 대해 학습할 수 있는 충분한 숫자의 사용자와 인터뷰를 진행해야 합니다. 편향된 답변을 방지하기 위해 개방형 질문을 준비해야 합니다.

월 구독제 헬스클럽 이용 서비스 클래스패스는 28개국 3만 개 이상의 헬스클럽과 제휴된 세계 최대 피트니스 플랫폼입니다. 클래스패스는 단순하게 여러 헬스클럽을 한 곳에서 검색하고 비교하는 기능으로 시작했습니다. 헬스클럽이 회원을 유치하기 위해서 보편적으로 사용하는 정책이 한 달 무료라는 것을 파악한 후, 클래스패스는 신규 가입 후 30일간 최대 10개 헬스클럽을 체험할 수 있도록 온보딩 경험을 재설계하면서 1년 반 동안 100건에 그치던 헬스클럽 예약 수를 반년에 2만 건까지 끌어올립니다. 여기서 재미있는 상황이 발생합니다. 꽤 많은 사용자가 30일 동안 10개 헬스클럽을 체험할 수 있는 신규 가입 혜택을 받기 위해 한 달마다 계정을 새로 만들었던 겁니다. 이는 이전에 피드백을 받고 재설계했던 ‘클래스패스로 헬스클럽 탐색 후 맘에 드는 곳에 안착’하는 사용 패턴과 다른 것이었습니다. 이 부정 사용 사례는 다양한 헬스클럽에 유연하게 참가할 수 있는 제품에 대한 가치를 말해주고 있었습니다. 클래스패스는 구독료를 더 받는 대신 수백 개의 헬스클럽 프로그램을 자유롭게 수강할 수 있도록 다시 재설계했습니다. 그 결과 예약 수는 2개월 만에 10만 건에 이르렀습니다.4)

가장 가치 있는 문제와 솔루션을 ‘선택’할 것 – 채널톡

위 3원칙을 따라오는 과정에서 사용자의 문제는 충분히 수집되었을 겁니다. 이 모든 과정을 용두사미로 만들지 않으려면 이번 원칙을 염두에 두어야 합니다. 제품을 쓰는 사용자는 한 명이 아닙니다. 도출되는 문제도 당연히 하나가 아닙니다. 가능한 그룹화를 최대한 진행했더라도 여전히 수십 개의 문제가 남아있을 수 있습니다. 이걸 전부 손봐야 할까요? 이 시점에서 MLP의 M, Minimum의 뜻을 되새길 필요가 있습니다. 여러 문제가 있지만 가장 중요한 문제 하나에 집중해야 합니다. 문제 하나에도 여러 솔루션이 제안될 수 있지만 하나로 통합해야 합니다. 문제와 솔루션, 이들의 선택 기준은 수용 가능할 뿐만 아니라 애정 받는 제품이라는 MLP의 목표와 이어집니다. 사용자에게서 ‘괜찮네요.’ 이런 평가가 돌아오는 솔루션이 아니라, ‘지금 쓸 수 있나요?’ 질문이 돌아오는 솔루션을 선택해야 합니다.

채널톡은 22개국에서 44,000곳이 넘는 기업에서 사용하고 있는 채팅 상담 및 CRM. 사내 메신저 서비스입니다. 채널톡 개발 전 팀은 오프라인 매장의 방문객을 분석하는 하드웨어와 고객 데이터를 분석하는 빅데이터 솔루션이 결합한 서비스가 실리콘밸리에는 이미 자리를 잡고 있지만, 아시아 시장에는 그런 제품이 없다는 사실에 주목해 오프라인 매장용 고객 분석 솔루션 워크인사이트를 서비스했습니다. 채널톡은 워크인사이트를 운영하다가 오프라인 매장처럼 웹페이지도 고객 분석을 요청하는 이용사를 여럿 만나게 됩니다. 온라인 환경을 분석하던 중 오프라인보다 온라인 구매 전환율이 현저하게 낮은 이유가 웹페이지를 사용하는 고객의 경험, 특히 점원과 대화하는 환경에 있다는 것이 드러났습니다. 채널톡은 기존 B2B 서비스보다 이 문제를 해결하는 것이 더 큰 가치를 창출한다고 보았고 피벗 했습니다. 피벗은 성공적이었고 채널톡은 빠르게 성장하고 있습니다.5)

정리

이번 글에서는 MLP를 만드는 데 필요한 4가지 원칙,

1. 비즈니스가 아닌 사용자의 ‘필요’에서 시작할 것

2. 문제와 솔루션을 ‘분리’할 것(성급하게 솔루션에서 시작하지 않을 것)

3. 사용자에게 귀 기울이되 맹목적으로 ‘판단’하지 말 것

4. 가장 가치 있는 문제와 솔루션을 ‘선택’할 것

그리고 각 원칙의 사례(뉴욕타임스, 디스코드, 클래스패스, 채널톡)을 알아봤습니다.

2부 구성으로 보여드렸지만, 여전히 MLP가 막막하게 느껴질 수 있습니다. MVP 남용의 부작용인 기계적인 업무 수행에서 벗어나 성장하는 제품을 만들기 위해 여러 관점을 폭넓게 생각하게 되었을 테니까요. 영영 해결할 수 없는 답답함일 수도 있습니다.

하지만 이미 알고 있습니다. 더 고민할수록 더 나아진다는 사실을.

1) First Round Review – Don’t Serve Burnt Pizza (And Other Lessons in Building Minimum Lovable Products)

2) Mine Safety Disclosures, 2020 – The (Not Failing) New York Times

3) Ian Vanagas, 2020 – How Discord Won

4) First 1000, 2021 – Classpass

5) 채널톡, 2020 – 방향 전환의 기술 ‘피벗’, 채널톡이 탄생하기까지

국내 1위 IT아웃소싱 플랫폼,
위시켓이 궁금하신가요?