Antigravity Agent
102 lines
8.7 KiB
Markdown
102 lines
8.7 KiB
Markdown
---
|
|
id: customer-discovery
|
|
title: "Customer Discovery"
|
|
category: "10_Wiki/Topics"
|
|
status: "draft"
|
|
verification_status: "conceptual"
|
|
canonical_id: ""
|
|
aliases: ["고객 발견", "Customer Development"]
|
|
duplicate_of: ""
|
|
source_trust_level: "B"
|
|
confidence_score: 0.90
|
|
created_at: 2026-06-12
|
|
updated_at: 2026-06-12
|
|
review_reason: ""
|
|
merge_history: []
|
|
tags: ["research", "Assumption Validation Loop", "Lean Startup", "Product Discovery"]
|
|
raw_sources: ["NotebookLM Synthesis"]
|
|
applied_in: ["Dropbox", "Airbnb", "Zappos", "Buffer", "Glovo", "Money", "Taxiapp", "Superstore"]
|
|
github_commit: ""
|
|
---
|
|
|
|
# [[Customer Discovery]]
|
|
|
|
## 🎯 한 줄 통찰 (One-line insight)
|
|
"Build Trap"과 시장 요구 없는 제품 개발을 방지하기 위해, 추측성 제품 전달에서 벗어나 실제 고객의 고통과 니즈를 매주 지속적으로 검증하여 증거 기반의 의사결정을 내리는 프로세스이다 [1-3].
|
|
|
|
## 🧠 핵심 개념 (Core concepts)
|
|
- **지속적 발견 (Continuous Discovery):** 제품 개발 초기뿐만 아니라 인도(Delivery) 과정과 병행하여 매주 고객과 소통하고 가설을 검증하는 실행 모델이다 [4, 5].
|
|
- **검증의 3계층 (Three Layers of Validation):** 문제 검증(문제의 실존 및 고통의 정도), 솔루션 검증(근본 원인 해결 여부), 비즈니스 모델 검증(수익성 및 확장성)의 순차적 단계를 거친다 [6-8].
|
|
- **증거의 위계 (Hierarchy of Evidence):** 단순한 구두 확인(약함)보다 평판 헌신, 시간 투자, 최종적으로 재정적 약속(강함)을 더 높은 신뢰 수준의 증거로 간주한다 [9, 10].
|
|
- **엄마 테스트 (The Mom Test):** 미래의 의도가 아닌 과거의 구체적인 행동에 대해 질문함으로써, 피면접자의 예의 바른 거짓말을 배제하고 객관적인 사실을 추출하는 인터뷰 기법이다 [11-13].
|
|
|
|
## 🧩 추출된 패턴 (Extracted patterns)
|
|
- **가설의 수치화 패턴:** "만약 [변경]하면, [기간] 내에 [지표]가 [영향]만큼 변화할 것이다" 또는 "적어도 [X]%의 [Y]가 [Z]할 것이다"라는 형식으로 반증 가능한 가설을 수립한다 [14].
|
|
- **위험 기반 우선순위 패턴:** [[Assumption Mapping]]을 통해 '중요도'와 '불확실성'이 모두 높은 '도약의 가설(Leap-of-faith)'을 최우선 검증 대상으로 격리한다 [15, 16].
|
|
- **RAT (Riskiest Assumption Test) 전략:** 최소 기능 제품(MVP)을 구축하기 전, 비즈니스를 붕괴시킬 수 있는 가장 위험한 단 하나의 가설만을 격리하여 최소한의 비용으로 테스트한다 [17-19].
|
|
|
|
## 📖 세부 내용 (Details)
|
|
- **발견과 인도의 통합:** 현대적 제품 팀은 발견 활동을 스프린트 내에 직접 포함하며, 엔지니어와 디자이너를 고객 인터뷰에 참여시켜 문제에 대한 공유된 맥락을 구축한다 [20, 21].
|
|
- **인터뷰 실행 원칙:** 고객에게 솔루션의 구매 여부를 묻는 대신, 해당 문제를 해결하기 위해 마지막으로 돈을 쓴 시점과 과정을 설명하도록 유도하여 실제 고통의 크기를 측정한다 [13, 22].
|
|
- **시장 신호 포착:** 랜딩 페이지의 클릭률(Fake Door), 데모 비디오 시청 후 가입 전환율, 수동 서비스 제공(Concierge)을 통한 워크플로우 이해 등 비코딩(No-code) 방식의 실험을 활용한다 [23-25].
|
|
- **의사결정 프레임워크:** 실험 결과가 사전 정의된 '실패 기준(Kill Criteria)'에 해당하면 감정을 배제하고 즉시 피벗(Pivot)하거나 중단하며, 지표가 목표를 달성했을 때만 정진(Persevere)한다 [26-28].
|
|
|
|
## ⚖️ 모순 및 업데이트 (Contradictions & updates)
|
|
- **MVP의 정의 변화:** 과거에는 MVP를 제품의 '축소판'으로 보았으나, 최근에는 질문에 답하기 위한 '학습 도구' 또는 '실험' 그 자체로 정의하며 제품 형태가 아니어도 무방하다고 본다 [29-31].
|
|
- **시장 연구 vs. 고객 발견:** TAM(전체 시장 규모) 보고서를 읽는 것은 시장 연구이지 고객 발견이 아니며, 발견은 특정 고객이 특정 가격에 특정 솔루션을 구매할지에 대한 실질적 증거를 찾는 것이다 [32].
|
|
|
|
## 🛠️ 적용 사례 (Applied in summary)
|
|
- **Dropbox:** 실제 코드를 작성하기 전 3분짜리 데모 비디오를 공개하여 하룻밤 사이 75,000명의 대기 명단을 확보함으로써 시장 수요를 검증함 [33-35].
|
|
- **Airbnb:** 낯선 사람의 집에서 숙박할 수요가 있는지 확인하기 위해 디자인 컨퍼런스 기간 중 자신의 아파트에 에어 매트리스 3개를 놓고 유료 고객을 유치함 [36-38].
|
|
- **Zappos:** 재고 시스템을 구축하기 전, 동네 신발 가게의 신발 사진을 찍어 웹사이트에 올리고 주문이 들어오면 직접 구매하여 배송하는 '오즈의 마법사(Wizard of Oz)' 방식으로 검증함 [25, 36, 39].
|
|
- **Buffer:** 랜딩 페이지에 가입 버튼만 두었다가, 이후 가격 페이지를 추가하여 사용자가 실제 결제 의사가 있는지 단일 변수 테스트로 확인 후 개발 착수함 [40-42].
|
|
- **COVID-19 대응 사례 (Glovo, Taxiapp 등):** 위기 상황에서 기존 비즈니스 가설이 붕괴되자 유휴 자원(라이더, 택시 차량)을 활용해 생필품 배송 등의 새로운 사용 사례를 빠르게 실험하고 피벗함 [43-45].
|
|
|
|
## ✅ 검증 상태 및 신뢰도
|
|
- **상태:** draft
|
|
- **검증 단계:** conceptual (실제 적용 사례 다수 발견됨)
|
|
- **출처 신뢰도:** B (Official Documentation / Primary Source via NotebookLM)
|
|
- **중복 검사 결과:** 신규 생성 (New discovery)
|
|
|
|
|
|
## 🔗 관련 문서 링크 (Related document links)
|
|
|
|
### 상위/유사 개념
|
|
#### [아키텍처/방법론]
|
|
- [[Assumption Validation Loop]]
|
|
- 연결 이유: Customer Discovery는 이 루프의 실행 엔진 역할을 함 [8].
|
|
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 가설 수립부터 학습까지의 전체적인 시스템 구조.
|
|
- [[Lean Startup]]
|
|
- 연결 이유: Customer Discovery의 핵심 철학적 기반을 제공함 [30, 46].
|
|
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: Build-Measure-Learn 피드백 루프의 원리.
|
|
|
|
#### [실행 도구]
|
|
- [[Minimum Viable Product]] (MVP)
|
|
- 연결 이유: 가설 검증을 위해 가장 빈번하게 사용되는 학습 도구임 [31, 47].
|
|
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 저충실도와 고충실도 실험 모델의 차이.
|
|
- [[Assumption Mapping]]
|
|
- 연결 이유: 발견 활동 전 어떤 가설을 먼저 검증할지 우선순위를 결정함 [15, 48].
|
|
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 리스크 기반의 자원 배분 전략.
|
|
|
|
### 심층 후속 질문 (Deeper Research Questions)
|
|
- Customer Discovery 과정에서 수집된 질적 데이터(인터뷰 등)를 어떻게 정량적 지표로 변환하여 [[Innovation Accounting]]에 반영할 것인가? [49, 50]
|
|
- [[Kano Model]]을 활용하여 발견된 니즈 중 '기본 요구'와 '매력적 요소'를 어떻게 구분하여 MVP 범위를 확정할 것인가? [51, 52]
|
|
- AI 기반의 발견 도구(IdeaProof 등)가 인간의 직접 인터뷰를 대체할 수 있는 범위와 그 한계는 무엇인가? [53, 54]
|
|
- 피벗(Pivot) 결정을 내릴 때 매몰 비용 오류(Sunk Cost Fallacy)를 극복하기 위한 객관적 '중단 기준(Kill Criteria)'의 구체적인 설정 방법은? [55, 56]
|
|
- 기업 내부의 이해관계자 정렬(Alignment)을 위해 Customer Discovery 결과를 시각화하고 스토리텔링하는 최적의 방법은? [57, 58]
|
|
|
|
### 실무 적용 맥락 (Practical Application Contexts)
|
|
- **Implementation:** 비코딩 도구(Webflow, Zapier)를 사용해 가설 검증용 랜딩 페이지를 24~48시간 내에 구축한다 [53, 59].
|
|
- **System Design:** 제품 내에 "이 기능이 도움이 되었나요?"와 같은 피드백 루프를 설계 단계부터 포함한다 [60].
|
|
- **Operation / Maintenance:** 매주 최소 1~2명의 실제 사용자와 대화하는 지속적 발견 캔디스를 유지한다 [5, 61].
|
|
- **Learning Path:** 엄마 테스트 기법을 숙지하고 인터뷰 가이드를 작성하여 팀원들과 공유한다 [11, 62].
|
|
|
|
### 인접 주변 주제 (Adjacent Topics)
|
|
- [[Jobs-to-be-Done]] (JTBD)
|
|
- 확장 방향: 고객의 단순한 요청이 아닌, 그들이 달성하고자 하는 근본적인 '과업'에 집중하여 솔루션의 적합성을 높임 [63, 64].
|
|
- [[Innovation Accounting]]
|
|
- 확장 방향: 매출이 발생하지 않는 초기 단계에서 '학습 속도'와 '리스크 감소량'을 측정하여 진행 상황을 평가함 [49, 65].
|
|
|
|
|
|
## 📝 변경 이력 (Change history)
|
|
- 2026-06-12: Initial draft generated via Datacollector_MAC P-Reinforce engine. |