by Mr. Lim

 

최근에 출간된 "도둑맞은 집중력"이라는 책에 따르면,

[우아한 기술블로그] 신미지: 레퍼런스 없이 000 만들기, 아이디어는 어디에서 왔을까?

• 그룹웨어 리뉴얼 프로젝트를 다룬 글입니다. 프로젝트 진행 방법론보단 어떤 방법을 활용했는지에 관해 다루고 있습니다.
• 워크샵을 통해 도출한 아이디어를 선별하는 과정은 결국 우선순위를 산정하는 과정과 같지 않나 싶어요. 각 기능 별로 예상되는 사용 빈도, 사용자 범위, 기대효과 등은 어떤 식으로 정의하고 계량화했을지 궁금증이 생깁니다.
• 우아한 오피스 첫 화면에서 겹겹이 쌓이는 팝업 공지와 수많은 연관사이트는 구성원들의 불편함을 토로하는 영역이었다고 합니다. 그러나 리뉴얼된 그룹웨어에서 노출되는 개인화 메시지는 구성원들이 이를 응원을 얻는다는 피드백을 받았다고 합니다. 어떤 기능은 문제점을 해결하기 위해 나오지만 어떤 기능은 서비스를 더 좋게 만들기 위해 나온다는 점을 생각해볼 수 있었습니다. 전자는 사용자의 불편함을 해결하고 후자는 사용자의 즐거움을 주지만, 둘다 사용자라는 공통점이 있네요.

[브런치] 조영수: (23년 3주 차) 가설 검증

해당 아이디어는 커뮤니티 이벤트로 올렸는데 반응이 매우 좋았다. 단기간 진행한 이벤트임에도 댓글 참여자가 480명이 넘었다. 댓글 추이를 보면 고객들은 평균 3~4개의 OTT를 구독중이다.

• 이벤트를 통해 신규 아이디어 실험을 진행했다니. 저는 2개 구축 프로젝트에서 프로모션을 담당하며 이벤트 관련 프론트오피스, 백오피스를 기획했습니다. 사이트 방문 그리고 구매 유도 목적의 이벤트만 고려했습니다. 이런 스스로를 반성하게 하는 글이었습니다. 
  • 생각해보면 이벤트는 사이트 관여도가 어느 정도 있는 사용자만이 참여할 수 있는 서비스인 것 같습니다. 특히나 커머스에서 단순 제품 검색 및 가격 비교 목적이라면 사이트 탐색 없이 제품 검색으로 바로 이동하기 때문입니다. 이벤트를 발견하고 내용을 확인한다는 건 사이트에 어느 정도 관여도가 나와야 나타날 수 있는 행동인 것 같습니다.
  • 설령 체리피커라 할지라도 해당 도메인에 어느 정도 지식을 갖춘 사용자라는 점에서 저관여 사용자로 나타나진 않을 것 같습니다.
  • 즉, 이벤트는 서비스 사용자들 중 관여도가 어느정도 나오는 이들이 모이는 메뉴라고 할 수 있습니다. 따라서 이벤트를 테스트베드로 활용하면 아마 서비스 미사용자 혹은 라이트 유저를 걸러내는 1차 필터링 효과를 얻을 수 있을 것 같습니다. 설령 라이트 유저가 응모하더라도 사용자를 대상으로 하기에 사용자 정보를 기반으로 테스트 대상으로 타당한지도 신뢰롭게 검증할 수 있습니다.

우리는 우리의 효율과 규모가 하락하는 한 매년 고객들을 위해 상품가격을 지속적으로, 또 현저히 더 낮추는 것을 목표로 의사결정을 해왔습니다. 이것은 숫자 계산을 기반으로는 할 수 없는 대단히 중요한 결정의 한 예입니다. 사실 가격을 낮출 때마다 우리는 수학이 말하는 것과 반대되는 방향으로 나아갑니다. 수학은 늘 가격을 올리는 것이 현명한 조치라고 말합니다.

• 모든 의사결정이 수학적으로 검증할 수 있는 건 아닌 것 같습니다. 그리고 수학적으로 옳은 것이 사업적으로 또는 서비스적으로 옳다는 것도 아닌 것 같습니다.
• 중요한 건 서비스의 목적을 생각할 때 이것이 맞는 행동인가를 판단하는 능력인 것 같습니다.

제품을 빠르게 만드는 것만큼이나 혹은 어쩌면 그보다 더 중요한 것이 있다.

바로 "우리가 방향에 맞게 실행하고 있는가?"이다.

올바른 방향을 설정에도, 정말 열심히 그리고 빠르게 실행에 옮겼음에도 그곳으로 나아가지 못할 수 있다.

이는 팀이 일단 생존을 하고 나면 발생할 수 있는 문제이다.

생사의 기로 앞에서 살아남으면 비교적 그 원인은 명확하다.

그러나 초기 성공과 함께 제품 기능이 다양해지면 인과관계 파악이 더욱 어려워진다.

이 지점에서 해야할 질문이 바로

"지금의 성과는 제품 팀이 실제로 들였던 노력의 결과물이라고 볼 수 있는가?"라는 것이다.

사용자 수가 늘어난 것이 정말로 개발한 것들 때문에 일어난 것일까? 아니면 혹시 신문에 그로킷에 대한 기사가 실려 사용자 수가 늘어나지는 않았을까?

따라서 제품팀은 기능이 사용자에게 어떤 영향을 미쳤는지 보다 정확하게 분석할 필요가 있다.

책에선 이러한 문제를 해결할 방법으로 코호트분석과 A/B 테스트를 소개했다.

코호트 분석이란 사용자를 특성에 따라 그룹으로 분류하고, 각 그룹 단위로 분석하는 것을 의미한다.

그리고 A/B 테스트는 그룹A, B를 나눠 한 그룹에는 새로운 기능 도입하고 다른 그룹에는 도입하지 않는 등 차이를 두고 기능에 대해 테스트하는 것이다.

보다 구체적으론 신규 출시된 기능에 대해 코호트 분류에 따른 A/B테스트를 진행하고 이 결과를 분석하는 방식으로 결과를 측정하는 프로세스라 생각된다.

분명 이러한 작업을 수행하지 않던 조직에는 매우 번거롭고 느린 작업이 될 거라 생각한다. 그러나 내딛는 한 걸음 한 걸음이 매우 소중한 스타트업에선 유효하지 않은 기능을 개발하지 않는 비용을 아낄 수 있어 결과적으로 효율적인 방법이라 생각한다.

인스파이어드를 읽고 있다.

읽으며 느낀 제품관리자란 어떤 역할과 책임을 갖고 있는지를 정리해보려 한다.

1. 제품관리자의 책임

제품관리자가 책임을 지니는 4가지 영역이 있다.

고객, 데이터, 비즈니스, 산업

고객, 사용자에 대해 가장 잘 알고 있고, 이해하고 있어야 한다.

마치 전문가라 할 수 있을 정도야 한다.

이런 맥락에서 일까, 사용자 인터뷰에도 항상 직접 참여할 것을 강조했다. 사용자 인터뷰를 보고받는 것이 아닌 그 현장과 과정을 관찰해야 한다는 것이다. 

왜 고객에 대한 이해를 전문가 수준이 되어야 할 정도로 강조하는 가에는 제품관리자의 핵심 역할 중 하나인, 제품의 발견과 관련이 깊은 듯 하다.

데이터에 대한 이해 또한 강조한다. 사내 데이터 전문가가 있다 할지라도 본인이 궁금한 건 직접 데이터로 해결할 정도는 되어야 한다고 소개한다. 정확히 말하면, 데이터를 보고 분석하는 것을 남에게 전가하면 안된다고 본다. 제품관리자에게 있어 데이터 분석 업무는 하루 업무의 시작이다.

비즈니스에 대한 깊은 이해도 필수적이다. 여기서 산업과 책임이 중첩되는 것은 아닌가 할 수 있다. 여기서의 비즈니스는 비즈니스 모델에 대한 이해를 의미하는 듯 하다. 비즈니스를 이해하는 것은 곧 이해관계자를 파악하는 것이다.

그렇다면 제품관리자는 왜 이러한 역량이 요구되는가? 책에서 소개하는 제품관리자는 백로그만 추적하는 사람이 아니다. 책이 바라는 제품관리자는 업무를 실행하는 사람이다. 내가 보기에 이것은 하나의 창업과도 같다. 자기 자본으로 창업을 하는 게 아니라면 창업가는 무수한 투자자를 만나 자신의 아이디어를 소개하고 그들을 설득해내야 한다. 그리고 제품관리자는 사내 인력을 제품관리자가 바라는 업무에 배치하고 또 실행하고 위해선 무수한 이해관계자들을 설득하는 과정이 필요하다. 이때 지피지기면 백전백승이라 하니 이해관계자를 이해하고 파악하는 건 필수적이라 할 수 있을 것이다.

마지막으로 산업에 대한 이해이다. 시장과 산업을 이해해야 하는 이유는 비교적 간단하다. 경쟁자보다 확연히 나은 제품을 만들어야 하기 때문이다. 책도 알고 있고 우리도 알고 있듯 이제 단순히 경쟁자와 똑같은 제품만으론 시장에서 성공하기 어렵다. 그냥 딱 봐도 나은 제품이어야 한다.

2. 제품관리자의 역량

위에 책임을 기술했다면 이번엔 내가 읽으며 느낀 제품관리자에게 필요한 역량이다.

개인적으로 느낀 제품관리자에게 필요한 역량은 학습능력이다. 물론 책에서도 제품관리자의 역량으로 소개된다.

정확히 말하면 성공적인 제품관리자가 되기 위해서 똑똑하고 창의적이고 집요해야 한다고 한다. 여기서 똑똑하다는 것은 지적 호기심이 많고 빠르게 학습할 수 있는 능력이라 한다. 이러한 역량에 내가 이해한 바를 한 스푼 더하자면 바로 어떤 상황이든 유의미한 인사이트를 끌어낼 수 있는 학습능력이다. 

책에서 소개한 제품 발견 계획 기법 중 고객 발견 프로그램 기법이 있다. 간단히 말하면 참조고객과 함께 제품을 발견하는 기법인데 이때 참조 고객은 실제 돈을 내고 사용하는 것에서 나아가 다른 이들에게까지 제품에 대한 찬사와 함께 제품을 소개하는 이들을 말한다. 제품 발견을 위해 참조 고객을 통해 검증해가는 것이 매우 효과적인데 만약 제품 발견 계획 기법을 실행하려는 팀에게 참조고객이 구해지지 않는다면? 제품관리자는 바로 이 상황에서조차 한가지 배울 수 있다. 어쩌면 팀이 풀고 있는 문제는 그다지 중요한 문제가 아닐 수 있다는 것이다. 

고객의 일탈 행동에서도 제품관리자는 무언갈 배울 수 있다. 이베이는 Everything else라는 카테고리를 만들었는데 말 그대로 기존의 카테고리 이외 모든 것을 거래할 수 있는 카테고리이다. 그리고 이 카테고리 덕에 이베이는 세계 최대 중고차 거래 회사가 되었다고 한다. 이러한 고객의 일탈을 통해 어떤 수요가 있는지 제품관리자는 학습할 수 있어햐 한다는 것이다.

전자는 계획하지 않았던 상황에서 얻은 인사이트이고 후자는 계획된 것이외의 상황을 예측해 얻어낼 수 있는 인사이트이다. 어떠한 상황이 되었든, 상황이 계획대로 흘러가든, 계획대로 흘러가지 않든 어떤 상황에서도 고객, 데이터, 비즈니스, 산업에 대해 유의미한 자료, 즉 업무에 활용할 수 있는 자료를 학습할 수 있어야 하는 것 같다.

3. 제품관리자는?

아직 책을 끝내지 못했고 모든 내용을 파악하지 못했다. 지금까지 읽으며 느낀 제품관리자는 마치 감독과 비슷하다 할 수 있을 것이다.

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

그러나 감독과는 본질적으로 차이가 있다. 나아가 CEO와 본질적으로 차이가 있다.

"하나의 차이가 있다면 CEO와 달리 제품관리자는 누구의 상사도 아니라는 것이다."