INSPIRED: How to make a tech product that customer loves – 요약

이 블로그 포스트는 책 내용을 되새겨 보기 위해 노트 형식으로 정리해 본 것임

PART I: Lessons from Top Tech Companies

대부분의 제품 개발 프로세스가 가진 가장 큰 문제점은 개발하는 제품이 정말 고객에게 필요한지 가장 마지막에 검증된다는 사실이다. 애자일 개발 방법을 도입한 곳에서도 무엇을 개발해야 하는가 하는 고민이 끝난 다음에 제품을 개발하기 시작하기 때문에 동일한 문제가 있다.

새로운 제품 개발의 세 가지 원칙

1. 제품 개발이 감수하는 리스크를 마지막이 아닌 사전에 검증하기
   • Value, usability, feasibility, business viability
2. 제품을 기획, 디자인, 개발하는 것을 순차적으로 하지 않고 협력하여 함께 하기
3. 기능을 구현하는 것이 아니라, 고객의 문제를 해결하는 솔루션을 만들기

제품을 발견하기 —> 개발해야 할 것을 구체화(=backlog 만들기를 )하는 과정

1. Value: 고객이 이 제품을 사용(구매)할 것인가?
2. Usability: 고객이 제품의 사용 방법을 알아낼 수 있는가?
3. Feasibility: 개발자들이 개발할 수 있는 제품인가?
4. (Business Viability ??) 제품의 이해관계자들이 제품을 지원할 것인가? 

먼저 프로토타입을 만들어야 한다 . 프로토타입을 가지고 제품(기능)이 개발할 가치가 있다는 게 검증되고 나면 그때 개발한다. 개발된 제품으로 Product-Market Fit을 검증한다.

Discovery : 프로토타이핑 -> Risk 검증 -> Product Vision 실현
Delivery : 제품 -> Product-market fit 검증 -> Product Vision 실현

이건 순차적으로 하는 것이 아니다. 즉, Discovery에서만 고객을 만나는 것이 아니고, Delivery에서만 제품을 개발하는 것이 아니다.

PART II: Right People

훌륭한 제품 팀

팀은 용병(mercenaries)이 아닌 전도사(missionaries)로 구성되어야 한다

1개 팀의 구성
= Product Manager, Product Designer, 10-12 Engineers (including Engineering manager) + Product Marketing Manager, 1+ Test Engineers, User Researcher, Data Analyst + Delivery Manager

분명한 목표가 팀에 주어지고, 팀이 그 목표를 달성하기 위한 충분한 권한이 주어져야 한다. 그리고 팀은 목표를 달성했는지 여부로 평가받아야 한다. (세부적으로 어떤 일을 해야 할지를 팀이 정할 수 있어야 한다 — 제품 관리자가 아니라 — 그래야 그 일이 그 팀의 일이 되고 오너십이 생긴다 — 참고로 괄호 안 글은 내 맘대로 해석한 내용)

프로젝트 기반으로 팀을 구성하면, 전도사가 아니라 용병이 되기 쉽다. 제품 팀은 해당 분야의 충분한 전문성이 쌓일 정도로 유지되어야 한다.

자율적으로 일할 수 있도록 팀 간의 의존성을 최소화해야 한다

제품 관리자의 역할

사업 기회를 평가하고, 무엇을 만들지 정하며, 제품을 만들어 고객에게 제공하는 것을 책임지는 사람 = 제품의 성공에 대해 책임지는 사람

제품이 성공하면 제품 팀의 모든 사람의 각자의 역할을 잘 해서 성공하는 것이지만, 제품이 실패하면 그건 제품 관리자의 책임이다

제품 관리자는 팀에게 4가지 분야에 대해 기여해야 한다

1. 고객에 대한 깊은 이해
2. 데이터에 대한 깊은 이해
3. 사업과 이해관계자들에대한 깊은 이해
4. 시장과 산업에 대한 깊은 이해

지적 호기심과 새로운 기술을 이해하고 제품에 적용할 수 있는 학습 능력, 문제와 해결책을 구분하여 효과적인 해결책을 제시할 수 있는 능력, 새로운 사업 모델을 만들 수 있는 능력이 필요하다

고객의 문제를 해결하는 것과 그런 제품을 제공하는 것에 대한 열정은 가르칠 수 있는 것이 아니다 (어떤 사람들은 그런 불편함이 눈에 보이고 고치고 싶어 한다 – 예를 들어 개발자의 경우는 기술적인 문제를 해결하고 싶어 한다)

훌륭한 제품 관리자와 좋은 제품 관리자를 구분하는 것은 진정한 리더십이다. 

(진정한 리더십 = 비전을 제시할 수 있고, 의미를 설명해 줄 수 있으며 진정으로 믿고 있으면서, 업무를 충분히 할 수 있을 조각으로 위임하여 조금 불편하지만 도전할 수 있도록 가이드 하고 가르치면서, 팀에 필요한 자원을 구해다 줄 수 있고, 오너십을 가지고 자율적으로 일할 수 있는 환경을 구성해 주면서도 필요할 때는 무자비하게 팀을 끌어 당겨서 꾸물거리는 팀에 모멘텀을 만들 수 있어야 하며, 팀의 비전에 맞는 훌륭한 인재를 설득해서 합류시킬 수 있고, 사소한 것부터 큰 성취까지 축하해 가며 팀원들이 더욱 돈독한 관계가 되어 갈 수 있게 할 수 있어야 하는 것이 진정한 리더십이 아닐까 한다. 참고로 저자는 “Leadership inspires and sets the direction, and management helps get us there”라고 하면서 리더십과 매니지먼트를 구분해서 얘기하더라)

Product Manager의 최고 중요 자질 = Smart, creative, and persistent

• Smart – 지적인 호기심이 높고 빠르게 배우고 배운 것을 적용하며, 고객, 사업에 있어서 새로운 접근을 시도하는 자질
• Creative – 사업 상에 발생하는 문제를 다른 시야를 가지고 해결할 수 있는 자질
• Persistent – 설득력있는 근거를 가지고 지속적인 커뮤니케이션을 통해서, 팀을 불편하지만 도전적인 업무를 수행할 수 있도록 할 수 있는 자질

제품 관리자에게 가장 필요한 자질은 Smart, Creative, Persistent이기 때문에 사실 어떤 특정 전공이 더 유리한 것이 없다. (Discovery, Delivery, and Go-to-market이 순차적이 아니라, 모두 함께 고려되어야 하는 복잡성 때문에 제품 관리자는 이러한 자질이 필요한 것 같다. 근데 좀 추상적이다.)

Product Designer

제품 디자이너가 하는 일 – Product Discovery 참여, Holistic UX Design, Prototyping, User Testing, Interaction and Visual Design

디자인이 아닌 제품의 성공으로 측정되어야 한다 (이건 디자이너에만 국한되는 문제는 아닐 듯 하다).

개발자 (Engineers)

제품 관리자는 개발자와의 관계보다 더 중요한 관계는 없다 .

개발자가 고객의 고통을 공감하고 해결책에 매진할 수 있도록 더 많이 소통하라 – 그렇지 않으면 용병이 된다.

제품 관리자는 디자이너, 개발자가 각각이 일하는 스타일이 있는 부분에 민감하게 반응하여 가장 효과적인 협업 방법에 대해 계속 고민해야 한다.

Product Marketing Manager

여러 제품 팀에 파트 타임으로 속해 있을 가능성이 높다. 제품 팀에게 시장을 대변하는 사람으로써, 제품의 포지셔닝, 메시징, go-to-market 계획을 제공한다.

(시장 진입 전략 Go-to-market plan = 타겟 고객군에게 제품을 전달하고 경쟁력을 확보하기 위한 구체적인 실행 계획으로써 보통 신규 제품을 소개할 때 준비하게 된다. 구성 요소는

• 타겟 시장을 정의하기
• 구매 고객을 정의하기
• 가치 제안을 정의하기
• 가격 정책을 정하기
• 마케팅과 프로모션 방법을 정하기
• 판매 채널 전략을 세우기

이 있음)

Product Discovery 단계에서 참여하고 팀에게 시장의 반응을 전달해야 하며, Go-to-market plan을 만들어 가야 한다

Supporting Roles

User Researchers – Qualitative, quantitative, generative, evaluative learning을 팀과 함께 하고 공유할 수 있어야 한다. 

Data analyst – 데이터의 수집과 해석을 제공하며, 개인 정보 보호를 책임지는 사람

Test Automation Engineer – 제품을 자동 테스트할 수 있는 기반을 만드는 사람

(전통적인 QA는 고객이 어떤 경험을 하게 되는지가 주요 판단 기준인 반면에 책에서 다루는 Test Automation Engineer는 소프트웨어 제품의 버그를 찾는 역할을 하는 듯 하다. 비록 저자는 QA를 매뉴얼하게 테스트를 하는 사람이고 Test Automation Engineer가 대체 중이라 하는데, 아마 업무의 범주는 동일하되 수동인가, 자동인가 하는 차이점을 가지고 논의하는 듯하다)

People at Scale

VP product, Director of product, principle product manager – 제품 관리자와 제품 팀의 성과를 모니터링하고 문제가 되는 지점을 파악하고 해결해 주는 역할. 네 가지 핵심 역량이 필요함

1. Team development – 다른 제품 관리자를 성장시킬 수 있는 역량이 필요하다. 가장 중요하다.
2. Product vision – 회사와 제품의 비전에 대해 CEO를 보완할 수 있는 사람
3. Execution – Product discovery, delivery, product development 에 우수한 사람으로 이해관계자와 내부의 설득에 있어서 뛰어난 역량을 지닌 사람
4. Product culture – 빠르며 지속적인 실험과 학습이 중요하다는 것을 알고 있으며, 학습을 위해서는 시행착오가 필수적이고 이를 위한 시간을 줄여야 한다는 사실을 알고 있고, 제품 관리자, 디자이너, 마케팅 매니저, 개발자와의 협력 없이는 훌륭한 제품을 만들 수 없다는 사실 (그들이 맡은 역할)에 대해 이해하며, 용병이 아니라 전도사로써 일해야 한다는 것을 알고 있는 문화
5. 
   

CTO, VP engineering – 전체 제품이 어떻게 구현되는 지를 관리하고 기술 부채를 관리하는 사람. 6가지 책임을 진다.

1. Organization – 팀원들을 성장시키고 숙련시키는 것을 중요하게 생각하는 관리 팀을 구성하는 것
2. Leadership – 전략의 방향에 따라 기술에 대해 책임
3. Delivery – 빠르고 안정적이며 완성도 있는 제품을 내 보내며 기술 부채를 관리하는 것
4. Architecture – 제품의 기술과 안정성, 스케일을 항상 제공할 수 있는 시스템 구조를 관리하는 것
5. Discovery – 개발자들이 Product Discovery에 참여할 수 있도록 하는 것
6. Evangelism – 회사의 개발 역량을 외부에 알리고, 내부의 개발자 외의 사람들과 얘기하며 개발 조직에 필요한 부분을 파악하는 것

CDO, VP design, principle product designer – (여러 제품 팀이 함께 만들고 있는) 전체 제품이 고객이 어떻게 비춰지는 지 처음부터 끝까지를 리뷰하는 사람

Delivery Manager – 제품 관리자를 지원하는 포지션으로 팀이 속도를 내는 것을 방해하는 모든 것을 파악해서 없애는 역할. 애자일 개발론에서 Scrum Master 역할. Project managment를 수행함.

Principles of Structuring Product Team

규모가 커진 회사에 여러 제품 팀으로 나눌 때 어떻게 나눠야 하지?

• 의존성을 최소화하는 방향으로 나누기
  
• 오너십과 자율성을 보장하는 방향으로 나누기
• 제품의 비전과 전략에 따라 나누기
• 공동의 필요한 부분을 제공하는 레버리지 중심으로 나누기
• 회사에 투자하는 리소스를 기반으로 나누기
• 팀 사이즈, 제품 구조, 대응하는 사용자나 고객, 회사의 사업 분야에 따라 나누기

위임과 자율성을 보장하되, 의사 결정을 못하거나 제약 조건을 가지고 있다고 느끼는 세부적인 부분을 찾아서 해결해 주어야 한다

PART III: Right Product

Outcome vs. output – Outcome은 사업적인 성과이고, output은 (제품과 같은) 산출물이다. 이 책은 output이 아니라 outcome에 집중해야 하는 것이 핵심이다.

경영팀은 (1) 구성원이 우선 순위가 높은 일을 하고 있는지 확신이 있어야 하고, (2) 제품 외의 마케팅, 세일즈, 관계사와의 협력 등의 다른 업무 또한 함께 일정과 리소스를 조율하기 위해서 계획이 필요하다. 이러한 이유로 우선 순위가 매겨진 기능 및 프로젝트 리스트(=제품 로드맵)을 보통 원하게 되는데, 이는 제품이 실패하는 가장 큰 이유 중에 하나이다.

Product Roadmap

로드맵을 그려두면 팀원들은 보통 이를 꼭 지켜야 하는 리스트로 보기 때문에 사업적인 성과(outcome)이 아니라 output (산출물)에 집중하게 되는 실수를 하게 된다. 로드맵 대신, 전체 회사가 성취 하려는 제품의 비전과 전략, 그리고 각 팀 별로 성취해야 하는 사업 목표(+ 목표의 성취 여부를 측정하는 방법)에 대해 팀과 커뮤니케이션하는 것이 필요하다. 즉, 사업의 맥락을 전체 팀원들과 공유하는 것이 필요하다. 제품 아이디어가 아닌 사업 성과를 리스트업하고 순위를 매기도록 해야 한다.

간헐적으로 마감일이 필요한 사업 성과들에 대해서만 마감일을 추가하고 high-integrity commitment를 요청한다.

High-Integrity commitment – 보통 마감일을 설정하는 것이 아직 정확한 일정을 산정하기 힘든 초기(discovery 중)에 요구되기 때문에 이를 늦추며 마감일을 설정할 수 있는 시간이 되면 그때 마감일을 정하게 되는 것

(마감일이 없는 일을 스스로가 도전적인 목표로 삼고 도전할 수 있도록 만들 방법은 무엇인가?

• 애시당초 그런 목표를 성취하기 위해 달려가는 것이 습관이 되어 있는 사람과 일 하기
• 자신이 일정을 확인해서, 이후에 쉽게 수정할 수 있는 임시 목표를 세우는 것 – 이때 제품 관리자의 승인을 얻어서 하는 것)

좋은 회사에서는 이러한 commitment가 최소화되어 있다 — 왜냐면 이미 사람들이 그런 commitment 없이도 고객의 문제를 찾아 솔루션을 제공하는 것에 대해 열정적이기 때문이다. (하지만 모든 스타트업이 그런 인재를 갖추고 있진 않다. 그렇기 때문에 절충된 방법이 필요하다)

Product Vision & Strategy

회사의 미션 (예: 세상 모든 사람을 연결하기)은 구성원이 함께 만들어 가려는 미래에서 고객들이 받는 가치에 대한 정리된 문장인 반면에, Product Vision은 그러한 미래를 어떻게 성취할 것인지(예: 세상 모든 사람이 다른 사람들과 일상을 나눌 수 있는 모바일 앱)을 나타낸다.

스토리보드나 프로토타입으로 Product Vision을 구성원과 공유하고, 구성원이 그런 미래를 현실로 만들수 있도록 도와야 한다.

Product Strategy는 Product Vision을 실현하기 위해서 순차적으로 릴리즈 할 제품들을 나타낸다. Product Vision은 영감을 줄 수 있어야 하고, Product Strategy는 우리가 현재 어디에 집중해야 하는지를 나타낸다.

Principles of Product Vision

1. 왜 라는 질문으로 시작하기
2. 솔루션이 아닌 고객 문제와 사랑에 빠지기
3. 큰 비전을 생각하는 것에 대해 두려워 말기
4. 원래 사업을 잠식하는 것을 두려워 말라. 당신이 아니면 다른 사람이 한다
5. Product Vision은 영감을 줄 수 있어야 한다
6. 세상이 변화해 가는 트렌드를 포괄해야 한다
7. 어느 방향으로 제품이 흘러가는 지를 봐야 한다
8. Product Vision에 대해서는 집착하되 디테일에 있어서는 융통성 있어야 한다
9. Product Vision은 합리적인 결과가 아니라 믿음이 동반되어야 한다는 것을 인식하라
10. 지속적이며 지치지 않는 열정으로 설파하라

(책에서 제안하는 신규 사업 찾기는 

• 미션 -> Product Vision -> Product discovery -> delivery -> go-to-market plan -> growth …)

Principles of Product Strategy

1. 한번에 하나의 시장 버티컬이나 고객군에 집중하기
2. Product Strategy는 사업 전략, 세일즈 전략, Go-to-market 전략과 맞물려 있어야 한다
3. 경쟁사가 아닌 고객에 집착하라
4. 전체 구성원과 Product Strategy에 대해 끊임없이 소통하라

Product Principles

Product vision은 만들려는 미래를 묘사한다. Product Strategy는 어떤 경로로 그런 미래를 만들어 갈 것인지를 알려준다. Product principles은 만들려고 하는 제품의 속성에 대해 알려 준다.

예를 들어 eBay에서는 구매자의 요구 사항과 판매자의 요구 사항에 있어서 이해 관계가 있다면, 구매자의 요구 사항을 더 우선 순위로 둔다는 원칙이 있었다.

Product Objectives

원칙

• 구성원들에게 어떻게 해야 하는지를 알려주려고 하지 말고 무엇을 해야 하는지 (=무엇을 성취해야 하는지)를 알려주기
• 성과 측정은 사업적인 성과를 측정하는 것임

OKR – Objectives and Key (Business) Results

Objectives

• 목표는 정성적이어야 하고, 1~3개의 적은 수로 유지해야 한다. 
  

Key Results

• 산출물이나 업무가 아니라, 성취라고 할 수 있는 사업 성과로 설정해야 한다.
• 각 팀은 매 주 이를 측정할 수 있어야 한다.
• 보통 0.0에서 1.0의 중간 값으로 측정하고, 0은 성과가 없는 것, 0.3은 최소한의 성취, 0.7은 기대한 수준의 성취, 1.0은 모든 사람이 놀랄만한 성취로 측정하기.
• High-integrity commiment의 경우는 목표를 0.7로 해야 하고, 이런 종류의 Key Results는 모두가 알 수 있게 표기하고 커뮤니케이션 해야 한다.
  

계층 구조를 가진다 : Company OKR <— Organization OKRs <— Individual Product Team OKRs

특정 기능을 제공하는 회사 내의 조직의 경우 Objectives가 사업 성과가 아닐 수 있다. 이때는 Leadership 레벨에서 사업 성과 Objectives와 함께 충분한 논의가 이뤄지고 우선 순위가 결정 되어야 한다.  구성원 개인의 성장을 위해서 1-2개의 Objective를 가지는 것은 괜찮고 필요하다.

Product at Scale

OKR이 큰 규모의 회사에서 사용될 때 Leadership 팀 (경영진)이 하위 조직과 팀의 Objectives가 전체 회사의 Objectives에 얼마나 합치되어 있는지를 관리하는 것과 개별 팀과 구성원이 전체에서 어떤 역할을 하는지를 명확히 이해하게 하는 것이 중요해 진다.

Product Evangelism

제품이 가져다 줄 미래를 상상하고 제품 팀의 구성원이 이런 미래를 만들어 갈 수 있는 제품을 만들도록 영감을 주는 일로써, 제품 관리자의 가장 중요한 책임 중에 하나이다.

방법론

1. 프로토타입을 사용하기
2. 고객의 고통을 공유하기
3. Product Vision을 공유하기
4. 성공으로 이끈 내용과 더불어 실패한 노력으로 얻은 학습한 내용을 공유하기
5. 자신의 제품이 아니라 팀의 제품인 것을 얘기하고 잘 되지 못한 것에 대해 인정하고 팀에 사과하기
6. 시연을 잘 하는 방법을 마스터하기
7. 고객과 시장, 경쟁자, 그리고 시대의 흐름에 대해 전문가가 되기
8. 진심으로 열정을 가지기
9. 진심이 담긴 열정을 전달하는 방법을 익히기
10. 팀원 개인들과 많은 시간을 가지기, 그러면서 열정을 전달하기

PART IV: Right Process

Product Discovery

많은 실험을 낮은 비용으로 빠르게 실천하며 빠르게 학습해야 하며, 동시에 완성도 있는 제품을 릴리즈할 수 있어야 한다. 모순적으로 보이는 두 가지 목표를 동시에 실현할 수 있어야 한다.

Principles of Product Discovery

Discovery에서 검증해야 하는 위험 요소들

1. (Value risk) 고객이 구매할 것인가?
2. (Usability risk) 고객이 제품을 사용할 방법을 (쉽게) 알아 낼 수 있는가?
3. (Feasibility risk) 개발팀이 만들 수 있는 제품인가?
4. (Business Viability risk) 우리 사업의 요구 사항에 맞는 제품인가? (회사의 이해관계자들이 모두 지원할 수 있는 제품인가? 비용, 수익 면에서 사업화가 가능한 제품인가?)

추가로 Business Viability risks 상세하게 보면

• Financial risk – 제품을 만들고 팔 수 있는 과정을 지탱할 재원이 있는가?
• Business development risk – 협력사가 도입하고 효과를 볼 수 있는 것인가?
• Marketing risk – 우리 브랜드와 일관적인 것인가?
• Sales risk – 세일즈 팀이 팔수 있는 솔루션인가?
• Legal risk, ethical risk

Product Discovery의 원칙

1. 고객이 어떤 제품을 만들어야 하는지 얘기해 줄 수 없다 (할 수 있다면 이미 있다)
2. Value risk가 가장 위험하다
3. 개발보다 UX가 더 어렵고 성공에 있어서 더 중요하다
4. 기능, 디자인, 기술이 모두 혼합되어 서로 엮여 있다
5. 대부분의 아이디어는 의미없을 것이고 동작하는 것도 여러번의 반복 개선을 통해야 한다
6. 실제 고객에게 검증해야 한다
7. 목표는 가장 빠르고 저렴하게 사업 아이디어를 검증하는 것이다
8. 개발 가능한 제품인지를 Product Discovery 단계에서 검증해야 한다 (엔지니어와 함께 해야 한다)
9. 우리 사업의 요구 사항에 맞는 제품인지를 Discovery 단계에서 검증해야 한다
10. 전도사 팀과 함께 학습하는 것이 가장 중요한 것이다

윤리적인 문제 때문에 사업화될 수 없는 것도 있다 (팀이 반대하거나 용병으로 전락하거나 …). 사전에 검토가 필요하다.  훌륭한 제품 팀은 10-20번의 반복 학습 (iterations)를 할 수 있다 (으아!).

Discovery Techniques

Framing – 어떤 리스크가 사전 검증되어야 하는 지를 식별해 내는 방법 Planning – 가장 큰 위험을 식별해 내고 어떻게 해결할 것인지 계획을 세우는 방법

Ideation – 팀이 집중하고 있는 고객 문제를 해결할 솔루션에 대한 아이디어를 얻는 방법

Prototyping – 프로토타이핑을 만들고 리스크를 검증하는 방법

Testing – Value, Feasibility, Usability, Business Viability를 테스트하는 방법들

Transformation – 조직이 일하는 방법이 변해야 하는 경우에 사용되는 방법

Discovery Framing

아이디어를 더 검증해 보기 전에 다각도로 짧게 살펴보고 검증해야 할 리스크를 식별하는 테크닉

Opportunity assessment

• 아주 작은 기능부터 중간 사이즈 프로젝트를 위한 테크닉
• Objectives, Key results, Customer problem, Target market을 정의해 보기

Customer letter

• 매우 큰 프로젝트나 복잡한 산출물을 기획할 때 사용하는 테크닉
• 제품을 정말 만족하는 고객이 감사의 뜻으로 CEO에게 보내는 편지를 써 보는 것

Startup canvas

• 완전 새로운 사업을 기획할 때 사용하는 테크닉
• http://gsong.pe.kr/startup/2012/12/02/eb-a6-b0-ec-ba-94-eb-b2-84-ec-8a-a4-lean-canvas-ec-9e-91-ec-84-b1-ed-95-98-eb-8a-94-ec-9a-94-eb-a0-b9.html
• 자신이 잘 알고 있는 분야의 리스크가 아닌 가장 큰 위험에 집중하는 것이 필요하다

Discovery Planning 

Story maps

• Backlog가 사업 상의 맥락이 없는 점을 보완하기 위한 것

Customer Discovery Program

– Reference Customer

• 레퍼런스 고객 = 실제 제품을 쓰고 있고, 가격을 지불하고 있으며, 앞장서서 주위 사람들에게 제품을 소개 할 정도로 만족하고 있는 고객
  
• 제품을 만드는 조직에 레퍼런스 고객보다 더 중요한 것은 거의 없다

– Customer Discovery Program

• Product discovery와 delivery를 하는 과정에서 이런 레퍼런스 고객을 발견하고 만들어 가는 것을 병행하는 방법
• 다른 기법에 대비해서 상당한 노력을 필요로 한다
• Rule of thumb – 타겟 마켓의 레퍼런스 고객 6곳이 필요하다

– Recruiting Reference Customer 

• 기술적인 호기심으로 관심을 보이는 고객을 제외해야 함 (특히 개발자)
• 불완전한 제품이라도 쓰고 싶어할 정도로 고통을 느끼는 고객을 찾아야 한다
• 하나의 Target Market에 속한 고객들을 찾아야 한다

– 고객의 부류에 따라 찾아야하는 고객의 수

• Platform/API Products – 우리 API를 사용하는 6개 이상의 레퍼런스 애플리케이션들을 찾는 것임
• Customer Enabling-Products – 6-8명의 인플루언서라 할 수 있는 빅 네임들을 찾아야 함
• Consumer Products – 10-50명의 제품을 사용하는 고객을 확보해야 함

Discovery Ideation

– 사업의 성과에 대한 목표치로써 고객의 문제가 주어지고, 이 문제를 가진 고객과 자주 만나고 얘기를 들을 수 있으면 제품에 대한 아이디어를 얻는 것은 어렵지 않다.

– Customer Interview – 인터뷰를 통해 학습해야 하는 것

• 정말 이 고객이 우리가 이해하고 있다고 생각되는 고객이 맞는가?
• 우리가 생각한 고객 문제를 이 고객이 정말 가지고 있는가?
• 고객은 그 문제를 현재는 어떻게 해결하고 있는가?
• 이들이 제품을 바꾸려면 어떠한 것이 필요한가?

– 인터뷰 팁

• 인터뷰를 통해서 무언가를 검증/증명 할 수는 없다. 대신에 고객에 대해 빠르게 배우는 방법이다.
• 가능하면 고객이 문제를 느끼는 원래의 장소에서 인터뷰를 하게 하라.
• Product Manager, Product Designer, Engineer 이렇게 세 명이 하는 것이 좋다

– Concierge Test – 실제 고객에게 가서 현재 문제를 해결하는 방법을 알려달라고 한 뒤, 그 해결책을 실제로 서비스로 제공하면서 더 나은 솔루션에 대한 영감을 얻는 방법

– Power of Customer Misbehavior – 제품 아이디어를 획득하는 세 가지 큰 접근 방법 중 하나

1. 심각한 고객 문제가 있고 시장 기회가 있는 곳을 선택하기
2. 기술과 데이터가 새롭게 가능하게 하는 분야 중에 심각한 고객 문제가 있는 곳 선택하기
3. 제공하고 있는 제품을 다른 목적으로 사용하는 것을 장려하고 고객이 어떻게 쓰는지 보기

– API를 제공하는 것은 개발자 커뮤니티에게 3번에 해당하는 방법으로 제품 아이디어를 얻기 위함이다

– Hack Day

• 개발자가 새로운 제품 아이디어를 낼 수 있도록 장려하게 된다
• 구성원이 전도사가 되는 문화에 기여할 수 있다

Discovery Prototyping

Principles of Prototyping

1. 제품을 개발하는 노력과 비용 대비 훨씬 값싼 방법으로 학습 하기 위해 프로토타이핑을 한다
2. 제품 아이디어에 대해 얘기하고 글로 쓰는 것보다 훨씬 깊은 레벨로 문제에 대해 고심하게 한다
3. 팀 내부의 협업에 큰 도움이 된다
4. 목적에 적합한 충성도(Fidelity)로 프로토타이핑을 해야 한다
5. Prototype as a spec으로 개발자와 커뮤니케이션 하는데 사용될 수 있다

Feasibility Prototype

– 체크 포인트 : Algorithm, performance, scalability, fault-tolerant, use of a new technology, use of a 3rd party tool, use of a legacy system that has not used before, dependency on new or related changes by other teams

– 보통 하루 이틀이면 검증이 끝나니 꼭 체크하고 가자

User Prototype

– 사전에 식별된 제품이 가지는 리스크를 검증하기 위해 제품의 일부만 만들어서 고객 대상으로 테스트하기 – Product Designer 가 담당 – 검증을 하기는 좋지 않은 방법이나 학습을 하고 팀 내부의 커뮤니케이션을 위해 필요하다

Live-Data Prototype 
– 어떤 사실을 증명하기 위한 백데이터를 모으기 위한 프로토타입 – 적용 분야 : game dynamics, search result relevance, social media features, product funnel work – 실 제품을 만드는 노력의 5-10% 노력으로 만들 수 있어야 한다

Hybrid Prototype
– 예: Wizard of Oz prototype – 프론트엔드는 멋지게, 백엔드는 사람이 수작업으로 하기

– 결국 빠르게 학습을 할 수 있는 툴을 재치있게 만드는 것

Discovery Testing

실제 Product Discovery에서 답을 얻어야 하는 질문들에 대해 답을 얻기 위한 테스트 방법들

• Value, Usability, Feasibility, Business Viability

요컨데, Value, Usability를 고객군을 대상으로 테스트하고, 내부 엔지니어들과 Feasibility 테스트를 한 다음에, 회사의 각 stakeholder들에게 프로토타입을 보여주고 설명하여 제품 출시에 문제가 될 수 있는 부분을 사전 검증하는 것

리스크를 감내하지 않는 문화를 가진 대기업에서 테스트를 하기 위해서는 (1) 회사의 매출과 브랜드를 보호하면서, (2) 직원과 고객들을 보호하면서 Discovery Testing을 해야 한다.

1. 매출과 브랜드 보호 – 아주 적은 소수의 고객 대상으로 테스트하기, Invite-only 혹은 NDA 대상과 하기
2. 직원과 고객을 보호 – 제품을 조금씩 배포하고, 배포 뒤에 고객 영향을 평가하기

Test Usability

1. 테스트 할 사람 모으기
   • Customer discovery program
   • 알바 구함 사이트 혹은 검색 키워드 마케팅
   • 회사 내의 자원자 구하기
   • 대상 고객군이 모이는 행사에 참여하기
   • Starbucks에서 하는 Starbucks 테스팅
2. 테스트 준비하기
   • High-fidelity prototype을 준비해서 Value testing과 함께 하기
   • Product manager, product designer, engineer가 한 팀이 되서 하기
   • 테스트를 하려는 태스크들을 사전에 정의하기
   • 리모트 테스트도 가능하나, 뒤 이어 해야 하는 Value Test를 할 수 없다
3. 테스트 진행
   • 진짜 개발할 제품이 아니라고 얘기해 줘서 진실된 피드백을 편하게 할 수 있게 하기
   • 최초 랜딩 페이지를 보여주며 이게 어떤 제품인지 얘기를 들어보기
   • 제품을 비평하는 게 아니라 사용하도록 사용자를 리드하기
   • 고객이 제품을 사용하고 있을 때는 입 닫고 있기
   • 고객에게 도움을 주지 않고 뭘 하는 지는 물어봐도 괜찮다. 계속 뭘 하는지 얘기하도록 하는 것은 고객이 비평 모드로 전환될 수 있으므로 피하자
   • 앵무새처럼 얘기하기 : 고객이 하고 있는 행동을 얘기해 주면, 왜 그걸 하고 있는지 보통 답을 한다. 예를 들어, 이거 클릭하면 구매가 되나요? 아 그걸 클릭하면 구매할 것처럼 느껴지나요? 
   • 고객이 제품을 어떻게 사용하려 하느냐를 관찰하면서 고객이 문제를 어떻게 인식하고 있는지에 대해 관찰할 수 있다. 예상과 다른 방식으로 제품을 사용하려는 행동은 제품 팀이 고객의 문제에 대해 잘못 이해하고 있는 것을 나타낸다
4. 학습한 것 요약하기
   • 학습한 것이 있으면 바로 프로토타입을 수정하기 – 빠르게 학습하는 것이 목표이지 뭔가를 증명하려는 것이 아니다

Value Testing

– 우리 제품을 누군가가 사용한다는 것이 그가 우리 제품에 가치를 느낀다는 것은 아니다

– Demand Testing

• 기존 제품보다 훨씬 더 큰 가치를 제공하는 제품인가?
• Fake door (or landing page) demand testing
  • 기능을 제공하는 것처럼 보이는 버튼(웹사이트)를 제공하고, 이를 클릭하면 인터뷰 대상으로 모시기
  • 수요를 정량적으로 측정할 수 있고, 정성적인 학습을 할 수 있는 고객을 확보할 수 있다

– Qualitative Value Testing

• Interview first -> Usability test & value test
• 고객이 제품을 사용하고 나서야 제품의 가치를 논할 수 있다. 그렇지 않으면 focus group interview처럼 고객이 제품을 상상해야 하고 가설이 넘치는 제품에 대한 피드백을 받게 된다
• 그러므로 Value testing을 위해서는 high-fidelity user prototype이 필요하다
• 고객이 좋은 말 피드백만 남기지 않을 수 있는 기제가 필요하다
  • 고객이 정말 필요한 것이라고 하면 구매를 하겠냐고 물어보라 (B2B의 경우 Non-binding letter of intent to buy 를 쓰게 하라)
  • (친구 혹은 B2B에서 상사)들에게 추천하겠냐? 바로 SNS공유 혹은 상사에게 이메일을 써 줄수 있겠냐?
  • B2B의 경우 긴 시간을 할애하는 스케줄을 잡는 것으로도 검증이 가능하다
  • 우리 제품으로 데이터를 이동시켜 주겠다고 하며 기존의 대안 제품에 대한 ID/PW를 물어보기

– Iterating Prototype – Qualitative Value Testing은 검증하려는 것이 아니라 빠른 학습을 위한 것이다. 고객의 피드백을 분석해서 제품이 필요한지, 문제를 해결하고 있는지를 판단하고 다른 접근 방식을 테스트해 보라. 

– Quantitative Value Testing

• Qualitative value testing은 빠른 학습을 위한 것인 반면에, Quantitative Value Testing은 (Live-data prototype을 사용해서) 증거를 만들 기 위한 것이다
• Qualitative testing은 이유를 설명해 주지만, Quantitative testing은 사실만 알려준다
• 방법 : A/B Testing, Invite-Only Testing, Customer Discovery Program

#참고 : Product Manager로써 Quantitative testing을 하기 위해서 애널리틱스와 친숙해야 한다

• User behavior analytics (click paths, engagement)
• Business analytics (active users, conversion rate, lifetime value, retention)
• Financial analytics (ASP, billings, time to close)
• Performance (load time, uptime)
• Operational costs (storage, hosting)
• Go‐to‐market costs (acquisition costs, cost of sales, programs)

Testing Feasibility

– Feasibility prototyping을 하는 것과 동일

– [다시 한번!] 체크 포인트 : Algorithm, performance, scalability, fault-tolerant, use of a new technology, use of a 3rd party tool, use of a legacy system that has not used before, dependency on new or related changes by other teams

– 이거 개발할 수 있나요? (X) —> 이거 개발하는 최적의 방법은 무엇이고 얼마나 걸릴까요? (O)

Discovery for Hardware Product – 어떤 제품을 만들어야 하는 지에 관한 실수가 소프트웨어 보다 더 큰 비용을 초래함 – 프로토타이핑이 더욱 더 중요하다

Testing Business Viability

이 제품이 사업적으로 생존가능한가?

• 우리 회사의 사업과 부합하는가 (=회사의 이해관계자들이 모두 제품 출시에 동의할 수 있는가)
• 다 만들어 놨는데 다른 부서 헤드가 이 문제 때문에 출시 없다 — 라고 하는 리스크 관리하기

방법

• 제품을 만들기 전에 (Product Delivery 진입 전에) 각 부서의 리더들과 만나서 제품을 설명하고 염려되는 부분을 피드백 받아서 사전에 해결하기
• 프로토타입을 가지고 기능 하나 하나를 설명하며 함께 사용해 보기
• 부서들 : Marketing, Sales, Customer Success, Finance, Legal, Business Development, (Compliance,) Security, CEO/COO/GM

Transformation

용병 스타일의 제품 로드맵이 드라이브하며 산출물 중심적인 팀에서

권한을 위임받고 사업적 성과로 진행 속도를 살필 수 있는 책임을 지는 진정한 제품 팀으로 변신하기 위한 테크닉

Discover Sprint – 일주일 단위로 주요 사업적인 문제나 위험 요소를 해결해 보려는 노력을 해 보는 것

Pilot Team – Product Discovery 활동을 먼저 시행해보는 파일럿 팀을 운영해 보는 것

Roadmap 떼어내기 – 기존 제품 로드맵에 사업 성과를 추가하고, 이 일은 이런 사업 성과 때문에 하는 것이라는 걸 계속 커뮤니케이션하기

Communicating Product Learnings – 1-2주에 한번 15-30분 정도 시간으로 그간 학습한 것을 회사 전체에 공유하는 방법

Process at Scale

제품을 만드는 지금까지 소개된 방법을 제도화 하려는 순간 혁신은 멈추고 만다.

Managing Stakeholders

Business viability를 체크하는 것과 동일함. 다만, Product Manager가 Stakeholder 들의 모든 염려에 대해 알고 있어야 하고, 그들의 염려에 대해 진정으로 해결할 수 있는 솔루션을 찾는 노력을 하고 있다는 신뢰가 필요하다. 그런 노력을 지속적으로 하고 있다는 것을 계속 알려야 한다. 그리고 high-fidelity prototype으로 walkthrough 해야 한다.

#참고: 좋은 제품 팀이 (훌륭한 팀이 되지 못하고 오히려) 나쁜 팀이 되는 케이스

– 성장이 멈춰서 Product Discovery를 하지 못하는 대기업의 리더들을 주요 리더십팀 멤버로 채용하는 경우

– 더 구체적으로 Product Discovery를 계속하지 못하는 Weak Product Company의 사람을 채용하는 경우다

PART V: Right Culture

Good Product Team/Bad Product Team

Ben Horowitz의 Good Product Manager/Bad Product Manager 원문
https://a16z.com/2012/06/15/good-product-managerbad-product-manager/

Good Product Team/Bad Product Team 원문
https://svpg.com/good-product-team-bad-product-team/

혁신을 잃게되는 가장 큰 이유들

다음 속성 중에 하나를 잃게 되면 혁신을 잃는다

1. 고객 중심의 문화
2. 강력하고 설득력있는 Product Vision
3. 한 번에 한 고객군, 타겟 시장을 공략하는 Product Strategy
4. 훌륭한 Product Manager
5. 충분한 시간이 주어지는 Product Team
6. Product Discovery에 개발자가 참여하는 문화
7. 위험을 감수하려는 대기업의 용기
8. 권한을 위임받은 Product Team
9. IT-마인드셋 (소프트웨어 개발을 도구로 생각하고 아웃소싱하거나 별도 부서로 운영하는 마인드셋)이 아닌 제품 중심의 마인드셋
10. 혁신을 수행할 시간

혁신의 속도를 잃게 되는 가장 큰 이유들

속도가 늦어진다고 싶을 때 확인해야 할 요소들

1. 기술 부채
2. 훌륭한 Product Manager가 있는가
3. Delivery Management가 제대로 동작하는가
4. 충분히 자주 제품 릴리즈를 하는지 여부
5. Product Vision과 Strategy의 존재 여부
6. 같은 위치에 있고 고객을 이해할 시간이 시간이 충분히 주어진 팀이 있는지 여부
7. Product Discovery에 Product Manager, Designer, Engineer가 모두 참가하는지 여부
8. 사업 성과에 대한 우선 순위가 너무 빠르게 바뀌진 않는지
9. 다수결 문화

훌륭한 제품 문화를 만들기

훌륭한 혁신 문화 + 훌륭한 실행 문화가 되면 훌륭한 제품 문화가 만들어 진다

훌륭한 혁신 문화

• 실험하고 실패하며 배우는 문화
• 어디서든 좋은 아이디어와 피드백을 받아들일 수 있는 오픈 마인드
• 전적으로 위임을 하는 문화
• 고객 뿐만 아니라 새로운 기술과 방대한 데이터가 혁신을 이룰 수 있다는 믿음
• 개발자도 사업과 고객에 대한 이해가 뛰어난 문화
• 개별 스킬과 구성원의 다양성을 추구하는 문화
• Product Discovery를 추구하는 문화

훌륭한 실행 문화

• 응급 상황 문화
• 충분한 이해 후에 마감일을 설정하고 지키려는 High-integrity commitment가 있는 문화
• 전적으로 위임을 하는 문화
• 결과를 전달하는 데 책임을 가져가는 문화
• 협력하는 문화
• 산출물이 아니라 결과물(=사업 성과) 중심의 문화
• Culture of recognition (?)