인스파이어드

출판사: 제이펍 · 추가 개념: 제품개발 프로세스, 제품 발견, 아키텍처 기준

1. 기존 제품개발 프로세스의 한계

전통적인 제품 개발 방식은 보통 다음 순서로 진행됨

• 제품관리자가 요구사항을 정의함
• 디자이너가 요구사항에 맞춰 화면과 사용 경험을 설계함
• 엔지니어가 이를 구현함
• 출시 후 시장 반응을 확인함

이 방식의 한계는 위험을 너무 늦게 발견한다는 점

이미 기획, 디자인, 개발이 끝난 뒤에야 고객이 원하지 않는다는 사실을 알게 되면, 시간과 비용을 크게 낭비하게 됨

따라서 좋은 제품팀은 “무엇을 만들까?”보다 먼저 “이걸 만들 가치가 있는가?”를 검증함

2. 제품 발견의 목적은 제품 위험을 줄이는 것

제품 발견의 목적은 아이디어를 예쁘게 다듬는 것이 아니라, 제품이 실패할 수 있는 핵심 위험을 초기에 확인하는 것

위험	핵심 질문	의미
가치 위험	고객이 이 제품을 살 것인가, 사용할 것인가	고객에게 진짜 가치가 있는지 확인함
사용성 위험	사용자가 쉽게 이해하고 쓸 수 있는가	복잡하거나 불편하지 않은지 확인함
실현 가능성 위험	우리 엔지니어가 만들 수 있는가	시간, 기술, 역량상 가능한지 확인함
사업 유효성 위험	이 솔루션이 사업적으로 작동하는가	영업, 마케팅, 재무, 법무 측면에서 가능한지 확인함

핵심은 이 위험들을 출시 직전에 확인하는 것이 아니라, 구현을 결정하기 전에 확인해야 한다

3. 좋은 제품팀은 순차적으로 일하지 않음

나쁜 방식

• PM이 요구사항을 혼자 정리함
• 디자이너는 그 요구사항에 맞춰 디자인함
• 엔지니어는 이미 정해진 요구사항을 구현함

이 구조에서는 각 직무가 자기 단계에만 갇히게 됨

반대로 좋은 제품팀은 PM, 디자이너, 엔지니어가 처음부터 함께 논의함

• PM은 고객 문제와 사업 목표를 봄
• 디자이너는 사용자가 이해하고 행동할 수 있는 경험을 설계함
• 엔지니어는 기술적 가능성과 더 나은 구현 방식을 제안함

4. 제품팀의 목표는 기능 구현이 아니라 문제 해결

전통적인 로드맵은 보통 기능 목록임

• 검색 기능 추가
• 추천 기능 추가
• 알림 기능 개선
• 대시보드 개발

하지만 좋은 제품팀은 기능을 몇 개 만들었는가보다 그 기능이 어떤 문제를 해결했는가를 봄

기능 중심 질문	문제 중심 질문
어떤 기능을 만들까	어떤 문제를 해결해야 하는가
언제 출시할까	어떤 위험을 먼저 검증해야 하는가
요구사항은 무엇인가	고객과 사업에 어떤 성과를 만들어야 하는가
MVP를 어디까지 만들까	무엇을 가장 빠르고 싸게 학습할 수 있는가

핵심은 Output이 아니라 Outcome

• Output은 기능, 화면, 배포, 개발량
• Outcome은 전환율 증가, 사용성 개선, 매출 증가, 리텐션 개선, 고객 문제 해결

5. PM이 하는 일

1. 제품 발견

• 어떤 문제를 풀 것인지 정의
• 어떤 기능이 필요한지 판단
• 고객에게 어떤 가치를 줄 것인지 검증
• 이 아이디어가 만들 만한 가치가 있는지 확인

2. 시장에 제품 전달

• 제품을 고객에게 어떻게 전달할 것인지 설계
• 출시 후 어떤 성과를 만들 것인지 관리
• 영업, 마케팅, 운영, 고객지원과 어떻게 연결할 것인지 조율

여기서 중요한 점은, 제품 발견의 산출물이 단순 아이디어가 아니라 검증된 제품 백로그라는 점

즉, 백로그는 누군가 요청한 기능 목록이 아니라, 검증을 거쳐 만들 가치가 확인된 문제 해결안의 목록

6. 제품 발견이 답해야 하는 4가지 질문

실무적으로는 이 4가지 질문 중 하나라도 답하지 못하면, 만들 준비가 된 것이라고 보기 어려움

질문	연결되는 위험
사용자들이 이 제품을 살 것인가, 사용할 것인가	가치 위험
사용자가 이 제품을 어떻게 쓰는지 이해할 수 있는가	사용성 위험
우리 엔지니어가 이것을 만들어낼 수 있는가	실현 가능성 위험
우리 이해관계자가 이것을 지지하는가	사업 유효성 위험

7. 프로토타입의 목적은 출시가 아니라 학습

제품 발견 단계의 실험은 보통 프로토타입을 활용함

여기서 프로토타입은 출시용 제품이 아님

프로토타입의 목적

• 빠르게 배움
• 싸게 검증함
• 고객 반응을 봄
• 만들 가치가 있는지 확인함
• 실제 제품 개발 전에 위험을 줄임

8. MVP는 제품이 아니라 프로토타입임

많은 사람이 MVP의 P를 “Product”, 즉 완성된 제품으로 오해

그래서 최소 기능만 들어간 실제 제품을 만들려고 함

하지만 『인스파이어드』의 관점에서는 MVP는 제품이라기보다 프로토타입에 가까움

핵심은 다음과 같음

• MVP는 판매 가능한 최소 제품이 아님
• MVP는 학습 가능한 최소 실험임
• 실제 제품 수준으로 만들 필요가 없음
• 고객이 원하는지 검증하는 것이 먼저임

실무적으로 보면, MVP를 너무 제품처럼 만들면 다음 문제가 생김

• 개발 시간이 길어짐
• 비용이 커짐
• 실패했을 때 손실이 커짐
• 팀이 학습보다 출시 자체에 집착함
• “만들었으니 밀어붙이자”는 관성이 생김

따라서 좋은 MVP는 작게 만들어서 파는 것이 아니라, 작게 실험해서 배우는 것

9. 제품팀 구조: 수평 협업과 직무 리드 보고

제품팀 안에서는 PM, 디자이너, 엔지니어가 수평적으로 협업함

각자의 직무 전문성은 별도의 리드에게 보고하거나 피드백을 받음

역할	제품팀 내 관계	전문성 관리
PM	디자이너·엔지니어와 수평 협업함	제품 리드에게 보고함
디자이너	PM·엔지니어와 수평 협업함	디자인 리드에게 보고함
엔지니어	PM·디자이너와 수평 협업함	엔지니어링 리드에게 보고함

이 구조의 장점

• 제품팀은 문제 해결에 집중
• 각 직무의 전문성은 별도로 유지
• PM이 모든 사람의 상사가 되는 구조를 피함
• 협업은 수평적으로 하되, 역량 관리는 직무별로 함

10. 제품팀을 나누는 기준: 기능이 아니라 아키텍처

기능 기준 예시

• 검색팀
• 추천팀
• 결제팀
• 알림팀

하지만 책에서는 제품을 구성하는 아키텍처 기준으로 팀을 나누는 관점을 제시함

기준	설명	예시
기능 기준	사용자가 겉으로 인식하는 기능 묶음	검색과 추천
아키텍처 기준	그 기능을 가능하게 만드는 내부 구조와 책임 단위	검색 시스템, 추천 엔진, 데이터 파이프라인

기능 기준은 사용자에게 보이는 단위이고, 아키텍처 기준은 제품을 실제로 지속 가능하게 운영하기 위한 책임 단위

따라서 제품이 커질수록 팀은 단순 기능보다 책임 영역과 시스템 구조를 기준으로 나뉘는 것이 더 적합함