# 인스파이어드 (Inspired)

### 책 요약

좋은 제품팀과 PO/PM의 역할, 프로덕트 비전, 디스커버리와 딜리버리 구조 등의 이해를 통해 제품 성공 방법론을 다룸

1. **Delivery vs Discovery (전달 vs 발견)**

- Delivery(전달): '정해진 것'을 일정·품질·기술적으로 완성하는 과정

- Discovery(발견): 만들기 전에 '성공할지'를 검증하는 과정

- Discovery는 4가지 리스크(가치·사용성·실현가능·비즈 타당성)를 줄이는 것이 목적
- 
- [실무 예시]

    - Delivery만 강한 경우: VIP 요청 '엑셀 내보내기'를 4주 만에 만들었지만 사용률 3% → 요청은 있었으나 '누가/왜/어떤 맥락'에서 필요한지 발견이 부족.

    - Discovery를 적용한 경우: 동일 요청을 '보고서 공유·결재 과정의 번거로움'으로 재정의 → 엑셀이 아니라 공유 링크·권한·요약 리포트 자동 생성으로 전환 → 사용률↑, CS 문의↓.
    - 
    - 

2. **Empowered Product Team (권한 있는 제품팀)
2. **

- 좋은 팀은 요구사항을 '받는 팀'이 아니라 성과(Outcome)를 만드는 팀

- 팀은 문제/목표를 받고, 해결책은 팀이 제안한다

- PM/PO–디자이너–테크리드(엔지니어)가 함께 Discovery를 수행한다
- 
- [실무 예시]

    - 권한 없는 팀(요청 접수형): 영업 '이 기능 없으면 계약 못 따요' → PM 문서화 → 개발 구현 → 제품이 고객사별 커스텀 늪에 빠지기 쉬움.

    - Empowered 팀(문제 번역형): 'A 고객 SSO' 요청을 '엔터프라이즈 보안/감사 요구 충족'으로 번역 → SSO만이 아니라 권한·감사로그·관리자 최소 세트로 제품화 → 확장 가능한 솔루션으로 수렴.
    - 
    - 

3. **Vision / Strategy / Principles (방향성을 운영하는 3종 세트)**

- 비전(Vision): 우리가 궁극적으로 만들고 싶은 미래

- 전략(Strategy): 어떤 고객/시장에 어떤 차별화로 갈지에 대한 선택

- 원칙(Principles): 반복되는 논쟁을 줄이는 판단 기준 문장

- 로드맵은 '약속 문서'가 아니라 방향과 학습을 공유하는 도구가 되어야 함
- 
- [실무 예시]

    - 원칙이 없을 때: 성장 vs 매출 vs 품질 vs 엔터프라이즈 요구가 회의마다 감정싸움으로 번짐.

    - 원칙 예시 문장: (1) 단기 매출보다 핵심 반복사용(리텐션)을 우선한다. (2) 기능은 늘리되 사용 복잡도는 늘리지 않는다(복잡도 예산). (3) 커스텀은 최소화하고 표준화 가능한 요구만 제품화한다.

    - 원칙이 생기면: '누가 더 세게 말하나'가 아니라 '원칙에 맞나'로 토론이 이동.

1. **MVP 재정의: '기능 최소'가 아니라 '최소 검증'**핵심 요약

- MVP를 빠르게 만드는 것-배포하는것 → '대충 만든 첫 버전'으로 오해하면 브랜드/신뢰/사용성이 깨질 수 있음

- 책의 관점은 '검증을 위한 최소구현'에 가깝다: 프로토타입, 컨시어지(수동 운영), 페이크 도어, 파일럿 등
- [실무 예시]

    - B2C 구독 기능: (잘못된 MVP) 결제·해지·쿠폰·프로모션까지 풀세트 개발 → 전환 낮음. (검증형) 랜딩+대기자/혜택 1~2개로 가치 검증 → 초기 결제는 단순 수동 처리로도 검증 가능.

    - B2B 관리자 기능: 실제 관리자 5명 프로토타입 테스트로 '필수 정보' 선별 → 화면 2개만 먼저 만들고 나머지는 로그/수동 리포트로 보완.
    - 
    - 

2. **Discovery의 4대 리스크를 각각 줄이는 법**
2. 

- 가치 리스크: 고객이 정말 원하는가?

- 사용성 리스크: 고객이 실제로 사용할 수 있는가?

- 실현가능 리스크: 기술·운영적으로 만들 수 있는가?

- 비즈 타당성 리스크: 수익·법무·보안·브랜드·세일즈·CS 관점에서 맞는가?

### 모임 아젠다

1. **PO/PM의 R&R**
1. : 현재 자신이 속한 조직에서 부여된 PO/PM의 역할과 책임을(R&R) 설명해 주세요. 그리고 인스파이어드에서 정의한 이상적인 PO/PM의 R&R과는 어떤 차이가 있나요? 이 차이가 발생하는 원인이 무엇 때문이라 생각하는지 의견을 남겨주세요
1. 
1. 

2. **PMF 검증을 위한 MVP
2. **: 진행했던 프로젝트 중 아이디어 검증 과정을 통해 PMF를 목표로 MVP를 정의해 구축 출시 후 단계별로 제품을 성장시켜 본 적이 있다면 그 과정과 결과를 공유해 주세요. 만약 PMF와 MVP를 적용해 본 적이 없다면, 어떻게 아이디어를 검증하고, 출시 스펙을 결정했는지, 그리고 그 결과는 어떠했는지 공유해 주세요. **
2. 
2. **

3. **프로덕트 구축/개선 프로세스**
3. : 현재 조직의 프로덕트를 구축/개선하는 과정과 인스파이어드에서 소개하는 이상적인 과정과 어떤 차이가 있나요? 애자일 방법론을 경험해 보신적이 있다면 어떤 장점과 단점이 있었는지 공유해 주세요. 
3. +(옵션) 회사의 제품 구축 프로세스와 체계를 구축하는 시점은 언제부터 필요할까요?
3. 
3. 

[https://slashpage.com/pgf/y9e1xp2x56pngm7k35vz](https://slashpage.com/pgf/y9e1xp2x56pngm7k35vz)

For the site tree, see the [root Markdown](https://slashpage.com/pgf.md).