린하게 창업하기, 근데 이제 노코드를 곁들인: 1부

이런 분들께 이 글을 추천합니다. 노코드 툴을 이용해 빠르게 프로덕트를 만들어 보고 싶은 분, 창업 팀이나 사이드 프로젝트를 시작한 지 얼마 되지 않은 분, PM 혹은 PO 꿈나무. 이 중 하나라도 해당된다면 재밌게 읽을 수 있습니다. 오늘은 빠르게 프로덕트를 만들게 된 배경에 대해 말해보겠습니다.

현재 회사와 별개로, 사이드 프로젝트 겸 창업 팀에서 PO로 활동하고 있다. 평일 낮에는 회사 일을 하고, 평일 저녁이나 주말에 틈틈이 창업 팀 업무를 하고 있다. 8월에 탄생한 팀은 3개월 동안 가설 검증을 진행했고, 1개월 만에 MVP 서비스를 론칭하고 고객에게 제공하고 있다. 팀에서 만드는 서비스는 'QR 코드 스마트 메뉴판'으로, 나를 포함해 4명의 대학생 친구들이 열심히 서비스를 만들고 있다. 지금까지 여러 프로젝트와 팀에서 일을 했지만, 이번 팀처럼 린하게 일하는 팀은 없었던 것 같다. 서비스 론칭을 기념해 지금까지 이야기를 끄적거려본다. 

정말로 사람들이 문제라고 생각하나요?

서비스의 가능성을 생각할 때, 가장 먼저 ‘이 서비스가 해결하고자 한 문제를 실제로 사람들이 겪고 있는가?’를 최우선 순위로 둔다. 팀에 합류한 이유도 가능성을 엿봤기 때문이다. 문제를 확인한 시점은 친한 고등학교 친구와의 술자리에서였다.

친구는 이자카야에서 알바를 하는데, 매장의 고충을 술과 함께 털어놓았다. 이자카야에서 취급하는 생선은 시즌마다 달라 기존 메뉴판은 메뉴의 변동성을 잘 담아내지 못한다고 한다. 또한, 메뉴 대다수가 일본어로 적혀있다 보니 손님이 메뉴에 대해 자주 물어본다고 말했다. 당시에는 "오 그렇구나"라면서 넘어갔었다. 

그 일이 있은 지 얼마 지나지 않아서 작년 학교 창업 수업에서 같은 조로 활동한 친구들과 술을 마시고 있었는데, 그중 한 명이 아이템을 준비하고 있으니 참여해볼 생각이 없냐고 물어봤다. 메뉴판을 QR 코드로 제공한다는 아이템이었는데, 문득 고등학교 친구와 술자리에서 나눈 이야기가 생각났다. 디지털 기반의 메뉴판에서 사장님이 메뉴를 쉽고 간편하게 바꿀 수 있다면? 실제로 문제를 겪고 있는 사람도 직접 봤고, 이걸 해결할 솔루션도 있는데 안 할 이유가 없었다.

검증하기 전까지 모든 게 뇌피셜이다.

모든 창업 팀이 그렇듯이 처음에는 엄청나게 많은 기능을 생각했다. 하지만, 이 모든 기능을 첫 서비스에 담아내기란 불가능했다. 무엇보다 무턱대고 기능을 만드는 건 위험한 일이었다. 서비스의 기능은 고객이 겪는 문제를 실제로 해결할 때 가치가 있다. 바꿔 말하면 고객의 문제에 집중하지 않은 기능은 전혀 의미가 없는 기능이다. 좀 더 본질에 접근해야 할 필요성을 느꼈고 기능 아이디에이션을 미루고 고객한테 제공할 수 있는 가치가 무엇인지 이야기를 나눴다. 즉, 가장 먼저 핵심 가치를 찾는 일에 집중한 것이다.

우리가 생각한 가치는 '고객'이 아닌 '우리'의 가설일 뿐이다. 그리고 가설은 검증을 해야 사실로 존재할 수 있다. 그렇다고, 모든 가설을 검증하기란 리소스가 너무 많이 든다. 무엇보다 팀의 서비스는 양면 시장에 기반하는데 '메뉴판을 사용하는 매장'과 '메뉴판에서 메뉴를 확인하는 손님'이 큰 타깃이 된다. 이 두 타깃을 처음부터 모두 가져가기엔 날카롭지 않다고 판단했고, 우선 ‘손님’에 집중하기로 했다. 타깃을 좁혔지만 아직까지 날카롭지 못했고 가설 중에서도 검증할 만한 가설을 찾아야 했다. 

이를 위해 '가정 지도'를 사용했는데, 이 지도는 '검증 필요성'과 '영향력'을 기준으로 가설을 비교하는 지도다. 각 기준은 X축, Y축이 된다. 여기서 가장 오른쪽 상단에 있는 가설은 검증 필요성이 크고 영향력도 큰 가설로서, '검증할 만한 가설'이 된다.

좀 더 이해를 돕기 위해 예시를 들어보자. ‘면적이 큰 매장에 방문한 고객은 우리 서비스를 원할 것이다’라는 가설을 살펴보자. 면적이 큰 매장은 고객 한 명 한 명에게 찾아가 메뉴를 설명하기 힘들다. 즉, 서비스의 니즈를 느끼는 데 '면적'은 영향력이 큰 요소가 된다. 하지만, 이걸 검증할 필요가 있을까? 너무도 당연한 말이므로 굳이 검증할 필요가 없다. 이런 가설은 '검증할 필요는 적지만, 영향력이 큰 가설'이 된다. 

데이터로 검증해봅시다

이렇게 가정 지도를 활용해 검증할 만한 가설을 선별했고, 크게 4개의 문제 가설에 주목했다.

이 가설들이 정말로 문제인지 검증할 차례였다. 각 가설을 검증할 수 있는 문항으로 구성한 설문지를 최대한 많은 사람에게 뿌렸다. 이후, 문항마다 점수를 매겨서 합산했고 정량적 데이터를 얻었다. 운 좋게도 데이터 분석 코딩을 공부한 덕분에 데이터를 시각화하는 데 큰 문제가 없었다. 그 결과, 메뉴 정보의 부족함이 고객이 겪는 가장 큰 문제임을 확인했다.

집중할 문제를 찾았지만, 한 번의 검증만으로 "이게 정말 문제고 해결해야 한다!"라고 결정하기엔 아직 섣불렀다. 이번에는 (1)메뉴 정보의 부족함이 진짜 문제일까? 와 (2)그렇다면 우리는 이 문제를 어떻게 해결할 수 있을까? 를 추가로 검증했다. 어도비 XD로 프로토타입을 만들고 직접 사람들을 만나 인터뷰를 진행했다. 인터뷰이에게 시나리오를 제공하고 해당 시나리오에서 어떤 행동을 했는지 관찰했다. 그리고 왜 그런 행동을 했는지 되물어보면서 인터뷰를 진행했다. 이와 같은 과정을 무수히 반복하며 아주 많은 인사이트를 얻었고 우리 팀에 집중해야 할 문제를 더 날카롭게 정의할 수 있었다.

중간중간 얼라인은 필수!

바쁘게 실험과 검증을 반복하면서 프로덕트의 방향을 구체화했다. 그런데, 이 과정이 지속되다 보니 예상치 못한 부분에서 문제가 생겼다. 알고 보니 각자가 생각한 프로덕트의 방향이 조금씩 달랐던 것이다. 좋은 프로덕트를 만들기 위해선 모든 팀원이 같은 방향을 그려야 한다. 특히, 린하게 움직이는 팀에서 각자가 서로 다른 그림을 그리면 큰 패착이 된다. 이를 위해 엘리베이터 피칭과 캔버스를 활용해 중간중간 모든 팀이 같은 그림을 그리는 시간을 가졌다.

이 두 가지의 가장 큰 장점은 요소화가 아닐까 싶다. 무턱대고 '우리 아이템은 이런 거야!'라고 주야장천 말하는 것보다, 각 요소마다 날카롭게 정의함으로써 모두가 빠르고 구체적으로 같은 그림을 그릴 수 있게 만든다.

제프리 무어의 엘리베이터 피칭

제프리 무어의 엘리베이터 피칭은 간단히 [상황], [고객], [제품의 가치], [경쟁사 기능], [차별점]의 5가지 요소를 갖는다. 양식은 아래와 같고, 각 요소마다 팀원이 모두가 동의하는 단어로 정의한다.

린 캔버스

린 캔버스는 스타트업에서 사용하는 캔버스로, 각 요소를 채워넣다 보면 서비스와 팀의 방향을 구체화할 수 있다.

이제 문제도 날카로워졌고 모든 팀원이 같은 그림을 그리게 됐다. 그렇다면, 이제 프로덕트를 만들어야 한다! 내가 정의하는 '프로덕트'는 '고객에게 가치를 제공하는 모든 것'이다. 이러한 정의에서 보면 단순히 서비스뿐만 아니라 홈페이지, 서비스 소개서 등등 작업할 게 매우 많았다. 하지만, 우리는 린하게 일하는 걸 매우 중요시 여기는 팀이라 모든 프로덕트도 린하고 빠르게 구현했다. 프로덕트를 구현한 과정은 다음 글에 이어서 써보려고 한다.