행동력이 미친 창업팀
5월에 PM으로 근무해 온 스타트업을 퇴사했고, 창업을 시작했다. 퇴사 직후 2개월 동안 팀 빌딩 과정을 거쳤고, 7월이 돼서야 만족스러운 팀 빌딩이 끝났다. 팀이 새로 만들어지면서, 서비스도 새롭게 리빌딩됐다. 문제와 핵심 가치도 새로 정의했으며, 전반적인 UI도 개편이 진행됐다. 무엇보다 서비스명도 ‘마이플랜잇’에서 ‘투두몰’로 바뀌었다. 마이플랜잇은 일단 회사명으로 가져가기로.
창업에 진심인 사람들이 모인 덕분에, 팀이 결성된 직후부터 지난 2개월 동안 많은 성과를 달성했다.
와! 정말 행동력이 미쳤네요!
지금까지 다양한 창업 팀, VC, 엑셀레이터 등을 만났고, 우리가 어떻게 일해왔는지를 이야기하면 모두가 이처럼 말한다. 특히 개발 없이 오직 노션만을 이용해 MVP 테스트를 진행한 이야기를 들려주면, 모두가 신기한 사람을 보는 듯한 눈빛을 보냈다. 노션 장인 FameLee 이번 글에는 우리 팀이 노션을 어떻게 활용해서 MVP 테스트를 성공적으로 마쳤는지 다뤄보려고 한다.
MVP 테스트, 왜 필요해?
1. 가설 검증의 도구
스타트업은 다양한 가설을 설정하고, 검증하는 과정을 반복한다. 애초에 검증을 하지 않는다면, 이는 탁상공론에 불과하다. 아무런 검증도 하지 않고 계속 서비스를 만든다면, ‘유저가 필요한 서비스’가 아니라 ‘나의 편견에 기반한 서비스’가 탄생할 수도 있다.
가설을 검증하기 위한 다양한 방법론이 있다. 피그마로 프로토타입을 만들거나, 랜딩 페이지를 제작해서 사람들의 반응을 볼 수 있다. 하지만 ‘가동되지 않은 프로덕트’로 검증할 수 있는 영역은 한정된다. (1) 피그마로 만든 프로토타입을 10분 동안 눈으로 본 후에 말하는 피드백과 (2) 실제로 구현되는 프로덕트를 며칠 동안 사용하고 주는 피드백, 이 둘을 비교하면 당연히 후자가 많은 인사이트를 줄 수밖에 없다.
MVP 테스트를 진행하는 이유도 마찬가지다. 구현되는 프로덕트를 유저가 직접 사용해봐야, 더 많은 인사이트를 얻을 수 있다.
여기서 잠깐! MVP의 기초 개념을 짚고 넘어가자. MVP는 Minimum Viable Product, ‘최소 기능 제품’을 뜻하며 좀 더 풀어서 설명하면 ‘핵심 가치를 전달할 수 있는, 최소한의 기능을 담은 제품’이다.
여기서 ‘최소한의 기능’에 주목해야 한다. MVP는 완벽한 프로덕트가 아니라, 가설 검증을 위한 실험 도구에 가깝다. 가설을 명확하고 확실하게 검증하기 위해서 유저가 직접 구현되는 서비스를 쓰는 게 가장 좋다. 이때 사용하는 게 바로 MVP다.
2. 무엇을 검증할까?
다시 본론으로 돌아오자. MVP 테스트를 위해, 가장 먼저 해야 할 일은 “어떤 가설을 검증할까?”를 답하는 것이다. 앞서 말했, MVP는 가설 검증을 위한 실험 도구다. 따라서 어떤 가설을 검증할지 명확히 정의해야 MVP 테스트가 의미가 있다. 일단 서비스를 만들어서 배포하고, 수집한 데이터를 기반으로 아무 가설이나 검증하는 것 자체는 너무 비효율적이다.
우리 팀은 ‘프로덕트 선언문’을 사용한다. 프로덕트 선언문이란 1장의 페이지에 다음과 같은 정의를 기재한 문서다.
- 타겟은 누구이며, 이들이 겪는 문제는 무엇이다
- 이를 위해 제공하는 핵심 가치
- 핵심 가치를 전달하는 프로덕트 기능
※ 해당 용어는 FameLee가 인위적으로 정의한 용어입니다.
이 프로덕트 선언문에 적힌 내용은 모두 가설에 불과하며, 계속 변경될 수밖에 없다. 매번 업데이트가 필요한 문서이기에 번거로워 보이지만, 이렇게 구체적으로 정의한다면 팀이 어떤 가설을 검증해야 하는지 동기화하여 결과적으로 같은 방향을 그릴 수 있다.
- 타겟은 누구이며, 이들이 겪는 문제는 무엇인가? → 문제 가설
- 이를 위해 제공할 핵심 가치는 무엇인가? → 가치 가설
- 핵심 가치를 전달한 프로덕트 기능은 무엇인가? → 솔루션 가설
과거 랜딩 페이지 실험과 인터뷰 등을 통해 우리가 정의한 서비스는 “전문가의 경험을 담은 체크리스트 기반의 클래스”였다. 이때 선언문에 적은 1. 문제 가설과 2. 핵심 가치 가설을 MVP를 통해 검증하기로 했다.
즉 1. 우리가 생각한 ‘타겟 고객의 문제’가 정말로 문제가 맞는지와 (2) 우리가 생각한 ‘고객이 원하는 가치’가 정말로 원하는 게 맞는지를 알아보는 걸 MVP 테스트의 목적으로 삼았다. (과거에 진행한 랜딩 페이지 실험이 궁금하면, 아래 링크 참고!)
3. 어떻게 검증할까?
무엇을 검증할지 명확히 정의했으니, 이제 어떻게 검증할지를 정의해야 했다. 검증을 위해 MVP를 만들어야 하지만, 이를 개발 기반으로 검증하기엔 ROI가 높지 않다. 애초에 MVP는 가설 검증을 위한 도구인데, 이 실험 도구를 만들기 위해 하나하나 개발하는 건 리소스 낭비다.
문득 든 생각, 개발 없이 노션만을 활용해 MVP 프로덕트를 만들 수 있지 않을까? 후다닥 노션으로 서비스 소개 사이트와 MVP 프로덕트 제작에 돌입했다. 노션 장인이라고 불러주세요
개발 없이 MVP 테스트!
1. 서비스 사이트 만들기
MVP 테스터 모집을 위해 먼저 서비스 사이트가 필요했고, 노 코드 툴을 활용해 하루 만에 모집 시스템을 구축했다.
- 노션과 우피를 활용해 하루 만에 사이트를 제작했고, 전문가의 경험을 담은 10개의 클래스를 소개했다.
- 탈리를 통해 개별 클래스 참가 신청을 받았고,
- 자피어를 이용해, 신청이 완료되면 바로 참가 확인 메일을 전송했다.
- 탈리와 슬랙을 연동해 신청 알림을 받았다.
- 마지막으로 실시간 현황 파악을 위해 탈리 데이터를 구글 스프레드시트와 연동한 후
- 다시 시트를 구글 데이터 스튜디오와 연결해서 대시보드를 구현했다.
100명의 테스터를 모으는 걸 목표로 여러 커뮤니티에 서비스 홍보 글을 올렸다. 테스터가 모이기까지 일주일의 시간을 예측했지만, 놀랍게도 2일 만에 수요가 넘쳐나서 모집을 마감했다.
2. 프로덕트 만들기
MVP 프로덕트도 개발 없이 노션으로 구현했다. 투두몰의 대표 기능은 크게 아래와 같다.
- “클래스”가 여러 “세션(목차)”로 구성되고, 각 세션에는 따라 해야 하는 “체크리스트”가 있다.
- “체크리스트” 안에는 어떻게 따라 하면 되는지 구체적으로 알려주는 “가이드라인”이 있다.
- 각 “세션”마다 “데드라인”이 있으며, 데드라인이 끝나기 전까지 “미션”을 인증해야 한다.
- “미션”을 인증해야지, 그다음 세션이 열린다.
이와 같은 기능을 노션의 데이터베이스, 관계형 속성과 필터 기능을 활용해 클래스 시스템을 구현했다.
하나의 페이지는 한 개의 클래스가 운영될 공간이다. 총 신청 클래스는 약 200개에 달하며, 이에 맞춰 200개의 클래스 페이지를 만들어야 한다. 200개의 페이지 하나하나에 내용을 직접 채워 넣는 건 리소스가 너무 많이 들기에, DB의 템플릿 기능을 사용했다. 클래스를 생성 및 관리할 DB를 만들고, 각 클래스를 템플릿으로 구현했다.
이후, 각 클래스 신청자 수에 맞춰서 템플릿 기능을 활용해 페이지를 만들었다. 각 페이지마다 신청자를 초대하고, 페이지 권한 설정 기능을 활용해 설정을 조작을 하지 못하게 만들었다.
미션 인증은 휴먼 지능을 사용했다. 죽여줘… 매일 아침 10시, 각 클래스에서 세션 미션을 달성했는지 하나하나 파악했고, 페이지 댓글 기능을 활용해 클래스 도전 상황을 공유했다.
3. 데이터 수집하기
MVP 프로덕트를 어떻게 만들지도 중요하지만, 데이터를 어떻게 수집할지도 놓치면 안 된다. 노션 DB에 저장된 클래스 상태 값(Ex. 현재 도전 중인 세션, 클래스 상태 등)은 Notion2Sheet를 활용해 구글 스프레드 시트로 불러왔다. 그리고, 노션에서 자동 수집되기 어려운, 상세 데이터(ex. 세션 오픈일, 단축 시간 등)는 매일 아침에 미션 유무를 확인하면서 시트에 직접 입력했다. 추가적으로, 탈리에 저장된 신청자 데이터를 쿼리로 불러와서 클래스 정보와 합쳤다.
파편화된 데이터를 한곳으로 모은 후, 구글 데이터 스튜디오를 이용해 대시보드를 구현해서 MVP 테스트의 진행 상황 및 이슈를 대시보드로 빠르게 파악할 수 있었다. 파편화된 데이터를 모은 구조는 대략 아래와 같다.
마지막 과정, MVP 인터뷰
1. 세그먼트 나누기
MVP 테스트에서 수집한 정량 데이터로 인사이트를 얻을 수 있지만, 가설을 명확하게 검증하기 위해서 정성 데이터가 필요하다. 테스트가 종료되자마자, 인터뷰 설계를 진행했다. 창업 팀은 쉴 틈이 없다…
MVP 테스터를 모두 동일 집단으로 보고 인터뷰를 진행하면, 자칫 데이터에 오류가 생길 수 있다. 예를 들어 대학교 1학년과 대학교 3학년은 놓인 환경이 다르기에 완전히 다른 행동 패턴을 보인다. 이를 고려하지 못하고 이들을 하나의 집단으로 본다면 데이터에 오류가 생긴다. 따라서 MVP 테스터를 여러 세그먼트로 구분 짓는 게 먼저 필요했다. MVP 테스트 동안에 수집한 데이터를 기반으로, 세그먼트를 분류했다.
2. 인터뷰 방법과 질문 정하기
전화, 줌, 오프라인 미팅 등 다양한 인터뷰 방법을 두고, 어떤 방법을 택해야 할지 고민했다. 각 세그먼트에서 인사이트를 뽑아내려면 충분한 모수가 모여야 한다. 만약 세그먼트에서 1~2명이 응답을 한다면, 자칫 편향된 정성 데이터를 얻을 수도 있기 때문이다.
따라서 인터뷰 응답률을 판단 기준으로 뒀고, 전화 인터뷰를 진행하기로 했다. 전화 인터뷰가 다른 방법에 비해 (1) 부담감이 가장 적고, (2) 즉각적으로 응답을 받아주리라 생각했다.
각 세그먼트마다 보인 행동 패턴을 데이터로 유추하고, 인터뷰 질문을 설계했다. 이때, MVP 테스트의 목적에 맞게 “(1) 문제 가설과 (2) 핵심 가치 가설을 검증하기 위해서 어떤 질문을 해야 할까?”를 생각하며 질문을 리스팅 했다.
3. 진행하기
각 세그먼트별로 전화 인터뷰를 진행했다. 전화 인터뷰 진행 프로세스도 최대한 응답률을 높일 수 있는 방향으로 설계했다. 전화를 받으면 (1) 서비스를 이용해서 고맙다는 감사 인사와 (2) 인터뷰 목적을 먼저 전달드려서, 낯섦과 거부감을 최대한 없애는 데 중점을 뒀다. 이후, (3) 참가 혜택과 (4) 인터뷰 예상 소요 시간을 전달드려서, 인터뷰 참가를 회유(?)했다.
추가적으로, 인터뷰 진행자에 따른 수집 데이터의 차이가 생기지 않도록 1명이 대화를 이끌고, 다른 1명이 응답을 기록하는 식으로 진행했다.
4. 인사이트 뽑아내기
전화 인터뷰에 엄청나게 높은 응답률을 보여줬고, 많은 정성 데이터를 수집할 수 있었다. 이제 정성 데이터에서 인사이트를 정의 내릴 차례다. 정성 데이터 분석으로 어피니티 다이어그램 방법을 사용했다. 세그먼트마다 얻은 정성 데이터를 포스트잇에 리스팅 하고, 화이트보드에서 클러스터링 해서 인사이트를 뽑아내는 과정을 몇 시간 동안 반복했다.
클러스터링 결과, 최종 정의한 인사이트를 기반으로 ① 문제 가설과 ② 핵심 가치 가설을 검증했고, 최종적으로 프로덕트 선언문을 업데이트했다.
마치며
이렇게 MVP 테스트의 AtoZ 경험을 기록해보니 생각보다 엄청나고 많은 걸 진행했다. 다양한 노 코드 툴을 쓸 줄 아는 덕분에 개발에 의존하지 않고도 아이디어를 구현하고, 체계적인 시스템을 구축할 수 있었다. 만약 초기 창업 팀이라면, 틈내서 노 코드 툴을 공부해보길 추천한다!
원문: FameLee의 브런치
이 필자의 다른 글 읽기
