프로세스

이 책에서 가장 실무적인 부분이야. 제품 발견과 전달을 위한 구체적인 기법과 사례를 다루거든. 프레이밍부터 프로토타이핑, 테스팅, 그리고 조직 변화까지 폭넓게 다뤄.

제품 발견의 목표는 네 가지 위험에 빠르게 답하는 거야. 고객이 가치를 느낄까? 사용할 수 있을까? 우리가 만들 수 있을까? 비즈니스에 도움이 될까? 핵심 원칙은 이래: 아이디어를 코드로 만들기 전에 가능한 한 빠르고 싸게 검증해야 해. 그래서 발견 단계에서는 프로토타입과 실험을 활용하지. 강한 팀은 매주 10-20개의 아이디어를 테스트하고, 그중 대부분을 빠르게 버려. 이게 비효율적으로 보일 수 있지만, 실제로는 잘못된 것을 완전히 만들어서 버리는 것보다 훨씬 효율적이거든.

케이건은 발견 기법을 크게 네 가지 범주로 나눠. 프레이밍 기법은 어떤 문제를 풀지 정의하는 것이고, 아이디에이션 기법은 솔루션 아이디어를 만드는 거야. 프로토타이핑 기법은 아이디어를 빠르게 시각화하는 것이고, 테스팅 기법은 그 아이디어가 실제로 작동하는지 검증하는 거지. 이 기법들을 상황에 맞게 조합해서 쓰는 게 중요해. 모든 기법을 매번 다 쓸 필요는 없고, 팀이 직면한 위험에 맞는 기법을 선택하면 돼.

기회 평가는 새로운 아이디어나 기능을 검토할 때 네 가지 질문에 답하는 거야. 어떤 비즈니스 목표에 기여하는가? 어떤 문제를 해결하는가? 누구를 위한 것인가? 성공을 어떻게 측정할 것인가? 이 네 질문에 명확히 답할 수 없다면, 그 아이디어는 아직 추진할 준비가 안 된 거지. 간단하지만 놀라울 정도로 많은 팀이 이 기본적인 질문 없이 바로 구현에 들어가거든. "왜 이걸 만드는 건데?"에 답하지 못하면서 만들기 시작하는 건 지도 없이 항해하는 것과 같아.

아마존에서 유래한 고객 편지 기법은 제품을 만들기 전에 가상의 고객 보도자료 또는 고객 편지를 먼저 쓰는 거야. 제품이 출시된 후 고객이 왜 이 제품을 사랑하는지를 미리 써보면, 팀이 정말 중요한 가치에 집중할 수 있지. 핵심은 기능 나열이 아니라 고객의 관점에서 어떤 문제가 해결되는지를 서술하는 거야. 미래에서 온 편지를 쓰면서 "이 제품이 고객의 삶을 어떻게 바꿨을까"를 상상해보는 거지.

스타트업 캔버스는 린 캔버스를 기반으로 한 프레이밍 기법이야. 한 페이지에 문제, 고객 세그먼트, 고유 가치 제안, 솔루션, 채널, 수익 모델, 비용 구조, 핵심 지표, 경쟁 우위를 정리하지. 특히 새로운 제품이나 사업을 시작할 때 유용해. 기존 제품의 개선에는 기회 평가가 더 적합하고, 완전히 새로운 것을 만들 때는 캔버스가 전체 그림을 잡는 데 효과적이거든. 한 페이지에 모든 핵심 가정을 올려놓으면, 빈 칸이 곧 검증해야 할 위험이 되지.

스토리 맵은 제프 패튼이 만든 기법으로, 사용자의 활동을 2차원으로 시각화하는 거야. 가로축은 사용자의 여정(시간 순서)이고, 세로축은 각 단계의 세부 작업(우선순위 순)이지. 이 맵을 통해 팀은 전체 사용자 경험을 한눈에 볼 수 있고, 어디를 잘라서 MVP를 만들지 결정할 수 있어. 백로그는 맥락을 잃지만, 스토리 맵은 전체 그림 속에서 각 기능의 위치를 보여주거든.

케이건은 모든 PM이 **레퍼런스 고객(reference customer)**을 확보해야 한다고 강조해. 레퍼런스 고객이란 당신의 제품을 사랑하고, 다른 사람에게 추천하고, 사례 연구에 참여할 의향이 있는 실제 고객이야. 고객 발견 프로그램은 타겟 시장에서 6명 정도의 잠재 레퍼런스 고객을 찾고, 그들과 함께 제품을 만들어가는 과정이지. 이 고객들과 매주 만나면서 프로토타입을 테스트하고, 피드백을 반영하고, 그들의 진짜 문제를 깊이 이해해. 이 6명이 진심으로 만족하면, 그 제품은 시장에서도 통할 가능성이 높거든.

고객 인터뷰는 가장 기본적이면서도 강력한 발견 기법이야. 케이건의 핵심 원칙: 솔루션이 아니라 문제에 대해 물어라. "이 기능 좋아요?"가 아니라 "오늘 이 작업을 어떻게 하고 계세요?"라고 물어야 해. 인터뷰의 목적은 아이디어를 검증하는 게 아니라 고객의 맥락, 고통, 행동 패턴을 이해하는 거야. 매주 최소 2-3명의 고객을 만나는 습관이 좋은 PM의 기본이지.

컨시어지 테스트는 제품을 만들기 전에 사람이 직접 서비스를 수행해보는 거야. 자동화할 기능을 수동으로 먼저 해보면서, 고객이 정말 이 서비스에 가치를 느끼는지 확인하지. 예를 들어 음식 추천 앱을 만들기 전에, 직접 고객에게 전화해서 맞춤 추천을 해주는 식이야. 이 기법의 장점은 제품을 한 줄도 코딩하지 않고도 가치 위험을 검증할 수 있다는 거지. 고객이 수동 서비스에도 가치를 느끼지 않으면, 자동화해도 마찬가지거든.

핵 데이는 엔지니어들이 하루나 이틀 동안 자유롭게 아이디어를 프로토타입으로 만들어보는 시간이야. 단순한 복지 행사가 아니라 진짜 혁신의 원천이지. 최고의 제품 아이디어 중 상당수가 핵 데이에서 나왔거든. 핵심은 엔지니어에게 기술이 무엇을 가능하게 하는지 탐험할 자유를 주는 거야. "이런 것도 가능하다니!"라는 놀라움이 종종 가장 혁신적인 기능의 시작점이 되지.

프로토타입의 목적은 배우기 위한 것이지, 만들기 위한 것이 아니야. 실제 제품의 1/5에서 1/10 수준의 노력으로 만들어야 하고, 프로토타입은 일회용이야 -- 프로토타입 코드를 실제 제품에 쓰면 안 되지. 검증하려는 것에 맞는 수준의 충실도(fidelity)를 선택해야 해. 가치를 검증하려면 고충실도, 구조를 잡으려면 저충실도가 적합하고. 프로토타입은 강력한 설득 도구이기도 해 -- 말로 설명하는 것보다 보여주는 게 백 배 효과적이거든.

실현 가능성 프로토타입은 **"이걸 기술적으로 만들 수 있는가?"**라는 질문에 답하기 위한 거야. 새로운 알고리즘, 성능 요구사항, 써드파티 연동 등 기술적 불확실성이 클 때 사용하지. 엔지니어가 주도하며, 보통 하루에서 이틀 정도 투자해서 핵심 기술적 위험을 검증해. 전체 제품을 만드는 게 아니라, 가장 위험한 기술적 부분만 빠르게 확인하는 게 핵심이야.

사용자 프로토타입은 가장 흔하게 사용되는 프로토타입 유형이야. 사용자가 제품을 실제로 사용하는 것처럼 상호작용할 수 있는 시뮬레이션을 만드는 거지. 충실도는 낮은 수준(와이어프레임)부터 높은 수준(실제와 구분 어려운 수준)까지 다양해. 핵심은 사용성 테스트에 활용하는 것으로, 사용자가 제품을 이해하고 사용할 수 있는지를 코드 작성 전에 확인하는 거야. Figma 같은 도구 덕분에 실제와 거의 구분 안 되는 프로토타입도 빠르게 만들 수 있거든.

라이브 데이터 프로토타입은 실제 데이터를 사용해서 제품 아이디어를 검증하는 거야. 추천 알고리즘이나 검색 결과 같은 경우, 가짜 데이터로는 가치를 판단할 수 없잖아. 이때 실제 데이터를 넣어서 결과의 질을 확인하는 프로토타입이 필요하지. 사용자 프로토타입과 달리 엔지니어의 참여가 필수적이며, 좀 더 많은 시간이 들어. 하지만 실제 제품을 만드는 것보다는 훨씬 적은 비용이야.

하이브리드 프로토타입은 여러 유형의 프로토타입을 결합한 거야. 예를 들어 프런트엔드는 사용자 프로토타입으로, 백엔드는 실현 가능성 프로토타입으로 만들어 사용성과 기술적 실현 가능성을 동시에 검증할 수 있지. 위저드 오브 오즈(Wizard of Oz) 프로토타입도 하이브리드의 한 형태로, 사용자에게는 실제 제품처럼 보이지만 뒤에서는 사람이 수동으로 처리하는 방식이야. 하이브리드는 복잡하지만 여러 위험을 한 번에 검증할 수 있다는 장점이 있어.

사용성 테스트는 실제 사용자에게 프로토타입을 주고 특정 작업을 수행하게 하면서 관찰하는 거야. 핵심 원칙: 사용자에게 답을 물어보는 게 아니라 행동을 관찰하는 거지. "이해되세요?"가 아니라 "이 작업을 해보세요"라고 해야 해. 보통 5명만 테스트해도 사용성 문제의 85%를 발견할 수 있어. 케이건은 매주 사용성 테스트를 하라고 강조하거든. 작은 문제를 빨리 잡으면 큰 문제로 커지지 않으니까.

사용성 테스트가 "쓸 수 있는가"를 확인한다면, 가치 테스트는 **"쓰고 싶은가"**를 확인해. 사용자가 프로토타입을 보고 실제로 돈을 내거나, 시간을 투자하거나, 전환할 의향이 있는지를 검증하지. 수요 테스트는 더 넓은 범위에서 시장의 관심을 측정하는 것으로, 랜딩 페이지 테스트나 가짜 문(fake door) 테스트가 대표적이야. 가치는 사용자가 "좋아 보여요"라고 말하는 걸로는 검증할 수 없어. 실제 행동(구매, 가입, 전환)으로만 검증되거든. 말과 행동은 다르잖아.

정성적 가치 테스트는 소수의 사용자와 직접 대면하면서 가치를 검증하는 거야. 고충실도 프로토타입을 보여주고, 사용자의 반응을 관찰하지. 핵심은 사용성뿐 아니라 **"이걸 쓰겠는가"**를 확인하는 거야. 사용자가 기존 솔루션을 버리고 이것으로 전환할 만큼 가치를 느끼는지, 돈을 낼 의향이 있는지를 대화와 관찰로 파악해. 보통 사용성 테스트와 함께 진행해서, 한 세션에서 사용성과 가치를 동시에 확인하지.

정량적 가치 테스트는 통계적으로 유의미한 수의 사용자에게서 데이터를 수집하는 거야. A/B 테스트가 대표적이며, 실제 트래픽의 일부를 새로운 버전에 노출시켜 행동 차이를 측정하지. 정성적 테스트가 "왜"를 알려준다면, 정량적 테스트는 **"얼마나"**를 알려줘. 케이건은 정성적 테스트를 먼저 하고, 그다음에 정량적 테스트로 규모를 확인하라고 권해. 정량적 테스트에는 충분한 트래픽이 필요하므로, 트래픽이 적은 초기 단계에서는 정성적 방법이 더 현실적이야.

실현 가능성 테스트는 엔지니어가 주도하는 것으로, 기술적으로 이게 가능한지, 가능하다면 얼마나 걸릴지를 판단해. 새로운 기술, 성능 요구사항, 확장성, 써드파티 의존성 등이 대상이지. 핵심은 완벽한 답을 찾는 게 아니라 **"이 정도 시간 안에 가능한가, 아닌가"**의 확신을 얻는 거야. 엔지니어를 발견 과정에 일찍 참여시키면, "이건 6개월 걸립니다"라는 소식을 다 만들고 나서야 듣는 비극을 피할 수 있거든.

가치도 있고, 사용도 가능하고, 기술적으로 만들 수도 있어. 하지만 비즈니스에 도움이 되는가? 이 질문에 답하는 게 비즈니스 유효성 테스트야. 마케팅이 이걸 팔 수 있는가? 법적 문제는 없는가? 재무적으로 성립하는가? 기존 제품이나 파트너에 부정적 영향은 없는가? PM은 이해관계자들 -- 법무, 재무, 영업, 마케팅, CEO -- 과 함께 이 질문들을 발견 단계에서 다뤄야 해. 출시 후에 "이건 팔 수 없다"는 말을 들으면 이미 늦거든. 네 가지 위험 중 이 위험이 가장 자주 간과되고, 가장 뒤늦게 발견되지.

디스커버리 스프린트는 구글 벤처스에서 유래한 기법으로, 1주일 만에 아이디어를 프로토타입하고 실제 사용자에게 테스트하는 집중 프로그램이야. 월요일에 문제를 정의하고, 화요일에 솔루션을 스케치하고, 수요일에 결정하고, 목요일에 프로토타입을 만들고, 금요일에 사용자 테스트를 하지. 특히 큰 결정이나 새로운 방향을 탐색할 때 강력해. 일주일의 투자로 몇 달치의 헛수고를 아낄 수 있거든.

조직 전체를 한 번에 바꾸는 건 위험해. 케이건은 파일럿 팀 전략을 권하지. 하나의 팀을 선정해서 이 책에서 말하는 방식으로 일하게 하고, 그 팀이 성과를 내면 다른 팀으로 확산시키는 거야. 파일럿 팀에는 가장 능력 있고 열린 마인드를 가진 PM, 디자이너, 엔지니어를 배치해야 해. 이 팀의 성공 사례가 조직 내부에서 가장 강력한 설득 도구가 되거든. 말보다 성과가 조직을 바꾸지.

현실적으로 로드맵을 하루아침에 없앨 수는 없어. 케이건이 권하는 방법: 먼저 로드맵의 항목들을 비즈니스 성과로 재정의하라. "검색 기능 개발"이 아니라 "검색 전환율 20% 향상"으로 바꾸는 거야. 그다음 팀에게 그 성과를 달성할 방법을 찾을 자율성을 부여해. 이해관계자에게는 커밋먼트가 필요한 소수의 항목과, 발견이 필요한 다수의 항목을 구분해서 제시하지. 점진적으로 발견 항목의 비중을 늘려가는 게 현실적인 전환 경로야. 혁명이 아니라 점진적 변화가 더 지속 가능하거든.

이해관계자는 적이 아니라 파트너야. 케이건은 PM이 이해관계자를 일찍, 자주 참여시켜야 한다고 강조해. 핵심 원칙: 이해관계자에게 솔루션을 물어보지 말고, 제약 조건을 물어봐라. "뭘 만들면 되나요?"가 아니라 "이 솔루션이 당신의 조직에서 문제가 될 부분이 있나요?"라고 물어야 하지. 또한 프로토타입을 보여주면서 피드백을 받으면, 추상적인 논쟁보다 훨씬 생산적인 대화가 가능해. 구체적인 것을 보여주면 구체적인 피드백이 나오거든.

제품 발견에서 얻은 학습은 팀 안에만 머물러서는 안 돼. 발견 결과를 조직 전체와 공유하는 습관이 중요해. 어떤 실험을 했고, 무엇을 배웠고, 왜 이 결정을 내렸는지를 투명하게 공유하면 여러 효과가 있지. 다른 팀이 같은 실수를 반복하지 않고, 이해관계자의 신뢰가 높아지고, 조직 전체의 제품 역량이 성장하거든. 학습을 공유하는 문화가 곧 성장하는 문화야.

케이건은 Apple을 하드웨어와 소프트웨어를 결합한 제품 발견의 대표 사례로 들어. Apple은 끝없는 프로토타이핑과 반복으로 유명하지. 수백 개의 프로토타입을 만들고 버리면서 하나의 제품을 완성해. 핵심 교훈은 Apple이 천재 한 명의 직관에 의존한 게 아니라, 극도로 엄격한 발견 프로세스를 통해 제품을 만들었다는 거야.

Google은 데이터 기반 발견을 가장 잘 실행하는 회사 중 하나야. 대규모 A/B 테스트와 정량적 검증을 일상적으로 수행하지. 동시에 20% 시간(자유 프로젝트 시간)과 핵 데이를 통해 엔지니어 주도의 혁신도 장려해. 정량적 테스트와 엔지니어 자율성의 결합이 지속적인 혁신의 엔진이라는 거야.

Netflix는 실험 문화의 교과서야. 모든 변경 사항을 A/B 테스트로 검증하고, 데이터가 결정을 이끌지. DVD 대여에서 스트리밍으로, 다시 오리지널 콘텐츠로 전환한 것도 강한 제품 비전과 데이터 기반 발견 프로세스 덕분에 성공했어. 작은 실험의 축적이 큰 전환의 근거가 되는 거지.

사티아 나델라 이후 Microsoft가 제품 문화를 어떻게 바꿨는지도 주목할 만해. 과거 Microsoft는 전형적인 기능 공장이었지만, 나델라의 리더십 아래 클라우드 중심 비전을 세우고, 제품 팀에 자율성을 부여하고, 고객 중심 발견을 도입했거든. 대기업도 리더십의 의지와 올바른 비전이 있으면 제품 문화를 근본적으로 바꿀 수 있다는 거야. 크기가 문제가 아니라, 의지가 문제지.

Spotify는 자율적 제품 팀(Squad) 모델로 유명해. 각 스쿼드는 PM, 디자이너, 엔지니어로 구성된 미니 스타트업처럼 운영되지. 관련 스쿼드들은 트라이브(Tribe)로 묶이고, 기술 영역별로는 챕터(Chapter)로 연결돼. 케이건이 강조하는 핵심은 Spotify의 성공이 구조 자체가 아니라 자율성과 정렬(alignment)의 균형에 있다는 거야. 구조만 베끼면 실패해 -- 그 안의 문화와 원칙이 핵심이거든. 형식이 아니라 정신을 배워야 하지.

---

정리

4장 읽고 기억할 거 세 가지:

1. 제품 발견은 가치, 사용성, 실현 가능성, 사업 유효성을 프로토타입과 실험으로 빠르게 검증하는 거야. 매주 10-20개 아이디어를 테스트하고 대부분 버리는 게 오히려 효율적이지.
2. 사용성은 관찰로, 가치는 실제 행동으로, 실현 가능성은 엔지니어의 판단으로 검증해. "좋아 보여요"라는 말은 검증이 아니야.
3. 조직 변화는 파일럿 팀의 성과로 시작하고, 로드맵은 점진적으로 성과 중심으로 전환하라. 최고의 기업들은 모두 체계적인 발견 프로세스와 실험 문화를 가지고 있거든.