01. <가설 검증> 산에 가지 않고 등산러의 목소리를 듣는 법

새로운 서비스를 만드는 과정은 다양하지만, 그 출발은 크게 두가지로 요약될 것 같습니다.

• 태초에 '아이템'이 정해지는 경우

• 태초에 '팀'이 정해지는 경우

저희는 후자였습니다. 삽은 있지만 어디를 파야할지 모르는 5명이 모여, 아이템을 선정하고 이에 대한 가설을 여러가지 방법으로 검증하면서 프로덕의 정의를 엣지있게 다듬어갔습니다. 그 과정에서 탄탄해진 논리와 확고해진 프로덕 정의는 이후에 저희가 프로덕을 제작하는 과정에서 흔들리지 않게 도와주는 기둥이 되었습니다.

본편에서는 그 과정을 요약해보려 합니다. 지금 '서비스를 만들고 싶은데, 무슨 서비스를 만들어야 할지 모르겠다'며 고민하시는 분들께 조금이나마 도움이 되길 바랍니다.

1. 아이템 선정

2. 가설 수립 - 핵심문제와 솔루션(제품) 정의

3. 가설 검증 - 리서치 & 인터뷰

4. PRD(제품요구사항정의서) 완성

1. 아이템 선정

우선 저희는 머리 속에서 생각나는 아이템을 한데 모았지만, 'good to have'가 아닌 'must have'에 집중하고자 했습니다. 단순 재미보다는 확실한 unmet needs를 찾고자 했고, 이에 대한 솔루션까지 고안해내야 하나의 아이템으로 제안할 수 있었습니다. 무에서 유를 창조하는 과정인만큼 ... 일과 삶이 분리될 수 없는 한주를 보냈습니다 🤯

그리고 나서 저희는 논리성/WOW/구현가능성/파급력의 기준에 따라 각자 점수를 책정하였고, 이에 대한 총점으로 최종 아이템을 선정하였습니다. 아이디어를 발산할 때는 보이지 않던 좋은 아이템들을 냉철한 판단과정을 통해 선별되었습니다.

2. 가설 수립 - 핵심문제와 솔루션(제품) 정의

아이템이 결정되고 나선, 이에 대한 뾰족한 가설을 수립하였습니다.

등산객들이 겪는 고충은 무엇일까? 그리고 그 고충을 겪는 등산객은 어떤 특징을 가질까? 를 정의하기 위해 '등산하기 전부터 등산한 후'까지의 User Story를 따라가며, unmet needs와 이를 해결할 수 있는 기능을 정리하였습니다.

결과적으로 저희는 아래와 같은 문제 가설과 솔루션 가설을 수립하게 되었습니다. 그리고 이러한 문제를 겪는 등산객은 아예 등산초보는 아니고, '일년에 3-4번 정도 산을 찾아 왕복 3-4시간 정도 등산을 즐기고 싶은 2030 등산객'일 것이라고 정의하였습니다.

3. 가설 검증 - 리서치 & 인터뷰

하지만 지금까지 수립한 가설은 모두 저희의 '뇌피셜'일 뿐. 이에 대한 정성적, 정량적 근거가 부족했습니다. 이는 저희 또한 가설에 대한 확신이 없었다는 것을 의미합니다. 가설에 대한 물음표를 느낌표로 바꿀 근거를 찾기 위해 저희는 다양한 수단을 동원했습니다.

1) 정성적 근거 - 유저 인터뷰

• 유저 인터뷰에서 저희는 스스로 뇌피셜로 그려본 User Story를 따라 질문하면서, unmet needs를 실제로도 느끼고 있는지 확인하였습니다. 그 결과 저희는 문제 가설을 더욱 뾰족하게 다듬을 수 있었습니다.

• 등산코스 추천 - 코스 추천에 대한 니즈는 있으며, 현재 코스를 선택하는 기준은 난이도, 포토스팟, 지역 등이 있다.

• 등산정보 종합제공 - 정보를 모아서 보여줄 필요는 없다. (어차피 네이버 블로그도 볼 것 같다) 하지만 보여준다면 '반드시 알아야 하는 정보 (운영시간, 주차장 운영 여부, 축제기간 등)'를 알려주면 좋겠다.

2. 정량적 근거 - 유저 리서치 & 데스크 리서치

• 또한 등산 커뮤니티, 개발자 커뮤니티에 유저 리서치를 배포하고, 데스크 리서치를 진행하였습니다. 그 결과 저희는 타겟팅하는 등산객의 비중이 얼마나 되는지 확인하고, unmet needs에 대한 수요도 확인하여 이 프로덕트의 필요성을 뒷받침할 수 있었습니다.

  

• 또한 이 과정에서 전체 시장규모를 파악하여, 저희의 단기/중장기적 Roadmap을 수립할 수 있었습니다. 처음에는 이 숫자들이 과연 의미가 있을까 하며 터무니 없다는 생각도 했지만, 결국 팀원 모두가 동일한 목표를 공유할 수 있었다는 점에서 반드시 필요한 과정이었던 것 같습니다.

  

• 마지막으로, 이를 통해 유사한 경쟁 서비스의 장/단점과 운영현황도 파악하여, 서비스의 본보기로 삼을 수 있었습니다.

4. PRD(제품요구사항정의서) 정리

위에서 리서치와 인터뷰를 통해 문제 가설에 대한 근거를 확보하였다면, 이제는 이를 해결할 수 있는 솔루션을 기깔나게 정리할 차례입니다. 간지러운 곳을 찾았는데, 엉뚱한 곳을 긁어주면 안되니까요.

저희는 제품을 정의하면서, 확실하게 문제 가설을 해결할 수 있는지에 집중하였습니다. 그러면서 필요한 기능들을 우선 나열하였습니다. 어차피, 나중에 기획/개발 단계에서 증발될 것이므로, 이 단계에서는 우리가 정의한 문제 가설을 해결하기 위해 필요한 기능들을 모두 정의하였습니다. 즉, 최종적으로 우리의 프로덕트가 그리는 이상향을 그려내었습니다.

지금 와서 보니, 기능이 많이 다르지는 않지만 몇몇 기능들은 흔적도 없이 증발되었네요. 제대로 정의한 요구사항정의서는 이후에 프로덕에서 중요한 기능을 선별하기 위한 후보군을 제공하고, 이후 개선단계에서도 방향성을 제시하는 것 같습니다.

이렇게 정의된 제품이 어떻게 구현되었는지는, 다음주에 계속됩니다!