최소 기능 제품 (MVP)

가장 흔한 MVP 실수는 MVP를 범위 결정이 아닌 품질의 정의로 취급하는 것입니다. 즉, 버그가 많고 거의 작동하지 않는 버전을 출시하고 이를 MVP라고 부르는 것입니다. MVP의 'Minimum Viable'은 최소한의 기능 범위를 의미하며, 최소한의 품질을 의미하지 않습니다. MVP는 프로덕션 품질이어야 하며 좁은 약속을 완전히 이행해야 합니다. 단지 전체 비전보다 작은 약속을 하는 것뿐입니다. 더 나은 사고 모델은 스티브 블랭크(Steve Blank)의 정의입니다. MVP는 특정 고객 세그먼트가 특정 문제를 해결하기 위해 비용을 지불할 최소한의 기능 세트입니다. 에릭 리스(Eric Ries)는 중요한 단어인 'viable(실현 가능한)'을 추가합니다. 제품은 실제 고객이 학습을 위해 사용할 수 있을 만큼 실현 가능해야 하며, 내부 팀만 수용할 수 있는 프로토타입 수준의 코드가 아니어야 합니다.

MVP를 구축하기 전에 학습 목표를 정의해야 합니다. 그렇지 않으면 실험이 성공했는지 여부를 판단할 방법이 없습니다. 학습 목표는 하나의 핵심 질문에 답합니다. '이 문제가 있다고 생각하는 고객이 실제로 이 솔루션을 사용할 것이며, 그들을 유지할 만큼 충분히 잘 작동할 것인가?' 테스트할 구체적인 가설: 'X 세그먼트의 고객은 첫 세션 내에 Y 기능에서 활성화될 것이다', 'Y 기능에서 활성화된 사용자는 최소한 매주 다시 방문할 것이다', '우리가 상상했던 전체 기능 세트 없이도 핵심 워크플로우를 구축할 수 있다'. Product Ops는 MVP 가설을 문서화하고, 정량적 성공 기준(예: 1주 이내 40% 활성화, 2주 이내 60% 재방문)을 설정하며, 각 가설을 확인하거나 반박하기 위해 MVP 후 분석을 실행합니다.

구축 투자 스펙트럼에 따라 여러 MVP 유형이 존재합니다. Concierge MVP — 소수의 고객에게 서비스를 수동으로 제공하여 그들이 가치를 느끼는지 이해합니다(코드 불필요). Wizard of Oz MVP — 고객은 자동화된 제품처럼 보이는 것과 상호 작용하지만, 실제로는 사람이 뒤에서 작업을 수행합니다. Prototype MVP — 이해도 및 작업 완료율을 테스트하는 중간 수준의 클릭 가능한 프로토타입입니다. Single-Feature Build MVP — 엣지 케이스, 오류 처리 또는 통합 없이 핵심 상호 작용 루프만 구축합니다. Tech-Spike MVP — 기술적으로 위험한 구성 요소만 구축하여(나머지는 모의) 기술적 타당성을 검증합니다. 적절한 MVP 유형은 검증할 주요 위험에 따라 달라집니다. 고객이 기능을 원하는지 여부가 위험이라면 Concierge MVP가 가장 빠르며, 기술적 위험이라면 Tech Spike가 필요합니다.