앱 경험이라곤 1도 없는 마케터에게 네이티브 앱 개발은 정말 버거운 일이었습니다. 약 1년 동안 글쓰기 데이팅앱, write을 만들면서 부딪힌 문제를 하나하나 해결하다 보니 앱 런칭까지 달성했는데요. 제가 마주했던 문제해결의 경험이 누군가에게는 큰 도움이 될 수 있겠다는 생각이 들어 앱 개발 과정에서의 ‘문제해결’ 경험을 시리즈로 남겨보려고 합니다.

• 시리즈1. 앱 기획에서 빼먹으면 안 되는 작고 소중한 것들
• 시리즈2. minimum 아니고 maximum viable product를 기획해버린 건에 대하여

문제: MVP(Minimum Viable Product)라고 부르기엔 기능이 너무 많다.

write은 MVP로 필요한 기능만을 가지고 빠르게 출시하는 것이 목표였습니다. 개발팀이 있는 것도 아니고 제가 프리랜서 개발자 한 명을 고용해서 개발할 계획이었기에 어쩌면 당연한 결정이었는데요. 문제는 막상 개발을 시작하고 보니 기획안에 들어 있는 기능이 너무 많다는 것이었습니다.

write에는 1.0버전부터 지인 차단, 맞춤 추천, 각종 알림 ON/OFF 토글과 맞춤법 검사기 기능이 모두 들어가도록 기획되어 있었습니다. 물론 대부분의 기능들이 ‘글쓰기’서비스를 표방하는 데이팅앱에 있다면 좋은 기능들이었지만 이 모든 기능을 한 명이 개발하려면 너무 많은 시간이 소요되고 당연히 비용도 늘어날 수밖에 없는 상황이었어요.

이유: 레퍼런스를 참고하다 보니 레퍼런스에 있는 기능을 전부 때려 넣었다.

왜 이런 일이 발생했을까? 곰곰이 생각해 봤습니다. 답은 ‘레퍼런스’에 있더라고요. 저는 write을 기획하며 정말 다양한 데이팅앱과 SNS, 글쓰기 앱을 참고했어요. 그중에 제가 볼 때 좋다고 생각되는 기능들을 하나하나 기획안에 추가하다 보니 어느새 write은 “최소 요건 제품”이 아니라 “최대 요건 제품”이 되어 있었습니다.

해결: 핵심 가설검증에 필요한 기능을 제외하고는 개발하지 않는다.

이미 기획안을 바탕으로 한 디자인은 나와있는 상태였어요. 그래서 개발 단계에서 ‘핵심 가설검증’에 필요한 기능이 아니라면 1.0버전에 넣지 않기로 결정했습니다. 즉 ‘글쓰기 만을 통해서도 사람들이 매칭될 수 있을까?’라는 핵심 가설을 검증하는데 필수적인 기능이 아니라면 개발하지 않았습니다.

디자인에서 제외하기 힘들거나 추후에 개발할 계획인 기능들은 개발 단계에서 보이지 않도록 디자인 요소를 숨기거나 고객이 클릭하면 ‘준비중인 기능입니다!’라는 시스템 배너를 띄우는 것으로 해결했습니다.

MVP는 핵심 가설 검증에 맞춰서 기획하자

write의 개발과정을 거치면서 MVP라는 개념에 대해서 다시 고민해 볼 수 있는 기회가 되었어요. 이전까지는 대부분 개선 과정에 있는 제품이나 서비스의 마케터로만 일했다 보니 MVP라는 용어를 피상적으로 알고 있었더라고요. MVP를 기획할 때는 핵심 가설 1개나 2개가 검증될 수 있는 수준의 기능만 들어가도록 기획되어야 시간과 비용을 줄일 수 있다고 생각합니다.

수많은 문제해결의 결과인 글쓰기 데이팅앱, write에서 매력적인 글들을 만나보세요! ✍️

→ write 앱 다운로드

→ write 사이트 구경하기