PM은 결국 가설을 검증하는 사람이다
PM의 역할과 가설을 세우는 방법에 관하여
1. PM이 하는 일은 결국 가설을 검증하는 일이다
프로덕트 매니저가 하는 일은 무엇인가?라는 내용에 대해 매일 정의하고, 또 체감하고 있다. 그리고 시중에도 프로덕트 매니저가 하는 일에 한 설명이 다양하고 또 자세하다.
- PM이 하는 일은 문제를 발견, 정의, 해결하는 일이다
- PM이 하는 일은 메이커(개발자, 디자이너)가 최상의 역할을 하도록 서포트하는 일이다
- PM이 하는 일은 사용자가 문제를 해결하도록 돕는 일이다
- PM이 하는 일은 제품의 성장을 책임지는 일이다
- 기타 등등...
그런데, 위의 정의에 따라 PM이 문제를 발견하여 정의하고 해결하든, 팀의 구성원이 최상의 컨디션으로 제품을 개선할 수 있도록 돕든, 사용자의 문제 해결 과정을 돕든, 그리고 제품의 성장을 책임지든, 공통적으로 들어가는 하나의 & 그리고 가장 중요한 일이 있다. 그것은 바로 가설을 설정하고 이를 검증하는 일이다.
가령 위의 정의는 아래와 같이 모두 가설과 검증의 형태로 나눌 수 있고, 이런 형태로 진행된다.
- 문제 발견 : 이런 문제가 있을 것이다 (가설) ▶ 이런 문제가 진짜로 있는지 확인 (검증)
- 문제 해결 : 이렇게 하면 문제가 해결될 것이다 (가설) ▶ 진짜로 해결되었는지 확인 (검증)
- 제품 성장 : 이렇게 하면 제품이 성장할 것이다 (가설) ▶ 진짜로 성장했는지 확인 (검증)
- 팀 서포트 : 이렇게 하면 팀원의 효율이 증가할 것이다 (가설) ▶ 진짜로 증가했는지 확인 (검증)
이는 결국 굳이 PM뿐만이 아니라, 모든 사람들의 생활과 업무에는 가설과 검증의 단계가 자리하고 있기 때문이다. 가령 우리의 흔한 점심시간에도 아래와 같은 가설과 검증의 단계가 녹아있다.
- 이 시간에 나가면 엘리베이터에 사람이 많을 것이다 (가설) → 나가보니 진짜로 많더라 (검증)
- 오늘은 돈가스를 먹으면 맛있고 배부를 것이다 (가설) → 막상 먹어보니 별로더라 (검증)
그래서 PM은 설문을 통해서든, 인터뷰를 통해서든, UT를 통해서든, 지표 분석을 통해서든, A/B 테스트를 통해서든, MVP를 통해서든, 혹은 또 어떤 수단이나 방법을 통해서든 결국 가설을 검증하는 역할을 담당하는 사람이다. (물론 이를 오롯이 혼자 하지는 않는다)
PM은 어떤 수단이나 방법을 통해서든
결국 가설을 검증하는 역할을 담당하는 사람이다.
2. 가설은 프로덕트의 사용자를 대상으로 한다
그러면 이러한 가설이란 대체 왜 세우고 또 검증하는 걸까? 결론적으로, 가설은 결국 '고객'에 대해 학습하기 위해 세우며, 이는 상상보다는 구체화된 문장 형태로 정리할 수 있다.
이전에 다른 글을 통해서 의견 혹은 정론을 공유했다시피, 프로덕트 팀은 사용자의 문제를 해결한다. 세상의 모든 프로덕트/서비스/솔루션은 사용자의 문제를 해결하기 위해 제작, 제공되기 때문이다.
다만 이를 제대로 해결하기 위해선 가장 먼저 & 결국 사용자에 대해서 알아야만 한다. 우리의 사용자는 누구이며, 어떤 문제pain point를 지녔으며, 이를 왜 어떤 맥락에서 지니고 있으며, 이를 어떻게 해결하고 있으며, 우리 서비스에 이를 해결하는 과정에서 아쉬운 점은 없는지 등등.
PM으로써 우리가 세우는 모든 가설은 결국 우리의 프로덕트/서비스를 사용하는 사용자를 대상으로 한다.
모든 가설은 결국 우리의 프로덕트/서비스를 사용하는 사용자를 대상으로 한다.
3. 가설은 상상, 뇌피셜과는 무엇이 다른가?
그런데 이런 가설이란 우리의 머릿속 상상, 속된 말로 '뇌피셜'과 다른 건 무엇인가? 이 역시 결론부터 말하자면 가설은 상상보다 훨씬 구체적인 형태를 지녀야 한다. 분명한 문장으로 정의할 수 있어야 한다.
가령 우리의 상상은 보통 아래와 같이 두리뭉실하다.
- '점심에 돈가스 먹으면 맛있겠다'
- '제품 금액을 할인해주면 우리 이용자들이 좋아하겠지?'
그런데 문제는, 이런 두리뭉실한 상상은 그다음의 구체적인 실행계획action plan이 도출되지 않는다는 점이다. 상상한 건 좋은데 그래서 뭘 어떻게 하라는 건지? 가 분명치 않다.
- '점심에 돈가스 먹으면 맛있겠다' ▶ 그래서 점심시간은 몇 시인 건지? 어느 식당으로 가야 하는지? 돈가스는 등심인지, 안심인지, 모둠인지? 맛있다는 건 얼마나 맛있다는 건지?
- '제품 금액을 할인해주면 우리 이용자들이 좋아하겠지?' ▶ 그래서 어떤 제품에 할인을 해준다는 건지? 할인은 얼마나 해준다는 건지? 우리 이용자들은 전체 유저인지 아니면 특정 유저인지? 좋아한다는 건 얼마나 좋아하는 건지? 좋아한다는 증거를 어떤 지표로 알 수 있는지?
반면 가설은 상상과 달리 구체적이다. 가능한 한 쪼갤 수 없는 단위까지 쪼개서 세밀하게 정의define하여 정리된 문장이 가설이다.
- 오늘 12:30 ~ 13:30 사이에 길 건너 최고 돈가스 집에서 안심 돈가스를 소금하고 고추냉이만 살짝 찍어먹으면 고소하고 담백한 게, 값으로 11,000원을 지불해도 전혀 아깝지 않을 정도로 맛있겠다
- 화이트데이를 맞이해서 캔디, 초콜릿, 껌 카테고리의 상품 전체에 일괄적으로 50% 할인을 해주면 기념일을 주로 챙기는 10대 중반 ~ 30대 초반 유저들이 좋아해서, 지난주 대비 캔디, 초콜릿, 껌의 총판매량은 30%가량 증가하고 해당 유저들의 이번 주 장바구니 객단가는 15% 정도 증가하겠지?
(물론 점심시간에 돈가스를 먹으러 가며 저 정도로 생각을 쪼개어 입 밖으로 꺼내면 훌륭한 PM이 아니라 함께 지내기 힘든 사람이라는 소리를 들을 가능성이 더 크다... 물론 이 또한 가설이다)
이렇게 분명하고 세밀한 형태로 정리된 가설은 이제 검증을 위한 구체적인 실행계획action plan을 도출할 수 있게 된다. 즉, 상상을 가설로 정리한 이유는 가설을 검증하기 위해 무엇을 해야 할지를 분명히 하기 위함이다.
가령 돈가스의 예시의 경우 12:30~13:30에 최고 돈가스에 가서 안심 돈가스를 시켜서 소금과 고추냉이를 살짝 찍어먹어 보면 검증이 가능하다. 11,000원을 지불할 만큼 맛있는지, 혹은 그 값이 다소 아깝다고 느낄 만큼 맛없는지 검증 가능하다.
또한 할인 행사 예시의 경우에도, 할인을 제공해야 하는 상품군과 할인 비중이 정리되었고, 누구를 대상으로 가설 검증을 진행하면 될지, 그리고 가설이 성공했는지 혹은 실패했는지 확인할 구체적인 기준도 정리되었다. 실험을 설계할 수 있게 되었다.
다만 이러한 가설-검증식 사고가 익숙지 않은 이들의 경우, 도대체 때에 따라 어느 단위까지 문장을 쪼개고/세밀화하고, 어떤 항목까지 포함하여야 하는지가 고민이 될 것 같다. 사실 이 부분은 서비스마다, 경우마다 매번 다를 수밖에 없다. 혼자 점심에 돈가스 집에 갈 때와, 양가 부모님을 모시고 상견례를 갈 때의 고려 요소가 다르듯이 말이다.
다만 일반적으로 가설은 아래의 형태를 띠게 되며, 아래의 형태에 때에 따라 구체적인 항목들을 추가하는 구조가 된다.
- Who : 어떤 유형의 사용자가, 어떤 행동을 하는 사용자가
- When : ~하면, ~할 때, 우리가 ~을/를 제공해주면
- Then : ~ 할 것이다, ~한 반응을 보일 것이다 (+그 결과 지표 a가 #만큼 or %만큼 증가할 것이다)
(이 외에 세부적인 실험 설계를 위해 When, Where, How와 같은 요소들을 추가할 수 있다)
