프로덕트오너

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’에 대한 글을 찾아보고 독자분들과 공유하는 이유입니다.

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

Product manager와 Product owner (2편)

Inyong Suh5 Comments

내 블로그의 첫 글 <그래서 Product owner는 뭐하는 사람이에요?>이 브런치에서만 조회수가 6천이 넘었다. 그리고  <Product owner? Product manager?>라는 글도 꾸준히 읽히고 있다. 한국에서 Product owner에 대한 관심이 높아지고 있긴 한가보다.

<Product owner? Product manager?>의 주요 내용 중 하나는 Product manager(이하 PM)과 Product owner(이하 PO)는 하는 일이 기본적으로 같다는 것이다. 하지만 어느 날 독자 분이 브런치 댓글을 아래와 같이 남겨주었다. 엄밀히 말하면 완전히 같은 건 아니라고 한다. 이론적으로 말이다.

<내 글에 달린 댓글 중 발췌. 참고로 SAFe는 Scaled Agile Framework로 나도 자세한 내용은 모른다. 공식 웹사이트 검색해보시길>

다시 한 번 말하지만 실제 내가 다녔던 회사(쿠팡, Booking.com)나, 면접 봤던 회사들이나, 지인들이 일하는 회사 등에서 PM과 PO가 따로 구분되어 있는 경우는 본 적이 없었다. 대부분 PM or PO 였고 그 둘이 하는 일은비슷했다.

하지만 최근에 내 주위의 한 회사에서 PO와 PM이 함께 있는 사례를 발견했다. 바로 암스테르담에 본사를 두고 있는 Tomtom이라는 디지털 지도 관련 회사(tomtom.com)이다. 나름 유명한 네덜란드의 IT 회사로 이 분야에선 유명한 회사다. 위의 사실을 알게 된 계기는 아래와 같다.

이 회사의 Senior PO 직무가 Linkedin이 떴었고, 제품이 재밌어 보여서 내 주위의 Tomtom 출신 동료에게 회사는 어떤지, 그 팀은 어떤지 그리고 PO라는 직무가 어떤 권한을 갖고 있는지 물어볼 기회가 있었다. 그때 이 친구가 이렇게 얘기했다.

  • 동료 : “Tomtom은 PM과 PO가 나뉘어져 있어. 난 Tomtom 외엔 IT 회사 경험이 없어서 모든 회사가 그런 줄 알았어. 그래서 오히려 Booking.com에 처음 왔을 때 Product owner가 하는 일의 범위가 넓어서 놀랐어.(이 당시 우리 회사에서는 Product owner로 부르고 있었고, 2019년부터 Product manager라고 이름이 공식적으로 바뀌었다. 나는 당시 Product owner였고 지금은 Product manager가 공식 직무이다) Tomtom에서는 PM은 고객과 만나고 데이터 분석을 하고 장기 계획과 로드맵을 짜는 일을 주로 했고, PO는 개발팀(제품팀)이 효과적으로 일할 수 있도록 일의 우선순위를 결정하고 개발 요구사항을 명확히 하고 백로그를 관리하는 일을 주로 했었거든. Booking.com의 PO는 그 둘을 다 하고 있잖아.”
  • 나 : “어? 나는 모든 회사의 PO나 PM이 이름만 다르고 똑같은 일을 하는 줄 알았어. 내 경험상 그랬고 주위에서도 Tomtom과 같은 사례는 들어본 적이 없었으니까.”
  • 동료 : “어, 그래서, 내가 아는 너는 Tomtom 기준에서의 PM일은 즐겨할 것 같은데, PO일은 안 맞을 수도 있을 것 같아. 그래서 얘기해주는 거야. 한 번 그쪽과 확인해봐.”

위의 대화를 통해 얻은 인사이트를 확인하기 위해 온라인상으로만 알고 있던(LinkedIn connection) Tomtom의 PM에게 직접 물어봤다.

  • 나 : “I heard from ex-TomTom employee that there is also a Product Manager role in TomTom who’s mostly in change of the vision/roadmap/user research and so on, while POs are mostly in charge executing the roadmap in agile method. If so, I am not interested in PO role. I wanted to clarify this and I thought about you.”
  • 그녀의 대답은 ‘그렇다’ 였다.

그렇다. 내 글에 댓글 달아주신 분 덕분에 알게된 사실을 실제 내 주위에서 사례로 검증을 했다.

더 궁금해져서 이것 저것 자료를 찾아보다가 아래와 같은 Atlassian의 동영상을 찾게 되었다. 참고로 Atlassian은 개발 협업 툴 Jira와 Trello(인수함)로 유명한 호주의 소프트웨어 업체이다.

위 동영상의 2:40 정도를 보면 PM과 PO에 대해 설명하는 부분이 나온다. 요약하자면 아래와 같이 역할과 책임을 구분한다.  (위 동영상과 같은 내용으로 Atlassian blog 글도 있다)

  • Product manager : Mission, vision, high level problems, what success looks like
  • Product owner : break down and translate the vision to day-to-day activities

즉, PM은 장기적이고 큰 그림을 그리고 비즈니스 목표를 정의하는 직무이며, PO는 그 큰 그림을 실제 디자이너와 개발자들이 구현할 수 있도록 작은 태스크로 나누고, 요구사항을 명확히 정의하며, 태스크의 우선순위를 정하여 제품팀이 최대한 효과적이고 효율적으로 일할 수 있게 이끄는 직무이다.

이 글에선 위와 같이 PM과 PO를 구분하는 사례가 있다는 것을 보여주고 싶었다. 조금 부끄럽기도 하다. 몇 천명이 읽은 내 예전 글에서는 PM과 PO가 하는 일이 거의 동일하다고 했기 때문이다. 하지만 여전히 누군가 내게 PM과 PO가 뭐가 달라요? 라고 물어보면 ‘대부분의 회사에선 비슷하다. 그러나 회사마다 역할과 책임을 다르게 정의하기 때문에 정답은 없다‘ 라고 대답할 것이다. 물론 ‘일부 회사에선 그 둘을 나누기는 한다’라는 것을 덧붙이며 말이다.

이런 리서치와 검증 과정을 거치면서 내가 배운 점은 딱 하나다. 독자분들께도 이 한 마디 마지막으로 하고 싶다. 모든 회사마다 PM과 PO의 역할과 책임의 범위가 다 다르다. 그러니 이직할 때, 입사 지원할 때 그 자리가 어떤 자리인지, 회사에서(위에서)는 어떤 기대를 하는 자리인지, 개발팀과는 어떻게 일하는지, 의사결정의 권한은 얼마나 있는지 등을 꼼꼼히 확인하고 지원하라는 것이다. 인터넷 검색으로 잘 모르겠으면 면접 과정에서 리쿠트링 담당자나 면접관에서 물어보면 된다. 나도 면접할 때 면접관에게 늘 하는 질문이 “그 회사, 그 자리에서 내가 의사 결정할 수 있는 권한이 얼마나 있는가?”이다. 물론 어떤 조건이 좋을지는 사람마다 다르니 무엇이 좋다 나쁘다 라고 얘기할 순 없지만 말이다.