프로덕트 오너 #4

9장 테스트 중 가설을 효과적으로 검증하려면

A/B 테스트와 P값을 활용한 가설 검증법

PO는 고객 경험을 개선하기 위한 여러 가지 방법 중 최적인 것을 가설로 선택한 후, 검증을 거쳐 선보인다. 이때, 가설을 검증하는 방법 중 널리 사용되는 것이 A/B 테스트다. 간단히 말해 새로운 디자인이나 기능에 노출된 B그룹 고객들이 A그룹과 비교했을 때 어떤 결과를 나타내는지 확인해보는 테스트다. 이때 유의 확률을 뜻하는 P-Value, P값은 실험의 결과가 우연히 나타난 것인지 아닌지 판단할 때 사용되는 수치이다. 당연히 통계적 유의도가 100%에 가까워야 신뢰할 수 있는데, 이 유의도를 1 빼기 P값으로 나타낼 수 있다. 예를 들어, A/B 테스트에서 P값이 0.02가 나왔다면 본 테스트의 유의도는 0.98, 98%의 유의도를 가진다고 해석할 수 있다. PO는 P값을 보며 테스트 결과를 판단할 수있다. PO가 내세운 가설이 맞는지 증명하는 것은 물론, 고객 모두에게 선보여도 큰 문제가 발생하지 않을 거라는 확신을 얻을 수 있다. 

실패를 인정할 줄 알아야 더 나은 경험을 제공할 수 있다

새로운 가설을 세우고 두세 개의 스프린트를 할애하여 새로운 기능의 A/B 테스트까지 진행했는데, 결과가 예상과 다르면 머릿속이 복잡해지는 것은 당연하다. 특히 애써서 개발과 디자인까지 한 팀원들에게 미안함을 느낄 수 있다. 테스트 결과가 유의미하지 않아 전체 적용을 못 하면, 그 디자인과 기능은 무용지물이 되기 때문이다. 하지만, PO는 이성적으로 판단해야 한다. 애초에 개발을 시작하기 전 문서화해뒀던 '원칙'을 찾아보는 것부터 시작하라. A/B 테스트 결과가 늘 예상했던 것처럼 나올 수는 없다. 우연의 일치도 발생하고, PO가 실제 고객의 행동을 잘 예측하지 못하는 경우도 있다. 어찌 외었건, 낙심하거나 팀원에게 미안해하는 데 시간을 너무 할애하지 않도록 해야 한다. 사실을 재빨리 인지하고, 원인을 명확하게 파악한 후, 그다음 목표 달성을 위해 나아가는 것이 PO의 미덕이다.

통계적인 결과를 토대로 결정해야 진실에 가까워진다

아무리 답답해도 PO는 통계적 의미를 믿고 차분히 기다려야한다. 예를 들어, 7일간의 테스트를 진행하려 계획했는데, 2일 차에 P값이 매우 낮게 떨어지는 경우가 있다고 가정해보자. 그러면 나머지 5일간 테스트를 더 진행해야 하는지 스스로에게 되물을 수 있다. 하지만 7일이라는 기간을 모두 거쳐야 시기에 따른 편차도 테스트가 감안할 수 있게 된다. 고객은 일요일과 월요일의 행동이 다르고, 목요일과 토요일의 행동이 또 다르기 때문이다. 일주일이라는 시간을 모두 거쳐야 기간적 변동을 통계적으로 헤아릴 수 있게 된다. PO는 늘 이성적이어야 한다. 서두르지 말고, 충분한 고객이 B그룹에 포함되어 유의미한 결과가 도출될 수 있도록 기다리자. 인내심을 가지고 기다리다 보면 진실에 더 가까워질 것이기 때문이다. 그래야만 진정으로 훌륭한 프로덕트를 얻게 된다. 

 

---

10장 론칭한 서비스의 문제를 바로잡기

업데이트 소식을 고객센터에 먼저 전달하라

회사에서 새로운 기능에 대해 가장 잘 아는 사람은 PO다. 고객은 물론, 내부 유관 부서에 제일 간결하게 설명할 수 있는 적임자다. 고객에게 어떤 경험을 제공하기 위해, 무엇을, 왜 개발했는지 충분히 이해하고 있기 때문이다. 따라서 PO는 고객과 최접전에서 대면하는 부서에게는 새로운 기능에 대해 필수적으로 알려야한다.  

 

프로덕트는 완벽할 리 없다

테스트까지 거치고 점차적으로 사용률을 높여가며 100%로 적용했더라도, 예상치 못했던 문제가 발생할 수 있다. 그럴 경우를 대비해서 PO는 개발 조직과 사전 협의하여 담당자가 계속 모니터링 할 수 있도록 조치를 취해야 한다. PO 역시 필수적으로 대기하며 다음 상황에 대해 적절한 결정을 내려줘야 한다. 

 

- 심각한 문제일 경우, 당장 이전 버전으로 롤백한다.

- 금방 고쳐질 문제일 경우, 잠시만 기다려달라고 안내한다.

- 금방 고쳐질 줄 알았지만 시간이 지체될 경우, 롤백하거나 차선책으로 대응한다. 

 

각 상황에는 그만의 특수함이 있기 때문에, PO는 모든 정보를 소화하며 언제든지 결정을 내릴 준비를 해야한다. 그리고 결정했으면, 무조건 일관성 있게 집행하라. PO는 모든 상황의 중심에 있다. 절대로 우유부단하게 행동해서는 안 된다. 

 

프로덕트는 완벽할 리 없다. 고객은 PO나 개발 조직이 예상하지 못했던 방식으로 프로덕트를 사용하기도 한다. 아무리 테스트를 오래 해도 모든 경우의 수를 검증할 수 도 없다. 프로덕트는 계속해서 개선될 뿐, 완벽한 프로덕트는 없다. 이 사실을 명심하면 문제가 발생해도 차분하게 대응할 수 있다. 미리 준비해서 이성적으로 판단하는 PO가 되어야 한다.

시간 낭비를 최소화하기 위한 전략

매우 빠른 속도로 발전하는 업계에 속해 있는 PO와 개발 조직은 시간이 귀하다. 그들의 시간이 곧 자원이자 비용이고, 시간을 효율적으로 활용해야 고객에게 더 나은 경험을 계속해서 선보일 수 있기 때문이다. 따라서 PO는 Hate Waste라는 원칙을 따라야 한다. 특히 시간을 잘 활용하기 위해 개발 조직과의 협업 시 일정을 잘 계획하는 것이 우선이다. PO는 한정된 시간 내에 최대의 가치를 고객에게 제공해야 한다. 프로덕트 개선은 끊임없이 이어져야 하는데, 주어진 시간과 자원은 무한하지 않으니 항상 빈틈없이 각 직무별로 작업에 집중할 수 있도록 준비한다.

고객의 소리를 들을 수 있는 환경을 조성하라

PO에게 VOC만큼 소중한 정보는 없다. 고객의 의견을 수렴하고, 고객이 느끼는 불편함을 제거하고, 고객이 원하는 가치를 제공하는 프로덕트를 만들 때, 고객의 생각을 생생하게 접할 수 있다는 것은 축복에 가깝다. 만약, 고객의 소리를 접할 수 있는 환경이 없다면 고객 서비스 조직과 협업하여 VOC 리포트를 생성하는 걸 추천한다. 고객의 소리를 접하다 보면 새로운 아이디어가 떠오르기도 할뿐더러, 반성도 하고 기쁨도 느낄 수 있기 때문이다. 

 

멀티태스킹으로 문제를 해결하는 세 가지 원칙

PO의 삶에서 가장 고된 요소 중 하나는, 하루 종일 수많은 정보를 흡수하고 곧바로 생각을 정리해야 하는 것이다. PO가 요점을 빨리 파악하고 결정을 내려야 하기 때문에, 회의에 들어가면 최대한 빨리 내용을 이해해야 한다. 이런 PO의 삶에 적응하려면 몇 가지를 꼭 지켜야 한다.

 

먼저, 꼼꼼해야 한다. 일단 모든 요청사항을 다 취합하는 것이 기본이기 때문이다.

그러고 나서 우선순위를 이성적으로 정하도록 한다. 

그런 후, 커뮤니케이션을 잘해야 한다. 저자는 이를 기대치 관리라고 부른다. 그 분기에 달성하기로 결정한 OKR과 성공지표, 그리고 각 프로덕트 별로 설정한 지침을 떠올리며, 각 요청사항이 어느 정도의 우선순위인지 상대방에게 알려준다. 서로 간의 올바른 기대치가 형성된다면 실망은 안 하기 때문이다. 

이 세가지만 잘 지켜도 큰 어려움 없이 정보의 홍수 속에서 가장 중요한 것에 집중할 수 있게된다.