PM 바이블, 인스파이어드 깊게 읽기
빡세게 공부하듯이 읽은 책 리뷰
텍스트를 읽고,
다음으로 작가와 시대를 읽고,
마지막으로 나 자신을 읽는 독서
500자 서평
인스파이어드는 2008년에 처음 출판된 책이지만 지금까지도 제품 기획의 교과서라고 불리는 책이다. 스타트업 생각을 꾸준히 하는 요즘 이 책에서 많은 것을 배우고 영감을 받았다. 독서가 아니라 공부하듯이 읽었다. 내가 제품팀을 꾸린다면? 혹은 내가 스타트업을 시작한다면? 하는 느낌으로 책을 읽으니 메모할 것도 많고 절로 밑줄 그을 곳도 많았다.
책 전체 내용을 한 줄로 요약하면 "강한 제품팀을 만들고, 좋은 제품 관리자(Product Manager)가 되기 위한 모든 작가의 지식과 노하우가 밀집된 책."이라고 할 수 있겠다.
책의 목차는 아래와 같다.
Part 1. 최고의 기술 기업에서 배운 것
Part 2. 사람 - 제품 관리자를 포함한 팀의 각 구성원의 역할과 구조를 설명한다.
Part 3. 제품 - 제품팀이 어떻게 일해야 하는가에 대한 내용이 담겨 있다.
Part 4. 프로세스 - 일하는 프로세스에 대한 노하우다.
Part 5. 문화 - 좋은 제품팀을 만들고, 강한 혁신 문화와 실행 문화를 만드는 방법에 대한 내용이다.
오늘은 각 Part에서 메모했던 내용을 요약 정리해 보려고 한다. 기억하고 싶은 내용이 많아 스압이 엄청나지만 공부한 내용을 노트 필기하듯이 일단 적어보려고 한다.
작가 소개: Marty Cagan
실리콘밸리 제품 그룹(SVPG)의 창립자로서 수많은 리더의 경험과 모범사례를 선도적인 기술 회사와 공유하고 있으며, 각종 강연회의 연사, 회사의 고문, 저자 및 수행 코치로 활동하고 있다.
SVPG를 시작하기 전에는 HP, 넷스케이프, 이베이 등 세계 최고의 기업에서 제품 책임자로 근무하였다. 제품 기획자의 필독서이자 베스트셀러인 《인스파이어드》의 저자이기도 하다. [Yes24 작가 소개에서 옮김]
SVPG를 알게 된 것은 엄청난 수확이다.
아티클부터, 팟캐스트, 동영상까지 제품/서비스 기획 관련된 질 좋은 콘텐츠가 많이 모여있다.
시대적 배경
이 책의 최초 발행일은 2008년. 이후, 2017년에 개정판이 나오고 한국 번역본은 2018년 12월에 비로소 출간되었다.
왜 최초 발행일 이후, 10년 뒤에나 번역본이 나왔을까 짱구를 굴리면서 2018년과 2019년 사이에 어떤 앱들이 인기를 끌었는지 살펴보았다.
여러 분야의 모바일 앱들이 두각을 나타내는 시기로 기억한다. 2017년에 구글플레이는 카카오뱅크, 호갱노노를 분야별 최우수 앱으로 선정했고 2018년에는 오늘의집, 틱톡, 마켓컬리를 분야별 최우수상으로 선정했다. 이 시기는 토스가 유니콘 지위를 확보한 때이기도 하다.
이외에도 모바일 기반의 스타트업도 붐이 일면서 제품 기획에 대한 관심도 높아졌을 것이고, 자연스레 한국에서도 이 책이 알려지고 많이 읽혔을듯하다.
나도 그때 읽었으면 참 좋았을 텐데 아쉽다.
여기부터 노트 필기 시작.
Part 1. 최고의 기술 기업에서 배운 것
[스타트업: 제품/시장 궁합 찾기]
1) 스타트업 정의
제품/시장 궁합(Product/Market Fit)을 찾고 있는 회사
유효한 비즈니스를 창출하는 제품을 찾기 위해 노력하고 있는 회사
스타트업은 통장 잔액이 떨어지기 전에 제품/시장 궁합을 어떻게든 만들어 내야 하고, 제품에 집중하여 초기 시장 니즈에 부합하는 강력한 제품을 만들어야 한다.
[폭포수 프로세스(Waterfall)의 문제점]
1)
아이디어가 대부분 판매 확대를 위한 기능이거나 이해관계자(외부)로부터 온 것인 경우가 많다. 이렇게 되면 제품팀에 권한 위임이 되지 않고 자율성을 훼손하여 동기부여를 잃고 용병처럼 그냥 열심히 일을 하기만 한다.
2)
"얼마큼 벌 수 있는가?"와 "얼마큼 비용이 드는가"는 현시점에서 전혀 근거가 없는 이야기다. 로드맵을 작성하는 단계에서 비즈니스 케이스를 작성하는 것 자체가 말이 안 된다. 우리가 만드는 것으로 얼마만큼 돈을 벌 수 있는가는 결국 얼마나 좋은 솔루션을 만드느냐에 달려 있다.
3)
제품 로드맵에 빠지면, 그 기능은 무조건 구현해야 하는 것으로 인식할 가능성 높은데, 이는 위험함. 만들었는데 고객도 이해관계자도 그렇게 중요하게 느끼지 않을 수 있다는 것 인지.
그래서 로드맵에 매몰되기보다는 수많은 아이디어를 실험을 통해 검증하고 그 과정에서 아닌 것은 과감히 버릴 수 있어야 한다. 아무리 가치 있는 아이디어라도 한 번에 그것을 완성시킬 수 없고 이터레이션(iteration)의 반복이 필요하다.
4)
제품 관리자의 역할이 주로 엔지니어를 위한 요구사항 수집과 문서화인 경우가 많다. 제품 관리(Product Management)보다는 프로젝트 관리(Project Management) 업무다. 디자이너와 엔지니어가 늦게 제품 개발 과정에 참여하여, 그 가치를 제대로 발휘하지 못할 가능성이 높다.
5)
애자일의 원칙을 훼손하는 모델이며, 프로젝트 중심적인 모델. 프로젝트 중심적이 되면 성과를 축하하는 것이 아니라 출시 자체를 축하하는 경우가 생겨버림. 성과나 목표 없는 출시는 의미가 없다.
[MVP(Minimum Viable Product)]
린 원칙을 따르고 있다는 수많은 팀이 겪는 오류는 MVP를 만드는 데 너무 오랜 시간을 투자한다는 것.
MVP는 프로토타입이지 제품이 아니라는 것 명심.
고객에게 팔 수 있을지 잘 모르면서 시간과 비용을 계속 투자할 필요 없음.
[제품팀이 지켜야 할 원칙]
1) 위험(risk)은 마지막보다는 초기에 대응한다.
가치 위험 (value risk): 고객이 과연 이 제품을 구매할 것인가?
사용성 위험 (usability risk): 사용자가 이 제품의 사용 방법을 쉽게 이해할 수 있는가?
실현 가능성 위험 (feasibility risk): 엔지니어가 구현할 수 있는가? (시간/기술/역량)
사업 유효성 위험 (business viability risk): 사업적으로 효과를 내는가?
2) 제품은 순차적인 방식이 아니라 함께 협업하며 설계한다.
제품 관리자, 디자이너, 엔지니어가 처음부터 끝까지 함께.
제품 관리자가 요구사항을 정하고, 디자이너가 요구사항에 맞게 디자인을 하고, 엔지니어가 구현하는 방식은 과거 방식이다.
3) 기능을 구현하는 것이 아니라 문제를 해결한다.
기능을 구현하는 생산량에 관한 것이 아니라, 고객/사용자의 문제를 해결하여 사업적인 성과를 만드는 것.
[핵심 개념]
1) 제품
제품은 기능, 기술, 사용자 경험 디자인, 어떻게 돈을 벌지, 고객의 마음을 사로잡고 획득하는 방안, 가치를 전달하기 위해 필요한 오프라인 경험 등 이 모든 것을 포함한다.
2) 제품 발견과 실행
제품 발견: 만들 제품을 발견하는 것 / 제품 실행: 발견한 제품을 만들어 시장에 전달하는 것 (제품 관리자, 디자이너, 엔지니어와 함께)
3) 제품 발견
좋은 아이디어와 그렇지 않은 아이디어를 빠르게 판별하는 것.
제품 발견의 산출물은 검증된 제품 백로그 (validated product backlog)
위에서 언급한 4가지 리스크에 답하는 과정 (가치 위험/사용성 위험/실현 가능성 위험/사업 유효성 위험)
4) 프로토타입
실험을 위해 작은 규모와 노력으로 만들어낸 것
5) 제품 실행
판매하고 비즈니스를 운영할 만큼의 제품을 만들고 전달하는 것
6) Product/Market Fit
특정 시장의 고객들이 원하는 것을 충족하는 가장 작은 단위의 실제 제품
Part 2. 사람
제품 관리자를 포함한 팀의 각 구성원의 역할과 구조
[강한 제품팀의 원칙]
1) 용병팀이 아니라 미션팀이 되는 것.
실리콘밸리의 벤처 캐피털리스트 존 도어가 한 말: 우리가 원하는 것은 용병팀(team of mercenary)이 아닌 미션팀(team of missionary)이다.
미션팀 vs 용병팀: 용병팀은 지시한 것만 따름. 미션팀은 진심으로 비전을 믿고 그들의 고객 문제 해결을 위해 최선을 다함. 마치 사내 스타트업처럼 행동하고 느낌.
2) 팀의 구성 (제안)
1명의 제품 관리자, 1명의 디자이너, 2명~12명의 엔지니어
필요에 따라 마케팅 매니저, 테스트 자동화 엔지니어, 데이터 분석가, 사용자 경험 연구원 등이 포함
3) 제품 관리자는 보고받는 관계나 상사가 아님
4) 팀의 자율성 확보가 중요
[제품 관리자(Product Manager)에 대하여]
1) 제품 관리자가 일하는 유형 3가지
- 제품 관리자는 모든 이슈와 의사결정을 CEO에게 보고한다. 이 모델에서 제품 관리자는 백로그 관리자. 스크럼 제품 오너 과정에서 설명하는 내용을 제품 관리자의 역할이다.
- 제품 관리자는 모든 이해관계자를 회의실에 불러 모을 수 있고, 그들끼리 끝장을 보도록 만든다. 큰 기업에서 자주 볼 수 있는 모델. '로드맵 관리자"의 역할이다.
- 제품 관리자가 스스로 업무를 실행한다. (-> 3번째만 정답이다.)
2) 제품 관리자의 책임
기회를 평가하고, 무엇은 만들고, 고객에게 전달할지 결정하는 사람
제품의 성공과 실패를 책임지는 사람
제품이 성공하면 모든 사람이 역할을 잘 해냈기 때문, 하지만 실패하면 제품 관리자의 잘못.
3) 갖춰야 할 것
고객에 대한 이해도 (정성적/정량적 학습)
데이터에 대한 이해도 (제품과 연관된 데이터)
비즈니스에 대한 이해도 (어떻게 비즈니스가 창출되는지? 조직의 주요 인원(이해관계자)은 어떻게 구성되는지?)
시장과 산업에 대한 이해도 (경쟁사/기술 변화/고객의 행동/관련 산업 분석 자료 등)
4) 준비할 것
사용자와 고객에 대해 전문가가 되어라 (고객의 이해가 필요한 경우 가장 먼저 찾는 사람이 되어야 함)
핵심 이해관계자, 비즈니스 파트너와 끈끈한 관계를 유지하라
제품과 산업에 관한 누구나 인정하는 전문가가 되어라 (지식을 아낌없이 공유)
제품팀과 끈끈한 협업 관계를 위해 최선을 다하라
5) 뛰어난 제품 관리자
CEO 역할이 비슷하고 그 마인드를 갖고 일해야 하지만 그 누구의 상사도 아니라는 점....
비즈니스 전반에 대한 깊은 이해
그 어떤 성공 사례에서도 사용자나 고객, 영업을 통해 최선의 솔루션이 나온 적이 없다.
=> 훌륭한 제품은 비즈니스 요구를 충족하면서도 사용자의 실제 문제 해결을 목표로 협업하는 과정에서 나옴
=> 어떤 문제를 어떻게 해결하냐에 집중
[제품 디자이너와의 협업]
1) 디자이너를 가장 중요한 멤버로 인식 (우리의 일을 지원하는 멤버라는 인식 X)
2) 아이디어 초기 단계부터 디자이너 개입해야 함
3) 디자인 아이디어가 있어도 웬만하면 이야기하지 않는 것이 좋음. 스스로 디자인 문제를 해결할 수 있는 충분한 여유와 기회 제공
4) 이터레이션에 참여하게 하되, 처음부터 세부적인 디자인 요소에 사소한 트집은 지양
5) 단순히 보기 좋은 것이 아닌, 올바른 제품을 발견할 수 있게 도와주는 디자인이 중요
[엔지니어와의 협업]
1) 고객의 불편함, 고객의 데이터와 비즈니스 상황을 공개적으로 엔지니어에게 공유
2) 문제 해결을 위해 다양한 해결 방법을 도출할 수 있는 장을 열어주는 것 중요
3) 가장 중요한 것 2가지
제품 발견 진행 시, 엔지니어와 함께 아이디어를 찾고 의견을 반영하는 것
제품 실행 단계의 실제 구현 단계에서 그들이 궁금해하는 것에 대답해 주는 일
Part 3. 제품
제품팀은 어떻게 일해야 하는가
[제품 로드맵의 문제점]
1) 제품 로드맵은 일반적으로 실망스러운 비즈니스 성과를 초래함
로드맵에 있는 아이디어 중 최소 절반 이상의 아이디어는 현시점에 유효하지 않을 것
아이디어의 가치, 사용성, 실현 가능성, 사업 유효성이 검증되었더라도 경영진이 희망하는 수준으로 가려면 최소 몇 번의 이터레이션 필요
2) 나쁜 팀, 취약한 팀은 제품 로드맵에 따라 일하다가, 잘 안 풀리면 그 기능을 요청한 관계자를 비난함
3) 뛰어난 팀은 효과적으로 솔루션을 완성하기 위해 빠르게 이터레이션 진행 (제품 발견의 핵심)
프로토타입을 만들고 사용자/고객/엔지니어/이해관계자와 아이디어를 함께 테스트 및 실험
이 테스트/실험을 몇 시간 또는 며칠 내로 가능하다면 비즈니스 역동성과 성과를 크게 개선할 수 있음
4) 로드맵에 있는 아이디어 목록 자체가 문제는 아님
'로드맵'이라는 타이틀을 달면 이해관계자들은 약속이라고 해석함 -> 아이디어가 문제를 해결하지 못하는 와중에도 구현에 몰두하는 상황 발생
아이디어는 실험을 통해 언제든지 추가하고 제거할 수 있다는 것을 깨달아야 함.
[제품 로드맵의 대안]
1) 제품 로드맵이 사용되는 이유
회사의 경영진은 비즈니스 가치가 높은 업무를 최우선으로 진행하기를 원하기 때문
또, 계획적으로 사업을 운영하고 싶기 때문 (일정 중심의 우선순위 관리)
2) 제품 로드맵의 대안은?
제품 비전과 전략: 전체 조직이 무엇을 달성하기 위해 노력하는지, 그 비전을 달성하기 위한 계획은 무엇인지에 대한 큰 그림이 필요
사업 목표: 제품에 대한 구체적이고 우선순위가 명확한 사업 목표를 설명해야 함 (측정 가능한 성과)
좋은 제품 팀은 제품 비전과 사업 목표를 바탕으로 성과 중심의 로드맵으로 일을 진행함. 또한, 해결해야 하는 비즈니스 문제들로 각 업무를 정의
[제품 비전]
개념: 2-5년 정도의 기간 내에 우리가 만들고자 하는 미래 (회사의 사명(Mission Statement)과는 다름)
제품 비전의 목적: 비전을 잘 전달하여 직원을 포함한 이해관계자, 투자자, 제휴사, 잠재 고객에게 영감을 불어넣는 것
제품 비전의 원칙
'왜'에서 시작하라 - 제품 비전을 목적 설명을 위해 활용하라.
솔루션이 아니라 문제와 사랑에 빠져라.
비전을 크게 생각하는 것에 두려워하지 마라.
현재의 자신을 파괴하는 데 두려워하지 마라.
제품 비전은 영감을 불어넣는다.
적절하고 유의미한 트렌드를 선택하고 포함하라.
공이 있던 곳이 아니라 공이 향하는 곳으로 움직여라.
비전은 완고하게 하되 세세한 부분은 유연하게 하라.
비전 변경(vision pivot)은 바뀌지 않도록, 하지만 세세한 부분에는 집착하지 않아도 됨.
모든 제품 비전은 믿음이라는 것을 깨달아라.
계속 집요하게 비전을 전파하라.
[제품 전략]
개념: 제품 비전을 실현하기 위한 과정을 통해 계획하고 있는 일련의 제품 또는 제품 출
제품 전략은 Product/Market Fit을 기반으로 구성해야 함
1)
예를 들어, 교육 서비스 앱을 만든다고 했을 때, 목표 시장을 고등학생 -> 대학생 -> 직장인 순으로 차근차근 확장하는 것 등을 말함
2)
혹은, 논리적이고 중요한 순서를 담은 핵심적인 단계를 정하고 달성하는 것
아마도 카테고리 확장의 개념이 여기에 속할 듯싶다.
오늘의집, 무신사, 토스가 슈퍼앱으로서 한 단계씩 새로운 비즈니스 카테고리로 확장하듯이
3)
한 번에 하나의 목표 시장에 집중하는 선택이 가장 유리하다.
다른 유형의 고객이나 시장과 관련된 내용은 미래를 위해 넣어둬~~~~
4)
제품 전략의 원칙
한 번에 한 가지 시장 혹은 고객에 집중하라.
제품 전략은 사업 전략과 연계되어야 한다.
제품 전략은 영업 및 시장 진출 전략과 연계되어야 한다.
경쟁사가 아닌 고객에 집중하라.
어느 순간 제품 전략을 잊어버리고, 고객에 집중하지 않고 경쟁사만 따라가는 현상.
고객이 떠나는 이유는 경쟁사 때문이 아니라 고객을 더 이상 케어하지 않기 때문임.
제품 전략을 조직 전체와 소통하라.
[제품 원칙]
제품 비전이 만들고자 하는 미래에 대한 설명이라면 제품 전략은 그 비전을 달성하는 길
제품 원칙은 당신이 만들고자 하는 제품의 특성을 의미함
예를 들어, 이베이의 제품 원칙은 "구매자와 판매자가 서로 원하는 것 사이에 충돌이 발생하는 경우 우리는 구매자가 필요로 하는 것에 우선을 둔다. 그것이 판매자를 위해 우리가 할 수 있는 가장 중요한 일이기 때문이다"
이렇게 제품 원칙을 만들어 놓고 룰을 따르면 많은 이슈를 해결할 수 있음
Part 4. 프로세스
일하는 프로세스에 대한 노하우
[가장 첫 단계, 제품 발견 / 제품 발견의 원칙]
제품 발견의 목적은 아래 Risk에 대응하기 위한 것
고객이 과연 이 제품을 구매하거나 사용할 것인가 (가치 위험, value risk)
사용자가 이 제품의 사용 방법을 이해할 수 있는가? (사용성 위험, usability risk)
우리가 만들 수 있는 것인가? (실현 가능성 위험, feasibility risk)
우리 사업에 효과가 있는 솔루션인가? (사업 유성 위험, business viability risk)
제품 발견 원칙 10가지
우리가 무엇을 만들어야 하는지 고객, 임원, 이해관계자들이 말해주지 않는다. 단지, 우리의 솔루션이 근본적인 문제를 해결하는 것이 맞는지 확인하는 것이 가장 중요하다.
무엇보다 중요한 것은 강력한 가치를 추구하는 것이다.
기술 구현이 어렵고 중요한 만큼이나, 훌륭한 사용자 경험을 제공하는 것은 보통 그 이상으로 어렵고 성공에 더 중요한 요소다.
기능과 디자인과 기술은 본질적으로 함께 얽혀 있다.
우리는 아이디어 중 다수가 효과를 내지 못할 것이며, 검증된 아이디어도 몇 번의 이터레이션이 필요하다는 것을 알고 있다.
우리는 실제 사용자와 고객을 대상으로 아이디어를 검증해야 한다.
제품 발견의 목적은 아이디어를 가능한 한 더 빠르고 적은 비용이 드는 방법으로 검증해 내는 것이다.
제품 발견 단계를 진행하며 아이디어의 실현 가능성에 대해 검증해야 한다.
사업 유효성은 제품 발견 단계에서 검증해야 한다.
공유 학습을 해야 한다.
[제품 발견 구조화 기법]
기회 평가 기법
이 일은 어떤 사업 목표를 다루는 것인가? (목표, objective)
성공을 어떻게 판단할 수 있는가? (핵심 성과, key result)
우리의 고객을 위해 어떤 문제를 해결하는 것인가? (고객 문제, Customer problem)
우리가 집중하는 고객은 누구인가? (목표 시장, target market)
특정 유형의 사용자나 고객
페르소나로 표현할 수도 있고 특정한 목표 시장에서의 해결해야 할 일을 나타낼 수도 있음
스타트업 캔버스 (린 캔버스)
Problem -> 나의 서비스가 해결하려는 문제
Exisiting Alternative -> 대체재, 대체 제품/서비스
Customer segments -> 첫 번째 항목에서 작성한 문제점을 가진 고객군 중에 목표로 삼을 고객
Early Adopter -> 가장 먼저 사용할 것으로 추정되는 사용자/고객
Unique Value Proposition -> 목표로 삼은 고객에게 제품과 서비스가 어떤 가치를 제공할 수 있는지
High-Level Concept -> 제품의 컨셉을 정의하는 한 문장 (X for Y)
Solution -> 우리 제품과 서비스의 주요한 기능과 장점
Channel -> 우리 제품과 서비스가 목표로 삼은 고객에게 전달되는 경로가 어디인지
Revenue Stream -> 수익을 어떻게 창출할 수 있을지
Cost Structure ->서비스를 유지하기 위해 발생되는 비용
Key Metrics -> 마케팅이 잘 수행되고 있는지 확인할 수 있는 핵심 지표
Unfair Advantage -> 우리 제품과 서비스가 다른 것보다 뛰어난 점
린 캔버스 샘플 (*출처: PageFly)[제품 발견 계획 기법]
스토리 맵
사용자가 제품을 사용하는 스토리에 맞게 그리는 지도
보통 아래와 같이 설계함
스토리맵 샘플 1 (*출처: realtimeboard)
스토리맵 샘플 2 (*출처: Nielsen Norman Group)고객 발견 프로그램
하나의 목표 시장에서 6명 정도의 레퍼런스 고객을 구함
그 6명을 대상으로 제품 발견과 실행 단계에서의 프토토타입을 보여주고, 테스트를 수행하고, 인터뷰하고, 베타 테스트
제품 출시도 위 6명을 대상으로 우선 진행
[아이디어 발상 기법]
1) 고객 인터뷰
2) 안내인 테스트: 실제 사용자와 고객을 찾아가서 그들이 어떻게 과업을 수행하는지 확인하고 솔루션을 찾는 것
3) 고객 일탈 행동의 관찰
보통은 아래 1번과 2번의 방법으로 제품 기회를 찾음
- 1번 시장 기회를 평가하고, 주요한 문제가 존재하면서도 잠재 수익성이 뛰어난 영역을 선택
- 2번 기술이나 데이터가 지금 가능하게 해주는 것을 살펴보고, 주요한 문제와 그것이 맞아떨어지는지 확인
- 하지만 3번도 있음. 놓치지 말아야 함.
고객이 공식적으로 제공하는 문제 해결 이외에 목적으로 제품을 사용하는 것을 수용하거나 심지어 권장하는 상황일 때.
혁신은 사람들이 무엇을 하기 원하는지 관찰하는 데서 비롯됨
따라서, 고객이 예측하지 못한 방법으로 제품을 사용하고 있다면 매우 소중한 정보가 됨 (왜 그랬는지, 왜 그럴 때 이 제품을 선택한 건지 등 확인해야 함)
4) Hack day (해커톤)
[프로토타입]
1) 실현 가능성(feasibility) 프로토타입
실현 가능성 위험을 완화하기 위한 목적에 필요한 수준의 코드를 작성하는 것
알고리즘, 성능, 확장성, 처음 활용하는 기술 등을 테스트
2) 사용자 프로토타입 기법
Lo-Fi vs Hi-Fi
여기서 Fi는 'Fidelity(충실함/정확도)'의 약자.
[제품 발견 테스트 기법]
1) 가짜 문 수요(fake door demand) 테스트
버튼이나 메뉴를 사용자 경험상 있어야 할 것으로 판단되는 위치에 넣어보고
해당 버튼을 클릭하면 특별한 랜딩 페이지로 보내어, 이 기능을 연구하고 있다고 설명하면서 의견을 요구
의견을 보내거나 별도 참여할 방법을 안내
클릭률을 통해 유용한 데이터를 확보할 수 있음
위 기법은 전체 제품에도 적용 가능
랜딩 페이지 수요 테스트: 해당 서비스를 실제로 출시하는 것과 같이 그 신규 서비스를 명확히 설명. 사용자에게 우리가 새로운 서비스를 만들기 위해 연구 중이라는 설명을 페이지에 작성
2) 제품 발견 스프린트
1주 단위(time box)로 제품 발견 업무를 진행하는 것으로 제품팀이 당면한 중요한 문제를 처리하기 위해 설계
1. 목표 설정
2. 제품 아이디어 및 접근 방법 탐색
3. 잠재 솔루션을 검증 (고객 및 사용자에게)
4. 결과 학습 -> 방향 결정
아래의 "스프린트: 세상에서 가장 혁신적인 프로젝트 수행법" 책에 나오는 스프린트 방식 공부 필요함
[이해관계자 관리하기]
임원진, 제휴 회사, 재무, 법무, 감사, 사업 개발과의 관계 중요
이해관계자의 제약사항과 고민을 이해하고, 고객뿐만이 아니라 이해관계자에게도 유효한 솔루션을 찾아내야 함
가장 큰 실수는 이미 제품을 만든 후에 솔루션을 보여주는 것
제품 발견 단계에서 핵심 이해관계자들에게 솔루션(Hi-Fi 프로토타입)을 먼저 보여주어야 함
높은 충실도(Hi-Fi)의 사용자 프로토타입으로 사업 유효성을 검증하라 -> 승인은 이렇게 받아야 함.
Part 5. 문화
좋은 제품팀을 만들고, 강한 혁신 문화와 실행 문화를 만드는 방법
[좋은 제품팀, 나쁜 제품 팀]
좋은 팀은 강렬한 제품 비전이 있고 선교사와 같은 열정을 추구한다. 나쁜 팀은 용병들이다.
좋은 팀은 그들의 비전과 목표, 고객 불편의 관찰, 제품을 사용하면서 고객들이 만들어낸 분석 데이터, 문제를 해결하기 위해 새로운 기술을 끊임없이 탐색하는 과정을 통해 영감과 제품 아이디어를 얻는다. 나쁜 팀은 영업과 고객으로부터 요구사항을 수집한다.
좋은 팀은 어떤 아이디어가 진정으로 만들 만한 가치가 있는가를 결정하기 위해 빠르게 제품 아이디어를 시도해 볼 수 있는 많은 기법에 능숙하다. 나쁜 팀은 우선순위 로드맵을 만들기 위해 미팅을 진행한다.
좋은 팀은 회사 전반에 걸쳐 브레인스토밍 토론을 즐긴다. 나쁜 팀은 외부의 제안에 방어적이다.
좋은 팀은 이기는 제품을 만드는 데 필요한 능력을 팀 스스로 갖추기를 고집한다.
좋은 팀은 최종 사용자 및 고객과 매주 직접 만난다.
좋은 팀은 그들이 기대했던 아이디어들이 결국 고객에게 효과가 없을 수 있다는 것과 심지어 검증된 아이디어조차도 희망하는 성과가 나오는 수준이 되려면 여러 번의 이터레이션이 필요하다는 것을 잘 알고 있다. 나쁜 팀은 그저 로드맵에 있는 것들을 만들면서 품질을 만족하고 일정을 준수하는 것에 만족한다.
좋은 팀은 요청된 업무를 진단하고 고객과 비즈니스에 유효한 솔루션을 가지고 있다고 확신했을 때 높은 신뢰 수준의 약속을 한다. 나쁜 팀은 영업 중심의 회사라고 불평한다.
좋은 팀은 그들의 고객에 집착한다. 나쁜 팀은 경쟁자에 집착한다.
좋은 팀은 비즈니스 성과에 유의미한 영향을 만들어 냈을 때 서로 축하한다. 나쁜 팀은 마침내 무언가를 출시했을 때 축하한다.
[혁신을 잃는 10가지 이유]
아래의 항목이 없으면 혁신을 잃어버릴 가능성이 높음
1) 고객 중심의 문화
2) 강력한 제품 비전
3) 제품 전략의 초점
4) 뛰어난 제품 관리자
5) 안정된 제품팀
6) 엔지니어의 제품 발견 (엔지니어를 제품 발견 초기부터 참여하게 하는 것)
7) 회사 차원의 용기 (위험 감수)
8) 자율적인 제품팀
9) 제품 마인드
10) 혁신의 속도
규모가 성장한 기업은 제품팀이 이른바 현상 유지 활동에만 전념할 가능성이 큼
오류를 수정하고, 비즈니스의 각 영역에 필요한 기능을 만들고, 기술 부채에 대응하는 등의 일만 할 가능성
[속도를 잃는 10가지 이유]
1) 기술 부재
2) 뛰어난 제품 관리자의 부재
3) 제품 실행 관리자의 부재
4) 느슨한 출시 주기
5) 제품 비전과 전략의 부재
6) 같은 장소에서 오래가는 제품팀의 부재
7) 제품 발견 단계에서 충분히 이른 시점에 엔지니어를 참여시키지 않는 것
8) 제품 발견에서 제품 디자인의 역할을 활용하지 않고, 엔지니어가 제품을 구현할 때 같이 업무를 진행하는 것
9) 우선순위의 변경 (급격한 우선순위의 변경은 심각한 구성원의 이탈을 초래 / 업무 처리량과 동기부여 감소)
10) 합의의 문화: 너무 많은 합의가 필요할 때
[강력한 제품 문화 구축하기]
강력한 혁신 문화
실험의 문화 - 팀은 그들이 테스트를 실행할 수 있다고 생각한다. 일부는 성공하겠지만 많이 실패할 것이다. 실패가 허용되고 이해할 수 있다.
열린 자세의 문화 - 좋은 아이디어는 어디에서든 올 수 있으며, 항상 확실한 아이디어는 없다고 생각
자율성의 문화
기술의 문화
비즈니스와 고객에 능숙한 팀의 문화 - 개발자를 포함하여
능력과 다양성의 문화
제품 발견 기법의 문화 - 아이디어가 빠르고 안전하게 시도될 수 있도록 하는 메커니즘
강력한 실행 문화
위기의 문화 - 항상 전시 상태에 있는 것처럼 느끼며 빠르게 움직이는 것
높은 신뢰 수준의 약속 문화 - 약속의 필요성과 힘을 이해하는 것
권한 위임의 문화
책임의 문화
협력의 문화
성과의 문화 - 결과물에 집중하는가? vs 성과에 집중하는 가?
인정의 문화
책에서 꼽은 딱 3 문장 (책꼽문)
나는 사람들에게 제품을 한 번에 하나의 목표 시장에 집중하는 선택이 가장 유리하다고 이야기한다. p.148
제품 발견의 목적은 가치 위험, 사용성 위험, 실현 가능성 위험, 사업 유효성 위험 이 4가지에 대응하는 것이다. p.188
고객이 과연 이 제품을 구매하거나 사용할 것인가 (가치 위험, value risk)
사용자가 이 제품의 사용 방법을 이해할 수 있는가? (사용성 위험, usability risk)
우리가 만들 수 있는 것인가? (실현 가능성 위험, feasibility risk)
우리 사업에 효과가 있는 솔루션인가? (사업 유성 위험, business viability risk)
좋은 팀은 강렬한 제품 비전이 있고, 그들은 마치 선교사와 같은 열정을 추구한다. 반면 나쁜 팀은 용병들이다. p.358
