Product & tech

Small talks on IT industry (Mobile & Web)

내가 이직했을 때 알았으면 좋았을 것들 (이직 후 PM이 처음 해야 할 것)

Inyong Suh1 Comment

개인적으로 PO/PM 직군으로 이직은 딱 두 번 해봤다. 처음은 삼성전자(상품 기획 및 해외 마케팅)에서 쿠팡으로 Product owner라는 직무로 이직했을 때, 두번째는 암스테르담에 있는 Booking.com으로 Product owner라는 같은 직무로 옮겼을 때다.

쿠팡으로의 이직의 경우 S/W Product management에 대한 경험이 전무한 상황에서의 이직이었고 생애 첫 이직이었기 때문에(삼성전자가 첫 직장) 적응을 위한 전략이고 뭐고 없었다. 모든 걸 맨땅에 헤딩하면서 배웠다. Web/인터넷이 어떻게 동작하는지부터 시작해서 인터넷 업계, 개발, 디지털 마케팅 관련한 용어과 개념을 배우면서 동시에 Product management도 사수나 주위 사람들을 통해 배웠다. 당시 Stakeholder였던 마케팅 팀장에게 가서 까놓고 “나 이런 거 하나도 모르니까 좀 알려달라”면서 광고 채널, user acquisition cost, LTV 등에 대해 A4 용지에 적어가면서 배웠던 기억이 아직도 생생하다. 이렇게 배움에 정진(?)을 했지만 Booking.com에 와서도 또 한차례 폭풍 학습을 했다. Booking.com은 PO/PM의 역할이 쿠팡보다는 좀 더 명확히 정리가 되어 있었다. (4~5년 전 얘기다) 물론 쿠팡과 Booking.com의 조직 구조나 문화 자체가 많이 달랐기 때문에 완전히 같은 기준으로 비교를 할 순 없지만, 최소한 Booking.com은 애자일 개발에 대한 경험이 쿠팡보다는 길었으며, 미국, 유럽 및 인도의 메이저 인터넷 업체에서 온 동료들로부터 좋은 practice를 배울 수 있었고, A/B 테스팅의 수준도 높았다. 이 과정에서 많이 질문하고, 싸우고(?), 피드백을 받고, 다양한 고민을 하고, 시행착오도 (또) 많이 겼었다.

이번 글은 ‘내가 이직할 때 알았으면 좋았을 것들‘이다. ‘PM으로 이직 초기에 해야 할 것‘이라 할 수도 있겠다. 지난 번 글 ‘스타트업의 첫 PM이 해야 할 일’에서 언급했듯이 조만간 경력상의 변화가 또 있을 것 같다. 이에 다른 회사로 옮기는 상황을 가정하면서 내가 쿠팡에서 Booking으로 이직했을 때 경험했던 실수와 아쉬웠던 점에 대한 회고를 해보았다.

  1. 해당 산업(Industry)과 주체들에 대해 충분히 공부하자.
    • 필요한 것
      • 해당 비즈니스를 만드는 주체들은 누구인지, 어떻게 거래가 이루어지고, 언제 어떻게 돈이 오고 가는지에 대한 이해
      • 우리 회사는 그 과정에서 어떤 부분을 맡고 있고, 누구와 거래하고 있고, 어떤 문제를 해결하려 하는지에 대한 이해
    • 내가 못했던 것
      • 파트너(호텔리어 측)가 사용할 제품 담당이라고 해서 초반에는 파트너에 대한 공부만 많이 했던 것 같다. 하지만 Marketplace 비즈니스 구조에서 공급(부킹 가능한 호텔 룸) 측면만 공부하는 건 반쪽짜리도 안된다. 결국 파트너도 수요(부킹을 할 게스트)의 트렌드에 따라 대응을 해야 하기 때문에, 수요와 공급 양쪽 주체의 니즈에 대한 철저한 파악이 필요하다.
  2. 매니저에게 ‘이 회사에서 개인의 성장을 위해서는 어떻게 해야 하는지’를 확인하자.
    • 필요한 것
      • 승진 싫어할 사람 많진 않다. 하고 싶다면 ‘어떻게 승진 대상자를 뽑고 어떻게 평가하는지’ 확실히 알아두자. 그리고 좋은 고과를 받기 위해서는 어떤 요건을 충족시켜야 하는지도 대놓고 물어보자. 새로운 회사에서는 어떤 사람이 일을 잘 하는 것인지 명확히 알면 개인의 경력 관리도 일찍부터 할 수 있다.
    • 내가 못했던 것
      • 한국은 좀 다를 수 있어도 유럽과 미국(풍문으로만 들었소)에서는 ‘열심히 한다고’ 승진을 챙겨주지 않는다. 내가 무엇을 원하는지 확실히 얘기해야 한다. 나는 이것을 늦게 깨달았다.
  3. 조직이, 팀이 어떻게 의사결정을 하는지 빨리 파악하자.
    • 필요한 것
      • 팀이 어떤 식으로 의사결정을 하는지 파악을 빨리 해서 나중을 대비하자. 상사와, 팀원들과 논쟁을 벌일 날이 멀지 않았다.
    • 내가 못했던 것
      • 지금도 그렇지만 내가 입사했던 3년 전에 부킹닷컴은 모든 소프트웨어(작던 크던) 릴리즈를 A/B 테스트를 통해 했고 자체 개발한 A/B 테스트 툴을 통해 결과를 분석하고 의사결정을 한다. 나도 쿠팡에서 A/B 테스트를 했었지만 부킹닷컴은 훨씬 더 상세히 가설을 잡고 지표를 선정하며 통계적으로 유효한 결과를 얻기 위한 여러가지 고민을 한다. 처음 몇 번은 이런 문화 및 ‘통계’에 대한 깊은 이해없이 팀의 중요한 의사결정을 하려고 했다가 역풍을 맞고 설전을 벌인 적이 있었다. (물론 졌다…여담이지만 이런 논쟁을 영어로 하는 것도 처음에는 굉장히 힘든 일이었다.)
  4. 당신 제품이 회사의 비즈니스 모델 그리고 사용자 여정(user journey) 등에서 어떤 역할을 맡고 있는지 파악하자.
    • 필요한 것
      • 당신이 맡을 제품이 회사의 전략 그리고 사용자의 삶/업무(B2B인 경우)에서 어떤 역할을 하고 있는지 좀 더 넓은 시야에서 자신의 제품을 바라보자. 당신 제품이 사용자와 회사에 어떤 영향을 미치는지, 어떤 문제를 해결하려고 하는지 확인하자는 말이다. (이런 넓은 시야는 본인 팀의 현재 성과 뿐 아니라 나중에 시니어나 리더가 되기 위해서도 필요하다)
    • 내가 못했던 것
      • 나의 경우 당시 신설됐던 팀을 맡게 되었다. 단기간에 이해하기 어려운 제품이었으며(주위 많은 동료들의 평이다), 나도 숙박(hospitality) 산업과 주체들에 대한 이해가 깊지 않은 상황에서 팀을 맡게 되어서 시야가 좁았다. 우리 제품이 사용자의 삶(업무)에서 어떻게 사용되는지, 그것이 (파트너 및 Booking의) 비즈니스에 어떤 영향을 미치는지에 대한 이해가 얕았다. 결과적으로 우리가 풀어보고자 했던 문제를 깊게 분석해 보지 못했고 초기 성과도 미미하였다.
  5. 상위 부서 및 자기 제품의 주요 지표를 확인하고 회사 전체 지표와의 연결을 파악하자.
    • 필요한 것
      • 위 4번과 사실 유사한 개념이라 볼 수 있다. 상위 부서 및 자기 제품의 주요 지표에 대해 알아보고 그 주요 지표가 회사 전체의 지표와 어떻게 연결되어 있는지 확인하자. 내 제품이 회사 전체의 비즈니스에 어떤 기여를 하는지 확인 할 수 있으며, 앞으로 어떤 부분을 중점으로 발전시켜야 할 지 파악할 수 있다. 대쉬보드를 확인하고 없다면 만들자.
      • 100% 확실한 지표를 찾기 힘들어도 최대한 ‘내가(우리 팀이) 한 일이 회사의 비즈니스 혹은 사용자에게 어떤 영향을 미쳤는지’에 대해 가늠해 볼 수 있는 지표를 찾아 팀원들 뿐 아니라 매니저, 상위 조직장들과 align을 하자.
    • 내가 못했던 것
      • 사실 제품의 특성에 따라 제품의 주요 지표와 회사의 주요 지표와의 연결점을 찾기 쉬울 수도 있고 아닐 수도 있다. 나는 어려운 편에 속했다. 이 연결점을 찾지 못하면 본인 뿐 아니라 팀원들도 ‘그래서 내가 한 일이 회사에 어떤 도움이 되지?’라는 의구심을 계속 갖게 된다. 이는 장기적으로 봤을 때 팀의 성과 평가 뿐 아니라 사기에도 영향을 준다.
  6. 모르는 건 모른다고 하고 질문을 하고 도움을 요청하자.
    • 내가 못했던 것
      • 처음에는 혼자 끙끙 싸매고 혼자 집에서 야근도 종종했다.(이 동네에선 야근은 거의 안한다고 본다) 하지만 모두가 모든 것을 알 수도 없고 시간이 지나면 당신도 자연스럽게 전문가가 된다. 첫 한 두 달은 무조건 질문을 빨리 많이 하자. ‘내가 바보같아 보이면 어쩌지?’라는 고민하지 말자. 질문을 짊어지고 있다가 너무 늦게 하는 것보다 빨리 물어보는 게 낫다. 다음 주 목요일에 있을 매니저와의 1:1까지 기다리지 말고 바로 물어보자. 아무도 뭐라고 하지 않는다.

<참고>

  1. 사실 써놓고 보니 지난 번에 쓴 ‘스타트업의 첫 PM‘ 글과 겹치는 부분이 꽤 많다. 흥미로웠던 부분이다.
  2. 인터넷 검색을 해보면 ‘First 30 days as a product manager(PM으로 이직 후 첫 30일 동안 해야 할 일)’와 같은 글이 많다. 그만큼 여러 사람들이 고민하는 질문인 것이다. 나도 예전에 그런 글들을 읽어보고 해당 에버노트 링크와 같이 정리해 본 적 있으나, 이번 글은 순전히 내 경험을 회고한 내용이다. 물론 예전에 읽었던 글이니 영향을 받았을 수도 있겠다.

스타트업의 첫 Product manager가 해야 할 일

Inyong Suh1 Comment

최근에 이직을 위해 10개 이상 회사와 연락을 주고 받았고 그 중 몇 군데와는 실제 내 매니저가 될 사람(보통 hiring manager)을 포함한 다른 Product manager(PM)들과 여러 차례 인터뷰도 진행하였다. 결과를 떠나 3~4년만에 하는 인터뷰는 스트레스이기도 했지만 지루했던 일상에 refresh가 되는 요소이기도 했다. 모든 회사는 다른 문제를 풀기 위해 노력을 하고 있기 때문에 다양한 회사와 인터뷰를 한다는 것은 다양한 고객의 문제에 대해 내 나름의 기준에서 고민해 볼 수 있는 기회이기도 하기 때문이다. 인터뷰어와의 대화도 즐거웠다. 인터뷰를 하다보면 나와 맞을 것 같은 회사와 사람이 보이고, 이런 인터뷰는 내가 ‘인터뷰를 당한다’라는 생각보단 ‘즐거운 대화를 나눴다’라는 느낌이 든다. 좋은 질문(내가 대답을 하기 쉽진 않지만 핵심을 짚는 질문들)을 하는 인터뷰어가 있을 경우 그 회사에 대한 매력도가 올라가기도 한다. (*참고로 PM 인터뷰는 어떻게 준비해야 하고 주로 어떤 질문을 하는지에 대해서는 나중에 포스팅할 생각이다.)

그 중에서 총 직원수가 10명이 넘지 않는 스타트업의 첫 PM으로 합류하는 케이스도 있었다. 이를 위해 ‘회사의 첫 Product manager로서 내가 해야 할 가장 중요한 일이 뭘까?‘에 대해 혼자 고민해보면서 인터넷 검색도 함께 해봤다. 이번 글에서는 그 (검색) 결과들을 간단히 요약해보고 나의 의견도 덧붙여보려 한다. 다만 아래의 내용은 ‘일반화’를 하긴 힘들 수도 있다는 것을 먼저 얘기해두고 싶다. 창업멤버들의 Product management 경험 여부, 어떤 유형의 제품을 만드는지, 제품의 life cycle 중 어디에 있는지(product-market-fit은 찾았는지, 찾는 중인지 등), 조직이 어떻게 구성되어 있는지, 개발자와 디자이너는 어디에 몇 명이 있는지 등 많은 변수에 따라 회사가 나에게 거는 기대와 내가 할 수 있는 일들, 내가 꼭 해야 할 일들이 달라질 수 있기 때문이다. 이에 아래 정리한 내용은 ‘참고 사항’일 뿐 꼭 따라야 할 ‘Bible’은 아니라는 점 염두에 두길 바란다.

살펴본 의견들을 6가지 카테고리로 나눠보았다.

  1. 기대 수준을 확인하고 조절하기 (set the expectation)
    • 우선 왜 PM을 채용하려는지, 나에게 어떤 기대를 거는지 확인해야 한다. 초기 단계에서는 보통 창업자와 인터뷰를 하고 창업자와 이 대화를 할 것이다. 보통은 창업자가 PM의 일을 겸임하다가 회사/조직의 성장과 함께 업무량이 많아지면서 자기 일을 대신해 줄 사람을 찾게 된다. 새로 채용할 PM이 주로 operational/tactical한 일을 하길 바라는지(자기의 비전을 실현시켜 줄 사람을 찾는 경우), 아니면 제품의 비전과 전략적인 부분까지 맡아주길 원하는지 확실히 확인해야 한다.
    • 함께 일할 다른 직무의 동료들(stakeholder)이 Product management를 어떻게 이해하고 있고, 내가 어떤 역할을 할 것이라 기대하는지 확인도 필요하다. 또한 제품의 의사결정에 입김이 센 동료가 누구인지 파악하고 권한에 대한 대화와 조율도 필요하다. (물론 창업자가 가장 큰 영향력이 있겠다)
    • 초기 스타트업은 인력이 모자라기 때문에 업무의 범위를 정확히 자르기 어려우며 ‘니 일, 내 일’ 딱 자르기 힘든 환경이다. 이에 내 책임과 역할의 범위도 유연하게 가져가야 한다. 필요한 경우 다른 직무의 업무도 어느 정도 대신해야 할 경우도 생기기 때문이다. (wearing multiple hats)
  2. 팀원들과 1:1 미팅하기
    • 함께 일 할 개발자, 디자이너 등 팀원들과 1:1 미팅을 하면서 개개인의 성향도 파악하고, 그들이 PM에게 기대하는 것이 무엇인지 확인하며, 그 동안 제품 개발을 하면서 어려웠던 점/어떤 문제점이 있었는지 확인한다. 이후 실제 업무를 시작했을 때 참고해야 할 중요한 사항들이 될 것이다.
    • 개발팀 리더나 시니어 개발자에게 제품의 기술적인 부분(아키텍처, 테크 스택 등)에 대해 배우고, 현재의 제약 사항 및 최근 이슈 등에 대해서도 브리핑을 받는다. 영업 및 마케팅 담당자와도 비슷한 대화가 필요하다.
  3. 해당 산업과 제품에 대해 이해하기
    • 많은 답변 중 하나가 “푹 쉬면서 산업 전반적인(macro) 부분에 대해 공부해라.”였다. 실제 실무에 들어가게 될 경우 큰 그림에서 상황을 바라보기 쉽지 않다. 이에 내가 일하게 될 산업의 전반적인 지식, 기술의 흐름, 전반적인 기회와 제약사항 등을 알아두자.
    • 경쟁사들이 누구이며 경쟁사의 제품의 강점과 약점이 무엇인지 확인한다.
  4. 고객에 대해 이해하기
    • 가장 좋은 것은 고객들을 직접 만나서 인터뷰를 하고 얘기를 들어보는 것이다. 시장에서 우리 제품을 대신할 만한 제품은 무엇인지, 어떤 제품을 선택했는지(+ 왜?), 사용하고 있는 제품의 pain point는 무엇이며, 고객이 (해당 제품군을 통해) 수행하려고 하는 일이 정확히 무엇이고, 수행하는데 있어 (특정 제품을 떠나) 불편한 점은 무엇인지 등 고객과의 대화를 통해 얻는 정보는 무엇보다 중요하다.
    • 블로그, 트위터, 커뮤니티 등에서 사용자들이 우리 제품을 어떻게 평가하는지 확인한다. 만약 고객의 피드백을 직접 듣는 채널이 있다면 그 피드백 내용들을 확인한다.
  5. 데이터를 정확하게 측정하고 확인하기
    • 회사의 핵심 지표 뿐 아니라 사용자가 제품을 어떻게 사용하는지, 사용에 만족하는지 등에 대한 지표를 확인하고, 그 지표들이 제대로 트래킹되고 있는지 확인한다. 단순히 ‘트래킹하고 있어요’라는 말만 믿지 말고 실제 데이터를 확인하고 검증한다. 관련된 데이터베이스 및 대쉬보드(있다면…) 등에 대한 접근을 요청하고, 이 지표들이 주기적으로 측정이 되고 있는지 확인한다.
  6. 제품 직접 사용해보고 리뷰하기
    • 이 부분은 사실 위 3번과 4번과 어느 정도 겹친다고 볼 수 있다. 경쟁사 제품을 써보기 전에 내가 담당할 제품을 써볼테니까. 내가 담당할 제품을 제대로 사용해보고 이해가 안되는 부분은 동료에게 물어보고, 개선의 여지가 있는 부분은 따로 정리해 두었다가 나중에 활용한다. B2B 제품의 경우 테스트가 쉽지 않은 경우가 있으므로 테스트 방법을 동료들을 통해 미리 확인하고 테스트한다.

사실 회사의 첫 PM이 해야 할 일의 범위는 정말 넓고 많겠지만 위 6가지는 회사에 막 입사했을 때 해야 할 일이다. PM도 업무를 파악하고 제대로 수행하려면 최소 몇 주 이상 걸릴 수 밖에 없다. 특히 완전히 새로운 제품군/산업을 경험하고 있다면 말이다. 너무 조급하게 생각해서 처음부터 디테일의 함정에 빠지지 말고, 넓은 시야에서 산업과 사용자와 제품을 이해하는 시간을 가져야 한다.

여기까지가 인터넷 검색을 통해 알아본 ‘스타트업의 첫 Product manager로서 해야 할 일’이며, 내 의견 또한 어느 정도 추가했다. 내가 참고한 글의 링크, 발췌한 내용 등은 다음의 노트(링크)에 있으니, 혹시 더 자세한 내용을 확인하고 싶다면 위 링크를 확인하기 바란다.

  • ‘스타트업의 첫 PM’ 혹은 유사한 경험이 있으시다면 댓글이나 이메일 등을 통해 인사이트를 나눠주시면 고맙겠습니다. 제가 곧 그 경험을 하게 될 것 같아서요. 🤞 😅

Product manager와 Product owner (3편)

Inyong SuhLeave a comment

* 이 글은 ‘Product owner, Product manager’의 세 번째 글로 아래의 두 글을 먼저 읽는 게 좋습니다.

Product owner? Product manager?

Product manager와 Product owner (2)

위 두 글을 짧게 요약하자면, 첫번째 글에서는 PO(Product Owner)와 PM(Product Manager)이 거의 동일한 일을 한다고 주장했으나, 두번째 글에서는 Tomtom과 같은 회사의 예에서 볼 수 있듯이 PM과 PO이 서로 다른 역할로 함께 일하는 케이스도 있다고 했다. 이번 3편(아마 마지막 편이 될 것 같아요)에서는 최근에 여러 회사와 인터뷰를 하면서 발견한 또 다른 조직 구조들을 포함하여 정리해 보겠다.

쉽게 그림으로 정리하자면 (내가 알고 있는 케이스들은) 아래와 같이 나눌 수 있다.

  • 1번 : 제 첫번째 글의 케이스. 회사는 PO 혹은 PM 직무 중 하나만 운영한다. 제가 일하는 Booking.com이나 예전에 있던 쿠팡이 이런 케이스였다. (참고로 Booking.com은 원래 Product owner로 운영하다가 약 2년 전에 모든 PO를 PM으로 바꾸었다. Role의 변화없이 정말 이름만 바꾸었다)
  • 2번 : 제 두번째 글의 케이스. 회사는 PO와 PM 둘 다 운영하며 두 직무의 책임과 역할의 범위는 다르다. 내가 직접 확인한 케이스는 Tomtom이라는 글로벌 Navigation & map 업체.
  • 3번 : 이번에 새로 발견한 케이스. PO가 PM에게 보고를 하는 구조이다. 두번째 글에서 확인할 수 있듯이 PM은 좀 더 멀리 바라보는 직무로, 제가 좋아하는 문구 “Build the right product to the right customer”에서 ‘right product’와 ‘right customer’ 부분에 포커스(어떤 고객군에게 어떤 제품을 제공해야 하는지)를 하는 직무라면, PO는 그 비전을 feature set으로 breakdown 해서 제품팀(개발자, 디자이너 등)과 함께 최대한 빨리 결함없는 right product을 ‘build’하는 쪽에 포커스를 한다고 볼 수 있다. 그러기에 어떤 회사에서는 자연스럽게 PM이 PO를 매니징하게 되는 경우가 생긴다. IKEA와 PVH(Calvin Klein, Tommy Hilfiger 등 패션 브랜드 회사)의 IT 조직에서 확인할 수 있었다. IKEA의 경우 PO —> Sr. PO —> PM 과 같이 직급이 올라가는 구조로 Product Manager가 실제 Group Product Manager(여러 명의 PM을 관리하는 직책)이나 Director급의 직급이었다.

이번 편이 Product Owner? Product Manager? 편의 마지막이라 한 이유는, 이제 굳이 이걸 구분하는 게 의미가 있을까? 라는 생각이 들어서이다. 올해 하반기에 10개 회사와 최소한 한 차례 통화나 인터뷰를 했었고 이를 통해 확인한 것은 ‘각 회사마다 해당 직무(PO, PM)에 대한 정의와 기대는 다 다르다’라는 것이다. 회사가 순수한 인터넷 기반의 비즈니스를 하는지, 조직의 IT에 대한 이해도와 활용도가 어느 수준인지, 작은 스타트업인지 이미 조직이 많이 커진 기업인지 등 각자의 상황에 따라 해당 직무에 대한 기대는 다 다르다.

이에 두번째 글의 말미에도 언급했지만 이직을 위해 Job apply를 할 때 Job description을 상세히 읽어보고, 조직의 크기, 구조, 책임의 범위 등에 대해 리쿠르터와 꼭 먼저 확인을 하자. 그래서 회사가 본인에게 기대하는 게 어느 정도 수준인지 파악할 수 있고, 이를 토대로 내가 할 수 있는 일인지, 내 경력상 도움이 될 경험인지 등을 판단할 수 있을 것이다. 나의 경우 리쿠르터와 통화를 할 때 아래의 질문들을 꼭 하는 편이다.

  • 현재 조직이 어떤 상황인가? 해당 Job을 Posting한 이유는 뭔가?
  • PM(PO)의 숫자 그리고 전체 개발팀의 크기는 어느 정도이며, 나는 누구에게 보고 하고, 전체 조직 구조는 대략 어떻게 되는가?
  • (첫번째 질문과 유사하지만) 나에게 거는 기대는 무엇인가?
  • 조직에서의 성장에 대한 기회는 어느 정도인가? 회사에서 이 조직에 거는 기대는 무엇이며 앞으로 어떤 성장/확장 계획을 갖고 있는가?

짧지만 하고 싶었던 말을 (오랜만에) 포스팅한다. 독자들의 삶에 크게 도움이 될 진 모르겠지만 최소한 ‘알아두면 좋을’ 정보라 생각해서 글을 적고 싶었다. 본 Product Owner? Product Manager? 편의 글들 중 1번과 2번 글은 ‘PO나 PM이 무슨 일을 하는지’에 대한 이해를 돕기 위한 글로 활용했으면 좋겠고, 이번 마지막 글은 ‘그냥 이런 게 있구나’ 정도의 정보성 글로 (독자분들이) 받아들였으면 좋겠다.

Change aversion : “내가 맨날 쓰는 거 그냥 좀 놔둬!”

Inyong SuhLeave a comment

사람은 대개 변화를 두려워하죠. 익숙한 것을 좋아하고 편안해하구요. 어느날 아침 출근하니 매일 사용하던 업무용 툴의 디자인이 하루 아침에 확 바뀌어 있다고 상상해 보세요. “와 엄청 예뻐졌네. 엄청 사용하기 편해졌겠어!”라는 생각보다는 “아 이제서야 좀 익숙해졌는데 또 바뀌었어? 아 그 XX메뉴는 어딨는거야? 바빠죽겠는데 하나씩 다 눌러봐야 하나?”와 같은 반응일 거에요.

얼마 전에 저도 업무 중에 같은 경험을 했습니다. 이번엔 제가 ‘사용자’가 아닌 그 변화를 주도한 ‘제품팀’이었다는 점이 다르지만요. 모든 맥락을 설명하자면 엄청 길기에 간단히 요약하자면 : “사용자들의 불편한 점을 개선하고자 새로 디자인한 제품을 프로토타입 테스트, 알파테스트, 베타테스트를 거치며 신중하게 테스트했고 마지막에는 78%의 만족도(기준선은 65%였음)를 확인하였기에 ‘성공’을 확신했던 제품 업데이트였습니다. 하지만 큰 규모의 사용자에게 릴리즈를 하기 시작하면서 이 만족도는 급감하였습니다. 처음엔 25% 수준까지 떨어졌죠. PM으로서 실망이 컸습니다. 하지만 이 만족도를 매일 측정하다보니 조금씩 높아지는 게 보였습니다. 2주가 지난 지금은 50% 이상까지 올라왔죠. 사용자들의 피드백을 확인해보면 ‘이전께 더 좋다’, ‘왜 바꿨냐’, ‘불편하다’ 와 같은 피드백이 다수였습니다. 구체적으로 무엇이 불편하다 라는 내용보다는 그냥 불편하다, 이전 것이 더 편하다 라는 의견들이 많았죠.”

사용자들은 갑작스런 변화를 불편하게 느낍니다. 익숙한 것이 편하고 안전하다고 느끼죠. 사실 이번엔 고객 만족도가 초기에 떨어질 것이라는 것은 예상하던 일이었습니다. 이전에 어느 정도 유사한 경험을 한 적이 있었고, 첨부한 링크와 같은 자료를 읽으면서 이것이 자연스러운 일임을 미리 알고 있었기 때문입니다. 첨부된 링크에서는 이러한 현상을 ‘change aversion(변화를 싫어하는 것)’이라는 용어로 사용하고 있습니다.

작은 변화를 적용하는 A/B 테스트라면 굳이 이런 걱정은 하지 않아도 될 것입니다. 하지만 어느 정도 큰 규모의 변화를 적용하는 케이스이고, 정량적인 데이터 뿐 아니라 정성적인 데이터(사용성, 만족도 등)의 중요성도 큰 변화/실험을 계획하고 있다면 첨부한 링크를 한 번쯤 꼭 읽어보시길 바랍니다. 변화의 레벨에는 어떤 것이 있고, 어떤 경우에 큰 change aversion을 예상할 수 있고, 패턴(사용자의 반응)에 따라 어떻게 대응을 해야 할지도 알려줍니다. Change aversion을 줄이기 위한 여러가지 방법도 설명해주고 있구요.

Change aversion은 인간으로서 자연스러운 일입니다. 그렇기에 완전히 피할 순 없어도 최소화 할 수는 있습니다. 첨부된 링크 한 번 읽어보세요. 나중에 피가 되고 살이 될 내용이라 생각합니다. 저만해도 당장 ‘지금’ 경험하고 있는 것이니까요.

* 궁금해 하실까봐 첨언하자면, 베타 테스트 시 change aversion을 확인하지 못했던 이유는 사용자들이 이미변화가 올 것을 알고 있었기 때문이죠. 테스트를 자발적으로 신청한 것이니까요. 그리고 일단 새 디자인의 제품을 사용해보고 원하지 않으면 베타 테스트에서 나갈(opt-out) 수 있도록 구성을 해놓았었습니다. 지금 진행하고 있는 ‘릴리즈’는 opt-out이 불가능한 일괄 변경이기 때문에 저항이 더 큰 것이라고 보구요.

** 이 글은 Publy News에 올린 글입니다.

RICE – 일에 우선순위를 매기는 방법

Inyong SuhLeave a comment

퍼블리 뉴스에 큐레이션해서 올린 글입니다.

원문 : RICE, simple prioritization for product managers

<RICE – Simple prioritization for PMs>

Product Manager의 중요한 역할 중 하나가 바로 어떤 프로젝트나 태스크의 우선순위를 결정하는 일이라 볼 수 있습니다. 이게 쉬운 일은 아니죠. 같은 프로젝트라도 상황에 따라(예, 코로나 전/후), 회사의 전략 방향에 따라, 조직의 목표에 따라, 주요 고객이 누구냐에 따라, 개발팀의 리소스나 디펜던시(다른 팀과 일이 엮여있는 정도) 등에 따라 그 중요성이 달라질 수 있습니다.

그렇기에 ‘이것만 따르면 돼’라고 할 수 있는 방법은 없습니다만 그래도 일반적으로 사용될 수 있는 프레임워크가 여러 가지 있습니다. 이번에 소개할 글은 그 중 RICE framework에 대한 설명입니다. 우선순위를 매기는데 있어 중요한 4개의 단어의 앞글자를 따서 RICE라고 이름 붙였으며 각 단어의 의미는 아래와 같습니다.

  • Reach : 얼마나 많은 수의 사용자에게 영향이 미치는지
  • Impact : 그 임팩트의 크기는 어떠할지
  • Effort : 이를 수행하는데 있어 드는 노력이 얼마나 클지 (시간, 인력)
  • Confidence : 내가 측정한 위 R, I, E의 값에 얼마나 자신이 있는지(예, 구체적인 증거가 있다면 자신감이 높음)

그리고 최종적으로 RICE 점수는 = R * I * C / E 로 계산을 합니다. 이 결과가 큰 순서대로 더 중요한 일이라고 보는 거죠.

사실 모든 일을 이렇게 계산할 수 있다면 좋겠지만 각자의 상황에 따라 이런 프레임워크가 유용할 수도 있고 아닐 수도 있습니다. 저의 경우는 우선순위를 계산할 때 위와 같이 점수를 매기는 방식을 활용하는 경우도 있지만 아닌 경우가 더 많습니다. 여러분들도 일단 이와 같이 우선순위를 계산할 수 있는 프레임워크가 있다는 것만 알아두고 본인의 상황에 맞게 적절히 활용하셨으면 좋겠습니다.

  • 저의 경우는 위의 값과 데이터를 쭉 늘어놓고 디펜던시, 리소스 상황, 현재 회사의 방향, 앞으로 몇 개월 동안 예상할 수 있는 장애물/난관 등 여러가지를 고려해서 우선순위를 결정합니다. 그리고 이렇게 결정한 로직을 제 매니저 그리고 제 개발팀, 디자이너, 마케팅 담당자에게 잘 설명하여 이해를 얻어내려 합니다. (물론 더 복잡한 경우도 많지만 지면상 생략합니다)