product manager

프로덕트 리더가 되기 위해 필요한 스킬들

Inyong SuhLeave a comment

Cracking the PM Interview라는 책을 공저한 Jackie Bavaro의 미디움 글입니다. 본인과 본인 팀원들의 경험을 통해 배운 경력 개발을 위한 중요한 스킬을 정리했습니다. 사실 논리정연한 글이라기보다는 본인이 생각한 중요한 스킬을 쭈욱 나열한 글입니다. 제가 봤을 때 이 글을 한 문장으로 요약하자면 다음과 같습니다.

다른 직무로 전환하는 경우가 아닌 이상 직무 내에서의 경력 개발은 담당 업무의 범위를 넓히고(increasing scope), 더 복잡한 문제(complexity)를 해결하고, 더 자율적(autonomy)으로 일하고, 더 큰 임팩트(impact)를 내는 방향으로 발전해야 합니다. (“Career growth within a role is usually about increasing scope, complexity, autonomy, and impact”)

제가 Booking.com에서 일하면서 배운 것도 위와 동일합니다. 한 제품, 한 문제에만 포커스를 하며 일하다가 스킬이 늘고 좀 더 넓게 볼 줄 아는 시야가 생기면, 자연스럽게 당신의 매니저도 당신의 실력을 믿고 더 많은 수의/더 복잡한 문제를 맡기게 됩니다. 그럴수록 더 큰 비즈니스 성과를 낼 수 있게 되구요. 조직 내에서 자연스럽게 시니어/리더가 되어가는 과정입니다.

성과를 내기 위한 더 많은 기회를 얻기 위해서는 매니저와 수시로 본인의 경력에 대한 논의를 해야 합니다. Career goal에 대한 논의를 말이죠. 매니저는 당신이 더 많은 성과를 내어 경력상의 목표를 달성하기 위해 돕는 역할을 합니다. 그러기 위해선 다시 한 번 말하지만 매니저가 내가 이루고자 하는 목표를 알아야겠죠. 한국의 조직 문화에서는 좀 어색할 수도 있는 대화일 수도 있습니다.

또한, 매니저가 내 목표를 알고 있다고 하더라도, ‘신뢰‘를 주지 못하면 새로운 기회를 얻기 힘들겠죠. 자율적으로 복잡한 문제를 해결하는 모습을 지속적으로 보여줘야 합니다. 문제를 제대로 해결하기 위해서는 각 회사 고유의 업무 문화/프로세스를 잘 알고 이를 토대로 실행 계획을 세워야 하기도 하구요.

‘임팩트’를 증명하기 위해서는 본인의 제품/업무가 회사의 전략/비전과 어떻게 연결되어 있는지 우선 파악을 해야 합니다. 아무리 열심히 일해봤자 회사의 리더들이 ‘중요하지 않다’고 생각하는 일일 경우 그 성과를 인정받을 수 없으며 오히려 리소스를 낭비했다고 생각할 수도 있습니다.

이외에 채용을 더 경험하고 배우라는 것, 사이드 프로젝트를 잘 선정해서 실행하라는 것 등 몇 가지의 조언들이 더 있습니다. 완전 짧은 글은 아니기에 5분 정도는 시간을 두고 읽어보셔야 할 것입니다.

PM을 매니징하고 성장을 도울 수 있는 방법

Inyong SuhLeave a comment

‘PM의 정의, PM이 해야 할 일’등에 대해서 늘 논쟁이 많죠? 함께 일하는 디자이너, 데이터 과학자, 개발자 등에 비해 역할과 책임을 한 마디로 정의하기 어려운 직무입니다. 정답도 없구요. 그러면 이런 PM들을 ‘매니징’한다는 것은 어떨까요? 링크된 글의 저자에 따르면 이는 ‘모호함’의 제곱(ambiguity² ; 직역은 늘 어색합니다..)입니다. 😂

이번 글은 현재 Shopify의 VP of Product인 Brandon Chu의 글입니다. 여러 명의 PM을 매니징해 본 경험이 있는 그가 밝히는 ‘효과적으로 PM을 매니징하기 위한 프레임워크’를 소개합니다.

1. The mental model for managing PMs — 그들은 사업가이고 당신은 그들의 투자자라고 생각하라 (they’re entrepreneurs, you’re the investor)

  • PM은 기업가의 기질을 가지고 있는 경우가 많다. 이들을 사업가로 생각하고 당신은 그들의 비전을 산 투자자로 생각해보라. 각 PM의 오퍼레이션에 깊이 관여하지 말되 적절한 피드백을 주고 그들이 보지 못한 부분(blind spot)을 볼 수 있도록 도와줘라.
  • 당신도 그들로부터 배울 수 있다는 것을 잊지 말라. 다양한 백그라운드(실제 스타트업 창업을 몇 번 해본 PM, FANG 등에서 일했던 PM 등)에서 온 직원들의 다양한 관점/능력을 통해 당신도 그들로부터 배울 점을 찾을 수 있다.
  • 그들이 당신보다 뛰어날 수 있다. 그들이 가능성을 펼치고 빛날 수 있도록 도와줘라.

2. Developing PMs — 적절한 업무 범위를 어떻게 설정할까?

  • Whole customer experience를 출시해 보는 경험은 PM의 성장에 가장 좋은 방법이다. PM은 그의 팀이 제공하는 end-to-end 고객 경험을 통해 가치를 만든다.
  • 당신의 임무는 해당 PM이 매니징 가능한 최대 범위의 업무를 맡겨 그들이 최대한의 성과를 내게 하는 것이다. 여기서 ‘업무 범위를 정해준다’라는 것은 ‘어떤 제품을 만들어라’라는 지시의 개념이 아닌 어떠한 크기의 ‘목표(goal)’가 적절한 지 PM과 함께 조절하는 개념이라 보면 좋겠다. 능력이 뛰어나고 야심이 있고 잠재력이 큰 PM의 경우는 더 큰 목표를 맡기면 될 것이다.
  • 그럼 어떻게 그 ‘적절한 범위’를 알 수 있을까? 우선 제품/프로젝트(의 복잡도)를 6가지 관점(이 6가지에 대해서는 첨부된 링크 확인바람)에서 분석을 한 후, 해당 PM이 이 제품/프로젝트를 맡아서 성공적으로 임무를 수행할 수 있을지 생각해 본다. 함께 오래 일한 PM이라면 가능성/잠재력에 대한 판단이 상대적으로 쉽겠지만, 새로 입사한 PM이라면 좀 어려울 수 있다. 이럴 경우 처음엔 좀 난이도가 낮은 제품을 맡기고 적응과 성과의 속도에 따라 업무 범위를 조정해 주면 된다.

3. Assessing PMs for performance — PM의 성과는 어떻게 측정할까?

  • PM은 특정 몇 개의 ‘스킬’만으로 일하는 직무가 아니기 때문에 성과를 평가하기 굉장히 어렵다. 아래의 4가지 관점에서 PM의 성과를 평가해 보자.
    1. 제품 성과(Product performance) : 이론적으로 가장 적합한 방법이다. 하지만 이것만으로 PM의 평가를 순전히 평가하는 것은 현실적으로 어렵다. 왜냐하면 : 1) 어떤 제품은 그 성공여부의 판단이 오래 걸리기도 하고, 2) 모든 제품의 성과를 직접적으로 측정하기 어려울 때도 많고, 3) 어떤 제품을 맡느냐에 따라 성과의 크기가 다를 수 있고, 4) PM은 팀의 일원으로 디자이너나 개발자의 역량에 따라서도 제품의 성과는 달라질 수 밖에 없기 때문이다.
    2. 다른 직원들과 얼마나 소통을 잘 하고 효과적으로 일하는가? : Product management는 직무적으로 리더일 수 밖에 없고 그들의 잠재적인 성과는 얼마나 다른 이들로부터 ‘신뢰’를 얻는가에 따라 달라진다. 함께 일하는 팀원, 동료 PM, 유관 부서 등으로부터 피드백을 받아보자.
    3. 의사 결정 능력 : 모든 의사결정은 기회 비용이 수반된다. PM이 내린 결정을 깊이 분석해보고 왜 그런 결정을 내렸는지 논의를 해보라. 이는 좋은 코칭 기회가 되기도 한다.
    4. 전략적인 사고 능력 : 디테일에 함몰되지 않고 큰 그림에서 제품을 바라볼 수 있는 능력.

저는 아직 PM을 매니징해 본 경험이 없습니다. 하지만 매니저의 관점에서 상황을 볼 수 있는 능력은 다음 세 가지의 장점이 있다고 생각합니다. (1) 어떻게 해야 성과를 낼 수 있는지를 명확히 알 수 있다, (2) 매니저와의 대화를 내가 능동적으로 이끌 수 있다, (3) 매니저도 사람이다. 매니저의 고충을 이해하고 그의 시선에서 상황을 바라보고 대화를 할 수 있다(인간적인 bonding에 좋음). 그것이 제가 종종 ‘Product leadership’에 대한 글을 찾아보고 독자분들과 공유하는 이유입니다.

내가 이직했을 때 알았으면 좋았을 것들 (이직 후 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와 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이 무슨 일을 하는지’에 대한 이해를 돕기 위한 글로 활용했으면 좋겠고, 이번 마지막 글은 ‘그냥 이런 게 있구나’ 정도의 정보성 글로 (독자분들이) 받아들였으면 좋겠다.

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 로 계산을 합니다. 이 결과가 큰 순서대로 더 중요한 일이라고 보는 거죠.

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

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