Inyong Suh

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

December 29, 2020December 29, 2020Inyong 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이 처음 해야 할 것)

December 28, 2020December 28, 2020Inyong 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으로 이직했을 때 경험했던 실수와 아쉬웠던 점에 대한 회고를 해보았다.

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

<참고>

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

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

December 16, 2020December 16, 2020Inyong 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가지 카테고리로 나눠보았다.

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

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

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

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

Product manager와 Product owner (3편)

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

책을 출간하였습니다 – ‘골든 해빗’

October 19, 2020December 13, 2020Inyong SuhLeave a comment

누구나 인생의 ‘버킷 리스트’는 있죠. 20대 때 저의 버킷 리스트의 가장 위에 있는 꿈은 (1) 내 이름으로 된 책을 출간하기, (2) 회사 그만두고 전 세계로 장기 배낭여행을 떠나기, (3) 해외에서 일하면서 살아보기 였습니다. 30대가 되고 결혼을 하게 되면서 장기 배낭여행은 좀 힘들어졌습니다만, 우여곡절 끝에 3번(해외에서 일하면서 살기)은 달성을 했습니다. 그리고 얼마 지나지 않은 작년에 1번(도서 출간)을 달성할 수 있는 기회가 생겼습니다.

이메일을 뒤져보니 작년(2019) 5월이었네요, 출판사의 편집자님으로부터 첫 연락이 온게. 1년이 넘는 시간 동안 많은 고민을 하고, 많은 시간을 책상 앞에서 보내고, “내가 이 짓을 왜 시작했지…”와 같은 자책도 종종 하였습니다. 책의 내용에 대해서도 고민을 많이 하였지만 집필의 처음부터 끝까지 저와 함께 했던 고민은 바로 “내가 이런 말을 할 자격이 있나?” 였습니다.

이 책은 흔히 말하는 자기계발서입니다. 보통 자기계발서라고 하면 ‘성공한 누구누구가 자기가 걸어온 길에서 깨달은 것들을 전해주는 형식’이나, ‘성공한 사람들을 연구하는 사람들이 그들의 공통점을 잘 정리해서 알려주는 형식’이 많은 것 같습니다. 그런데 전 한 번도 내가 ‘성공했다’고 생각해 보지 않았습니다. 물론 제 나름의 버킷리스트 중 하나인 ‘해외에서 일하기’를 달성한 점은 뿌듯하게 생각하나 제가 누구에게 조언을 해줄만큼 뛰어난 사람은 아니며 아직도 30대로 어린 축에 속하구요.

하지만 우리는 책을 읽으면서 책의 모든 내용을 그대로 받아들이거나 따르지 않죠. 다 각자 나름대로 해석을 하고 알아서 받아들입니다. 저도 그랬구요. 이렇게 생각하니 마음이 좀 편해졌습니다. 내가 무슨 말을 하든 그건 나의 경험에서 나온 나의 생각인 것이고 그것을 받아들이는 것은 독자들의 몫이라는 것. 내가 굳이 ‘자격’에 대해 생각을 할 필요는 없다는 것을요.

책은 한국어로 집필했으며 한국에서만 출간합니다. 다음 주(10월 20일)부터 온라인 출고가 되며 그 다음 주(10월 26일 주) 정도에는 서점에서 확인하실 수 있을 것 같습니다. 네덜란드에 거주하고 있기에 실제 어느 서점에 어떻게 깔릴지 실제로 확인은 못하겠습니다. 아쉽게두요. 책에 대한 설명은 아래 링크에 있는 도서 상세 페이지에서 확인하시길 바랍니다. 읽어볼 가치가 있다고 생각하시면 구매해주시면 좋구요. 🤟🏻

다음 번에는 책을 쓰는 과정, 그리고 그 과정에서 깨닫고 느꼈던 것들에 대해 적어보겠습니다.

– 알라딘 https://www.aladin.co.kr/shop/wproduct.aspx?ItemId=253734493

– 예스24 http://www.yes24.com/Product/Goods/93788210

– 교보문고 http://www.kyobobook.co.kr/product/detailViewKor.laf?ejkGb=KOR&mallGb=KOR&barcode=9791158511920&orderClick=LAG&Kc=

‘골든 해빗’이라는 제목은 솔직히 제가 짓진 않았습니다. 마케팅 측면을 많이 고려한 제목임을 알아 주시길 바랍니다. 😂