IDEA VALIDATION
웹서비스 아이디어를 검증하는 가장 작은 방법: 고객 행동 하나를 먼저 만들기
좋은 MVP는 많은 기능을 빨리 쌓는 일이 아니라, 누가 어떤 이유로 다음 행동을 하는지 확인하는 일이다. 첫 웹앱은 이 확인을 위한 가장 작은 운영 화면이어야 한다.
아이디어를 설명할 때 기능부터 나열하면 범위가 급격히 커진다. “로그인, 결제, 알림, 관리자, 커뮤니티”는 모두 필요해 보이지만, 처음 확인할 질문은 하나면 충분하다. 이 서비스가 생기면 누가 어떤 행동을 더 쉽게 하는가?
첫 MVP의 목표는 완성도가 아니라 행동의 증거다. 고객이 신청하는지, 견적을 남기는지, 결제 의사를 보이는지, 다시 들어오는지 확인할 수 있어야 한다.
기능 목록보다 먼저 정할 다섯 가지
사용자누구의 어떤 상황을 위한 서비스인가.
계기사용자는 언제 이 문제를 해결하려 하는가.
한 번의 행동신청, 저장, 문의, 결제 중 무엇을 확인할 것인가.
받는 결과사용자는 행동 뒤 무엇을 얻는가.
운영 신호운영자는 어떤 데이터로 다음 개선을 결정하는가.
제외 범위첫 버전에서 의도적으로 만들지 않을 것은 무엇인가.
한 문장으로 서비스의 첫 흐름 만들기
문장을 다음 형태로 적어본다.
“[사용자]가 [상황]에서 [입력 또는 선택]을 하면, [즉시 얻는 결과]를 받고, 운영자는 [확인할 정보]를 본다.”
예를 들어, “독립 출판을 준비하는 크리에이터가 판매할 PDF를 등록하면, 고객은 미리보기와 결제를 거쳐 구매하고, 판매자는 주문과 다운로드 현황을 본다”가 된다. 이 한 문장만으로도 상품 화면, 장바구니, 테스트 결제, 구매 내역, 운영 화면의 우선순위를 정할 수 있다.
첫 웹앱에서 확인할 신호
아이디어 검증은 방문자 수만 보는 일이 아니다. 다음 중 하나를 정해 관찰하면 된다.
- 잠재 고객이 자신의 정보를 남기는가.
- 옵션을 고르고 신청 또는 구매까지 진행하는가.
- 운영자가 그 요청을 처리할 수 있는 정보가 남는가.
- 한 번 사용한 뒤 다시 들어오거나, 다음 개선을 요청하는가.
작은 운영이 다음 제품을 만든다
첫 웹앱을 공개한 뒤에는 사용자의 질문, 막히는 지점, 반복되는 요청을 기록한다. 이 기록은 다음 화면을 위한 요구사항이 된다. 같은 요청이 여러 번 반복되면 그때가 자동화하거나 별도 기능으로 만드는 시점이다. 처음부터 모든 흐름을 예측하기보다, 실제 사용을 통해 우선순위를 얻는 편이 빠르고 안전하다.