2nd/10_Wiki/Topics/Topic_Agent/Problem-Solution Fit.md

---
id: problem-solution-fit
title: "Problem-Solution Fit"
category: "10_Wiki/Topics"
status: "draft"
verification_status: "conceptual"
canonical_id: ""
aliases: ["Problem Validation", "Solution Validation"]
duplicate_of: ""
source_trust_level: "B"
confidence_score: 0.85
created_at: 2026-06-12
updated_at: 2026-06-12
review_reason: ""
merge_history: []
tags: ["research", "Assumption Validation Loop", "Lean Startup", "Discovery"]
raw_sources: ["NotebookLM Synthesis"]
applied_in: ["Airbnb", "Zappos", "Buffer", "Dropbox", "Money (Case Study)"]
github_commit: ""
---

# [[Problem-Solution Fit]]

## 🎯 한 줄 통찰 (One-line insight)
Problem-Solution Fit은 실제적이고 고통스러운 고객의 문제가 존재하는지, 그리고 제안된 해결책이 그 문제의 근본 원인을 해결할 수 있는지에 대해 자원을 투입하기 전 증거 기반으로 검증하는 첫 번째 핵심 이정표이다 [1-3].

## 🧠 핵심 개념 (Core concepts)
- **문제 검증 (Problem Validation)**: 타겟 문제가 실제로 존재하며, 고객이 능동적으로 해결책을 찾을 만큼 고통스러운지 확인하는 과정 [2, 3].
- **솔루션 검증 (Solution Validation)**: 제안된 방식이 문제의 표면적 증상이 아닌 근본 원인(Root Cause)을 해결하는지 평가하는 단계 [3, 4].
- **고객 페르소나 및 초기 수용자 (Early Adopters)**: 기술적 결함이나 미비함을 감수하고라도 문제를 해결하고자 하는 '문제 인식(Problem-aware)' 고객군을 식별함 [5, 6].
- **연속적 발견 (Continuous Discovery)**: 주 단위의 사용자 조사와 가설 검증을 통해 로드맵을 내부 의견이 아닌 실제 고객 데이터에 고정시키는 운영 방식 [7, 8].

## 🧩 추출된 패턴 (Extracted patterns)
- **과거 행동 기반 조사 (The Mom Test)**: 미래의 의향("이걸 사용하시겠습니까?")이 아닌, 과거의 실제 행동("마지막으로 이 문제를 해결하기 위해 어떤 행동을 했나요?")을 질문하여 편향을 제거함 [9-12].
- **마찰 지점 중심 스코핑 (Friction-based Scoping)**: 사용자 여정 지도(User Journey Mapping)를 통해 가장 마찰이 큰 순간을 찾고, 오직 그 마찰을 제거하는 최소한의 기능으로 MVP를 구성함 [13, 14].
- **선 검증 후 구축 (Learn-Measure-Build)**: 코드를 작성하기 전에 대화, 스프레드시트, 또는 페이크 도어(Fake Door) 테스트를 통해 가설을 먼저 검증하여 자원 낭비를 방지함 [15-17].
- **계층적 검증 순서**: 문제 검증이 선행되지 않은 비즈니스 모델 검증은 무의미하므로, 반드시 '문제 -> 솔루션 -> 수익 모델' 순으로 검증을 진행함 [3, 18].

## 📖 세부 내용 (Details)
- **제품 수명 주기에서의 위치**: Ash Maurya의 모델에 따르면, Problem-Solution Fit은 제품-시장 적합성(PMF) 및 확장(Scale) 단계 이전에 반드시 도달해야 하는 첫 번째 단계이다 [1, 19].
- **문제 검증의 지표**: 고객이 촉구하지 않아도 구체적이고 감정적으로 자신의 고통을 설명하거나, 현재의 임시 해결책(Workarounds)을 나열할 때 강력한 신호로 간주한다 [2, 9].
- **솔루션 검증의 지표**: 고객이 예의 바르게 고개를 끄덕이는 대신 "언제부터 사용할 수 있나요?"라고 구체적인 사용 의사를 물을 때 적합성이 입증된 것으로 본다 [4].
- **가치 제안 캔버스 (VPC) 활용**: 고객의 작업(Jobs), 고통(Pains), 이득(Gains)을 정의하고 제품 기능이 이러한 고통을 어떻게 완화하는지 매핑하여 적합성을 도출한다 [20].
- **정성적 데이터의 우선순위**: 초기 단계에서는 대규모 통계적 유의성보다 소규모 타겟 그룹에서의 정성적 수렴(Qualitative Convergence)과 깊이 있는 통찰에 집중해야 한다 [21, 22].

## ⚖️ 모순 및 업데이트 (Contradictions & updates)
- **금전적 보상 vs 제품 가치**: 결제 의사가 시장성을 증명할 수는 있지만, 그것이 제품이 '무엇을 해야 하는지'에 대한 정답을 알려주는 것은 아니다 [23].
- **MVP vs MLP**: 전통적인 MVP가 기능적 적합성에 집중한다면, 최소 사랑받을 수 있는 제품(Minimum Lovable Product)은 초기 단계부터 감정적 연결과 즐거움(Delight)이 적합성의 요소로 포함되어야 한다고 본다 [24, 25].
- **시제품(Prototype)과의 차이**: 시제품은 설계 개념을 테스트하는 도구이나, Problem-Solution Fit을 위한 MVP는 실제 가치를 전달하여 고객의 행동 변화를 유도해야 한다 [26, 27].

## 🛠️ 적용 사례 (Applied in summary)
- **Airbnb**: 샌프란시스코 디자인 컨퍼런스 기간 중 자신의 아파트에 에어 매트리스를 배치하고 아침 식사를 제공하여 '낯선 사람의 집에 머물 의사'가 있음을 입증 (Problem Validation) [28-30].
- **Zappos**: 지역 상점의 신발 사진을 찍어 웹사이트에 올리고 주문이 들어오면 직접 구매해 배송하는 방식(Wizard of Oz)으로 '온라인 신발 구매 수요'를 검증 [28, 31-33].
- **Buffer**: 실제 제품 구축 전, 기능 설명 페이지와 가격 책정 페이지를 순차적으로 노출하여 수요와 결제 의사를 동시 검증 [23, 34, 35].
- **Dropbox**: 복잡한 동기화 기술을 개발하기 전, 개념을 설명하는 3분짜리 데모 비디오만으로 하룻밤 사이 75,000명의 가입자를 확보하여 시장의 갈증을 증명 [36-39].
- **Money (이탈리아 사례)**: 코로나19 위기 상황에서 지자체의 긴급 자금 배분 문제를 식별하고, 기존 기업용 선불카드 인프라를 지자체용 긴급 구호 카드로 재목적화하여 적합성을 창출 [40, 41].

## ✅ 검증 상태 및 신뢰도
- **상태:** draft
- **검증 단계:** conceptual (실제 적용 사례 발견 시 applied/validated로 승격 가능)
- **출처 신뢰도:** B (Official Documentation / Primary Source via NotebookLM)
- **중복 검사 결과:** 신규 생성 (New discovery)

## 📝 변경 이력 (Change history)
- 2026-06-12: Initial draft generated via Datacollector_MAC P-Reinforce engine.