minimum 아니고 maximum viable product를 기획해버린 건에 대하여
앱 경험이라곤 1도 없는 마케터에게 네이티브 앱 개발은 정말 버거운 일이었습니다. 약 1년 동안 글쓰기 데이팅앱, write을 만들면서 부딪힌 문제를 하나하나 해결하다 보니 앱 런칭까지 달성했는데요. 제가 마주했던 문제해결의 경험이 누군가에게는 큰 도움이 될 수 있겠다는 생각이 들어 앱 개발 과정에서의 ‘문제해결’ 경험을 시리즈로 남겨보려고 합니다.
문제: MVP(Minimum Viable Product)라고 부르기엔 기능이 너무 많다.
write은 MVP로 필요한 기능만을 가지고 빠르게 출시하는 것이 목표였습니다. 개발팀이 있는 것도 아니고 제가 프리랜서 개발자 한 명을 고용해서 개발할 계획이었기에 어쩌면 당연한 결정이었는데요. 문제는 막상 개발을 시작하고 보니 기획안에 들어 있는 기능이 너무 많다는 것이었습니다.
write에는 1.0버전부터 지인 차단, 맞춤 추천, 각종 알림 ON/OFF 토글과 맞춤법 검사기 기능이 모두 들어가도록 기획되어 있었습니다. 물론 대부분의 기능들이 ‘글쓰기’서비스를 표방하는 데이팅앱에 있다면 좋은 기능들이었지만 이 모든 기능을 한 명이 개발하려면 너무 많은 시간이 소요되고 당연히 비용도 늘어날 수밖에 없는 상황이었어요.
*기획안에 있었던 맞춤법 검사기, 1.0에서는 개발되지 않았다.
이유: 레퍼런스를 참고하다 보니 레퍼런스에 있는 기능을 전부 때려 넣었다.
왜 이런 일이 발생했을까? 곰곰이 생각해 봤습니다. 답은 ‘레퍼런스’에 있더라고요. 저는 write을 기획하며 정말 다양한 데이팅앱과 SNS, 글쓰기 앱을 참고했어요. 그중에 제가 볼 때 좋다고 생각되는 기능들을 하나하나 기획안에 추가하다 보니 어느새 write은 “최소 요건 제품”이 아니라 “최대 요건 제품”이 되어 있었습니다.
*레퍼런스로 참고한 다양한 앱들
해결: 핵심 가설검증에 필요한 기능을 제외하고는 개발하지 않는다.
이미 기획안을 바탕으로 한 디자인은 나와있는 상태였어요. 그래서 개발 단계에서 ‘핵심 가설검증’에 필요한 기능이 아니라면 1.0버전에 넣지 않기로 결정했습니다. 즉 ‘글쓰기 만을 통해서도 사람들이 매칭될 수 있을까?’라는 핵심 가설을 검증하는데 필수적인 기능이 아니라면 개발하지 않았습니다.
디자인에서 제외하기 힘들거나 추후에 개발할 계획인 기능들은 개발 단계에서 보이지 않도록 디자인 요소를 숨기거나 고객이 클릭하면 ‘준비중인 기능입니다!’라는 시스템 배너를 띄우는 것으로 해결했습니다.
*개발되지 않은 기능들은 숨기거나 개발 예정이라는 것을 알리는 팝업을 넣었다.
MVP는 핵심 가설 검증에 맞춰서 기획하자
write의 개발과정을 거치면서 MVP라는 개념에 대해서 다시 고민해 볼 수 있는 기회가 되었어요. 이전까지는 대부분 개선 과정에 있는 제품이나 서비스의 마케터로만 일했다 보니 MVP라는 용어를 피상적으로 알고 있었더라고요. MVP를 기획할 때는 핵심 가설 1개나 2개가 검증될 수 있는 수준의 기능만 들어가도록 기획되어야 시간과 비용을 줄일 수 있다고 생각합니다.
수많은 문제해결의 결과인 글쓰기 데이팅앱, write에서 매력적인 글들을 만나보세요! ✍️
아래 링크에서 iOS/AOS 모두 다운로드하실 수 있어요!
글쓰기에 진심인 사람들을 위한 데이팅 서비스 ✍️
댓글
로그인 후 댓글을 남길 수 있습니다.
아직 댓글이 없습니다.