1. MVP는 ‘기능이 적은 서비스’가 아닙니다.
MVP를 최소 기능 제품이라고 번역하다 보니 기능 수를 줄이는 데만 집중하기 쉽습니다. 하지만 로그인, 알림, 관리자, 통계 기능을 몇 개 뺐다고 자동으로 좋은 MVP가 되는 것은 아닙니다.
따라서 먼저 “사용자가 이 문제를 실제로 느끼는가?”, “우리가 제안하는 해결방식을 사용할 것인가?”, “사용 후 다시 찾거나 비용을 지불할 가능성이 있는가?”처럼 확인할 질문을 정해야 합니다.
2. 기능 목록보다 먼저 4가지를 정하세요.
첫 번째 사용자를 구체적으로 정합니다.
사용자가 실제로 해결하려는 핵심 문제를 정의합니다.
신청·예약·구매·작성 등 핵심 행동을 정합니다.
사용·재방문·문의·결제 등 확인할 신호를 정합니다.
3. 기능을 세 단계로 나눠보세요.
검증에 반드시 필요
이 기능이 없으면 사용자가 핵심 가치를 경험하거나 가설을 검증할 수 없는 기능입니다.
검증 후 추가
필요성은 예상되지만 실제 사용자 반응을 확인한 뒤 만들어도 되는 기능입니다.
운영 규모 이후
자동화·고급 통계·세부 편의기능처럼 사용량과 운영규모가 커진 뒤 가치가 생기는 기능입니다.
4. 기능 하나마다 이 질문을 해보세요.
| 질문 | YES라면 | NO라면 |
|---|---|---|
| 이 기능이 없으면 핵심 사용자 흐름이 끊기는가? | MUST 가능성 높음 | 다음 단계 검토 |
| 이 기능으로 검증하려는 가설이 명확한가? | 검증 지표와 함께 유지 | 개발 목적 재검토 |
| 사용자가 직접 사용해야만 검증할 수 있는가? | 제품 구현 필요성 높음 | 수작업·대체방식 검토 |
| 사용자가 없어도 운영 편의를 위해 필요한 기능인가? | 최소 수준만 검토 | 후순위 가능 |
| “나중에 필요할 것 같다”가 주된 이유인가? | 우선순위 재검토 | 현재 필요성에 집중 |
5. 20개 기능을 그대로 만들 필요는 없습니다.
예를 들어 전문가 상담을 연결하는 서비스를 검증한다고 가정해보겠습니다.
회원가입 · 소셜로그인 · 전문가 검색 · 추천 · 예약 · 결제 · 채팅 · 알림 · 리뷰 · 쿠폰 · 포인트 · 관리자 통계 등 20개 기능
전문가 확인 → 상담 요청 → 일정 확정 → 상담 진행 → 사용 후 반응 확인. 나머지는 초기에는 운영자가 수작업으로 보완할 수도 있습니다.
이 단계의 목적은 완성된 플랫폼을 증명하는 것이 아니라 사용자가 실제로 전문가를 찾고 상담을 요청하는지 확인하는 것입니다.
6. 개발을 시작하기 전 체크리스트
MVP는 작은 완성품이 아니라 가설을 검증하기 위한 제품입니다.
“서비스라면 당연히 있어야 하는 기능”을 모두 만드는 대신, 이번 단계에서 반드시 확인해야 할 사용자 행동과 가설을 기준으로 개발 범위를 정하세요.