책 <인스파이어드>

1. 소감

2. 기억하고 싶은 문장들

1) 최고의 기업에서 배운 것

• 최고의 기업들과 다른 대부분의 기업들이제품을 만드는 방식에는 엄청난 차이가 있다.

• 만들만한 가치가 없는 제품이라면 엔지니어 팀이 얼마나 훌륭한지는 아무 의미가 없다.

• 모든 훌륭한 제품 이면에는 지칠 줄 모르고 무대 뒤에서 최선을 다하는 누군가가 있다. 그 사람은 제품팀을 이끌며, 비즈니스 목표에 맞는 방향으로 기술과 디자인을 통해 고객의 실제 문제를 해결한다. 이 사람이 바로 제품 관리자, Product Manager 이다.

• 스타트업은 제품, 시장 궁합(Product-Market Fit)을 아직 찾지 못한, 새로운 제품을 만드는 회사이다.

• 성장단계의 회사에서는 성공을 위한 확장이 필요하다. 초기 성공했던 제품과 다른 PMF, 기술부채, 리더십, 조직운영 등 다양한 문제상황에 마주하게 된다.

• 대기업은 끊임없는 제품 혁신의 과제가 존재한다. 비전 상실, 느린 의사결정, 제품팀의 혁신 부재 등 다양한 문제에 마주한다.

• 폭포수 방식의 제품 개발 방식은 10가지의 심각한 문제점이 있다.

  • 아이디어의 출처가 제품팀 밖으로부터 전해지면 제품팀은 단순히 외부 용병처럼 일할 수 밖에 없다.

  • 아이디어만 나온 상태에서는 비즈니스 케이스(예상수익과 예상비용)를 알기 힘들다.

  • 당신의 아이디어 중 절반 이상은 유효하지 않을 것이고 그것이 비즈니스 가치를 만들어내기까지는 몇 번의 이터레이션(time to money)이 필요하다.

  • 폭포수 방식에서 제품관리자(product manager)가 하는 일은 엔지니어를 위해 요구사항을 수집하고 문서화해주는 일이다. 이것은 실제 기술 제품 관리자가 하는 일과는 180도 다르다.

  • 진정한 디자인 가치를 담기 너무 늦은 타이밍이다. 결국 '돼지입술에 립스틱 바르기'를 하게 된다.

  • 엔지니어들이 너무 늦게 참여하게 된다. 제품 개발에서의 가장 작은 비밀이 있다면 엔지니어들은 보통 혁신을 하는 데 가장 훌륭한 원천이라는 것이다.

  • 애자일의 원칙과 장점을 충분히 활용하지 못한다.

  • 프로젝트 중심적이다. 프로젝트는 결과물에 관한 것이고 제품은 비즈니스 성과에 대한 것이다. 결과물만 있고 비즈니스 성과만 없다면, 애초에 그 제품은 왜 만들어진 것일까?

  • 고객에 대한 검증이 너무 늦게 일어난다. 많은 기업들은 폭포수방식으로 일하고 있으면서 린 원칙을 적용하고 있다고 착각한다.

  • 엄청난 기회비용이 발생한다. 이 시간에 우리는 다른 더 멋진 일을 할 수 있었다.

• 최고의 제품팀이 일하는 방법

  • 위험을 초기에 대응한다. 구현 이전에 위험을 발견하고 대응한다.

    • 가치위험 : 고객이 구입을 할 것인가?

    • 사용성 위험 : 고객이 쉽게 이해하고 사용할 수 있는가?

    • 실현 가능성 위험 : 우리가 보유한 엔지니어의 시간, 역량, 기술로 필요한 것들을 만들어낼 수 있는가

    • 사업 유효성 위험 : 이 솔루션이 영업, 마케팅, 재무, 법무등 우리 사업의 다양한 측면을 고려했을 때, 제대로 효과를 발휘할 수 있는가

  • 제품은 순차적인 방식보다는 함께 협업하여 정의하고 설계된다.

    • 제품관리자, 디자이너, 엔지니어가 함께 붙어 활발하게 의견을 주고받으며 고객이 사랑하고 비즈니스적 성과를 이룰 수 있는 제품을 만들어낸다.

  • 기능을 구현하는 것이 아니라 문제를 해결한다. 사업적인 성과를 낸다.

• 제품이라는 단어는 총체적으로 사용해야한다.

  • 제품은 기능, 기술, 사용자 경험 디자인, 돈을 버는 과정, 고객의 마음을 사로잡는 방법, 오프라인 경험 등 모든 것들이 총체적으로 포함된 개념이다.

  • 전자상거래 비즈니스에서 제품이란 판매되는 물품을 제외한 모든 경험이 포함된다.

  • 미디어 회사는 콘텐츠 자체를 제외한 모든 경험을 제품이라고 한다.

2) 사람

• 훌륭한 제품 이면에는 지칠 줄 모르고 무대 뒤에서 최선을 다하는 누군가가 있다. 그 사람은 제품 팀을 이끌며 비즈니스 목표에 부합하는 방향으로 기술과 디자인을 통해 고객의 실제 문제를 해결한다.

• 모든 제품팀은 1) 만들 제품을 발견하는 것과 2) 시장에 그 제품을 전달하는 것, 이 두가지를 끊임없이 동시에 실행한다.

• 강한 제품팀의 원칙

  • 용병팀이 아닌 미션팀. 하나의 미션을 진심으로 믿고 그들의 고객 문제 해결을 위해 최선을 다한다.

  • 피자 두 판의 법칙. 팀의 규모는 피자 두 판을 나눠먹기 충분한 정도의 인원으로만 유지한다.

    • 1명의 PM, 1명의 디자이너, 2-12명의 엔지니어로 구성

  • 모든 팀원들은 권한이 있고 결과에 대한 책임도 진다.

  • 제품팀은 보고 관계가 아니다. 진정한 의미의 협업관계이다.

    • 여기서 협업은 제품관리, 디자인, 기술 구현이 솔루션을 만드는 데 함께 집중한다는 뜻

  • 같은 장소에서 함께 일한다. 다른 모든 조건이 같다면 같은 장소에서 근무하는 팀이 흩어져 있는 팀보다 훨씬 더 높은 성과를 낸다.

  • 제품팀은 프로젝트를 위해 만들어지지 않는다. 한 분야에서 혁신이 일어나기 위해서는 충분한 전문성을 확보할 시간이 필요하다. 팀의 지속성은 그래서 중요하다.

  • 충분한 권한을 가졋다고 느끼면서 고객 문제를 해결하기 위한 열정으로 뭉친 팀은 구성원들에게 높은 수준의 자율성을 제공해야한다.

• 제품관리자가 일하는 다양한 방식이 있다. CEO에게 일일히 업무를 보고하기도 하고, 실무자들을 모아두고 알아서 정하라는 식으로 일할 수도 있다. 하지만 제품관리자라면, 스스로 업무를 실행할 수 있어야 한다.

• 흔히 제품 관리자는 평판이 나쁘고 그 필요성에 종종 의문을 제기받지만, 회사 내에서 가장 뛰어난 사람이 제품 관리자가 된다면, 그런 일은 없을 것이다. 기술에 대한 기본적인 소양, 사업에 대한 지식, 핵심 임원들로부터의 신뢰, 제품에 대한 열정, 제품팀으로부터의 존중까지 모든 소양이 갖추어진 사람이어야 한다.

• 제품이 성공하면 팀의 모든 사람들이 제 역할을 잘 해냈기 때문이다. 하지만 제품이 실패하면 그것은 제품 관리자의 잘못이다.

• 제품 관리자는 네 가지 중요한 책임을 다한다.

  • 고객에 대한 깊은 이해. 고객에 대해 누구보다 잘 알고 있다고 인정받는 전문가가 되어야 한다.

  • 데이터에 대한 깊은 이해. 하루의 시작을 분석 도구와 함께. 30분정도 시간동안 지난 24시간의 고객 행동을 분석한다. 매출분석데이터 혹은 고객 사용 데이터를 살펴본다.

  • 비즈니즈에 대한 깊은 이해. 성공적인 제품은 고객에게 사랑받는 것은 물론이고, 사업적인 성과도 함께 창출한다.

  • 시장과 산업에 대한 이해. 경쟁사 이해, 주요 기술의 변화, 고객 행동과 기대사항, 관련 산업의 분석가 자료, 소셜미디어의 영향력 이해 등

• 성공적인 제품 관리자는 최고로 똑똑하고 창의적이고 집요해야한다.

  • 똑똑하다는 것은 단순히 IQ가 뛰어나다는 것이 아니라 지적 호기심이 많고, 빠른 학습 능력이 있어야 한다. 새로운 기술을 고객 문제 해결, 신규 고객 확보, 비즈니스 모델의 발굴에 적용할 수 있어야 한다.

  • 창의적이라는 것은 평범한 제품 기능의 범위를 뛰어 넘는 비즈니스 문제 해결의 방법을 생각해낼 수 있는 능력을 말한다.

  • 집요함은 완강한 저항에도 불구하고 적당함과 타협하지 않도록 추진해내는 것을 의미한다. 이를 위해 설득력 있는 근거, 끊임없는 대화, 기능 조직 간의 가교 역할을 수행해야 한다.

  • 제품에 대한 열정과 고객 문제 해결에 대한 열정은 가르친다고 습득되지 않는다. 지금 있는지 없는지에 대한 문제이다.

• 성공적인 제품 관리자가 되기 위한 네 가지 조언

  • 사용자와 고객에 대한 전문가가 된다. 좋은 결과이건 나쁜 결과이건 학습한 것을 공개적으로 공유한다. 팀이나 회사에서 고객에 대한 정량적이거나 정성적인 이해가 필요한 경우, 가장 먼저 찾는 사람이 되어야 한다.

  • 핵심 이해 관계자 및 비즈니스 파트너와 끈끈한 관계를 만드는 작업을 해야한다. 1) 그들이 업무상 겪고 있는 제약사항과 2) 그 제약사항들을 잘 반영한 솔루션을 제공해야한다.

  • 제품과 산업에 관해 누구나 인정하는 전문가가 되어라. 지식을 공개적으로 아낌없이 공유한다.

  • 제품팀과 끈끈한 협업관계를 만들기 위해 최선을 다한다.

• 뛰어난 제품 관리자들

  • 제인 매닝, 구글

  • 레아 힉맨, 어도비

  • 알렉스 프레스랜드, BBC

  • 마르티나 로쳉코, 마이크로소프트

  • 케이트 아놀드, 넷플릭스

  • 카미유 허스트, 애플

• 뛰어난 제품 관리자들의 예에서 얻을 수 있는 인사이트

  • 제품 관리자는 다른 역할과는 뚜렷한 차이가 있다. CEO와 가장 비슷하지만 그 누구의 상사도 아니다.

  • CEO 처럼 제품 관리자는 비즈니스 전반에 대해 깊게 이해해야 한다. 고객과 비즈니스 모두에 유효한 해법을 파악해야 한다.

  • 어떤 사례에서도 사용자나 고객, 영업을 통해 최선을 솔루션이 나오지 않았다. 훌륭한 제품은 비즈니스의 요구를 충족하면서도 사용자 및 고객의 실제 문제 해결을 목표로 디자이너, 엔지니어와 치열한 협업 과정을 통해 만들어진다.

  • 진정한 리더십이 좋은 제품 관리자와 위대한 제품 관리자를 구분하는 중요한 요소이다. 당신이 타이틀이나 지위가 어떻든 간에 위대한 사람이 되고자 한다면 리더십을 두려워 마라.

• 제품 관리자와 제품 소유자

  • 제품 기업에서는 보통 제품 관리자가 소유자의 역할을 동시에 수행한다.

  • 제품 관리자는 제품 소유자의 역할을 포함한다.

• 제품 관리자에게 도움이 되는 두 가지 수업

  • 컴퓨터 프로그래밍 개론

  • 비즈니스 회계/재무 개론 : 영리 기업이 어떻게 운영되는지 이해해야 한다. 비즈니스가 어떤 방식으로 동작하는지 큰 그림에 대해 이해해야 한다는 것이다.

• 제품 디자이너와의 협업하기

  • 무슨 수를 써서라도 디자이너와 가까이 일해야한다.

  • 초기 단계뿌터 디자이너와 가까이 일해야한다.

  • 디자이너와 함께 고객과 사용자에 대해 학습하라

  • 디자인 아이디어가 떠올라도 말하지 말라. 디자이너가 스스로 해결하도록 해라

  • 디자이너가 이른 시점부터 자주 이터레이션에 참여할 수 있도록 한다.

• 성공적인 팀에는 제품총괄, 디자인 총괄, 기술 총괄자가 항상 존재한다. 프로덕트가 뭔가 엉성하고 아쉬운 사용자 경험을 비춘다면, 분명 위의 세 역할 중 하나가 부재할 것이다.

• 훌륭한 제품 총괄은 아래의 4가지 핵심 역량이 검증된 사람이다.

  • 팀 개발, 제품비전과 전략, 실행, 제품문화

3) 제품

• 제품 로드맵의 문제

  • 당신이 시도하는 것의 절반 이상의 아이디어는 유효하지 않을 것이다.

    • 가치, 사용성, 실현가능성, 사업유효성 고려

  • 아이디어의 가치, 사용성, 실현가능성, 사업 유효성이 검증되더라도 비즈니스 가치를 만들어내려면 최소한 몇 번의 어터레이션을 반복해야한다. 즉, 돈을 버는데 필요한 시간이 존재한다.

• 제품 로드맵을 작성하는 이유

  • 회사의 경영진은 비즈니스 가치가 높은 업무를 우선적으로 처리하기를 원한다.

  • 계획적으로 사업을 운영하기를 원한다.

• 제품 로드맵의 데안 : 성과 중심의 로드맵

  • 제품팀이 달성해야하는 구체적인 사업 목표가 있어야 한다.

  • 그러면 팀은 자신이 생각한 최선의 방법으로 문제 해결을 시도한다. 용병팀이 아니라 미션팀이 된다.

  • 요청받은 기능이나 프로젝트가 완료되었다고 끝나는 것이 아니라 해당 기능이 핵심 성과를 달성했고, 비즈니스 문제를 해결했는지를 확인한다.

  • 실패의 가능성을 기꺼이 받아들인다.

문득 지난 번 인터뷰 때 받았던 질문이 떠올랐다. 당시에는 제대로 만족할만한 대답을 못했는데 책을 다시 읽다보니 아래와 같은 생각이 들었다.

일을 잘하는 사람과 일을 열심히 하는 사람의 차이는 일의 결과물에 집착하느냐와 일의 성과에 집착하느냐의 차이인 것 같다는 생각이 든다. 일을 잘하는 사람은 일의 결과물이 어떻든 간에 성과를 만들어낸다. 하지만 일을 열심히만 하는 사람은 결과물이 나왔음에 만족한다. 실제 일의 결과물이 문제를 해결했는지, 얼마만큼의 비즈니스 성과를 만들어냈는지에는 관심이 없다.

• 높은 신뢰 수준의 약속

  • 약속에 대한 모든 근심의 근본 원인은 약속이 발생하는 '시점' 이 너무 이르다는 것이다. 책임지고 제품을 전달할 수 있을지 알기도 전에 약속이 발생해버린다.

  • 제품팀은 약속이 발생하기 전에 제품 발견을 위한 일부 시간을 요청한다. 제품 발견 단계 이후에는 이해 관계자들이 효과적으로 그들의 업무를 준비하고 진행할 수 있게 일정과 결과물에 대해 기꺼이 약속한다.

• 목표 시장의 우선순위 결정시 고려해야할 점들

  • 총 유효시장. 이왕이면 큰 시장이 좋다.

  • 시장 진출

  • 제품 출시 기간

• 제품 비전의 10가지 원칙

  • 왜 에서 시작하라

  • 솔루션이 아니라 문제와 사랑에 빠져라

  • 비전을 크게 생각하는 것을 두려워하지 말라

  • 현재의 자신을 파괴하는 것을 두려워 마라

  • 제품 비전은 영감을 불어넣는다.

  • 적절하고 유의미한 트렌드를 선택하고 포함하라

  • 공이 있던 곳이 아니라 공이 향하는 곳으로 가라

  • 비전은 완고하게 세세한 부분은 유연하게

  • 모든 제품 비전은 믿음이다.

    • 만약 비전을 검증할 수 있다면 그것인 비전이 충분히 크지 않다는 것이다. 비전 달성까지는 몇 년정도 걸린다.

  • 계속, 집요하게 비전을 전파하라. 팀원들에게 두려움이 전파되기 전에 비전을 계속해서 전파하라.

• 제품 전략의 다섯가지 원칙

  • 한번에 한가지의 시장 혹은 고객에 집중

    • 모든 사람들 만족시키려고 하지 않는다.

    • 많은 사람들에게 도움이 되면서도 최소한 누군가에게는 깊이 사랑받게 된다.

  • 제품 전략은 사업 전략과 연계되어야 한다.

  • 제품 전략은 영업 및 시장 진출 전략과 연계되어야 한다.

  • 경쟁사가 아닌 고객에 집착하라

  • 제품 전략을 조직 전체와 소통하라

• OKR 기법 적용시 주의할 점

  • 목표는 정성적이어야 한다. 핵심성과는 정량적이고 측정 가능해야한다.

  • 핵심 성과는 결과물이나 작업이 아니라 사업 성과의 측정값이어야 한다.

  • 제품관리, 디자인, 기술조직은 조직의 목표에 집중해야한다. 개인의 목표나 기능별 목표가 제품 조직이 집중하는 목표를 흐트러트리거나 혼란을 주면 안된다.

  • 조직에 맞는 주기를 찾아야 한다.

  • 각팀의 목표와 핵심 성과는 가능한 적은 개수여야 한다. 목표는 최대 3개, 목표별로 핵심성과도 최대 3개여야 한다.

  • 진척상황을 활발히 추적할 것

  • 목표는 각 팀이 달성해야만 하는 일을 포함한다.

  • 어떻게든 구성원들이 책임감을 느끼는 것이 중요하다. 크게 실패했을 때에는 동료, 경영진과 함께 회고를 진행하는 것이 좋다.

  • 핵심 성과를 어떻게 평가할 것인지 조직으로서 동의가 필요하다. 보통은 1점 만점으로 매긴다.

  • 핵심 성과는 평범한 목표가 아니다. 진정으로 높은 신뢰 수준의 약속을 기반으로 달성했을 때를 구분하는 일관성있는 기준 설정이 필요하다.

  • 각 제품팀이 무슨 목표를 위해 일하는지, 현재 실적이 어떤지 조직 전반에 투명하게 공개되어야 한다.

  • CEO와 임원들은 전체 조직의 목표와 핵심 성과에 대한 책임이 있다.

• OKR을 제품팀에서 실행할 때 주의할 점

  • 종종 제품팀 구성원들의 경우, 기능 부서 차원에서의 목표를 전달받기도 하고, 하나의 재품팀으로서의 비즈니스적 목표도 전달받는다. 문제는 각 구성원들이 자신의 시간을 어디에 쓰는 것이 맞는지, 그 우선순위에 있어서 헷갈려한다는 점이다.

  • 예를 들면 개발 조직 차원에서 기술부채 관리 주요 목표로 삼아서 팀원들에게 내려온다면, 팀원들은 기술부채 관리가 더 중요한지, 아니면 제품팀으로서 비즈니스 문제를 해결하는 것이 더 중요한지 그 우선순위에 있어서 헷갈리게 된다.

  • 이럴 때에는 각 개인이 제품팀의 목표에 주목하도록 유도해야한다. 각 기능 조직의 상위 목표들은 다른 사업 목표와 연계하여 리더십 레벨에서 먼저 우선순위가 논의되어야 한다. 그리고 나서 제품팀의 목표에 적절하게 통합되어야 한다.

• 확장 단계의 조직은 OKR 을 사용하여 제품 목표를 정할 때, 조직이 긴밀하게 연계되도록 많은 노력이 필요하다. 이는 리더십과 경영진의 몫이다. 각 제품팀이 그들이 기여하는 것은 무엇이고, 전체 범주에서 어떻게 들어가는지 이해할 수 있어야 한다.

• 제품 에반젤리즘 : 꿈을 파는 것

  • CEO, PM으로서 매우 중요한 능력.

  • 사람들이 미래를 상상할 수 있도록 도움을 주고 그 꿈을 만드는 데 도움을 줄 수 있도록 영감을 불어 넣는 것이다.

• 제품 관리자들이 에반젤리즘, 즉 꿈을 파는데 필요한 10가지 조언들

  • 프로토타입을 이용하라. 그들이 명확하게 숲을 보면서도 나무를 볼 수 있도록 해줘라.

  • 고객의 문제를 공유하라. 팀에게 고객의 불편함을 보여줘라.

  • 비전을 공유하라.

  • 학습한 것을 아낌없이 공유하라. 모든 사용자 테스트나 고객 방문 이후 학습한 것을 공유하라. 문제점 역시 공유하라.

  • 아낌없이 인정하라.

  • 훌륭한 제품 시연 방법을 학습하라.

  • 열심히 학습하라. 사용자와 고객에 대해서 모두가 인정하는 전문가가 되어라. 경쟁사, 관련된 트렌드를 포함하여 시장에 대해서도 인정받는 전문가가 되어라.

  • 진정으로 흥미를 느껴라. 만일 당신의 제품에 대해서 흥미를 느끼지 못한다면, 당신은 그 상황을 벗어나야만 한다. 다루는 제품을 바꾸거나 당신의 역할을 바꾸거나 둘 중 하나의 선택을 해야한다.

  • 열정을 보여주는 방법을 배워라. 절대 진실하되, 당신이 정말로 설레고 있음을 사람들이 확인할 수 있게 해 주어라. 열정은 정말로 전염성이 있다.

  • 팀과 함께 시간을 보내라. 당신 팀의 디자이너, 엔지니어들과 직접 마주하는 시간을 많이 쓰지 않는다면, 그들은 당시 눈에서 비치는 열정을 확인할 길이 없다.

• 집 밖에서의 BBC

  • 전통적으로 BBC가 도달하던 집이나 차 이외에 방송 미디어가 도달하지 않는 곳을 찾기 시작

  • 도심에 있는 전자 스크린을 발견.

  • 특정 장소와 시청자에 적합한 콘텐츠를 맞춤형으로 특별히 만들어보기로 결심. 실험 진행

  • 집 밖에서의 BBC라는 이 제품 실험은 성공적이었으나 그 과정에서 편집부서, 법무부서 등 다양한 이해관계자들을 설득하는 과정이 필요했다.

  • 대기업에서 큰 규모의 변화를 추진하는 것은 결코 쉽지 않다. 하지만 뛰어난 제품 관리자라면 어떻게 해야하는지 파악해야만 하는 역량이다.

4) 프로세스

• 제품 관리자는 사업적으로 효과가 있으면서도 고객이 사랑하는 솔루션을 발견해내기 위해 대부분의 시간을 제품팀, 핵심 이해 관계자, 고객들과 보낸다.

• 동시에 제품 관리자와 제품 디자이너는 제품 실행 단계에서 발생하는 엔지니어들의 질문에도 대답할 수 있어야 한다는 것을 유념해야한다.

• 제품팀은 두 가지 큰 도전이 있다. 첫째는 고객의 위한 솔루션이 구체적으로 어떤 것인지 발견하는 것이다. 더 어려운 것은 많은 사용자에게 유효한 단 하나의 솔루션을 찾아내야만 한다는 것이다. 둘째는 우리 고객들이 끊임없이 신뢰하는 가치를 기대하도록 탄탄하고 확장성 있는 실행력을 갖추고 있어야 한다. 자신감있게 제품을 출시할 수 있어야 한다.

• 당신이 위대한 제품을 반견하기 원한다면 실제 사용자와 고객을 대상으로 더 일찍 더 자주 당신의 아이디어를 보여주는 것이 중요하다. 당신이 위대한 제품을 실행하기 원한다면 기술 구현의 최고 방법들을 사용하고 엔지니어가 말하는 우려 사항을 무시하면 안된다.

• 제품 발견의 목적은 다음 네 가지 중요한 위험에 대응하는 것이다.

  • 가치 위험 : 고객이 과연 이 제품을 구매하거나 사용할 것인가

  • 사용성 위험 : 사용자가 이 제품의 사용 방법을 이해할 수 있는가

  • 실현 가능성 위험 : 우리가 만들 수 있는 것인가

  • 사업 유효성 위험 : 우리 사업에 효과가 있는 솔루션인가

• 위의 질문에 대한 대답 + 증거를 함께 수집해야한다.

• 제품 발견의 원칙

  • 우리가 무엇을 만들어야 하는지는 우리의 고객, 임원, 이해 관계자들이 말해주지 않는다.

  • 무엇보다 중요한 것은 강력한 가치를 구축하는 것이다.

  • 기술 구현이 어렵과 중요한 만큼이나 훌륭한 사용자 경험을 제공하는 것은 보통 그 이상으로 어렵과 성공에 더 중요한 요소다.

  • 기능과 디자인과 기술을 본질적으로 함께 얽혀있다.

  • 우리는 아이디어 중 다수가 효과를 내지 못할 것이며, 검증된 아이디어도 몇 번의 이터레이션이 필요하다는 것을 알고 있다.

    • 가장 중요한 것은 당신이 알 수 없는 것을 알아내야 한다는 것이다.

  • 우리는 실제 사용자와 고객을 대상으로 아이디어를 검증해야한다.

    • 제품 발견 단계에서 가장 흔히 발생하는 함정은 우리 제품에 대한 사용자의 실제 반응을 우리가 예측할 수 있다고 믿는 것이다.

    • 실제 제품을 만들기 위한 시간과 비용을 낭비하기 전에 검증을 진행해야 한다.

  • 제품 발견의 목적은 아이디어를 가능한 한 더 빠르고 적은 비용이 드는 방법으로 검증해 내는 것이다.

  • 제품 발견 단계를 진행하며 아이디어의 실현 가능성에 대해 검증해야한다.

    • 당신의 개발자가 스프린트 계획 미팅에서 아이디어를 처음 봤다면 당신은 실패한 것이다. 구현을 결정하기 전에 실현 가능성을 분명히 확인해야 한다.

  • 사업 유효성은 제품 발견단계에서 검증해야한다.

    • 제품을 만드는 시간과 비용을 쓰기 전에 우리가 만드는 솔루션이 우리 비즈니스가 원하는 것이 맞는지를 확인하는 것이 절대적으로 중요하다.

  • 공유학습을 해야한다.

    • 조직이 용병팀 대신 미션팀을 가져야만 하는 핵심적인 이유는 바로 팀이 함께 배운다는 것이다. 고객의 불편함을 함께 관찰하고, 어떤 아이디어가 실패하고 성공하는지 함께 확인하며, 왜 이 일이 중요하고 진행되어야 하는지에 대한 맥락을 함께 이해한다.

• 우리가 그것을 만드는 것이 맞는가? 일반적으로 제품 발견은 가치, 사용성, 실현가능성, 사업 유효성 위험에 대응하는 것이지만, 어떤 경우에는 윤리적 위험까지 고려해야한다.

  • 나는 제품팀에 그들의 솔루션이 미치는 윤리적인 영향을 고려할 것을 권장한다.

  • 고위 경영진에게 윤리적 이슈를 제기하라. 당신은 이슈를 찾아내고 잠재적인 해결 방법을 모색해야하는 사람이다.

• 제품 발견 이터레이션

  • 제품 실행단계 뿐만 아니라 발견 단계에서도 이터레이션을 적용할 수 있다. 능숙한 팀들은 보통 한 주에 10-20개의 이터레이션 테스트를 진행한다고 한다.

  • 이때 중요한 것은 적은 시간과 노력을 들여야 한다는 점!

• 제품 발견 구조화 기법

  • 제품 발견 업무의 대부분은 특정 문제에 대한 솔루션만 찾아내면 되므로 비교적 문제해결이 간단하다. 하지만 큰 프로젝트, 여러 팀이 함께하는 프로젝트에서는 그것이 굉장한 고민과 노력이 필요해진다.

  • 구조화의 중요한 목표

    • 첫째. 분명한 목적과 연계성에 대해서 팀이 함께 이해하고 있도록 한다.

    • 둘째. 제품 발견 업무를 하면서 대응해야하는 큰 위험을 찾아내는 것이다.

      • 기술적 위험이나 사용성 위험은 사실 비교적 해결하기 쉽다.

        • 문제는 가치 위험이다. 고객이 이러한 문제해결을 원하는 것이 맞는가?

  • 기회 평가 : 아래의 네가지 핵심적인 질문에 답한다.

    • 사업 목표 : 이 일은 어떤 사업 목표를 다루는 것인가

    • 핵심성과 : 성공을 어떻게 판단할 수 있는가

    • 고객 문제 : 우리는 고객을 위해 어떤 문제를 해결하는 것인가

    • 목표 시장 : 우리가 집중하고 있는 고객은 누구인가

    • 대부분의 경우, 위의 4가지 질문을 통해 문제 해결이 가능하다.

  • 고객 편지

    • 아마존 - 거꾸로 일하기 working backward 를 보면, 제품에 대한 홍보기사를 먼저 작성해보는 방법으로 제품팀이 만들기로 한 모든 기능에 대해 즉각적으로 빠져들도록 매료시킨다.

    • 이러한 방법은 결과물이 아닌 성과에 대응하고 몰입할 수 있도록 해주며 제품 에반젤리즘 효과가 있고, 수요를 검증하는 기법이 되기도 한다.

    • 하지만 이보다 더 좋은 방법은 고객편지 기법이다. 고객편지 기법은 명확히 정의된 하나의 사용자 혹은 고객 페르소나가 가상의 관점으로 작성한 고객 편지 형식을 말한다. 매우 행복해하며 감동한 고객이 CEO에게 보내는 내용을 담아 고객의 불편에 더욱 공감하고, 우리 제품이 고객에 미치는 영향을 더욱 명확하게 느낄 수 있도록 한다.

  • 스타트업 캔버스

    • 스타트업이나 대기업에서 신규 제품을 생각해야할 때 유용하게 사용할 수 있다. 즉, 기존 제품에 대한 개선이 아니라 완전히 새로운 제품을 만들어야 하는 경우 사용한다.

    • 새로 들어온 제품관리자의 경우, 핵심적인 비즈니스 영역에 대한 이해와 제품에 대한 총체적인 이해하는데 도움이 된다.

    • 가장 큰 위험인 가치 위험을 해결한 다음 다른 위험들에 집중해야한다. 아직 진정으로 가치 있는 제품을 발굴하지 못했다면, 가격 최적화, 판매도구 등 다른 자잘한 일들에 신경쓸 시간이 없다. 가치 발견이 최우선이다.

문제 vs. 솔루션

• 특히 스타트업 창업자들은 문제보다 솔루션에 관해 생각하고 이야기한다.

• 하지만 중요한 것은 솔루션이 아닌 문제와 사랑에 빠지는 것이다.

• 우리의 첫번째 솔루션은 대개 그 문제를 해결하지 못한다. 근본적으로 문제를 해결하는 솔루션이 나오기까지는 보통 몇 번의 다른 시도들을 하게 된다.

• 제품 발견 계획 기법

  • 스토리맵

    • 가장 활용도 높은 기법 중 하나

    • 두 축으로 구성된 맵을 그리는 방법이다. 수평축으로는 주요 사용자 활동을 대략적인 시간 순서로 정렬되어있고, 수직축으로는 구체적인 레벨이 된다. 중요 활동을 사용자 과업의 조합으로 구체화해나간다.

    • 이 맵 하나만으로도 총쳊거인 시야를 가질 수 있게 되고, 하나의 스토리가 다른 스토리와 어떻게 맞춰져 있는지를 볼 수 있게 된다. 제품팀은 시스템이 어떻게 만들어지기를 바라는지 단번에 파악할 수 있게 된다.

    • 주로 프로토타입을 구상할 때 사용될 수 있다.

    • 추천도서 <사용자 스토리 맵 만들기> by 제프 페튼

  • 고객 발견 프로그램

    • 뛰어난 제품 만이 비즈니스를 지속 가능하게 한다. 영업팀, 고객만족팀, 마케팅 팀 등 다른 모든 팀을 행복하게 할 수 있다.

    • 참조고객은 실제 고객이고, 실제 돈을 내고 제품을 구매했으며 다른 사람들에게 제품에 대한 이야기를 할 자발적인 의사가 있는 사람들이다.

    • 참조고객이 없는 것은 제품관리자 당신의 잘못이다.

    • 고객 발견 프로그램은 이러한 참조 고객을 만들어 내기 위해 설계되었다. 우리는 실제 제품을 발견하고 개발하는 것과 함께 참조 고객의 조합을 발굴하고 개발한다.

    • 이 기법을 수행한다는 것은 앞으로 만들 제품의 성공에 대한 최고의 선행 지표를 확인하는 것이다.

    • 제품 유형별로 참조 고객 프로그램의 4가지 변형이 있다. 1) 사업자를 위한 제품을 만드는 경우 2) 플랫폼 제품인 경우 (API 등) 3) 내부 직원을 위한 제품인 경우 4) 소비자를 위한 제품인 경우

    • 사업자를 대상으로 하는 제품이나 서비스의 경우, 6명의 참조고객이 핵심 숫자이다. 이는 통계적 유의미함을 의미한다기 보다는 자신감이 생기는 수준이다. 6명 이상이면 좋지만 한명 한명 큰 노력이 들기 때문에 6명을 목표로 하는 것이다.

    • 우리가 찾는 것은 목표 시장이나 세그먼트에 해당하는 6명의 유사 고객이다. (미국-독일-브라질... 순차적으로 6명 확보 or 재무 -제조 순차적으로 6명 등)

    • 6명을 확보하기 전까지는 시장에 제품을 출시하지 않는다. 영업이나 마케팅이 성공할 수 있다는 증거가 필요하다.

    • 우리는 이 6명의 참조 고객을 통해 프로토타입을 충분히 실험해보고, 제품이 유효한지 확신해야한다. 그럴려면 그 고객들이 충분한 노력과 시간이 있어야 한다.

    • 대신 고객들은 그들이 필요했던 솔루션을 실제로 획득할 수 있다.

    • 많은 고객에게 성공적으로 판매할 수 있는 범용적인 제품을 만들어 내는 것이 당신의 임무라는 것을 각 참조 고객에게 설명해야한다. 고객 맞춤형 솔루션을 만들 필요가 없다.

    • 그렇다고 해서 6명이 요청하는 모든 것을 제품에 넣으면 안된다. 각각의 잠재 고객을 깊이 탐구하여 6명의 고객 모두를 만족시키는 하나의 솔루션을 찾아내야 한다.

    • 우리는 이 프로그램에 절대적으로 시간을 낼 수 있을 만큼 솔루션에 목말라 있고 간절한 고객들을 찾고 있다. 모든 시장에는 이러한 고객 군이 있기 마련이다.

    • 만약에 6명을 구하는 것에 큰 어려움을 겪고 있다면, 아마 그다지 중요하지 않은 문제를 쫓고 있을 가능성이 크다. 이것은 당신이 무언가 가치있는 것에 시간을 쏟고 있는 것이 맞는지 매우 초기에 현실을 확인하는 (수요검증이라는) 방법이다. 만일 고객이 이 문제에 흥미가 없다면 처음부터 계획을 다시 생각해보는 것이 좋겠다.

    • 고객이 실제 의도한 단일 목표 시장에 속한 것이 맞는지 분명히 확인해야한다.

    • 마케팅 부서와도 끊임없이 협업해야한다.

    • 초기 잠재 고객을 제품 발견의 파트너라고 생각하라. 그들을 동료로서 대하라. 솔직하게 대화하고 서로에게 도움을 줘라. 당신이 만들어 낸 관계가 몇 년간 지속할 수 있음을 알게 된다.

    • 전체 출시를 진행하기 전에 이 사람들에게 먼저 제품을 출시하라. 제품 출시 전에 이미 그들은 제품 사용에 만족하고 있기 때문에 출시 시점에 당신의 든든한 지지층이 된다.

    • 플랫폼/API 제품의 경우, 고객은 우리의 API를 활용해서 성공적인 응용 프로그램을 만든다. 고객은 엔지니어 혹은 제품 관리자이다.

    • 고객 서비스 담당자를 위핸 대시보드 같은 내부 고객을 위한 도구의 경우, 우리는 6-8명의 신망이 두텁고 영향력 있는 내부 사용자/직원을 선택한다. 다른 사람들이 리더처럼 존경하는 사람들이어야 한다.

    • 소비자 제품의 경우도 비슷하지만 6명이 아닌 10-50명 정도로 더 큰 수의 소비자들을 대상으로 한다.

    • 이들을 대상으로 할 때에는 훨씬 넓게 제품 아이디어를 테스트할 수 있도록 프로그램을 보완해야한다는 점이다.

제품/시장 궁합 정의하기

• 제품-시장 궁합에 대한 대부분의 방법은 다소 주관적이다. 진정으로 제품/시장 궁합은 눈으로 볼 수 있을 때 비로소 알 수 있다. 더 행복한 고객, 낮은 이탈률, 더 빠른 판매 기간, 더 급속한 자연 성장을 보여주는 개념이다.

• 많은 기업들은 흔히 제품/시장 궁함이 그들에게 어떤 의미이며, 그들이 달성한 상태인지 아닌지에 대해 수많은 시간동안 논쟁하는데 시간을 쏟는다. 제품/시장 궁합을 진단하는데 가장 보편적으로 사용되는 것은 션 엘리스 테스트라고 알려진 기법이다. 사용자에게 더 이상 이 제품을 사용할 수 없게 되면 어떤 기분일지를 물어보는 것이다. 일반적으로 40%이상의 사용자가 매우 실망스럽다고 한다면 당신이 제품/시장 궁합을 달성했을 가능성이 충분하다고 본다.

마이크로소프트의 마티나 로쳉고 사례

• 1993년 마소에서는 워드 6.0을 출시함. 코드 베이스가 각 플랫폼 별로 분기되어있던 것을 통일시켜 개발상 효율을 개선했다.

• 그러나 새로 출시된 맥용 워드는 너무 느렸고, 많은 항의를 받았다. 심지어는 빌게이트까지 직접 이메일을 전달했다.

• 코드베이스를 통합하는 목표도 중요하지만, 고객들이 모든 플랫폼을 위한 통합 제품을 동시에 제공받는 것보다 시간이 조금 더 걸리더라도 특정 플랫폼에 최적화된 솔루션을 사용하는 것을 선호한다는 것을 깨달았고 제품팀은 성능에 쏟던 노력을 멈추고, 맥의 장점을 살린 제품을 6.1로 출시했다.

• 결과는 매우 성공적.

• 엄청난 압박이 자주 발생하는 상황에서도 고객을 위해 올바른 제품을 만드는 것이 얼마나 어려운 일인지 보여준다.

• 아이디어 발상 기법

  • 고객 인터뷰는 모든 제품 관리자에게 가장 강력하고 중요한 기술이 된다. 제품의 돌파구가 되는 다수의 아이디어를 만들어내는 원천이나 영감을 자주 제공한다.

  • 모든 사용자 또는 고객과의 상호작용에서 우리는 항상 가치 있는 통찰을 배울 기회를 가지고 있다. 다음은 내가 항상 이해하고자 노력하는 것들이다.

    • 당신이 목표했던 고객들이 맞는가?

    • 당신이 생각했던 문제를 고객들이 실제로 가지고 있는가?

    • 고객이 이 문제를 지금은 어떻게 해결하고 있는가?

    • 그들을 전환하려면 무엇이 필요한가?

  • 매주 2-3시간 정도는 고객 인터뷰를 진행해야한다.

  • 인터뷰를 하는 동안에는 무엇인가 증명하려고 해서는 안 된다. 고객을 이해하고 빠르게 학습하기 위해 노력하면 된다.

  • 당신의 목표 시장에 해당하는 고객들과 주로 이야기를 나눠라.

  • 고객에 태어나고 자란 거주지에서 관찰하는 것은 항상 놀라운 학습 효과가 있다.

  • 사전에 그들의 문제가 무엇이라고 생각하는지 분명히 해둬라.

  • 제품 관리자, 제품 디자이너, 그리고 희망하는 엔지니어 등 3명으로 팀을 이루어 참여하는 것이 가장 좋다. 보통은 디자이너가 주도하고, 제품관리자는 기록하고, 엔지니어는 관찰한다.

  • 자연스럽고 편안한 분위기를 유지한다. 그들이 지금 격고 있는 일을 학습하는데 초점을 맞춘다.

  • 모두가 같은 내용을 듣고, 같은 배움을 가졌는지 동료들과 공유한다. 인터뷰 중 고객에 약속한 것이 있다면 지키도록 한다.

  • 인터뷰는 노력이 시간 대비 훌륭한 결과물을 만들어 낸다.

  • 안내인 테스트는 높은 품질의 제품 아이디어를 빠르게 도출하기 위해 사용되는 기법이다.

  • 안내인 테스트는 오랜 기간 사용된 방법이다. 기본적으로 우리가 고객의 과업을 개인적으로, 수동으로 수행해주는 것이다. 사용자나 고객이 원하는 것을 당신이 직접 해준다.

  • 안내인 테스트는 실제 사용자와 고객에게 찾아가서 그들이 어덯게 과업을 수행하는지 보여주기를 요청해야 한다. 그러면 그들이 과업을 어떻게 수행하는지 당신은 학습할 수 있게 된다. 그 결과로서 당신은 훨씬 나은 솔루션을 그들에게 제공하도록 일을 수행할 수 있게 된다.

  • 고객 일탈 행동의 힘. 오늘날 훌륭한 팀들이 제품 기회들을 찾아내기 위해 사용하는 방법은 보통 두가지로 시장을 따르거나 기술을 따르는 것이다. 하지만 가장 성공적인 회사 중 일부는 세번째인 고객 일탈 행동을 따르는 방법을 택했다. 고객 일탈 행동의 힘은 애초에 고객이 우리가 계획하고 공식적으로 제공하는 문제 해결 이외의 목적으로 제품을 사용하는 것을 수용하거나 심지어 권장하는 것이다.

  • 마이크 피셔의 <고객 일탈 행동의 힘> 에서는 이베이에서 '나머지 모두'라는 카테고리에서 사람들이 예상치 못한 온갖 물건들을 거래하는 것을 관찰할 수 있다는 것을 말한다. 실제로 이베이는 원래 전자 제품이나 수집품과 같은 물건의 거래를 촉진하기 위해 설계되었지만, 사람들은 공연 표나 미술품, 심지어 자동차까지 거래하기 시작했다. 지금 이베이는 전 세계에서 가장 큰 중고차 거래 회사 중 하나가 되었다.

  • 만일 당신의 고객이 예측하지 못한 방법으로 당신의 제품을 사용하고 있다면 이는 잠재적으로 매우 소중한 정보가 된다. 그들이 무슨 문제를 해결하기 위해서 그랬는지, 왜 그들이 당신의 제품이 적합한 수단이라고 생각했는지 더 깊게 파헤쳐보고 학습해 볼 수 있다.

  • Open API 역시 개발자 일탈 행동의 힘의 선상에서 볼 수 있다. 공개 API와 함께 개발자들이 우리의 서비스를 이용해서 어떤 생산물을 만들어낼지는 아무도 모른다. 진심으로 혁신적인 제품 아이디어가 나오는 지속 가능한 최고의 원천은 여전히 개발자들이다.

  • 헥데이(hack day) 는 긴급한 비즈니스 혹은 고객의 문제를 해결하는데 초점을 맞추어 다양하고 높은 잠재성을 가지 ㄴ아이디어를 빠르게 획득할 수 있는 기법이다.

  • 직접적인 핵데이는 특정 고객문제 혹은 사업 목표를 위해 직접 구성원들이 아이디어를 탐색하고 프로토타입을 만들어낸다. 결과물이 적절하면 실제 사용자에게 테스트해본다. 이를 통해 엔지니어들은 아이디어 발굴 단계에 직접 참여할 수 있고 문화적으로도 용병팀이 아닌 미션팀을 만들어내는데 큰 도움이 된다.

• 프로토타이핑 기법

  • "버리기 위해 계획하라. 어쨋든 결국 그렇게 될 것이다." by 프레드 브룩스

  • 프로토타입의 5가지 원칙

    • 작은 규모의 시간과 노력. 최소화.

    • 대화나 필기보다 더 깊은 수준으로 문제를 드러냄

    • 팀 간의 협업에도 유용하다.

    • 의도한 목적에 맞는 올바른 수준의 충실도

    • 엔지니어와 그 외 조직 전체에 무엇이 만들어져야 하는지 효과적으로 커뮤니케이션 가능

  • 실현 가능성 프로토타입은 주로 엔지니어가 구현할 기능에 대해서 성능, 확장성, 내고장성 등의 우려가 있거나 사용해본적 없는 기술, 컴포넌트의 경우라서 걱정이 되는 경우, 하루 이틀 내에 빠르게 구현해보는 것을 말한다. 대부분의 경우는 구현가능성만 판단하고 버려진다.

  • 사용자 프로토타입 (모의실험)은 일종의 시뮬레이션이다. 진짜 데이터는 아니지만 상호작용이 가능하도록 구성된 가짜 제품이다. 이 방법은 무언가를 증명해주지는 않지만, 프로토타입을 사용하는 사용자들과 이야기를 하면서 제품팀은 인사이트를 얻을 수 있고 내부적으로는 만들 제품에 대해 같은 그림을 그리며 의사소통할 수 있도록 돕는다.

  • 라이브 데이터 프로토타입

    • 사용자 데이터를 수집하기 위해 출시 가능한 실제 제품을 만드는 시간과 비용을 사용하기 이전에 제품 발견 단계를 진행하며 증거를 수집해야한다. 이때 사용할 수 있는 것이 라이브 데이터 프로토타입이다. 이는 실제 제품을 만드는데 필요한 유스 케이스의 모든 조합, 자동화 테스트, 분석도구, 성능 등을 고려하지 않는 매우 제한적인 프로토타입이다.

    • 따라서 두 가지를 기억하는 것이 중요하다. 첫째는 이것이 코드기 때문에 엔지니어가 제작해야만 한다는 점, 둘째는 이것이 상업적으로 출시가능한 제품이 아니기 때문에 엔지니어에게 충분한 시간을 제공해야한다는 점이다.

    • 요즘에는 2-3일이면 좋은 툴들로 프로토타입을 만들어낼 수 있다.

    • 라이브 데이터 프로토타입은 제한된 양의 트래픽을 보낼 수 있고, 라이브 데이터 프로토타입이 어떻게 사용되었는지에 대한 분석 데이터를 수집할 수 있다는 것이 핵심이다.

  • 혼합 프로토타입

    • 오즈의 마법사 프로토타입은 프론트엔드 차원에서는 높은 퀄리티를 자랑하지만 실제 뒷단에서는 사람이 수동을 데이터를 조정하는 방식을 말한다. 확장 가능성이 없지만 빠르게 구현하고 검증할 수 잇다는 점이 이점이다.

• 제품 발견 테스트 기법

  • 제품 발견 단계에서 우리는 필연적으로 좋은 아이디어와 나쁜 아이디어를 빠르게 구별하기 위해 노력한다. 아래의 네 가지 유형의 질문에 대해서 생각한다.

    • 가치, 사용성, 실현 가능성, 사업 유효성 등

  • 대부분은 먼저 가치 평가를 진행한다. 솔루션이 가치가 없다면, 나머지는 크게 의미가 없기 때문이다.

  • 보통 가치 평가를 진행하면 사용자가 사용할 수 있는 형태로 그것을 디자인한다. 이 과정에서 사용성과 실현 가능성에 대한 평가도 같이 이루어진다.

  • 마지막으로 사업 위험들에 대해서 주요 비즈니스 담당자들과 이야기를 한다. 이 단계가 마지막인 이유는 제품의 가치가 있는지 확실하지 않은 상태에서 조직 전체의 섣부른 움직임을 만들고 싶지 않아서이다.

• 사용성 테스트

  • 요즘은 제품 발견 단계에서 사용성 테스트를 하기 때문에 문제를 발견하고 이를 고치는 것이 한결 수월해졌다.

  • 조직 내 사용자 리서치 조직이 있다면 반드시 출시 전에 이들과 시간을 맞춰 사용성 테스트를 진행해야한다.

  • 하지만 그들을 이용할 수 없을 경우, 직접 테스트를 진행해볼 수도 있다.

  • 먼저, 테스트 할 사용자를 모집해야한다. 기존 사용자의 이메일 등의 정보를 통해서 모집하거나 회사 홈페이지를 통해 자원자를 모집할 수도 있다. 벼룩시장이나 구글 에드센스에 광고를 붙일수도 있다. 항상 사용자들이 모이는 곳을 가야한다. 소정의 선물을 챙겨가 1시간 정도 시간을 낼 수 있는 사람들을 모집한다.

  • 테스트를 준비할 때에는 제품관리자, 디자이너, 엔지니어가 함께하도록 한다. 디자이너가 주로 주도하고,제품관리자가 기록하며 엔지니어는 주로 관할한다.

  • 테스트를 하고자 하는 과업들의 조합은 사전에 정의되어있어야 한다.

  • 프로토타입 테스트하기

  • 학습내용을 요약할 때에는 거창한 리포트를 만들지 말고 이메일로 간단하게 공유한다. 이미 프로토타입은 실시간으로 부족한 부분들 개선하여 바뀌고 있으므로 보고서를 작성할 때 즈음에는 해당 정보는 가치가 없어져 버린다.

• 가치 테스트

  • 누군가 우리 제품을 사용할 수 있다는 것이 그들이 우리 제품을 선택할 것이라는 의미는 아니다.

  • 수많은 스타트업 실패의 원인은 팀이 제품을 디자인하고 구현해서 마침내 출시를 했을 대 사람들이 그것을 사지 않는 것을 깨닫는 것이다. 단순히 구매를 하지 않는 것이 문제가 아니라 사용도 원하지 않는 것이 문제이다.

  • 수요테스트는 가짜 문 수요 테스트라고 불린다. 사용자가 특정 버튼을 클릭하면 실제 동작하는 것이 아니라 안내 페이지로 이동하는 것이다. 실제 사용자의 클릭률 데이터를 확보할 수 있어서 많이 쓰인다. (새로운 기능을 출시하기 전에 메뉴만으로 미리 노출하는 방법처럼 사용할 수 있을 듯) . 랜딩 페이지 수요 테스트도 그와 유사하다.

  • 이를 통해 우리는 1) 수요에 대한 훌륭한 근거와 2) 새로운 기능에 대해 당신과 이야기할 준비가 되어있고 의사가 있는 사용자들의 목록을 얻을 수 있다.

  • 수요가 있는 것까지는 사실 쉽게 테스트할 수 있다. 더 복잡한 문제는 사용을 한 뒤에 더이상 관심을 보이지 않는 것이다.

  • 정량적인 테스트는 무슨 일이 일어나고 있는지를 말해주지만, 왜 그런일이 생기는지를 설명해주지는 않는다. 그리고 그 상황을 바로잡기 위해 무엇을 해야 하는지도 알 수 없다. 그래서 우리는 정성적인 테스트가 필요하다.

  • 정성적인 테스트는 무언가를 증명하는 것이 아니다. 이는 빠른 학습과 통찰에 관한 것이다.

  • 정성적인 테스트를 하는 과정이다. 먼저, 고객 인터뷰를 한다. 그 후 사용성 테스트를 진행한다. 여기까지 진행하면 사용자는 당신 제품이 무슨 목적이고 어떤 의미로 사용되는지 알아야 한다.

  • 중요한 것은 이 이후에 바로 뒤이어 가치 테스트를 진행해야한다는 점이다. 사용자와 고객에 제품을 사용할 방법을 습득할 기회도 주지 않고 가치테스트를 진행하는 것은 무의미하다.

  • 당신이 사용자 또는 고객과 마주 앉아서 가치 테스트를 할 때 문제는 사람들이 일반적으로 친절하다는 것이다. 그리고 그들은 진짜 생각을 말하려고 하지 않는다. 그래서 가치 테스트를 할 때는 모든 상황에서 그 사람이 당신에게 친절하지 않도록 설계해야한다.

  • 예를 들면 그 솔루션에 돈을 낼 의사가 있는지 확인할 수 있다. 값비싼 기업용 제품이라면 강제력이 없는 구매 의향서에 서명해달라고 요구할 수도 있을 것이다.

  • 혹은 그들의 평판을 지불할 의사가 있는지 확인할 수도 있다. 소셜미디어 공유, 동료나 상사에게 추천할 의향(점수) 등

  • 이 일과 관련해 상당 시간을 할애해 줄 수 있는지 물어볼 수도 있다.

  • 사람들에게 전환하고자 하는 기존 제품의 로그인 정보를 요청해 볼 수도 있다.

  • 프로토타입을 반복해야한다. 정성적 테스트는 놀라운 정도로 쉽고 효과적일 수 있다. 프로토타입을 스마트 폰이나 랩톱에 탑재하고 아직 그것을 본 적이 없는 사람에게 찾아가서 한번 써보게 한다.

  • 정량적인 가치 테스트

    • 대용량의 데이터를 통해 통계적으로 유의미한 결과를 도출한다.

    • 대표적으로 A/B 테스트가 있는데 이를 통해 우리가 이상적으로 찾고 있는 예측성 높은 데이터를 얻을 수 있다.

    • 가치 테스트 상에서의 A/B 테스트는 최적화 A/B 테스트와는 다르다. 최적화 A/B 테스트는 보통 낮은 위험 수준의 변화이고, 분할 테스트로 자주 실행한다. 반면 제품 발견 단계에서의 A/B 테스트는 사용자의 1% 에게만 노출된다.

    • 요즘은 데이터가 의견을 압도한다는 태도를 기반으로 간단히 테스트를 수행하며, 어느 정도의 데이터를 수집하고 나서 그 데이터를 의사결정에 활용한다.

    • 데이터를 깊이 학습한다는 것은 획기적인 제품 아이디어를 이끌어 내는 통찰을 제공해 줄 수 있다.

    • 데이터를 다룰 때 명심해야할 것은 바로 데이터는 무슨일이 일어나고 있는지에 대한 어둠을 밝혀주지만 왜 그런지 설명해주지는 못한다는 것이다. 정량적인 테스트 결과에 관해 설명할 수 있으려면 정성적인 기법이 필요하다.

    • 나는 고객에게 영향이 없는 기능들을 제거함으로써 제품을 철저히 단순하게 만드는 것을 추구한다.

    • 우리가 제안한 이론이나 결론을 뒷받침하는 데이터가 없다면 경영진은 결정을 망설이게 된다.

• 가끔은 엔지니어가 찾아와서 한개 또는 그 이상의 질문들에 대한 답을 얻기 위해 실현 가능성 프로토타입을 만드는 것이 필요하다고 할지 모른다. 그런 경우라면 먼저 그 아이디어가 제품 단계에서 그만큼의 조사가 필요한 잠재적인 가치가 있는지 고려한 뒤, 그렇다고 판단되면 응원해주면 된다.

• 엔지니어가 조사를 위한 시간이 필요하다고 말하는 제품 아이디어의 경우, 꽤 괜찮을 수 있다. 첫째, 최고의 제품 아이디어들은 오직 지금 가능한 문제 해결의 방식을 바탕으로 한다. 이는 새로운 기술이며 이를 조사하는 시간이 필요하다. 둘째, 엔지니어에게 하루나 이틀만 조사시간을 주어도 실현 가능성에 대해 훌륭한 답변을 받을 수 있다. 셋째, 이러한 종류의 아이디어는 팀에게 학습하고 실력을 뽐낼 기회가 되므로 흔히 동기부여가 높다.

• 하드웨어 제품에 대한 발견은 소프트웨어의 그것보다 훨씬 어렵다. 소프트웨어보다 제조 시간이 오래 걸리고 실수가 초래하는 결과가 시간과 비용측면에서 훨씬 치명적이기 때문이다. 따라서 하드웨어 제품이 가치, 사용성, 실현 가능성, 유효성 위험에 대해 훨씬 더 적극적인 대응이 필요하며, 실제 생산을 시작하기 전에도 훨씬 높은 수준의 자신감을 가지고 기준을 높여야 한다.

• 사업 유효성 테스트

  • 유효하다, viable : 제품을 만들어 시장에 공급하는 비용을 충분히 감당하며 + 실제 판매할 수 있다는 것

  • 사업 유효성을 다루는 것이야말로 좋은 제품 관리자와 위대한 제품 관리자의 차이를 만들어 내는 것이다.

  • 마케팅팀, 영업팀, 고객만족팀, 재무팀, 법무팀, 사업개발팀, 보안팀, CEO/COO/GM 등 다양한 팀과 논의하고 협의한다.

  • 사업 유효성을 검증한다는 것은 당신의 팀이 제안하는 솔루션이 이러한 각 비즈니스 영역의 제약범위 내에 있는지 확실히 확인하는 것을 말한다.

규모가 큰 회사에서는 어떻게 제품 발견 테스트를 할 수 있는가

• 이미 기업이 명성을 쌓고 매출을 만들어 냈다면 이제 이러한 명성과 매출을 지키는 방법으로 제품 발견을 해내는 것은 제품팀의 몫이다.

• 우리는 라이브 데이터 프로토타입이나 A/B 테스트 프레임워크를 사용해볼 수 있다.

• 완만하고 지속적인 배포를 통해 제품에 대한 고객의 학습 피로도를 낮추고 내부 직원들을 보호해야한다.

• 변화 기법

5) 문화