린 캔버스로 아이디어 검증하기

 

신규 아이디어가 나올 때마다 바로 기획서를 쓰기 시작하면, 절반은 중간에 방향이 바뀌고 절반은 그냥 흐지부지됩니다.
저도 예전엔 아이디어가 나오면 바로 와이어프레임부터 그렸는데, 나중에 보면 "이게 정말 필요한 서비스인가"라는 근본적인 질문에 답을 못 하는 경우가 많았어요.
그래서 요즘은 신규 아이디어가 나오면 제일 먼저 린 캔버스(Lean Canvas)를 채워보는 걸 습관으로 만들었습니다.

 

린 캔버스는 문제, 고객군, 고유의 가치 제안, 솔루션, 채널, 수익 구조, 비용 구조, 핵심 지표, 경쟁 우위까지 한 장에 정리하는 프레임워크예요.
비즈니스 모델 캔버스와 비슷하지만, 스타트업 초기 아이디어 검증에 맞게 "문제"와 "솔루션"을 앞쪽에 배치한 게 특징입니다.
저는 이 순서가 특히 마음에 들었어요.
솔루션부터 생각하고 문제를 억지로 끼워 맞추는 실수를 막아주기 때문입니다.

저희 팀에서 최근 검토했던 "정기구독 리마인더 알림" 기능을 예로 들면, 캔버스를 채우기 전까지는 다들 "구독 관리가 편해질 것 같다"는 느낌으로만 이야기하고 있었어요.
그런데 캔버스의 "문제" 칸을 채우려고 하니, 실제로 우리 사용자가 겪는 문제가 뭔지 다들 정확히 말을 못 했습니다.
그래서 기존 CS 문의 데이터를 뽑아봤고, "구독 해지를 깜빡해서 요금이 나갔다"는 문의가 전체 CS의 8% 정도를 차지한다는 걸 확인했어요.
문제가 숫자로 확인되자 캔버스의 나머지 칸을 채우는 방향이 훨씬 명확해졌습니다.

 

캔버스의 장점은 한 페이지라는 제약 그 자체에 있다고 생각해요.
PRD처럼 길게 쓸 수 있는 문서라면 애매한 부분을 문장으로 얼버무리고 넘어갈 수 있는데, 캔버스는 한 칸에 한두 문장만 들어갈 수 있으니 애매한 부분이 바로 드러납니다.
저희 팀에서 캔버스를 처음 써봤을 때, "핵심 지표" 칸을 채우다가 팀원 세 명이 서로 다른 지표를 적었던 적이 있어요.
누구는 "알림 클릭률"을, 누구는 "해지 문의 감소율"을, 누구는 "재구독률"을 적었습니다.
이 차이를 그 자리에서 발견하고 논의할 수 있었던 게, 오히려 개발이 다 끝난 뒤에 "그래서 이 기능 성공한 거예요?"라고 묻는 것보다 훨씬 나았어요.

 

저희 팀이 캔버스를 쓸 때 가장 오래 걸리는 칸이 바로 "고유의 가치 제안(Unique Value Proposition)"이었습니다.
"편리한 알림 서비스"처럼 뭉뚱그린 문장을 쓰면 리뷰할 때 바로 반려당해요.
저는 이 칸을 채울 때 "다른 대안(수동으로 캘린더에 적기, 은행 앱 알림)과 비교했을 때 우리만 줄 수 있는 게 뭔가"를 계속 물어보게 합니다.
리마인더 기능의 경우, 결국 "구독 서비스 안에서 결제 정보와 연동된 채로 알림이 오기 때문에 바로 관리 화면으로 이동할 수 있다"는 점이 다른 대안과의 차이였어요.
이 문장이 나오기까지 회의를 세 번 정도 더 했던 것 같습니다.

 

캔버스를 채우는 것만으로 끝내면 의미가 없습니다.
저희는 캔버스의 각 칸 옆에 "이 가정이 틀렸다면 어떤 신호로 알 수 있는가"를 같이 적어두기 시작했어요.
예를 들어 "사용자는 해지 리마인더를 반갑게 여길 것이다"라는 가정 옆에는, "알림 클릭률이 15% 미만이면 이 가정은 틀린 것으로 본다"라고 적었습니다.
실제로 파일럿을 2주 돌려보니 클릭률이 22%로 나왔고, 이 정도면 가정이 맞았다고 판단해서 정식 개발로 넘어갔어요.
반대로 다른 아이디어였던 "친구 추천 리워드" 기능은 캔버스 검증 단계에서 초대 전환율이 예상치의 3분의 1도 안 나와서, 정식 개발 전에 접었습니다.
개발 리소스를 하나도 안 쓰고 아이디어를 접을 수 있었던 게 캔버스 덕분이었다고 생각해요.

 

캔버스를 쓰면서 느낀 건, 이게 정답을 주는 도구가 아니라 질문을 강제하는 도구라는 점이었습니다.
채우다 보면 팀이 그동안 당연하게 여기던 가정이 사실 근거가 없었다는 게 드러나고, 그 가정을 검증할 방법을 같이 고민하게 돼요.
저는 요즘 새로운 아이디어가 나오면 회의 시작 전에 먼저 캔버스 초안을 각자 채워오게 하는데, 이렇게 하면 회의 시간의 절반은 "누가 뭘 다르게 생각했는가"를 맞춰보는 데 쓰게 됩니다.

처음엔 이 과정이 시간을 더 쓰는 것처럼 느껴졌는데, 결국 잘못된 방향으로 두세 달 개발하는 것보다는 훨씬 빠른 길이었어요.
다음 아이디어 검토 때도 이 방식을 계속 써볼 생각입니다.