가설! 가설! 가설!
STORM 기획 가설 점검하기
"그래서 너의 가설이 뭔데?"
STORM은 말이지, 아이디어 회의에서 어려움을 느끼는 사람들을 위한 앱이고, 각자 브레인스토밍 하다가 시간이 다 지나면 아이디어를 한 데 모아 볼 수 있어서, 아, 기능이 좀 복잡하게 느껴질 수도 있는데... 글쎄, 가설? 가설은 말이지, 음, 그냥 일단 잘 만들어내면 되는 것 아니었나.
선뜻 대답하지 못하고 얼버무려야만 했다. 애당초 명확히 검증된 가설이 존재하지 않았기 때문.
실시간 브레인스토밍 협업 툴인 STORM을 기획할 당시, 그 여정의 시작은 나의 개인적인 문제의식과 필요에서 비롯된 것이었다. 어차피 '나', 혹은 '나와 같은 사람들'이라는 타겟이 분명 존재하기에, 일단 만들면 누군가는 쓰지 않겠냐며 안일하게 생각했다.
그것이 STORM의 한계였다. 이전 회고글에서도 언급했듯, STORM을 기획하는 과정에서 가장 까다롭게 느껴졌던 부분은 타겟의 규정과 구체화였다. 확실한 타겟이 부재하다 보니 비지니스 모델(BM)을 설계하는 것 역시 어려웠다.
프로젝트를 진행한 앱잼(AppJam) 기간 동안 이를 놓쳤다는 건 일단 둘째치고 – STORM을 이대로 타겟과 BM을 배제한 채 개인의 필요에 의해 만들어진 토이 프로젝트로 남겨둘 것인가, 아니면 명확한 타겟을 대상으로 끊임없이 검증하고 테스트하는 서비스로 발전시킬 것인가.
이러한 고민을 발판 삼아 문제의식을 도출했을 당시로 돌아가 타겟에 대한 가설을 다시 점검하는 시간을 가졌다.
(글 시작에 앞서 STORM에 좋은 경험과 인사이트를 허락해준 이화여대 기술창업 린스타트업 교육팀과 이 과정을 함께 해준 팀원 세영이에게 고마움의 인사를 남긴다!)
STORM의 기존 비지니스 모델 중 고객군 및 가치 제안 요약기존에 STORM이 정의한 타겟은 'young creator team'이었다. 앱잼에 이어 한창 서비스를 출시하던 시기에는 각각의 'young', 'creator', 'team'이라는 단어를 풀어 타겟을 명시하고자 했으나, '아이디어를 결정하기 어려운 사람/팀', '아이디어 회의를 시작하고자 하는 사람/팀' 등의 타겟은 여전히 모호했다.
1. 핵심 기능을 바탕으로 타겟 재설정하기
먼저, 가치 제안 및 고객 프로파일 캔버스(Value Proposition & Customer Segment Canvas, VP-CS Canvas)를 점검했다.
이전에는 일반적인 아이디에이션/브레인스토밍 회의를 바탕으로 STORM의 기능을 확정 짓기 위해 VP-CS 캔버스를 활용했다. 이미 기능이 어느 정도 확정되어 있는 지금은 기능에 따른 타겟 구체화가 필요한 상황이다. 이를 위해 1) 개인적인 배경에 의해 시작된 서비스인 만큼 '나'라는 타겟이 속해있으면서 2) 가장 일반적인 young creator team의 아이디에이션 회의 상황 중 하나인 '디자인 팀플 과제의 아이디에이션을 막 시작한 팀'을 바탕으로 캔버스를 고민해보았다.
캔버스 우측의 고객 프로파일 맵의 고객 활동(Customer Jobs) 영역에는 아이디에이션 회의 상황을 세세하게 적어 내렸다. 회의 전과 회의 중을 바탕으로 해당 타겟 군에 속하는 잠재 고객은 어떤 활동 및 대화를 통해 어떤 경험을 하게 될지 번호를 매겨 정리했고, 이를 바탕으로 해당 타겟 고객이 어떤 불만이나 방해 요소를 느낄지(Pains)와 어떤 혜택이나 이점 등을 기대하거나 바랄지(Gains) 정리했다. 고객 프로파일 맵을 완성한 후에는 기존의 핵심 가치 및 기능을 비교하며, Pains 및 Gains에서 중요도가 높다고 판단되는 항목 세 개에 빨간색으로 표시해두었다.
좌측의 가치 제안 맵에서는 빨갛게 표시해둔 Pains와 Gains 항목을 바탕으로 Pain Relievers와 Gain Creators를 발전시켰다. 타겟 고객이 회의 과정에서 느낀 불만사항을 어떻게 해소시켜줄 수 있을지, 또 반대로 회의 과정에서 발생한 긍정적인 부분들은 어떤 식으로 강조해 타겟 고객에게 더 큰 만족감을 줄 수 있을지 정리했다. VP-CS 캔버스의 마지막 단계로, STORM이 앱 서비스로서 타겟 고객에게 어떤 기능을 제공할지(Products & Services) 정리해보았다.
지금까지는 어쩌면 '기능 확정'이라는 의미에서 기존 VP-CS 캔버스와 큰 차이가 없다고 볼 수도 있겠다. 하지만 초기의 VP-CS 캔버스와는 달리 이번에는 '학교 팀플 과제'라는 특수한 상황의 타겟을 미리 설정해 각각의 맵 항목을 더 명확하게 채워 넣을 수 있었다.
VP-CS 캔버스를 바탕으로 확장시킨 타겟 고객군캔버스의 각각의 항목이 명료하니, 다음 단계인 타겟의 확장 역시 비교적 수월했다. '디자인 팀플 과제의 아이디에이션을 막 시작한 팀'이라는 타겟 군에서 비롯된 가치 제안 맵을 바탕으로, 중요도가 높다고 판단된 Pains 및 Gains를 또 어느 고객군이 겪을 법한지, 또 우리가 정의한 기능(Products & Services)이 어떤 사람들에게 유용할지 고민해보았다. 이를 바탕으로 타겟을 '학교 팀플 과제'를 위한 팀과 '스타트업 및 창업'을 위한 팀, 두 개의 군으로 분류해보았다.
2. 타겟 관련 가설 수립해 인터뷰 진행하기
VP-CS 캔버스에서 정리한 기능 내용과 이를 바탕으로 한 세 가지 가설타겟에 대한 검증을 위해 VP-CS 캔버스의 가치 제안 맵 내용을 바탕으로 세 가지 주요 가설을 설정해보았다. 아래의 가설 프레임워크를 활용해 각각의 가설마다 세 단계로 나누어 이를 세밀하게 검증하고자 했다.
n-1. 고객 요구 상황: ~은 ~한 상황에 처한다 / ~한 행동을 한다.
n-2. 불편사항: 왜냐하면 ~이기 때문이다.
n-3. 기대효과: 그러므로 ~할 것이다.
세 가지 가설을 모두 검증할 수 있다면 더없이 좋겠지만, 시간 관계상 일단 2번 가설인 '팀플에 참여하는 팀원들은 상대방의 의견에 피드백하는 것을 어렵게 느낀다'를 검증해보기로 결정했다. 2번 가설을 고른 것은 STORM의 핵심 가치인 '중심, 소통, 공유'에 가장 부합한다고 판단했기 때문이다.
인터뷰를 통해 검증하고자 하는 주요 가설 (2번 가설)가설 검증을 위해서는 위에서 CS-VP 캔버스를 통해 설정한 두 개의 타겟 군, '학교 팀플 과제'를 위한 팀/팀원과 '스타트업 및 창업'을 위한 팀/팀원을 각각 인터뷰하기로 했다. 미리 준비한 질문지를 바탕으로 함께 가설 검증을 진행하던 친구와 함께 해당 타겟 군에 속해있는 사람들 총 6명을 이틀에 걸쳐 인터뷰하였다.
인터뷰 질문지는 '문제의식', '고객 행동', '해결방안' 세 가지 주제로 나누어 구성했다. '문제의식'과 관련해서는 아이디어 회의 중의 문제가 무엇이고, 그 문제에 대해 어떻게, 혹은 언제 느끼는지 등을 물어보았다. '고객 행동'과 관련해서는 그러한 상황에서 왜 그렇게 행동했는지, 얼마나 자주 그 행동을 하는지, 또 그 행동을 할 때 가장 힘든 것은 무엇인지 등의 질문을 준비했다. 마지막으로 '해결방안'과 관련해서는 문제 해결의 필요성이나 가능성, 그리고 현재 해결 방법에 대한 만족도 등을 물어보았다.
가설 검증을 위한 인터뷰 질문지타겟을 검증하기 위한 인터뷰인 만큼, 기획 초기에 진행한 인터뷰와 다소 다른 방식으로 진행했다. 기획 초기에는 따로 세세하게 인터뷰 질문지를 준비하지 않았다. 아이디어 발산(divergence) 단계인 기획 초기에는 문제의식만 희미하게 있었고, 문제점에 대한 인사이트를 인터뷰를 통해 도출함으로써 가설을 발전시켰기 때문이다. 어떠한 가설이나 문제점을 증명하기 위한 것이 아니라, 다양한 배경의 사람들과 인터뷰를 진행하며 그들의 경험과 관련해 자유롭게 물어보고 그 안에서 공통적인 인사이트를 도출해내고자 했기에 질문에 대한 큰 그림만 그린 채로 인터뷰를 진행했었다.
반면, 타겟의 유효성을 검증하기 위한 이번 인터뷰를 진행하기 위해서는 위와 같이 세부적인 인터뷰 질문지가 필요했다. 미리 가설을 '고객 요구 상황', '불편사항', '기대효과' 세 단계로 나누어 정리해둔 덕에 인터뷰 질문도 명료하게 세 단계로 나누어 준비할 수 있었다.
3. 인터뷰 결과를 바탕으로 가설 검증하기
결론부터 얘기하자면, 인터뷰 결과는 굉장히 흥미로웠다. 준비한 2, 3단계의 가설이 모두 기각되었기 때문이다.
우선 주요 가설의 1단계인 '팀플에 참여하는 팀원들은 상대방의 의견에 피드백하는 것을 어렵게 느낀다'는 유효하다고 판단되었다. 인터뷰 결과, 다양한 이유로 인해 사람들은 다른 팀원들의 아이디어에 피드백을 제시하는 것을 어렵게 느낀다고 답하였기 때문이다.
두 가지 타겟 군을 인터뷰한 만큼 2, 3단계 가설 또한 두 갈래로 나누어 검증하였다. 먼저, '학교 팀플 과제' 경험이 있는 타겟을 바탕으로 한 인터뷰 결과, '과제'라는 특성상 하기 싫어도, 혹은 관심 없는 주제여도 강제로 프로젝트를 수행해야 한다는 '학교 팀플 과제' 타겟 군만의 특징이 있었다. 아이디어의 발전에 관심을 갖고 피드백을 적극적으로 하기 위해 노력하기보다, 또래 팀원들과의 감정적 요인이나 성적 등 외부적인 요인에 더 영향을 받는다는 점을 인터뷰를 통해 파악할 수 있었다. 이러한 점으로 미루어보아, '상대방의 의견에 대해 충분히 검토하지 못한 채로 자신의 생각을 말하는 것을 어려워한다'는 2단계 가설은 '학교 팀플 과제' 타겟 군 안에서 기각되었고, 그에 따라 3단계의 가설 역시 기각되었다.
이에 '이익/매출'이라는 공동의 목표를 두고 적극적으로 회의에 참여해야 하는 '스타트업/창업' 타겟 군을 좀 더 집중적으로 인터뷰하게 되었다. 하지만 인터뷰 결과, 다양한 직책/업무/전문 분야에 종사하고 있는 팀원들이 모여 발생하는 '피드백 회피 현상'을 관찰할 수 있었다. 다른 분야에 대한 본인의 이해도가 낮음으로 인해 아이디어를 자유롭게 제안하기를 우려한다는 뜻이다. 또, 최대한 빠르게 이익을 창출해야 하는 수익성 목적을 띄는 타겟이다 보니, 아이디어의 다양성을 존중해 피드백을 무조건 많이 하는 것보다는 짧은 회의 시간 안에 효율적으로 유의미한 결론을 내는 것이 더 중요하다는 점을 파악할 수 있었다. 이를 통해, '스타트업/창업' 타겟 군에서도 상대방의 의견에 대해 충분히 검토하지 못해 피드백이 잘 이루어지지 않는 것이 아니라는 것이 밝혀져 가설 2단계는 기각되었다.
인터뷰를 통해 도출된 인사이트 요약희망적인 점은, 준비한 가설이 각각의 타겟 군에서 기각된 이유가 명확하다는 것이다. '학교 팀플 과제' 팀에서는 '강제성'이라는 변수가 있었고, '스타트업/창업' 팀에서는 '효율성'이 더 우선시되었다. 그렇다면, STORM의 브레인스토밍 및 의견 교류 기능에만 집중한다면, '강제성'이나 '효율성' 등이 배제된 회의에서는 유용하게 쓰일 수 있을 것이라는 새로운 가설이 세워지게 된다. 이를 바탕으로 세 번째 잠재 타겟 군을 도출할 수 있었는데, 바로 '브레인스토밍 및 협업 관련 교육 및 워크샵을 진행하는 기관/참여자'이다.
인터뷰를 바탕으로 정리 및 추가하게 된 타겟 고객군참 흥미로운 과정이었다. 당연한 수순이지만, 검증 과정에서 가설이 기각됨으로 새로운 가설이 도출되었다는 점이 상당히 흥미로웠다.
정리하자면 – 기획 초기에는 young creator team이라는 대분류 아래에 회의 상황을 기준으로 타겟을 나누었다. 아이디어 결정이 어려운 팀, 회의를 이제 막 시작한 팀 등 상황을 기준으로 하다 보니, 각 상황마다의 문제점을 가설로 정의하기가 꽤나 어려웠다. 이에 초기 기획안의 불씨였던 세 가지 문제의식인 '아이디어의 제한', '팀원 소통의 한계', '회의 방식의 비정형화'를 기정 사실화해둔 채 기능 발전에 집중했었다.
타겟을 재차 점검하기 위해 이번에는 VP-CS 캔버스를 통해 STORM의 기능이 유효한지 점검해보았고, 이를 바탕으로 타겟 군과 가설을 1차적으로 설정하였다. 이렇게 세워진 가설을 각각의 타겟 군에 해당하는 사람들을 인터뷰함으로써 유효한지, 혹은 기각인지 파악할 수 있었고, 이러한 판단을 바탕으로 다음 단계에서 검증해야 할 새로운 가설을 세울 수 있었다.
그간의 가설 검증 과정에서 한 가지 아쉬운 점이 있다면, 기획 초기나 지금이나 타겟 군이 여전히 전체 보완적/포괄적이지 않다는 것이다. (컨설팅 업계에서는 이를 MECE하지 않다고 한다지.) 훨씬 더 심도 있는 고민이 필요하겠지만, 회의 상황(기존)이나 팀/조직의 특징(현재)을 기준으로 타겟을 분류하기보다는, 회의가 추구하는 방향이나 회의 단계를 기준으로 삼아 타겟 군을 설정해 가설을 세워 검증하는 것이 더 바람직하지 않을까 하는 생각이 든다.
이번 과정을 통해 그토록 어렵게 느껴지던 타겟 정의의 과정을 어렴풋이나마 이해할 수 있었다. 또 가설을 세우는 것은 물론이거니와, 가설을 검증하는 과정에서 확인해야 할 것이 굉장히 많다는 점을 체감했다. 가설에 해당하는 타겟 군, 가설을 확인하기 위한 인터뷰 질문, 그리고 인터뷰이의 답변에서 도출해야 하는 인사이트까지.
글을 어떻게 끝맺어야 할지 모르겠는데, 아무튼 중요한 건 가설이다. 처음 기획을 시작하면서, 혹은 기획안을 다져가는 과정에서 어느 순간 감이 잡히지 않는다면, 더더욱 가설은 놓치지 말아야 한다. 중요한 건 가설이다!
