### Intro
- 모든 제품 팀은 일련의 활동을 통해 무엇을 만들지 결정한 다음, 그것을 만들고 제공하기 위해 또 다른 일련의 활동을 수행
- 무엇을 build 할지 결정하는 작업을 **Discovery (발견)**
- 제품을 build 하고 출시하는 작업을 **Delivery (배송)**
- 많은 회사들이 약속한 시간과 예산에 맞춰 제품을 Delivery(배송)했는지 여부에 초점을 맞추는 반면, 제대로 build 했는지 평가하는 것을 잊고 Discovery(발견)에 대한 투자는 소홀. 이러한 불균형을 바로잡는 것을 목표
- Discovery 는 1회성 활동이 아니다.
- 디지털 제품은 절대 완성되지 않는다.
- 계속 진화할 수 있고 진화해야 한다.
- => 이 책에서는 팀이 새로운 제품을 발견하고 기존 제품을 반복적으로 개선할 수 있는 Continuous Discovery (지속적인 발견) 프레임워크를 소개
### The Evolution of Modern Product Discovery
- 역사
- 초창기
- 소프트웨어 초창기에는 비지니스 리더가 발견을 주도하여 무엇을 build 할지 결정
- Discovery 는 1년에 한 번씩 연간 예산 프로세스에서 이루어졌으며, 일정이 정해진 프로젝트가 특정 엔지니어링 팀에 할당
- Product Manager 가 작업, 예산, 일정만을 관리 (때론 비지니스 요구 사항을 제품 요구 사항으로 전환하기 했지만..)
- 소프트웨어 개발은 예측 불가 (예산 초과 기한 초과)
- 비지니스 요구사항이 고객의 요구사항보다 우선시되는 경우가 많음
- 제품이 출시된 후에야 고객이 자신이 만든 제품에 만족하지 않는다는 사실을 인지 => 많은 비용의 낭비
- => 이런 유형의 팀이 **Delivery 팀 (배달 팀)**
- 애자일 선언문 시대
- 애자일에서 강조되는 4가지 원칙
- **짧은 주기와 빈번한 고객 피드백**
- **지속적으로 유지할 수 있는 속도로 작업**
- **고객 피드백에 빠르고 쉽게 적응할 수 있는 유연성 극대화**
- **단순함 추구** (극도로 최소한의 것만 개발)
- 스크럼/칸반 도입, 고객 피드백(UX, 유저 리서치) 강조 => 그럼에도 문제 발생
- 주기가 짧아지고 고객 피드백이 많아져도 원래의 아이디어를 고수
- 예측불가능한 작업을 예측하지 못함
- 스프린트가 지속적인 속도를 찾지 못하게함 (격주 스프린트?)
- 나머지 비지니스가 바뀌지 않기 때문에 유연성이 없고 (제품 팀만 바뀐다고 되지 않음)
- 작동하지 않는다는 사실을 알게 되더라도 예산 범위 내에서 제시간에 맞춰 제공
- 사용성 테스트는 종종 프로세스 후반부에 너무 늦게 진행되어 발견한 중요한 문제를 해결하기에는 이미 너무 늦었을때가 많음
- **팀은 계속 누가 사용했는지, 고객이나 비지니스에 어떤 가치를 창출했는지 여부가 아니라 여전히 무엇을 제공했는지에 따라 평가 받음**
- 그럼에도 불구하고
- 배포 주기가 단축 됨
- 프로덕트를 더 잘 측정할 수 있게 됨
- 사용성 테스트를 더 잘하게 됨
- 작은 솔루션 -> 큰 솔루션 반복하는 걸 잘하게 됨
- 그럼에도 불구하고22
- 여전히 **무엇을 build 할지 결정하는 데는 어려움**을 겪었음
- 그래도 더 잘 측정하게 되면서 이러한 문제를 훨씬 더 심각하게 인식하게 됨
- 무엇을 만들지(build) 결정하는 것
- 비지니스 이해관계자에서 프로덕트 매니저로, 프로덕트 매니저에서 제품 팀 전체로.
- Discovery 과정 전반에 걸쳐 고객을 참여
- Discovery 가 끝날 때 아이디어를 검증하는 대신 처음부터 고객과 공동 창작
- Delivery Cycle 이 짧아지면서 Discovery Cycle 도 짧아짐
- Continuous Discovery
#### 이 책의 대상
- "PM, 디자이너, 개발자"(product people) 제품 "**트리오**"가 대상임
- 
- 최소한의 Discovery 를 위해 "트리오"가 필요. 그 이상을 포함시킬 수 있으나 그에 대한 대가가 따름 (속도, 의사결정 균형 등)
#### 필수 마인드셋
- 많은 팀이 프레임워크, 도구, 방법론을 쫓으며 새로운 혁신이 갑자기 제품 성공의 문을 열어줄 것이라고 기대하지만, 결국 이러한 것들은 **마인드셋이 동반**되지 않으면 안된다.
- 여섯가지 사고 방식
- 1. Outcome-oriented (결과 지향적)
- 결과물보다는 결과 중심 (마인드셋이자 습관이어야 함)
- 출시하는 솔루션으로 성공을 정의하기보다 솔루션이 고객과 비지니스에 창출하는 가치로 성공을 정의
- 고객의 삶에 미친 영향, 비지니스의 지속 가능성과 성장에 미친 영향 등 Impact 로 성공을 측정
- 2. Customer-centric (고객 중심)
- 고객을 세상의 중심에 두는 것
- 비지니스의 목적은 고객을 창출하고 고객에게 서비스를 제공하는 것
- 고객의 요구를 비지니스 요구와 동등한 수준으로 끌어올려 고객 가치 창출에 집중 (비지니스 가치 뿐만 아니라)
- 3. Collaborative (협업)
- Digital Product 의 Cross-functional 한 특성을 이해하고 분업화되어 단계별로 결과물을 전달하는 사일로화된 모델을 거부 (PM이 결정하고 디자이너가 디자인하고 엔지니어가 코딩 X)
- -> 각자가 가진 전문성과 지식을 활용하면서 팀이 함께 의사 결정을 내리는 모델을 받아들여야함
- 4. Visual (시각)
- 말과 글이 아닌 시각화가 필요.
- 이 책에 소개된 습관은 그림을 그리고, 생각을 외부화하며, 아는 것을 매핑 (스토리 매핑?)
- 공간적 추론 능력을 활용하는 습관을 가져야 한다.
- 5. Experimental (실험적 사고)
- Discovery 를 잘하려면 가정을 확인하고 증거를 수집하는 과학자처럼 사고하는 법을 배워야함
- 6. Continuous (지속성)
- Discovery 를 프로젝트 초반에 하는 일로 생각하지 않고 개발 프로세스 전반에 걸쳐 지속적으로 Discovery 해야함 (구체적인 내용은 뒤 챕터에서)
#### Continuous Discovery 의 실무적 정의 (Working Definition)
- 이미 많은 제품 팀에서 [[린 고객 개발을 위한 고객 인터뷰 기본 질문 5가지]], 고객 인터뷰, 사용자 테스트, A/B 테스트 를 채택하고 있다.
- 그러나, 이러한 Discovery 활동들을 **체계적이고 지속 가능한 방식**으로 채택하여 제품 결정에 지속적으로 반영하는 팀은 드물다 (고객의 의견을)
- 단순히 Discovery 가 아닌 Continuous Discovery 란?
> 고객과 최소 주 1회 접점 (At a minimum, weekly touchpoints with customers)
> 제품을 개발하는 팀이 주도하여 (By the team building the product)
> 소규모 리서치 활동을 수행하며 (Where they conduct small research activities)
> 목표한 결과를 달성하기 위해 노력한다. (In pursuit of a desired outcome)
- 제품 팀은 매일 의사 결정을 내린다 -> 일상적인 의사 결정에서 최대한 많은 고객 의견을 반영하는 것이 Continuous Discovery 이다.
- 제품 팀이 한 달에 한 번만 고객과 소통한다면, 그 사이 한 달 동안의 의사결정은 고객의 의견 없이 이루어지게 되는 것
---
[[2. A Common Framework For Continuous Discovery]]