---
id: continuous-discovery-habits
title: "Continuous Discovery Habits"
category: "10_Wiki/Topics"
status: "draft"
verification_status: "conceptual"
canonical_id: ""
aliases: ["지속적 발견 습관", "OST 방법론"]
duplicate_of: ""
source_trust_level: "B"
confidence_score: 0.90
created_at: 2026-05-24
updated_at: 2026-05-24
review_reason: ""
merge_history: []
tags: ["research", "logic tree", "product-management", "discovery"]
raw_sources: ["NotebookLM Synthesis"]
applied_in: ["SuperAwesome", "Seera Group", "Grailed", "trivago"]
github_commit: ""
---

# [[Continuous Discovery Habits]]

## 🎯 한 줄 통찰 (One-line insight)
비즈니스 결과와 고객 니즈, 실험적 솔루션을 시각적으로 정렬하여 제품 팀이 불확실성 속에서도 지속적으로 고객 가치를 창출하게 돕는 의사결정 프레임워크 [1-3].

## 🧠 핵심 개념 (Core concepts)
- **Desired Outcome (비즈니스 결과):** 트리의 루트(뿌리)로서, 팀이 달성하고자 하는 구체적이고 측정 가능한 목표(예: 북극성 지표, OKR)를 설정함 [3-5].
- **Opportunity Space (기회 영역):** 고객 인터뷰를 통해 발견된 미충족 니즈, 페인 포인트, 욕구를 구조화한 영역 [5-7].
- **Solution Space (솔루션 영역):** 특정 기회를 해결하기 위해 제안된 다양한 제품 아이디어 및 기능 [3, 8, 9].
- **Assumption Testing (가설 검증):** 솔루션 전체를 구축하기 전, 그 아이디어가 성공하기 위해 전제되어야 하는 위험한 가설들을 빠르게 테스트함 [9-12].
- **Product Trio (제품 트리오):** 제품 매니저, 디자이너, 소프트웨어 엔지니어가 공동으로 발견 프로세스를 소유하고 협업함 [13, 14].

## 🧩 추출된 패턴 (Extracted patterns)
- **'Whether or not'에서 'Compare and contrast'로의 전환:** 하나의 아이디어를 할지 말지 결정하는 것이 아니라, 여러 솔루션을 동시에 고려하고 대조하여 최적의 경로를 선택함 [10, 15, 16].
- **Small Opportunities, Faster Sprints:** 거대한 기회를 작고 해결 가능한 단위로 쪼개어 가설 검증의 주기를 단축함 [17].
- **Evidence-based Evolution:** 매주 인터뷰를 진행하고 3~4회의 인터뷰마다 트리를 업데이트하여 학습된 내용을 실시간으로 반영함 [18-20].

## 📖 세부 내용 (Details)
- **방법론의 기원:** Teresa Torres가 2016년에 제안했으며, 그녀의 저서 'Continuous Discovery Habits'를 통해 상세화됨 [15, 21-23].
- **결과 중심의 발견(Outcome-driven):**
    - 단순한 기능 산출물(Output)이 아닌, 비즈니스에 기여하는 제품 결과(Product Outcome, 예: 특정 행동의 증가)를 최상단에 배치함 [24, 25].
    - 이는 비즈니스 가치와 고객 가치 사이의 긴장을 해결하는 장치가 됨 [26, 27].
- **기회 매핑의 규칙:**
    - 기회는 반드시 고객의 실제 '스토리'에서 도출되어야 하며, 문맥이 결여된 영업 요청이나 지원 티켓은 인터뷰의 영감으로만 활용함 [28-31].
    - "이 기회를 해결할 수 있는 방법이 여러 개인가?"라는 질문을 통해 솔루션이 기회로 위장되지 않았는지 점검함 [32].
- **실험 설계:**
    - 아이디어 전체를 테스트하는 데는 몇 주가 걸리지만, 기저의 가설(Assumption) 테스트는 하루 이틀 내에 가능함 [33].
    - 세 가지 솔루션을 동시에 탐색하여 데이터 기반의 비교 우위를 확보함 [10, 12].
- **운영적 특징:**
    - OST(Opportunity Solution Tree)는 살아있는 문서(Living Document)로서, 팀의 의사결정 이력을 보존함 [34, 35].
    - 전사적 트리를 만들기보다는 각 제품 팀의 범위에 맞는 개별 트리를 운영할 것을 권장함 [36].

## ⚖️ 모순 및 업데이트 (Contradictions & updates)
- **비즈니스 vs 고객 가치:** 초기에는 비즈니스 결과(Outcome)에서 시작하는 것이 고객 중심적이지 않다는 비판이 있을 수 있으나, 소스는 비즈니스 가치가 확보되어야 지속적으로 고객을 섬길 권리를 얻게 된다고 강조함 [27].
- **정적 로드맵과의 관계:** 전통적인 로드맵이 날짜 기반의 기능 목록이라면, OST 기반의 로드맵은 검증된 기회와 해결책을 포함하는 결과 지향적 로드맵(Now Next Future)으로 진화함 [37, 38].

## 🛠️ 적용 사례 (Applied in summary)
- **Grailed:** 기회 매핑(Opportunity Mapping) 적용을 통해 LTV(고객 생애 가치)를 20% 향상함 [39].
- **Seera Group:** 여행 시장이 멈춘 위기 상황에서 OST를 활용해 새로운 시장 기회를 발견함 [39].
- **trivago & SuperAwesome:** 제품 팀 내부에 OST 프로세스를 도입하여 정렬(Alignment)과 의사결정 속도를 개선함 [39].
- **비즈니스 외 사례:** 일상 생활의 복잡한 의사결정(예: 구직, 저녁 메뉴 선택)에도 트리를 활용한 사례가 보고됨 [39, 40].

## ✅ 검증 상태 및 신뢰도
- **상태:** draft
- **검증 단계:** conceptual (Grailed 등 다수 기업의 적용 사례를 통해 실무적 유용성이 입증됨) [39]
- **출처 신뢰도:** B (전문가 저서 및 교육 기관의 자료 기반)
- **중복 검사 결과:** 신규 생성 (New discovery)


## 🔗 관련 문서 링크 (Related document links)

### 상위/유사 개념

#### [[Logic Tree]] 아키텍처
- [[Opportunity Solution Tree]] (OST)
  - 연결 이유: 지속적 발견 습관을 실천하기 위한 핵심 시각화 도구 [22, 41].
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 비선형적인 발견 과정을 구조적으로 관리하는 방법 [41].
- [[Issue Tree]]
  - 연결 이유: OST는 문제 해결을 위해 질문을 분해하는 Issue Tree의 한 종류임 [23].
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 논리적 disaggregation(분해)의 기본 원리 [23, 42].

#### 방법론 및 프레임워크
- [[MECE Principle]]
  - 연결 이유: 기회와 솔루션을 분류할 때 중복과 누락을 방지하는 기본 논리 [43, 44].
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 팀 내 커뮤니케이션의 명확성 확보 [42, 45].
- [[Assumption Testing]]
  - 연결 이유: 아이디어를 실행으로 옮기기 전 위험을 관리하는 필수 habits [10, 46].
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 빠른 학습 사이클 구축 [11, 47].

### 심층 후속 질문 (Deeper Research Questions)
- 비즈니스 결과(Outcome)와 산출물(Output)을 구별하는 것이 제품 팀의 자율성에 어떤 영향을 미치는가? [24, 48]
- 기회(Opportunity)를 솔루션의 위장이 아닌 고객 니즈로 정확히 정의하기 위한 '기회 프레임워킹' 기술은 무엇인가? [32, 49]
- 제품 트리오(Trio) 내에서 가설 검증의 책임을 어떻게 분배하고 조율하는가? [13, 14]
- OST가 기존의 날짜 기반 로드맵(Date-based Roadmap)과 충돌할 때 이를 어떻게 통합 관리하는가? [37, 38]
- 조직 전체의 전략(Vision)과 팀 단위의 OST 결과 지표를 어떻게 정렬(Align)시키는가? [3, 36]

### 실무 적용 맥락 (Practical Application Contexts)
- **Implementation:** Miro, Mural 등 디지털 화이트보드를 활용해 팀이 실시간으로 트리를 공유하고 업데이트함 [34, 50, 51].
- **System Design:** 애자일 스프린트 프로세스 내에 가설 검증 단계(Discovery Sprint)를 통합하여 설계함 [52, 53].
- **Operation / Maintenance:** 매주 인터뷰를 예약하고 3~4회마다 트리를 재검토하는 리듬을 운영함 [18-20].
- **Learning Path:** 스토리 기반 인터뷰 기법과 가설 추출 능력을 배양하는 교육 과정(Discovery Fundamentals) 연계 가능 [54, 55].

### 인접 주변 주제 (Adjacent Topics)
- [[Design Thinking]]
  - 확장 방향: 고객의 공감(Empathy)을 통해 기회를 발굴하는 전단계로서의 상호보완적 활용 [56, 57].
- [[Product Trio]]
  - 확장 방향: 다학제적 팀이 OST를 효과적으로 운영하기 위한 조직 구조와 커뮤니케이션 연구 [13, 14].


## 📝 변경 이력 (Change history)
- 2026-05-24: Initial draft generated via Datacollector_MAC P-Reinforce engine. (Source: NotebookLM Synthesis based on 41 sources). [2, 21-23]