내 서비스가 토이 프로젝트를 벗어나려면.
플랫폼 비지니스는 웹이나 앱 서비스다. 그저 잘 만든 앱이 전부가 아니라 시작부터 끝까지 정밀하게 짜여진 계획 안에서 진행되는 사업이다. 요즘 트렌드는 이 플랫폼을 기반으로 작은 메타버스를 만들어 작은 디지털 빌딩을 세우고 그 안에서의 interaction을 통해 기반을 공고히한 다음 본격적인 BM을 펼치는 것이다.
플랫폼 비즈니스를 하고자하는 사업가들이 가지는 가장 큰 착각 중 하나가 다양한 기능을 넣으면 내 아이템이 더 돋보이거나 좋은 서비스라고 생각한다는 것이다. 절대적으로 하나의 핵심기능이 서비스의 대부분을 차지해야 하고, 부가적인 기능들은 정말 부가적인 수준에서 그쳐야 한다. 여기까지 한 상태에서, 사용자 경험을 극대화할 수 있는 UX/UI를 신경쓰고, 최대한 사용하면서 발생하는 버그를 잡아내야한다.
하나의 기능에 충실한 서비스가 되어야 한다. 그것이 서비스의 Identity다. 나는 최근 리멤버라는 명함공유 어플리케이션의 행보를 보면서 최초의 의도와 많이 동떨어진 컨셉으로 가고 있다고 생각했다. 물론 명함공유 기능 하나만큼은 잘 되지만, 최근에 진행중인 피보팅들은 뭔가 사업적으로는 좋을 수 있으나 해당 브랜드의 이미지와는 다르지 않나 싶었다.
즉 identity를 잃으면 더이상 그건 그 서비스가 아니라는 뜻이다.
사용자는 1~2번 앱이 튕기거나 404 Not Found 정도는 용인한다. 하지만 3번째 그런 버그와 마주하는 순간 앱을 지우거나 다른 사이트를 알아본다. 아무리 서비스가 편하고 좋아도 사용자 경험에 단절을 가져오거나 불쾌함을 주게 되면 사용자는 떠나고, 떠난 사용자가 다시 돌아올 확률은 처음 우리 서비스를 본 사람이 우리 고객이 될 확률보다 극히 낮다.
UX라는 용어는 UI와 함께 묶이지만 비교적 가볍게 여겨지곤 했다. 실체가 없기 때문이다. 하지만 사용자의 입장에서 생각해보면 UX는 UI보다 더 중요한 부분이라고 볼 수 있다. 쉽게 생각해서 UX는 UI의 흐름이 얼마나 사용자 친화적인지에 대한 척도다. 버튼을 눌러도 반응이 없거나, 누를 수 없는 조건인 버튼이 버젓이 똑같은 상태인 경우 그리고 form 데이터에서 하나 입력하고 다음 입력을 마우스로 클릭하게 focus이동하도록 지원하지 않는 경우.
여러줄을 입력하는데 커서가 따라가지 않느 경우 등등이 있을 수 있겠다. 또한 글을 다 작성하고 어떤 버튼을 눌러야 글이 업로드되는지 모르도록 UI를 구성한 경우, 사진 등록을 할 수 있는 작성페이지에서 사진 등록 버튼이 안보여서 며칠동안 사진 없는 글만 올리는 사용자를 배출해낸 서비스도 같은 맥락에서 감점이라고 볼 수 있다.
서비스 크기가 방대해진다면 다른 앱이나 웹을 만들어 ReDirecting이나 Deep Linking 시켜주는 방법을 생각해봐야한다. 크기가 큰 서비스의 기준은 다소 모호할 수 있지만 그것이 사용자 수는 아니다. 서비스가 제공하는 기능이 많아지고 디테일한 기능 제어와 같이 기능 하나하나의 무게가 무거워지면 서비스의 성능이 떨어진다. 그래서 이런 경우 서비스를 쪼갤 수 있는 단위로 쪼개고 해당 기능을 최고의 퍼포먼스 안에서 충실하게 수행할 수 있도록 한 뒤 필요하면 앱 끼리 서로 이동할 수 있게 하면 될 일이다.
사용하지 않아도 백그라운드에서 데이터가 낭비된다던지, 강제 사진 다운로드로 인한 다운로드 폴더가 더러워짐 같은 부분이 생기면 점차 앱을 쓰지 않게 된다. 앱 크기가 크다거나 업데이트마다 리소스가 무자비하게 추가되는 어플리케이션은 찾지 않게된다. 개발의 측면에서 충분히 줄일 수 있는데도 하지 않는다는건 당장의 이익에 급급해서 마구잡이로 리소스를 넣었다고 추측될 수 있다. (물론 이건 개발자의 시각에서 그렇긴 하다. )
타겟 설정은 굉장히 중요하다. 누구에게 뭘 팔것인가. 그 사람들의 needs를 피부로 확인해 봤는가? 관련 데이터는 얼마나 있는가? 이 부분을 잘 해놔야 나중에 기능을 수정하거나 추가할 때 needs의 변화가 있었는지, 성향이 어떻게 변하고 있는지 등을 추적하여 서비스 사용량이나 특정 스크린에서 머무는 시간 등의 변화를 감지하고 원인을 파악할 수 있고, 이 과정에서 주먹구구식으로 업무처리를 하지 않을 수 있다.
플랫폼 비즈니스에서는 3분류의 사람이 존재한다. 공급자, 이용자, 중계자. 서비스의 성패는 이 3분류의 사람들이 손해를 보기 시작하면서 시작된다. 저 3분류의 사람들은 서비스를 통해 항상 이익을 얻어야한다. 그래야만 사람들이 떠나가지 않고, 3박자를 이루며 생태계를 조성한다.
공급자가 제대로된 아이템을 공급하지 않는 경우 : 예를 들어 오늘의 집이라는 플랫폼에 판매자가 없다면?
중계자가 서비스를 제대로 하지 않는 경우 : 우리 서비스가 툭하면 404를 뱉고, 앱이 터진다. UI/UX도 형편없어서 사용자 경험이 바닥을 친다.
이용자가 없거나 질이 낮은 경우 : 애초에 마케팅을 잘못해서 초기 유입 유저가 질이 낮다던가 특정 커뮤니티의 성향을 옮겨놓은듯한 수준을 보이는 경우를 생각해볼 수 있다.
기획에서 모든게 판가름난다. 누구에게 뭘 어떻게 팔지를 100페이지든 200페이지든 정리해놓은 글이다. 어떤 기술로 어떻게 구현할 것이고, 누구에게 어떤 방식으로 얼마정도에 Exit할지, 어떤 위험이 있는지, 그 위험에 대한 해결책은 뭔지. 현금확보는 어떻게 할꺼고 cash Flow는 대강 어떻게 될지. 시장의 동향은 어떻고, 타겟의 성향은 어떤지 등등 전부 분석해서 하나의 문서로 정리해야 한다.
피칭를 할 때, 10분짜리 짧은 PR을 할때 각각 다른 버전의 PPT나 Presentation파일을 만들지라도 모든 경우의 수와 모든 공격과 방어의 수를 생각하고 시나리오를 만들어놔야 비로소 사업을 시작할 수 있다.
중계자의 역할은 사용자와 공급자의 시간을 줄여주는 것이다. 우리 플랫폼을 사용하면 어떤 목적을 달성하는데 시간이 적게들어야 한다. OKR을 만들 때 Objectives의 1번은 항상 사용자의 시간단축을 적어야 한다.
잘 생각해보면 거의 대부분의 플랫폼 비즈니스들은 사용자와 공급자의 시간을 줄여주는 방향을 지향하고 그렇게 발전해왔다.
배달의 민족은 흩어져있던 음식점 목록을 한곳으로 끌어모아 빠르게 음식을 주문할 수 있게 만들었고, 뭘 먹을지 고민하지 않아도 되도록 추천시스템을 만들었다. 오늘의 집은 인테리어 가구점의 DT를 이루어내어 사용자들이 가구공단이나 백화점에서만 살 수 있었던 가구들을 빠르고 쉽게 접할 수 있도록 만들었다. 모두, 번거롭지만 할 수 있었던 행동들을 쉽고 편하고 빠르게 만들어주며 모두 시간을 단축해줬다는 공통점이 있다.
기획에서 모든 가능성에 대한 시나리오를 작성했어도 분명 예상과 다른 시나리오가 나오기 마련이다. 그리고 그 시나리오는 꽤나 높은 확률로 크리티컬할 수 있다. 어이없게 규제에 막힐 수도 있고, 강력한 신생업체가 나올 수도 있다. 기술 구현이 생각외로 늦어지거나 완성도가 안잡힐 수 있다. 모든 것은 계획대로만 흘러가지 않기 때문이다. 그럼에도 각 상황에서 최고의 선택을 도출해나가며 이끌어 가는 것이 플랫폼 비즈니스의 의의라고 생각한다.