밋썸데이 2022. 4. 10. 21:09
728x90

2주 만에 앱을 출시하다! - 그 출발점

거인일기라는 아이템을 생각해내고, 2주 만에 앱을 출시하게 되었습니다.

 

왜 거인의 일기인가

불편한 순간 「타이탄의 도구들」​ 책을 읽으면서 일기의 중요성에 대해 깨닫게 되었고, 이를 몸소 실천하기로 했습니다. 그러나 요즘 세상에 살면서 좀처럼 느끼기 힘든 '불편한 순간'을 경험

meetsomeday.tistory.com

 

둘 다 The Lean startup이라는 책을 읽었기 때문에, 어떻게 방향을 정하고 나아갈지에 대한 것들이 꽤 명확했습니다. 우리가 계획했던 출시 계획은 다음과 같습니다.

 

린 스타트업

1부 비전 스타트업은 극심한 불확실성 속에서 신규 제품이나 서비스를 만드려는 조직이며, '세상을 바꿀 만한 사업을 일으킨다'는 비전을 가지고 있습니다. 모든 스타트업은 그 비전을 바탕으

meetsomeday.tistory.com

 

  1. 시장에 검증하고자 하는 가설을 세운다
  2. 제품을 빠른 속도로 만든다
  3. 데이터를 분석하여 가설을 검증한다
  4. 검증한 가설을 통해 학습한 지식들을 토대로 새로운 방향을 찾는다

MVP 전략 @cliche-cliche

 

MVP가 검증하고자 했던 가설

 

「타이탄의 도구들」 아침 일기처럼 일관된 서식의 일기를 쓰는 고객들은 템플릿 기능을 필요로 할 것이다

 

우리의 MVP가 검증하고자 하는 가설입니다. 이 가설은 어떻게 검증해볼 수 있을까요?

 

플레이 스토어는 기본적으로 전체 사용자 공개 노출이기 때문에 우리가 목적하는 타겟층이 아닙니다. 따라서 정확한 고객층을 타깃 하기 전까지의 지표는 가설 검증에 있어서 의미가 없다고 생각했습니다.

 

타이탄의 도구들을 최근에 읽거나 검색한 사용자에게 마케팅(인스타그램, 블로그)했을 때 반응하는 지표들(주간 다운로드 등)을 보고서 검증할 수 있을 것으로 기대하고 있습니다.

 

 

MVP가 아닌 스펙을 만들지 않으려 노력하다

 

검증하고자 하는 가설을 정했기 때문에 곧바로 제품 개발에 들어갔습니다. 그것이 Lean 한 움직임이라고 생각했기 때문입니다. 그러나 Flutter를 거의 처음 해봐서그런지 아무 기능도 없이 간단해 보이는 MVP를 만드는 데 거의 1주일을 쓴 것 같습니다.

개발 중에는 꼭 필요한 기능을 만드는 데 집중하기 보다, 가설 검증에 필요 없는 기능들을 붙이지 않으려 노력했습니다. 최대한 빠르게 출시를 하기 위해서입니다.

 

'의도적으로 만들지 않은' 기능들은 다음과 같습니다. 가설 검증에 도움이 되지 않는다고 판단했기 때문에 제외했습니다.

  • 클라우드 데이터 백업
  • 인증(회원 가입 / 로그인 / 로그 아웃)
  • 테마, 폰트, 글씨 두께, 사진 업로드 기능
  • 사용자 데이터 분석 프레임 워크 도입

 

특히 사용자 데이터 분석 프레임워크는 고객의 데이터를 수집할 수 있다는 점에서 처음에는 포함해야 할 기능이라고 생각했으나, 시장 반응은 다운로드 수만 가지고도 파악할 수 있다는 진아의 의견에 공감했습니다.

 

진아가 뚝딱 만들어준 앱 로고.생각보다 잘 만들어서 놀랐었다.

 

'굳이' MVP에 포함시켰던 기능들

 

  • 예쁜 시스템 폰트 적용
  • 다크모드 전환
  • 의견 보내기

 

이 기능들은 공수가 적기 때문에 MVP에 포함시켰습니다. 기껏해야 30분이면 추가할 수 있는 기능들입니다. 황무지처럼 앱에 아무것도 없는 것보단 있는 게 낫다고 판단했습니다.

 

특히 다크모드 전환 기능은 플레이 스토어 스크린 샷 중 하나를 꿰차고 있기 때문에 만들길 잘했다고 생각하고 있습니다.

 

거인일기 스크린샷, 그래픽 이미지 만들기

태어나서 처음으로 디자인을 해봤기에 쉽지 않았습니다.. UX/UI 디자인 툴은 Figma를 사용하였는데, 가장 최신 프로그램이기도 하고 웹 기반으로 가볍게 돌릴 수 있어서 선택하게 되었습니다. 빈

meetsomeday.tistory.com

 

또, 지금은 고객의 소리를 듣는 것이 가장 중요한 단계이기 때문에 '의견 보내기' 기능을 넣었습니다.

 

다크모드 전환 & 의견 보내기 기능

 

어디까지 만들어야 가설을 검증할 수 있는거지?

 

모든 과정이 다 순조로웠던 것은 아닙니다.

일단 둘 다 디자인에 소질과 경험이 없었기 때문에 참 막막했습니다. 그냥 개발하기 편한대로 막 만든 것 같습니다.

 

또, 우리 둘 다 MVP에 대한 명확한 이해가 없었습니다. '이건 만들어야 하는 기능이다/그렇지 않다'와 같은 소모적인 논의에 시간을 뺏겼습니다. 무엇보다 '어디까지 만들어야 가설을 검증할 수 있다고 할 수 있는가'에 대해 서로의 의견이 달랐습니다.

 

한참 논의 끝에 얻었던 결론은 '알 수 없다'였습니다. 맞습니다. 시장에 출시하기 전까지 시장 반응도 알 수 없고, 따라서 검증도 할 수 없습니다. 하지만 귀결점은 있었습니다. 바로 '제품을 만드는 사람들이 모두 동의할 수 있는 제품의 스펙이 바로 MVP다' 라는 것입니다.

 

드디어 거인일기 출시! (지금은 앱 심사중)

 

번외이지만, Apple app store 에는 출시하지 않았습니다. 구글 플레이 스토어에 올려놓는 것만으로 진이 다 빠져버렸을뿐더러, 애플 개발자 등록 비용이 꽤 비쌌기 때문입니다. 시장 반응이 나오면 그때 출시를 준비하기로 했습니다. 그러나 이게 맞는 방향인지에 대한 확신은 없네요.


다음 단계에 대한 고민

 

비즈니스 모델에 대한 고민을 크게 하지 않았다는 것을 나중에서야 깨달았습니다. 이 부분은 다른 일기 앱들의 BM을 비교 분석하면서 저희만의 방법을 찾게 될 것 같습니다. 타깃 하는 고객층이 국소적이기 때문에 다른 일기 앱들과 동일한 BM은 잘 동작하지 않을 것 같다는 생각입니다.

 

가설 검증 결과 '아침 일기를 쓰는 고객들은 템플릿 기능이 필요가 없었다' 고 밝혀지게 되었을 때의 pivot 전략도 미리 세워 두었습니다. 저희들은 저희와 같은 생각을 하며 사는 사람들(소위 말이 통하는 사람들)과의 소통에 갈증을 느끼고 있습니다. 스승을 찾아 많이 배우거나 동료를 찾아 같이 성장하고 싶습니다. 그러나 좀처럼 그런 사람들을 주변에서 찾기가 힘듭니다. 전략은 '시장에서도 그런 니즈가 있는가'에 관한 가설을 검증하는 것입니다.