📒 | 인스파이어드 PART4. 프로세스(2)

 

 

💡INSIGHT

 크게 두가지의 내용을 다뤘다.
먼저 테스트에서 가장 중요한 것은 아이데이션 단계에서 빠르게 검증을 하는 것. 막대한 손실이 나지 않기 위해서는 무조건 검증을 빨리 하는 것이 중요하다.  더불어 정량적 테스트만 중요하다고 생각했는데, 어떻게? 왜?에 대한 인사이트를 얻을 수 있는 정성적 테스트도 PM에게 꼭 필요한 것이라는 생각의 확장을 경험할 수 있었다.

 끝으로는 고객, 엔지니어, 디자이너와의 소통도 중요하지만 이해관계자와 소통이 더욱 중요할 수도 있겠다는 생각을 하게 되었다. 만약 의견이 대립할 경우 그들이 더욱 경력자이며, 그들의 경험치가 더 높기 때문에 팀의 의견이 좌절될 확률이 굉장히 높다고 책에 쓰여져 있다. 이러한 것들을 예방하기 위해서는 아이디어 회의 초반에 그들의 의견을 반영하고, 계속해서 우리의 상황을 투명하게 공개하는 것이 중요하다는 인사이트를 얻었다.

---

 

 

PART 4.  프로세스 (2)

- 이해관계자들에게 고객에게 어떤 것이 유효했고 어떤 것이 기대와 달랐는지, 그리고 왜 어떻게 지금의 결과가 도출되었는지에 대한 증거를 보여줄 수 있다면 훨씬 효과적일 것이다.

 

 

 

 

CHAPTER 50. 사용성 테스트

- 실제 제품을 만들기 전인 제품 발견 단계에서 사용성 테스트를 실행해야 한다.

- 마지막에 사용성 테스트를 하면 이슈를 수정하기에는 너무 늦어서 막대한 낭비 또는 더 심각한 상황을 초래한다.

테스트할 사용자 모집하기

- 항상 사용자들이 모이는 곳을 찾아가라. 기업용 소프트웨어를 위한 무역 박람회나 전자상거래를 위한 쇼핑센터, 판타지 스포츠를 위한 스포츠바 등에서 당신은 아이디어를 얻을 수 있다.

- 당신이 있는 장소로 사용자의 방문을 요청하는 경우라면 그들의 시간에 대한 충분한 보상을 제공해야 할 것이다. 보통은 서로가 편한 장소인 스타벅스 같은 곳을 테스트 장소로 잡는다. 실제 이러한 방식이 보편화되면서 보통 스타벅스 테스트(Starbucks testing)이라고 부른다.

테스트 준비하기

- 사용성 테스트에 이은 가치 테스트를 위해 제품이 더 현실적으로 만들어질 필요가 있다.

- 테스트를 할 때 PM, 디자이너, 개발자가 함께한다. 엔지니어가 있을 때 마법 같은 일들이 자주 발생한다.

- 테스트를 원하는 명확한 과업들의 조합을 사전에 정의해 두어야 한다. 

- 테스트를 객관적으로 수행하기에는 디자이너의 감정이 상할 수 있는 경우를 피하기 위해

-- 제품 관리자와 디자이너들이 사용성 테스트를 직접 수행할 수 잇도록 훈련을 받는다.

-- 그들이 아이디어에 더 빠져들기 전에 테스트를 빠르게 수행한다.

프로토타입 테스트하기

- 우리는 사용자나 고객이 우리가 생각했던 문제를 실제로 가졋는지, 그들이 이러한 문제를 지금은 어떻게 해결하고 있는지, 그들을 전환시키려면 무엇이 필요한지에 대해 학습해야한다.

- 시작하며 참여자들에게  이것은 단지 프로토타입이며, 매우 초기 제품 아이디어이고, 실제 제품이 아님을 밝힌다. 더불어 나쁜 의견이든 좋은 의견이든 솔직한 의견을 말하고, 그로 인해 전혀 감정이 상하는 일은 없을 것이라고 설명하라.

- 참여자들이 프로토타입의 랜딩 페이지부터 무언가를 이야기할 수 있는지를 확인하라

- 테스트할 때 당신의 사용자가 비평가의 태도가 아닌 사용자의 태도를 유지하기 위해 할 수 있는 모든 일을 해야 한다. 그들이 무슨 말을 하는지보다 그들이 무엇을 하는지를 관찰하라

- 침묵을 지킴으로 참여자를 돕고자 하는 자연적인 충동을 억누를 필요가 있다.

학습내용 요약하기

- 핵심은 당신의 사용자와 고객에 대한 더 깊은 이해를 얻고자 하는 것이다. 

 

 

 

CHAPTER 51. 가치 테스트

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

- 고객이 당신의 제품을 구매하는 동기가 생기려면 당신의 제품을 월등히 나은 것으로 인식해야만 한다. 하지만 가치가 없다면 사용성, 신뢰성, 성능이 아무리 좋아도 소용이 없다.

 

 

 

CHAPTER 52. 수요 테스트 기법

- 가장 크게 시간과 노력이 낭비되는 경우이자 수없이 많은 스타트업실패의 원인은 팀이 제품을 디자인하고 구현해서 마침내 출시했을 때 사람들이 그것을 사지 않는 것을 깨닫는 것이다.

가짜문 수요(fake door demand)테스트

- 버튼이나 메뉴를 사용자 경험상 있어야할 것으로 판단되는 정확한 위치에 넣어본다. 하지만 유저가 클릭하면 실제로 작동하는 것은 아니다. 대신 특별한 페이지로 보내고, 연구하고 있다고 설명하면서 고객의 의견을 기대한다.

- 핵심은 사용자들이 버튼을 클릭할 때까지 테스트 상황임을 알 수 있는 어떠한 시각적인 표시가 없다는 것이다.

- 클릭율(CTR, Click-Through Rate)을 기대 수준 혹은 다른 기능들과 비교할 수 있게 해주는 매우 유용한 데이터를 빠르게 수집할 수 있다는 것이 장점이다.

랜딩 페이지 수요 테스트

- 마치 해당 서비스를 실제로 출시하는 것처럼 신규 서비스를 정확히 설명한다. 유저가 버튼을 누르면 시험버전에 가입하는 것 대신 유저는 연구중임을 설명하는 페이지를 보게 된다. 

 

 

CHAPTER 53. 정성적인 가치 테스트 기법

- 정성적인 테스트는 왜 그런일이 생기는지, 그리고 그 상황을 바로잡기 위해 무엇을 해야하는 지 통찰하는 것이다.

- 한 유저로부터만 답을 찾으려 하면 안되고, 여러 유저의 테스트의 충분한 퍼즐 조각으로 맞춰봐야한다.

- 제품 관리자로서 모든 정성적인 가치 테스트에 반드시 참여해야 한다.

먼저 인터뷰하기

- 우리가 생각했던 문제를 유저가 가지고 있는 것이 맞는지, 지금은 그 문제를 어떻게 해결하고 있는지, 현재 솔루션에서 전환을 시키려면 무엇이 필요한지 등을 확인한다.

사용성 테스트

- 사용자가 우리 제품을 사용하는 방법을 알아낼 수 있는지 확인하고자 한다. 중요한 것은 사용성 테스트 후에 당신의 제품이 무슨 목적이고 어떤 의미로 사용되는지에 대해 유저가 알아야 한다

- 최소한 제품 관리자와 제품 디자이너는 필수로 참여해야하며 개발자도 직접 관찰하면 마법과 같은 일을 자주 만들어 낸다.

가치 입증을 위해 돈을 사용하기

- 사용자가 그 솔루션에 돈을 낼 의사가 있는지를 확인하는 것

가치 입증을 위해 평판을 이용하기

- 그들이 친구나 동료나 상사에게 제품을 추천할 의향이 얼마나 있는지 물어보는 것

- 소셜 미디어에 공유해달라고 요청

- 추천을 위해 상사나 친구 이메일을 입력해 달라고 요청

가치 입증을 위해 시간 이용하기

- 기업용 제품 : 이 일과 관련하여 상당 시간을 할애해 줄 수 있는지 물어보기

가치 입증을 위해 접근성 이용하기

- 전환하고자 하는 기존 제품의 로그인 정보를 요청

- 그들이 기존 제품에서 우리의 제품으로 즉시 전환할 만큼 충분한 가치를 느끼고 있는지 알 수 있을 것

프로토타입 반복하기

- 가치 테스트는 무언가 증명하고자 하는 것이 아님

- 해결할 어떤 문제를 가지고 있다고 생각하는 순간이나 뭔가 다른 접근 방식을 시도하고 싶을 때 하는 것

- 당신의 제품 또는 프로토타입을 스마트폰이나 랩톱에 탑재하고, 아직 그것을 본 적이 없는 사람에게 찾아가서 한번 써보게 하는 것

 

 

 

 

CHAPTER 54. 정량적인 가치 테스트 기법

- 정석적인 테스트가 빠르게 학습하고 커다란 통찰을 얻는 것이라면 정량적인 기법은 근거를 수집하는 것

A/B 테스트

- 우리가 이상적으로 찾고 있는 예측성 높은 데이터를 얻을 수 있다.

- 사용자의 99%에게는 기존 제품이 보이고, 라이브 데이터 프로토타입은 단지 1%이하의 사용자에게만 노출된다.

초대 테스트

- 유용한 결과를 가능한 빠르게 얻고 싶다면 사용자를 초대하는 테스트를 통해 근거를 얻으면 효과적이다.

- 사용자에게 연락을 해서 새로운 버전을 시도하는 일에 초대하는 것

 

 

 

 

CHAPTER 55. 실현 가능성 테스트

- 엔지니어에게 해야할 질문은 "이것을 할 수 있나요?"가 아니다. "이 아이디어를 진행할 최선의 방법은 무엇인가요? 그것을 하는 데 얼마나 걸릴까요?"최고의 제품 아이디어들은 '오직 지금 가능한'문제 해결의 방식을 바탕으로 한다. 그것은 새로운 기술을 의미하며, 그 기술을 조사하고 학습하는 시간이 필요하다.

- 엔지니어에게 심지어 하루 이틀 정도만 주어져도 그들은 실현 가능성의 질문에 대한 훌류한 답변뿐만 아니라 문제를 해결하는 더 나은 방법을 찾아서 돌아올 때가 많다.

 

 

 

 

CHAPTER 56. 사업 유효성 테스트

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

- 사업 유효성을 다루는 것은 진정으로 제품의 CEO가 되게 해준다.

마케팅

- 마케팅은 시장에 적합하고 설득력있으며, 시장 진출을 위한 채널에 부합하는 제품을 원한다. 그래서 당신이 고려하고 있는 무언가가 시장에 위험을 초래할 것 같은지가 그들의 핵심적인 관심사다.

- 제품 구현을 고려하기 이전에 당신이 제안하는 것이 무엇인지 그들에게 프로토타입을 보여 주어야 한다.

- 그들이 걱정하는 것에 대한 대처 방안을 찾기 위해 함께 협력하라.

영업

- 성공적인 제품은 보통 영업 채널의 강점과 제약사항을 고려하여 설계되어야 한다.

- 제품구현을 시작하기 이전에 영업 리더들과 마주 않아서 그들에게 당신이 제안하고자 하는 것을 보여 주어라.

- 함께 이 제품ㅇ르 효과적으로 판매할 방안이 있을지 파악하라.

고객 만족

- 하이 터치 모델(high-touch model) 고객과 매우 밀접한 관계를 맺는 것 : CS담당자들은 제품의 통찰과 프로토타입 테스트에 큰 도움이 된다.

- 로우 터치 모델(low-touch model)고객과 접점을 줄이는 방식

- 회사의 고객 만족 전략이 무엇인지를 이해하고 당신의 제품이 그 전략에 부합하는지 확인해야한다.

재무

- 비용을 설계하는 것은 당신이 사업적으로 유효한 계산을 하고 있음을 리더에게 설명하는 데 중요한 일이다.

법무

- 법무팀의 누군가와 간으하면 빠르게 만나 당신이 제안하는 것에 관해 설명하고, 그들이 예상하는 어떠한 이슈가 있는지 혹은 당신이 알아야 하는 특별한 영역이 있는지에 대해 상의해 보라. 

- 엄청난 시간을 절약하고, 큰 고민에서 해방될 수 있을 것

사업 개발

- 어떤 경우이건 당신의 제품과 관련된 이러한 사업관계와 당신이 제안하는 것이 미치는 영향을 이해해야 한다.

보안

- 당신이 제안하는 것이 무엇인건 보안과 조금이라도 관련이 있다면, 기술 리더 보안 부서의 리더와 함께 앉아서 그 아이디어가 무엇인지, 당신이 그들의 고민을 어떻게 대응할지에 대해 함께 이야기를 나누어라

CEO/COO/GM

- 제품관리자가 이러한 이슈를 모르고 있거나 대응할 계획을 하고 있지 않다면, 그들은 제품 관리자나 제품팀을 신뢰하지 않을 것이다.

 

 

 

 

CHAPTER 58. 제품 발견 스프린트 기법

- 제품 발견 스프린트는 1주 단위(time box)로 제품 발견 업무를 진행하는 것으로서 제품팀이 당면한 중요한 문제나 위험을 처리하기 위해 설계되었다.

- 집중적으로 스프린트 주간 동안 당신과 팀은 중요한 사업 문제를 해결하고자 하는 목표와 함께 수십가지의 제품 아이디어와 접근 방법을 탐색할 것이다.

 

 

 

CHAPTER 57. 파일럿팀 기법

- 조직의 어떤 사람들은 변화를 좋아하고, 다른 누군가가 먼저 성공적으로 사용하는 것을 지켜보기 원하는 사람도 있다. 또한, 변화를 소화하는 데 더 긴 시간이 필요한 사람들도 있고, 일부는 변화를 싫어하며 강요를 받는 경우에만 변화하고자 한다.

- 파일럿팀은 보다 넓은 범위로 실행되기 이전에 일단 조직의 제한된 부분에서 변화의 시작이 허용된다.

- 파일럿팀이 좋은 성과를 낼 수 있는 확률을 최대로 높이려면 참여하는 사람들, 장소, 그리고 그들의 자율성에 대해 세심하게 고려해야 한다.

 

 

 

CHAPTER 60. 로드맵 끊기

- 특정 날짜에 출시하는 구체적인 기능에서 비즈니스 성과로 조직의 초점이 변하는 것을 목표로 한다.

이해 관계자들이 특별히 로드맵에 매력을 느끼는 두가지 큰 이유

1. 그들은 당신이 하는 업무에 대한 가시성을 원하고, 당신이 가장 중요한 업무를 진행하는지 확인하고 싶어 한다.

2. 그들은 사업에 대한 계획을 세우고 싶다. 그러기 위해 중요한 이벤트가 언제 발생하는지 알고 싶어 한다.

 

 

 

 

 

CHAPTER 61. 이해 관계자 관리하기

제품 관리자가 할 일

- 제품관리자는 다양한 이해 관계자들의 고민과 제약사항을 이해하고, 이러한 지식을 제품팀에 전달할 책임이 있다.

- 각 이해관계자의 제약사항과 고민을 이해하는 것을 넘어, 당신이 가장 효과적인 솔루션을 찾아내는 자유를 원한다면 제품 관리자가 각 이해 관계자에게 확신을 주는 것이 중요하다.

성공을 위한 전략

- 이해 관계자를 관리하는 데 성공한다는 것은 이해 관계자가 당신과 당신의 헌신을 존중한다는 것을 말한다.

- 필요한 핵심적인 기법은 중요 이해관계자와 일대일 대화의 시간을 보내는 것이다. 그들의 제약사항을 더 잘 이해할수록 더 나은 솔루션을 찾을 수 있다.

- 제품을 만든 후에 솔루션을 보여주는 것은 실수다.

- 아이디어를 포함하기 전에 제품 발견 단계에서 핵심 이해 관계자들에게 솔루션을 먼저 보여 주기 위해 최선을 다하라.

- 의견이 아닌 데이터에 대한 토론으로 바꾸어라. 당신이 학습하고 있는 것을 매우 투명하게 공유하라. 둘 모두의 의견이 틀렸을 수도 있다. 다시 한번 강조하지만, 제품 발견 업무는 이러한 테스트들을 위해 특별히 설계된 것이다.