플랫폼(서비스) 컨셉 기획하기

문제정의? 가설 세우기? 가설 검증? 솔루션? 그게 뭐야?

스타트업에 대해서 깊게 생각해 본 적은 없다. 그냥 멋진 곳, 배달의 민족이나 마켓 컬리의 BI가 머릿속에 맴돌 뿐이다. 그런 스타트업을 흉내 내고 있다고 생각하니 웃음이 베어 나왔다. 설상가상(?)으로 나를 부르는 명칭이 '대표'가 되어 버렸다. 사내벤처 관리팀 직원들도, 엑셀러레이터들도 나를 대표라고 부른다. 한 달 남짓 '대표'라는 직함으로 불렸더니 익숙해졌다. 이제 과장이라는 직함보다 대표 직함이 더 어울리는 듯 하니 참 우습다.

https://brunch.co.kr/@mumaster82/217

갑자기 1인 기업이 되어버렸다.

지난번 글에서 말했던 것처럼 1인 기업이 되어버렸다. 엄밀히 말하면 1.4인 기업이랄까? 대표인 나는 온전히 파견을 나올 수 있었다. 다른 일은 하지 않고 서비스 기획 및 개발에 집중할 수 있다. 다른 2명의 팀원들은 일주일에 한 번 와서 서비스 기획 및 개발에 참여할 수 있도록 허락(?)해 주었다.

이 허락도 쉽지 않았다. 팀장을 만나고 임원을 만나고 사내벤처 관리 부서의 임원까지 만나 사정했다. 그 결과 일주일에 한 번 사내벤처 업무를 할 수 있게끔 허락 받았지만 업무는 전혀 줄지 않았다. 일주일에 한 번 자리를 비워도 되지만 기존 업무에 영향을 미치면 안된다. 그것도 정말 특별히 지원해준다는 태도였다. 지원부서에 있던 1명은 일주일에 한 번 만날 수 있었지만, 영업 부서에 있던 다른 1명은 단 한 번도 참여하지 못했다. 정확히 우리는 1.2인 기업이었다.

플랫폼(서비스) 콘셉트 잡기

플랫폼이나 서비스를 만드는 프로세스는 대충 이렇다. 아이디어를 떠올리거나 떠오르는 아이디어를 잡는다. 그 중 제일 괜찮은 아이디어를 선택하는 과정에서 고객의 어떤 문제를 해결할 수 있을지를 생각해본다. 반대여도 상관없다. 우리가 해결해야만 하는 고객의 문제가 무엇이 있는지 떠올려보고 아이디어로 연결 할 수도 있다. 솔루션을 바로 떠올려도 좋고 문제를 떠올려도 좋다. 무언가를 관찰하면서 만난 새로운 시각이거나 어떤 경험이나 타인의 고통을 공감하는 과정에서 아이디어는 떠오른다. 이러한 과정을 지나 문제를 발굴하고 정의한다. 즉 문제에 대한 가설을 세운다.

예를 들면, 카닥은 <자동차를 수리할 때 과연 이 수리가 필요한지, 이 가격이 맞는지 알 수 없어 불편할 것이다.>라는 가설을 세웠을 것이며, 배달의 민족은 <식당은 종이 전단지 광고는 하지만 정확한 효과를 알 수 없어 불만이 많을 것이다>, <사용자는 전단지를 보고 주문하는 것이 불편할 것이다> 혹은 <배달 식당에 대한 리뷰가 없어 불편할 것이다>라는 가설을 세웠을 것이다.

이제 이 가설이 맞는지 검증해 봐야 한다. 검증하는 방법으로는 인터뷰와 설문조사가 있다. 더 많은 방법이 있겠지만 난 모른다. 스타트업 창업가들의 바이블인 에릭 리스의 <린 스타트업Lean Startup>을 보면 가설을 검증하기 위해 '린 캔버스'를 작성하고 인터뷰를 진행하는 방법을 안내한다.

린 캔버스 lean canvas 예시

정의한 문제 즉 가설을 가지고 린 캔버스를 작성해 본다. 채울 수 있는 것만 채우면 된다. 가설이 진짜인지를 확인하는 과정이기 때문에 완벽할 필요는 없다. 완벽보다 중요한 건 스피드였다. (스타트업을 흉내낸 내 경험상 그랬다.) 작성한 린 캔버스를 가지고 인터뷰를 진행해서 우리가 세운 가설이 맞는지 확인한다.

여기서 중요한 건 학습이다. 문제가 맞는 지 확인하는 과정에서 새로운 사실을 알게된다. 우리가 생각한 문제가 그리 힘들지 않았다는 것을 알게되고 다른 문제를 발견하게 될 수도 있고, 생각지도 못했던 타깃으로 바뀌게 될 수도 있다. 그렇기 때문에 완벽보다는 스피드가 중요했다. 난 10명의 사람들을 만나 인터뷰를 했고 우리가 생각했던 문제가 문제가 아님을 확인했다.

(우리는 아니었지만) 우리가 생각한 문제가 '정말 문제'임이 확인됐다면 이제 프로토타입을 만들 차례다. 최소한의 비용을 사용하여 최소한의 기능을 담은 (기능이 없어도 상관없다) 제품을 만든다.

이 프로토타입을 가지고 다시 인터뷰(혹은 설문조사)를 진행한다. 이 서비스가 마음에 드는지, 얼마면 이 서비스를 이용할 것 같은지를 확인하는 단계이다. 우리가 만든 솔루션을 사람들이 정말 필요로 하는 지를 확인하는 단계라고 보면 된다. 솔루션 검증 혹은 고객 검증 단계라 부를 수 있다.

여기서도 학습이 중요하다. 설문조사 보다 인터뷰가 더 효과적인 이유다. 설문조사는 지인 혹은 지인의 지인에게 부탁하는 경우가 많기 때문에 자신도 모르게 우호적인 답을 할 가능성이 있다. 설문조사에 응하는 일은 생각보다 굉장히 귀찮은 일이기 때문에 양질의 정보를 얻지 못할 가능성이 크고, 설계한 문항 이외의 답을 얻기도 힘들다.

심층 인터뷰를 진행하면, 상황에 따라 더 깊은 질문을 하기도 하고, 상대방도 더 많은 이야기를 해주기 때문에 그 과정에서 추가적인 인사이트나 적용점을 얻을 수 있다. 상대방의 음성, 표정에서 드러나는 것들도 많이 때문에 훨씬 솔직한 생각이나 의견을 들을 수 있다는 장점도 있다.

프로세스를 정리해 보면 다음과 같다.

1. 아이디어와 문제를 떠올린다.
2. 새로운 시각으로 관찰하거나 타인이나 자신의 고통에 공감하는 과정이 도움이 된다.
3. 떠오른 아이디어나 문제에서 가설을 설정한다.
4. 가설을 검증한다.
5. 가설이 검증되지 않았다면, 학습한 내용을 가지고 1번, 2번 혹은 3번으로 돌아가 적용한다.
6. 가설이 검증되었다면, 프로토타입을 만들어 솔루션(고객)을 검증한다.
7. 검증되지 않았다면, 프로토타입에 다시 검증하던가, 3번 단계로 다시 돌아간다.
8. 솔루션(고객) 검증이되었다면, 이제 비로소 서비스를 기획할 수 있다.

지금이야 이 내용이 머리에 있지만, (지금도 이 내용이단단하게 머리에 있지는 않지만) 콘셉트를 잡을 당시에는 하나도 머리에 없었다. 모래알처럼 개념이 글자 단위로 흩어져 머리에 흩뿌려져 있는 느낌이랄까. 무언가가 머리에서 잘 나오지 않으면 그냥 넘어갔다가 나중에 그 단계가 필수적이라는 것을 깨닫고 다시 돌아오곤 했다.

'시키는 일을 얼마나 그럴 듯 하게 보여지게 만들까'만 생각하다 문제를 떠올리고 구체화시키고 검증하는 일을 하기에 내 역량이 부족했다.

게다가 1.2명이었다. 팀원을 만나는 그 하루가 일주일 중 가장 기다려지는 하루였다. 비록 만난 하루의 절반은 내가 일주일 동안 한 일을 브리핑하다 끝나버렸지만 말이다. 그래도 화이트 보드에 그럴 듯 하게 글자와 화살표를 그려가며 회의하는 일은 즐거웠고 내가 뭐라도 된 것 같은 착각에 빠지기에 충분했다.