product manager

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의 역할과 책임의 범위가 다 다르다. 그러니 이직할 때, 입사 지원할 때 그 자리가 어떤 자리인지, 회사에서(위에서)는 어떤 기대를 하는 자리인지, 개발팀과는 어떻게 일하는지, 의사결정의 권한은 얼마나 있는지 등을 꼼꼼히 확인하고 지원하라는 것이다. 인터넷 검색으로 잘 모르겠으면 면접 과정에서 리쿠트링 담당자나 면접관에서 물어보면 된다. 나도 면접할 때 면접관에게 늘 하는 질문이 “그 회사, 그 자리에서 내가 의사 결정할 수 있는 권한이 얼마나 있는가?”이다. 물론 어떤 조건이 좋을지는 사람마다 다르니 무엇이 좋다 나쁘다 라고 얘기할 순 없지만 말이다. 

소프트 스킬, 커뮤니케이션을 여는 열쇠

Inyong SuhLeave a comment

2019년 4월에 ‘일하는 사람들의 컨텐츠 플랫폼’ Publy의 파이낸셜 타임스 큐레이션 글로 발행한 글입니다. Publy에서 파이낸셜 타임스 큐레이션 서비스를 중단했기에, 제가 작성했던 본문(‘큐레이터의 말’)을 Publy 동의 하에 아래와 같이 공유합니다. 

지난 12년의 경력 중 이직을 두 번 경험했다. 경력에 비해 많은 편은 아니지만, 두 번 모두 환경의 변화가 굉장히 컸다. 첫번째는 삼성전자에서 8년간 일하다 쿠팡으로 다른 직무로 이직한 경우였고, 두번째는 멀리 네덜란드에 있는 Booking.com 본사로의 이직이었다. 두 번 모두 초기에는 빠르게 적응하기 위해 업계와 제품에 대해 공부하고, 업무에 필요한 스킬을 익히기 위해 밤낮으로 노력했다. 

처음에는 해당 직무를 일단 ‘수행하기 위한’ 하드 스킬 위주로 업무를 익혔다. 그러나 어느 순간부터 ‘더 잘하기 위해서’는 소프트 스킬이 필수적이라고 느꼈다. 

삼성전자에서 스마트폰 상품기획과 해외영업 업무를 하다가 쿠팡으로 옮겨서는 ‘제품관리자(당시 쿠팡에선 Product owner라고 불렀다)’라는 타이틀로 첫 업무를 시작했다. 처음에는 당장 업무에 필요한 지식과 프로세스를 위주로 공부했다. 애자일 개발 방법론, 데이터 분석(SQL), 웹 서비스가 기술적으로 어떻게 작동하는지 등을 익혔다. 

무엇보다 당장 팀이 돌아가야 했다. 문제를 해결하기 위해 데이터를 분석하고, 개발팀과 함께 해결방안을 구상하고, 실행의 우선순위를 결정하고, 실행(신규 기능 런칭 혹은 제품 개선)한 후 다시 데이터를 확인하는 싸이클을 멈추지 않고 팀을 운영하기 위해서는 그런 하드 스킬이 필요했다.

그러나 업무가 어느 정도 궤도에 오르고 나자 더 효율적으로 일하고 더 큰 임팩트를 내기 위해서는 커뮤니케이션이 굉장히 중요하다는 것을 깨달았다. 

제품관리자의 주요 역할 중 하나는 바로 관련부서(stakeholder)와의 업무 조율이다. 새로운 결제 서비스를 런칭하는 과정에서 나는 주문 관련 개발팀, 고객서비스 담당부서, 회계 및 자금 부서, 대외정책팀, 법무팀, 그리고 금융사 및 결제 관련 협력업체 같은 외부업체들과 지속적으로 커뮤니케이션하면서 서비스를 기획하고 런칭 마케팅 계획을 세웠다. 

각자 바쁘게 돌아가는 부서에 새로운 요구사항을 전달하고, 계획한 일정 내에 작업을 모두 끝마치고 서비스를 런칭하는 건 쉬운 일이 아니다. 새로운 서비스가 왜 필요한지, 누가, 어떤 부분을, 언제까지 해야 하는지 등을 관련 부서가 모두 ‘이해’할 수 있도록 내용을 문서화해서 공유하고, 직접 만나서 설명하고 설득하는 과정을 반복했다. 

특히 결제 서비스 런칭에는 보다 세심한 준비와 조율이 필요했다. 새로운 결제 서비스를 고객이 어떻게 사용할 수 있는지, 취소 및 환불 정책은 어떻게 되는지, 결제 및 취소 관련 내용은 (고객 및 상담원 각각의 입장에서) 어디에서 어떻게 확인할 수 있는지 등의 내용을 고객 상담원이 숙지하고 있어야 하기 때문이다. 이를 위해 본사 사무실과는 멀리 떨어져 있는 고객서비스 부서에 방문해 상담원들을 직접 교육했고, 질문과 답변을 통해 상담원의 궁금증을 해소해주기도 했다. 그 때까지만 해도 제품팀에서 직접 상담원 교육을 하는 일은 없었던 터라 고객서비스 부서에서 좋은 피드백을 받았고, 일정 내에 서비스 런칭을 하는데도 도움이 됐다. 

한국에서 10년 간 일한 후 네덜란드에서 일하게 된 것도 큰 변화였다.

유럽에서 제품관리자로 일하면서 처음에는 우리가 이걸 왜 하는지, 왜 이것부터 해야 하는지, 이걸 하면 뭐가 좋아질지 같은 질문에 계속 답하는 게 가장 힘들었다. 업무 속도는 한국이 훨씬 빠르지만, 이곳은 한국보다 ‘왜’에 더 집중한다. 데이터를 기반으로 명확한 가설을 내세우지 않으면 팀원들을 움직이게 하기 힘들다. 

사용성을 개선하는 경우처럼 통계 데이터로 증명하기 어려울 때도 종종 있는데 그럴 때는 조직 및 제품의 비전을 기반으로 그 당위성을 ‘스토리’로 풀어낼 필요도 있다. 동료들에게 우리가 가는 길과 하는 일에 대한 확신을 심어주기 위해서다. 

이런 커뮤니케이션을 더 잘 하기 위해 ‘내가 어떤 식으로 대화를 이끄는지’에 대해 동료들로부터 피드백을 받았고, 어떻게 하면 더 큰 임팩트를 낼 수 있을지 친한 동료들 및 매니저와 상의해보기도 했다. 그 덕분에 나름의 전략을 짜고 실행에 옮길 수 있었다.

예를 들어 잘 짜여진 스토리텔링이 필요한 미팅을 앞둔 경우, 에버노트 등에 내가 할 이야기를 미리 적어 논리의 타당성을 검토했다. 그런 다음 믿을만한 동료에게 피드백을 받아 메시지를 다듬고, 미팅에서 목소리가 큰 사람들과 사전 1:1 대화를 통해 핵심 메시지에 대한 피드백을 받았다. 

회사에서 제공한 ‘Art of Influence’라는 4일짜리 트레이닝도 어느 정도 도움이 됐다. 트레이닝을 통해 내 커뮤니케이션 타입을 파악했고, 상대방의 타입을 파악하는 방법을 배웠으며, 서로 다른 타입에 어떻게 대응해야 하는지를 익혔다. 이후 지금까지 실습을 계속하면서 성공과 실패를 경험했고, 나만의 방식을 찾아가고 있다.

글로벌 기업에서 일하면서 또 하나 느낀 점은 함께 일하는 동료들의 문화적 스펙트럼이 굉장히 넓다는 것이다. 

서로의 ‘다름’으로 인해 문제가 생길 때도 있다. 특히 네덜란드와 한국은 여러 면에서 반대편에 있다. 예를 들어 부정적인 피드백을 주는 경우 네덜란드인들은 직접적(direct)으로 얘기하는 반면, 한국인들은 돌려 말하는(indirect) 편이다. 또 한국에서는 상대방의 의견에 동의하지 않더라도 돌려서 말하거나 여러 사람 앞에서 강하게 부정하는 일은 피하는 편이지만(avoid confrontation), 네덜란드인들은 상대방이 나보다 몇 직급 높은 상사더라도 ‘동의하지 못하겠다’고 당당히 말하는(confrontational) 문화다. 

애초에 이런 부분을 미리 염두에 두고 커뮤니케이션을 했다면 서로에게 잘 맞춰갈 수 있었을 테고, 불필요한 오해도 피할 수 있을 것이다. 하지만 나는 이런 내용을 배운 적이 없었다. 동료들도 이런 부분은 잘 몰랐고, 생각해 본 적도 없는 경우가 많았다. 

나는 네덜란드인 동료의 직설적인 피드백을 감정적으로 받아들였고, 한 동안 스트레스를 많이 받았다. 그 때 한 동료가 추천해 준 The culture map이란 책을 읽고서야 상황을 바로 볼 수 있게 되었다. 일례로 미팅 도중 러시아인 동료가 무안할 만큼 나에게 강하게 반론을 제기하거나, 네덜란드인 동료가 1:1 대화 중 “인용, 너에게 실망했어”라고 대화를 시작했을 때 기분이 나빴던 일들이 떠올랐다. 그들이 나에게 나쁜 감정이 있는 게 아니라, 서로 커뮤니케이션 하는 방식이 ‘다른 것’ 이라는 걸 알게 됐다. 내가 ‘틀린 게 아니라는 것’을 깨닫고 나서, 스트레스가 많이 완화됐다. 

이런 일들을 겪으며 ‘누가 이런 것 좀 가르쳐 줬으면 좋았을텐데’ 하는 생각을 자연스레 하게 됐다. 

펜실베이니아 대학교(University of Pennsylvania) 와튼 스쿨(Wharton School)의 사울 P 스타인버그 경영학 교수(Saul P Steinberg Professor of Management)인 애덤 그랜트(Adam Grant)는 MBA 과정에서 소프트 스킬을 가르쳐야 한다고 주장한다. 그렇게 하지 않는 것은 “잘못된 생각이며 어쩌면 위험한 생각일 수도 있다”는 것이다. 그랜트 교수에 따르면 소프트 스킬이 “가치 있을 뿐 아니라 가르칠 수 있다”는 명백한 증거가 많이 있다. “우리는 가장 중요한 스킬을 가르칠 책임이 있습니다.” (파이낸셜 타임스 기사 중)

여러 경로를 통해 배운 커뮤니케이션의 핵심 중 하나는, 우선 내가 어떻게 커뮤니케이션을 하는지 아는 게 중요하다는 것이다. 우리는 스스로를 잘 알고 있다고 생각하지만, 커뮤니케이션은 나 혼자 하는 게 아니다. 상대방과 하는 것이다. 

동료들의 피드백을 통해 나를 알아보는 것도 좋다. 솔직하고 건설적인 피드백을 잘 주고 받는 것도 스킬이며, 이런 스킬들은 모두 ‘배울 수 있다’. 관심을 갖고 나를 지켜본다면 내가 무엇을 잘 하고, 무엇이 필요한 지 파악할 수 있다. 그런 다음 책에서 길을 찾을 수도 있고, 온/오프라인 트레이닝 등을 통해 이런 소프트 스킬들을 배울 수도 있다.

경험을 통해 성장하는 방법도 있지만 필요할 때 적절한 트레이닝을 받는 것도 성장을 위한 좋은 방법이다. 세계 유수의 경영대학원들도 현장에서 피드백을 받아 꾸준히 교과과정을 개선해 나간다. 그래야 ‘경쟁력 있는 졸업생’이라는 좋은 산출물을 낼 수 있기 때문이다. 우리 자신도 마찬가지다. 

이 수업은 LBS 경력개발센터의 피드백을 반영한 것이다. “채용 담당자들은 학생들이 자신을 너무 모른다고 이야기합니다.” 졸리 교수의 설명이다. “학생들이 거만하기만 하고 타인의 이야기를 경청하지 않는다는 것이죠.” 그는 학생들이 새로운 일자리를 찾는 것 그 이상을 이 수업이 도울 수 있기를 바란다. “높은 자리에 오를수록 관계의 중요성이 커집니다. 예를 들어 이사회에 들어가면 엑셀 작업을 하는 것이 아니라 관계를 쌓아 나가게 되죠.”

PO는 꼭 데이터 분석을 잘 해야 할까

Inyong SuhLeave a comment

 

3년 전 국내 모 대기업을 그만두고 한창 떠오르던 이커머스 업체 C사에 Product owner라는 직무로 일을 시작했을 때, 그 방대한 고객(user)/상품(C사가 판매하는 상품)/제품(우리가 개발/서비스하는 제품) 관련 데이터은 나에게 신세계였다. 비록 그 전 회사가 글로벌 스마트폰 제조사였지만 직원들이 접근할 수 있는 데이터는 굉장히 제한적이었다. 시스템적으로 다른 부서(개발팀)의 데이터에 접근을 해서 분석을 한다는 건 상상도 해본 적 없고, 아마 인프라적으로도 불가능했을 것이다.

 

하지만 시스템적인 이유보다는 1) Android라는 타사 OS를 기반으로 스마트폰을 제조/판매하는 한계, 2) 판매 물량 대부분 B2B(통신사나 도매/소매 업체)로 제품을 판매하다보니 시장분석 및 이를 base로 한 제품 기획에 필요한 ‘고객’ 데이터가 없었다는 게 더 큰 이유일 것 같다. 당시 주로 하던 데이터 분석은 모 시장조사 업체에서 주기적으로 받은 글로벌 휴대폰 판매 raw 데이터를 기반으로 지역/국가별로 가격대별 제조사별 Market share를 확인하거나, 모델별 판매량을 기반으로 자사 모델의 경쟁력을 평가하고 타사 주력모델을 대비하기 위한 분석들이었다. 분석을 위한 도구는 거의 Microsoft Excel 이었다. 이미 3~6년 전 일이지만, 워낙 다양한 신제품이 출시되고 환경이 빨리 바뀌는 산업이기에 당시 ‘제품 경쟁력’을 고민하면서 실시간 데이터에 대해 목 말라했던 기억이 있다. (대부분 시장조사 데이터나 리서치들은 몇 달 지난 데이터들이었다)

 

이직 후 C사에서의 환경은 전혀 달랐다. 직접 회사 데이터베이스에 접근해 SQL query로 데이터를 추출/가공/분석하거나, 고객 이슈를 실시간으로 데이터를 확인해서 대응하던 모습은 완전히 새로운 환경이었다. Web base로 사업을 하는 회사라면 당연할 수 있겠지만, 8년 동안 제조사에서만 일하다 온 나에게는 신세계였다. 그렇지만 항상 좋을 순 없는 법. 향상된 데이터에 대한 접근성이 또 다른 고민을 가져오기도 했다. 오늘은 이 글을 통해 아래 몇 가지 주제에 대한 내 생각을 적어보자 한다.

 

  1. 업무 환경에서 향상된 데이터의 접근성이 가져오는 긍정적인 / 부정적인 부분
  2. Product owner가 데이터 분석을 어느 정도까지 해야 할까?
  3. 데이터 과학이란 또 다른 세계에 대해

 

무한한 데이터. 어떤 가치를 찾을 수 있을까? 무작정 좋을 뿐인가?

 

더 많은 고객 프로필/행동 데이터를 접할 수 있고, 이에 따라 내가 모르던 세계가 펼쳐진 것은 분명했다. 무한한 가능성인 것 같았다. 하지만 데이터베이스 여기저기 돌아다니며 데이터 까보는 것도 잠깐일 뿐, 너무 많은 데이터에 실시간으로 접근할 수 있다보니, 이에 따라 부작용이 생기기도 했다. 향상된 데이터 접근성이 가져온 긍정적인 부분과 부정적인 부분을 개인적인 경험을 토대로 적어보겠다. 기술적/사업적인 기준보다는 Product owner인 내 개인적인 기준이다.

 

긍정적인 결과
  1. 고객의 데이터(개인정보 말고 행동 패턴)를 실시간으로 확인할 수 있기에 사용자들이 내가 기획/개발한 제품을 내가 의도한 대로 사용하고 있는지 바로 확인할 수 있다. 그리고 여기서 배운 것을 통해 제품을 지속 개선할 수 있다. 이직 후 내가 가장 만족해했던 부분이다.
  2. 뻔한 얘기지만, 이 방대한 데이터 속에서 Insight를 찾거나 미래 트렌드를 prediction 할 수 있다(고 믿는다)
  3. 위 1번의 연장선일 수 있지만, 내가 기여한 제품의 performance를 쉽게 확인할 수 있다는 부분은 나중에 인사 ‘평가’ 프로세스를 조금은 더 수월하게 할 수 있지 않을까 한다. 적어도 ‘우리 부장님 잘 모셔서’ 고과 잘 받는 모습은 피할 수 있고, (다른 팀/팀원들도 데이터를 확인 할 수 있기 때문에) 성과에 대해 조금은 더 투명해질 수 있다고 생각한다.

 

부정적인 영향
  1. 데이터가 의사결정의 기반이 되는 것은 좋으나, 간혹가다 데이터를 핑계로 의사결정을 미루는 경우가 생긴다. 의사결정을 해야 하는데, 어느 쪽도 뚜렷하지 않은 경우 ‘이 부분 더 데이터를 파보자’라고 하는 경우가 간혹 있다. 나도 안 해본 것 아니다. 하지만 impact가 클 데이터 분석이 아닐 경우, 일단 결정을 하고 테스트를 빨리 해서 결과를 빨리 확인해보는 게 나을 수 있다.
  2. 데이터 분석을 하다보면 궁금증에 궁금증이 꼬리를 물어 너무 디테일한 부분까지 내려가는 경우도 있다. 위 1번과 비슷한 얘기일수도 있으나, 만약 제품이나 팀의 direction을 결정하기 위한 데이터 분석이 너무 디테일한 부분까지 touch하려다 보면 ‘디테일에서 길을 잃는 경우’를 만날 수 있다. 큰 트렌드를 통해 방향을 잡고, 세부적인 내용은 개발팀과 함께 하나하나 파악해 나가면 되는데, ‘데이터 분석을 위한 분석’이 되어 버리게 되면 본래의 의도(전략 방향 설정을 위한 트렌드 분석)가 distort된다. 이 역시 내 경험에서 나온 의견이다. (쓰다보니 자괴감이….)
  3. 고객님들이 사용하는 제품/서비스의 경우 ‘실시간 대응’이 가능하다는 장점이 있지만, ‘내 일이 5시에 안 끝날 수 있다’는 부정적인 부분도 있다. 이것은 회사 업무문화와도 밀접한 관계가 있겠지만, 고객 이슈가 급히 생길 경우 밤에 노트북 열어서 데이터 확인해보게 되는 경우도 종종 생긴다. 이것은 사실 부정적인 부분이라기 보단 비즈니스 성격과 팀/Role에 따라 다를 수 있는 부분이지만 한 가지 확실한 건 집에까지 와서 일하던 내 모습을 내 아내는 싫어했다.
다른 글에서 다뤘다시피 PO(Product Owner)는 Web 기반 서비스를 직접 개발하여 운영하는 IT 업체에 있는 Role이다. 이에 PO와 데이터는 뗄레야 뗄 수 없는 관계이다. 이에 PO가 데이터를 파보는 것은 어찌보면 문제점 파악 및 의사결정을 위해 당연히 해야 할 일이나, 너무 데이터에 몰입하다보면 정작 PO가 해야 할 중요한 일을 간과하거나 더 나아가 나무에 빠져 숲을 못보는 경우가 생길 수도 있다.

 

Product owner(혹은 Product manager)는 어느 정도까지 데이터 분석을 해야 할까?

 

당연하겠지만 “잘 하면 잘 할수록 좋다”. 본인의 Product을 전담할 데이터 분석 담당자가 없는 경우(대부분이 그럴 것 같다), 외부 분석 담당팀이나 개발팀 내 Back-end 개발자(서버 개발자)에게 데이터 분석 요청을 해야 하는데, 상대방 업무의 우선순위에 따라 분석에 걸리는 시간이 오래 걸릴 수도 있고, 정확히 내 입맛에 원하는 결과를 얻기 쉽지 않을 수도 있다. 이럴 경우 PO가 직접 DB에 접근하여 데이터를 추출/분석/시각화 할 수 있다면 상당히 생산적일 것이고, 덤으로 본인이 담당하는 제품(Product)의 내부 데이터 구조도 파악할 수 있다. (생각보다 중요하다)

 

하지만 이 데이터를 다루는데 쓰는 시간은 잘 관리해야 한다. 위에서 얘기한 대로 PO로서의 업무 우선순위를 잊지 말아야 한다. PO는 사용자의 요구사항/문제점을 파악하여, 제품/팀의 방향을 정하고, 개발할 업무의 우선순위를 정하는 것이 Main role이다. 데이터 분석은 이 과정에서 고객의 행동 패턴을 파악하거나, 문제점을 파악하거나, 개발팀이 개발한 제품/기능이 제 역할을 하고 있는지 등을 파악하여 PO가 의사결정을 할 때 참고하려고 하는 것이 주요 목적이다. 절대 ‘데이터’가 가장 우선이 되어야 하는 경우는 없어야 한다. “데이터 분석을 위한 데이터 분석”은 지양해야 하겠다는 얘기다.

 

개인적으로는 기술적인 부분에도 관심이 많아 C사 입사 후 SQL query를 배워 상용 데이터에 종종 접근하여 필요한 데이터를 확인하곤 했다. (실제 Raw data는 아니었고, 분석을 위해 Raw data를 복사해놓은 분석용 DB 데이터였다.) DB에서 ‘데이터를 추출’한 후 필요한 경우 Microsoft Excel의 일부 유용한 함수(vlookup, countif  등)/피벗 테이블을 사용해서 ‘데이터를 가공’하여 분석에 활용하곤 했다. 개인용으로 사용할 경우 ‘데이터 가공’에서 끝내기도 했지만, 공유나 보고용으로 데이터를 가공한 경우에는 Excel 내장 그래프/차트 기능으로 ‘시각화’까지 신경써서 했다.
참고로, 아래 정도가 내가 데이터를 직접 추출/분석한 케이스(목적)였다. 솔직히 좀 더 복잡한 지표를 분석(장문의 query를 작성)하거나, Tableau 등의 전문화된 시각화툴을 사용하여 Dashboard를 만드는 케이스 등은 직접 하지 못하고 데이터 분석 담당자(C사에서는 Business Analyst라 불렀다)께 요청을 하여 처리하곤 했다.

 

  1. 주요 비즈니스 지표 분석 (예, 매출 성장 추이, 결제 성공율, 고객 재방문율 등)
  2. 고객 이슈(CS) 직접 대응 (예, 고객센터 매니저가 급히 ‘고객 A가 할인쿠폰을 사용해서 결제했다고 하는데, 할인 적용이 안되었다고 한다. 실제 쿠폰이 적용 된 건지, 언제 된 건지, 얼마 결제가 된건지 확인을 해달라’라고 전화해서 부탁하는 경우)
  3. 주요 지표는 아니지만 내 제품을 고객이 어떻게 사용하고 있는지 확인할 때 (예, ‘새로운 프로모션 페이지에서 실제 쿠폰을 다운받은 고객은 몇 명이고, 아무것도 안하고 바로 나가버린 고객은 몇 명인지 등을 확인하고 싶을 때’ 등)

 

그러나 여기서 끝이 아니었다. 얼마 전 호텔 관련 온라인 비즈니스를 하는 B사로 이직 후에는 데이터 과학자(Data scientist)과 협업을 할 일이 많아졌다. 당연히 C사에도  있는 Role이나, 나는 직접적으로 같이 일하는 경험은 거의 하지 못했었다. 이에 그들이 정확히 무엇을 하는지, 그리고 나는 그들과 어떻게 일해야 하는지, 그들을 통해 무엇을 얻어낼 수 있는지 잘 알지 못했었다. 이에 이 글 마지막에서는 ‘PO와 데이터 과학’에 대해 잠시 얘기해보고자 한다.

 

그럼 PO/PM은 데이터 과학을 공부해야 하는가?

데이터 분석의 경우와 같은 의견이다. 당연히 알면 좋고, 많이 알면 더 좋다. 하지만 이 역시 필수는 아니다.

 

모든 웹 기반 서비스들은 결국 데이터 기반이고, 이 안에서 가설을 세워 ‘가치’를 찾고 ‘검증’해 낼 수 있는 능력이 중요하다. 문제 해결을 위한 가설이든, 새로운 기회를 찾기 위한 가설이든, 이 ‘가설’을 기반으로 실험(experiment)를 하고 이의 결과를 데이터로 검증해야 한다. 이때 A/B 테스트와 같이 일부 트래픽만 실험에 참여한 경우, 이 실험 결과가 통계적으로 유의미한 결과인지도 확인해야 한다. (예, 전체의 10%만 신규 기능을 사용했는데 결과가 좋았다고 100%가 사용했을 때도 똑같이 결과가 좋으란 법은 없다)

 

이렇게 대규모 데이터로 ‘실험’을 하거나, 실험의 기반이 되는 Insight를 찾기 위해 데이터를 뒤지는 경우 데이터 과학자와 일하게 될 경우가 많다. 데이터 과학자의 정확한 Role은 이 채용 공고를 통해 확인해 볼 수 있겠지만, 짧게 얘기하자면 기존 데이터 속에서 Insight를 찾거나, 기존 데이터를 활용해서 미래를 예측(prediction)하거나, 고객에게 더 나은 검색결과를 보여주거나, 상품을 추천해주기 위한 데이터 모델링을 하는 사람들이다.

 

솔직히 나도 아직 이 데이터 과학자들이 어떤 방식으로 데이터를 분석하고 결과를 만들어내는지 모른다. 그러나 내가 잘 모른다고 해서 데이터 과학을 ‘활용’하지 못하는 건 아니다. 어떤 방식으로 분석할 지에 대해 고민하는 것은 데이터 과학자의 역할이다. 대신 PO는 좋은 질문을 던져야 한다고 생각한다. 좋은 질문을 던지기 위해서는 흔히 ‘도메인 지식’이라 얘기하는 인더스트리에 대한 이해가 토대가 되어야 하고 이를 기반으로 여러 각도에서 계속 질문해야 한다. 예를 들자면, “여름 휴가시즌에 호텔들은 방 가격(A)을 매일 어떻게 결정할까”와 같은 질문이 있다면, 단순히 ‘휴양객이 많은 8월 초(B : 수요)에 가격이 가장 높을 것이다’를 넘어서 당시 호텔들의 객실이 얼마나 차 있는지(C : 객실 예약율), 그 호텔들의 작년 휴가시즌 가격은 어땠는지(D : 작년가격) 등 여러가지 영향을 줄 수 있는 요소들을 미리 생각해놓고, 이 값(B, C, D)들의 변화에 따라 A(가격)이 어떻게 움직이는 지를 확인해 볼 수 있다. 이때 이 B, C, D를 뽑아낼 수 있는 게 결국 도메인 지식이라고 생각한다. 또한, 분석의 목적에 따라 ‘여름 휴가’를 8월로만 한정할 것인지, 7-8월 2달간 데이터를 볼 것인지, 유럽만 볼 것인지, 4성급 이상 호텔만 확인할 것인지 등 여러가지 상세한 조건들을 결정하여 분석에 적용을 해야 한다. 이를 결정하기 위한 기반도 결국 도메인 지식이라고 생각한다.

 

다시 한 번 정리하자면, PO는 본연의 Role을 잊지 말고 데이터 분석/예측도 결국 문제 분석과 의사 결정을 돕기 위한 과정 혹은 Tool로 생각해야 한다. PO가 슈퍼맨이 될 수는 있지만 될 필요는 없다. 오히려 본인의 제품과, 이 제품의 시장/산업에 대한 이해를 토대로 좋은 질문을 던질 수 있어야 한다. 이 좋은 질문에 좋은 답변을 해줄 수 있는 데이터 분석가/과학자가 옆에 있다면 그 PO의 제품과 팀은 좀 더 밝고 깨끗한 안경을 끼고 고객과 시장을 바라볼 수 있을 것이다.

 

* 참고로, ‘머신러닝’이나 ‘딥러닝’이란 얘기는 이제 많이 들어봤을텐데, 데이터 과학은 이들을 아우르는 범주이다. 실무에서는 일부 product을 제외하고 머신러닝을 사용하는 경우는 거의 보지 못했다. (내가 추천, 검색, 랭킹 등 product을 담당하지 않아봐서 그럴지도 모른다)

Product owner? Product manager?

Inyong Suh3 Comments

3년 전 대기업에서 (상대적으로 훨씬 작은) e-commerce 업체에 Product owner라는 직무로 이직을 했을 때 가장 많이 들었던 질문이 ‘Product owner가 뭐하는 거야?’ 라는 질문이었고(이에 대한 내 의견은 이 글에서 확인할 수 있다), 이직 후에 Product owner의 역할/정체성에 대해 고민하던 시절 내가 궁금해했던 다른 하나가 Product manager랑 Product owner랑 무슨 차이가 있는 건가? 였다. 왜냐하면 실리콘밸리에 있는 많은 회사 얘기에서 빠지지 않는 게 PM(Product manager) 이기 때문이었다.

Product manager와 Product owner는 다른 직무인가?

위 질문에 대해 나는 ‘아니다. 같다고 보면 된다’ 라고 대답한다. 내 생각에 Product owner(이하 PO)는 agile 개발 방법론을 따르는 일부 software 회사에서 (개발조직 내) 비즈니스 담당을 하는 role로 부르는 이름이고, Product manager(이하 PM)는 IT(software based) 업계에서 일반적으로 쓰는 용어인 것 같다. PO나 PM이나 모두 고객의 니즈를 파악하여 제품(product)의 가야 할 방향을 설정하고, 목표를 달성하기 위해 가장 중요한 일이 무엇인지/먼저 해야 할 일이 무엇인지(우선순위) 결정하여 개발팀과 함께 고객이 만족할 만한 제품을 만들어가는 게 Main role이다. 일례로, 아래는 글로벌 검색업체 G사(^^)의 Product manager 직무의 responsibility 조건이다.

  • Launch products.
  • Identify market opportunities and define product vision and strategy
  • Understand customer needs and gather product requirements.
  • Develop new products and enhance existing products.
  • Engage closely with the engineering team to help determine the best technical implementation methods as well as a reasonable execution schedule.

이전 글에서 쿠팡 & Booking.com의 PO 직무 내용과 비슷한 것을 볼 수 있다. 거의 같은 일을 하지만 회사에 따라 PM으로 불리기도 하고, PO라고 불리기도 한다고 본다. 참고로, PM이나 PO들이 하는 업무를 IT 업계에서는 Product management 업무라고 한다. 이 Product management 업무에 대해 좀 더 자세히 알고 싶으면 구글 검색을 해도 좋고, 아래 몇 가지 도서/사이트를 참고해보면 될 것 같다.

  • 도서 Inspired(링크) : PM이 무엇인지, 어떤 게 좋은 PM인지에 대해 기본적으로 설정이 가장 잘 되어 있는 책으로 생각한다. 번역본 ‘인스파이어드’도 있다.
  • Silicon Valley Product Group(링크) : 웹사이트로, 좋은 PM, 나쁜 PM 등 Product management 관련하여 괜찮은 문서들이 다수 있다. 위 도서 Inspired의 저자가 만든 그룹.
  • Ken Norton 블로그(링크) : 유명 Product manager Ken Norton의 블로그로 PM 관련한 유용한 조언/팁들이 많다.
  • 그 외에도 많지만, 도서/웹사이트 소개가 이 글의 목적이 아니기에 여기서 그만. 더 궁금한 내용이 있다면 댓글이나 이메일로 연락해주세요.

 

Software 업계 외 Product manager

위에서 얘기한 PO와 PM의 역할은 모두 IT 업계, 특히 software 기반의 서비스를 직접 개발하여 운영하는 업체에 한한 내용이다. ‘Product’를 어떻게 정의하냐에 따라 전혀 다른 제품, 전혀 다른 업무를 managing 할 수도 있을 것이다. 물론 보험회사에서 보험을 ‘상품화’하여 판매한다고 해서 보험 상품을 관리하는 사람을 Product manager라고 하진 않는 것 같지만(그렇다고 해도 틀렸다고 할 수도 없다), Software package를 개발/판매하는 회사나, 제조업체에서는 판매하는 상품의 기획부터 판매/마케팅 까지 총괄하는 담당자를 Product manager라 할 수 있다.

스마트폰을 제조/판매하는 첫 직장에서도 ‘Product manager’라는 직무가 있었다. 한국의 본사에는 Global Product Management 팀이 있었고, 이 팀의 주요 역할은 사양(H/W, S/W specification)이 확정된 제품의 개발, 생산, 마케팅 일정을 관리하고, 해당 제품의 Global distribution/pricing(손익)을 결정하고, 영업을 지원하고, 수익성 및 회사 전략을 기반으로 제품의 단종(생산/판매 중단)까지 책임지는 업무(product life cycle management)를 했던 걸로 기억한다. (* 워낙 큰 회사기 때문에, 고객 리서치 및 시장상황을 토대로 신제품의 사양을 기획/결정하는 업무는 다른 부서가 맡았다)

또한 해외 판매 법인/지사에도 Product manager라는 직무가 있었는데, 이 담당자들은 해당 지역/국가 내에서 판매중인 제품의 도입(소개)부터 마케팅 전략 및 런칭을 기획하고, 판매를 지원하는 업무를 했다. 해당 지역/국가에서 판매할 신제품의 도입 및 마케팅 계획을 담당하고, 전체 제품의 포트폴리오를 관리하고, 시장 상황(경쟁사 제품, 판매량)과 본사 제품 전략을 토대로 제품의 가격 및 단종을 결정하는 업무가 주요 업무였던 걸로 기억한다.

정말 쉽게 얘기하면 사무실에서 ‘우리 회사가 판매하는 제품에 대해 가장 잘 아는 사람’이다. (그래야 한다) 시장에 제품을 내놓고 팔 때 전시만 해놓고(디자인) 가격표만 붙여놓는다고(가격) 다 팔리는 게 아니잖은가? 이 제품이 고객에게 왜 좋고, 경쟁 제품보다 뭐가 좋고, 이 가격 붙일만한 가치가 어디 있는지 등의 내용/정보를 마케팅/홍보/영업팀에 전달하여 최적의 마케팅/광고 전략을 짤 수 있도록 지원하는 제품 전도사가 되어야 한다. (이 판매 법인의 Product manager 직무 관련해서 가장 참고할 만한 도서로는 이걸 꼽고 싶다. 마케팅 천재가 된 홍대리. 애플 한국법인의 Product manager가 된 홍대리가 성장해나가는 과정을 그린 책이다)

개인적으로 위에서 얘기한 두 Product manager(본사 & 해외 지사)들과 업무를 많이 했었다. 쉽지 않은 업무로 본인이 맡은 제품에 대한 애정과 책임감이 넘쳐야 제대로 해낼 수 있는 업무라고 생각한다. 괜히 ‘전도사’라는 표현을 쓴 것이 아니다.

제품을 런칭하기까지의 길이 얼마나 고된 지…

Program manager, Technical program manager

지금까지도 헷갈린데 또 비슷하게 생긴 애들이다. Program manager. 정말 쉽게 말하면 기존 한국 소프트웨어 업체에서 Project manager라고 불렀던 직무랑 비슷하다고 생각한다. 한국에서는 쿠팡에 Technical Program manager라는 직무가 있고, 미국의 아마존, 마이크로소프트에도 Technical Program manager라는 직무가 있다.

이 분들이 무엇을 하는지 설명하려면 우선 다시 처음으로 돌아가서 Product manager, Product owner가 담당하는 product에 대해 생각해 봐야 한다. 이 PO/PM들이 담당하는 Product의 예를 들자면, 결제/주문/물류/상품평 등 소프트웨어 기반 서비스의 일부분이다. 각 PO/PM들은 본인들이 담당하는 Product들의 성공을 위해 열심히 일하지만, 다른 Product와 연관되지 않고 일할 수는 없다. 고객 입장에서는 결국 하나의 경험이고, 고객 경험의 흐름에 따라 Product들이 자연스럽게 연관이 된다.

예를 들자면, 고객이 쿠팡 웹사이트에 들어가서(Home), 상품을 검색(Search)하고, 상품리스트(Product list)에서 상품을 골라 장바구니에 넣고(Cart), 주문서(Checkout)를 통해 결제(Payment)한 후, 로켓배송을 통해 배송을 받는(물류) 과정에서 고객은 각각의 Product들(위에서 괄호에 있는 내용)을 거쳐가게 된다. 그렇기 때문에 각각의 Product들은 직간접적으로 서로 Data를 주고받으며 고객이 주문을 마치고 무사히 제품을 배송받을 수 있도록 지원을 한다.

Program manager들은 특정 프로젝트의 개발 과정에서 (연관되는) 여러 Product들의 상황을 파악하여 문제가 되는 장애물을 제거하고 프로젝트가 성공적으로 마무리 될 수 있도록 지원해주고/이끌어주는 역할을 한다. Technical Program manager는 말 그대로, 깊은 지식/경험을 기반으로 기술적인 부분의 문제까지도 파악하여 해결책을 찾아 프로젝트를 이끌 수 있는 사람이다. (본인이 해결한다기 보단, 여러 개발팀을 이끌고 해결책을 찾는 것이다.)

사실 Technical Program manager(이하 TPM)들과 같이 일해 본 적은 있으나, 당시는 해당 직무가 소개된 지 얼마되지 않아 과도기적인 상황이었다. 이에 위에 설명한 TPM에 대한 소개가 좀 틀렸을 수도 있으나, 1년여의 간접 경험을 통한 내용이기에 완전히 다른 방향은 아닐 것 같다. TPM이 좀 더 궁금한 사람은 구글에서 Amazon Technical program manager와 같은 키워드로 검색해보면 다양한 글을 확인할 수 있을 것이다.

참고로 Amazon TPM의 responsibility 검색해 본 내용 중 가장 중요하다고 생각한 몇 가지를 아래에 붙여넣어 본다. 문제점 해결 그리고 커뮤니케이션이 주 내용이다.

  • Working closely with service owners(다른 Product owner) and partner teams(다른 개발조직) to understand roadmaps and drive overall new feature introductions.
  • Anticipating bottlenecks, managing risk and escalations, and balancing the business needs versus technical constraints.
  • Communicating with influence with technology owners, customers, and upper management.

Product owner는 뭐하는 사람이니?

Inyong Suh7 Comments

3년 전 모 e-commerce 업체에 Product owner라는 직무로 이직을 했을 때, 주위의 많은 사람들이 이 Product owner(이하 PO)라는 직무를 이렇게 생각했다.

웹사이트에서 판매하는 제품(product)들 중 특정 제품군을 담당하는 관리자.

아마  e-commerce 사업을 하는 회사라서 위와 같이 유추했을 가능성이 높지만, 대부분의 사람들은 PO의 Product을 ‘판매하는 제품(군)’으로 생각을 했다. 솔직히 나도 회사 인사팀에서 연락이 오기 전까진 Product owner가 뭔지도 몰랐고, 입사 후에도 한동안은 헤맸던 기억이 난다. (참고로 e-commerce 회사에서 판매 제품군을 관리하고 판매업체(seller)와 커뮤니케이션을 주로 하는 직군을 MD라고 주로 한다. 아마 Merchandiser의 약자 일 것이다)

 

그래서 Product owner는 뭐하는 사람이에요?

Product owner은 보통 자체 개발한 software를 기반으로 사업을 하는 IT 업체 특히 애자일 개발 방식을 따르는 회사에 있는 직무로, PO의 Product은 보통 software 중 일부 기능/모듈/서비스를 뜻한다. 예를 들어, 주문(order), 결제(payment), 검색(search), 판매자 사이트(seller office) 등은 각기 다른 product이라고 얘기할 수 있고, 이 product들을 담당하는 product owner들이 있는 것이다.

그럼 product owner가 하는 일은 무엇일까? 특정 product을 개발하여 서비스하기 위해선 개발자, 디자이너 외에 product owner와 같은 비즈니스 담당자가 필요하다. 뛰어난 기술과 화려한 디자인으로 제품을 만들어도 고객이 이를 사용하지 않으면 말짱 꽝이지 않는가. Product owner는 고객 입장에서 제품을 볼 수 있게 해주는, 그래서 결국 비즈니스로 연결되는, 방향타 같은 role이라 보면 된다. (물론 PO의 능력과 관심사에 따라 시선은 달라진다)

우선 일부 회사 채용 공고의 Product owner의 역할/책임을 보자. 아래는 쿠팡 e-commerce 조직의 PO 채용 공고이다.

Responsibilities: 

  • Design and launch innovative products and services
  • Own the product roadmap to improve KPIs related with your domain
  • Define and drive key initiatives in areas
  • Build a best-in-class customer shopping experience for mobile app and website
  • Analyze customer feedback and data, perform usability tests, and run A/B tests
  • Improve productivity and quality of our major operational processes
  • Find and remove bottlenecks that create pain points for customers

그리고 Booking.com 의 Product owner 채용 공고도 함께 살펴보자.

Responsibility :

  • Help identifying customers’ behaviors and needs through research and analysis.
  • Take full ownership of the product, the prioritization of new features and enhancements to existing features in line with the strategy set by Booking.com B.V.
  • Empower and collaborate with your team to unlock their full potential.
  • Analyze, understand and share learnings from experimentation to build a strong knowledge base of the product.
  • Thrive to achieve optimal implementation of changes made to the product.

PO는 회사의 조직, 상황 그리고 제품의 특성에 따라 다양한 일들을 하지만, 가장 중요한 몇 가지만 꼽아 보자면 아래와 같다. (내 의견이다)

  1. 고객이 원하는 바를 파악하여 이를 제품에 반영한다.(identify customer behaviors/needs)
  2. 제품이 가야 할 방향을 설정하고(product roadmap, vision), 제품을 개발하는 팀이 가장 효과가 크고 중요한 업무부터 수행할 수 있도록 우선순위 결정을 한다(prioritization).
  3. 고객이 런칭한 기능/서비스를 우리가 원했던 대로 사용하고 있는지 분석을 하고, 분석을 통해 배운 것을 다시 제품에 반영한다. (design > implementation/release > data analysis > learning > iteration of the process)

사실 나도 Product owner로 일하면서 처음 1년 동안은 닥치는대로 일했었다. 개발자, 디자이너들이 자기 본업에 충실할 수 있도록 운영 업무, 타 팀 컨택 및 협의 등 어찌보면 귀찮을 수 있는 업무들을 ‘내가 할게요’ 라고 하면서 처리했었다. 그러면서 내 업무량도 늘고, 야근도 늘어갔다. 허나 product management 관련된 도서와 문서를 찾아보면서 어느 순간 이런 깨달음을 느낀 적이 있었다. “아, 내가 개발자/디자이너를 돕는다고 내 본업(위 1, 2, 3번)에 focus하지 못하고 있었구나. 그리고 내가 이걸 제대로 못하면 배(team)가 다른 방향으로 갈 수 있겠고, 이는 오히려 우리 팀 개발자/디자이너에게 피해를 입히는 일이겠구나” 라고 생각을 했었다. 솔직히 입사 후 1년 정도 지난 시점이었던 것 같다. PO는 제품/팀의 우선순위를 설정하는 역할을 함에도 나는 정작 ‘내 업무’의 우선순위도 제대로 잡지 못하고 일을 하고 있었던 것이다. 그 깨달음의 순간 이후부터는 바쁠 때일수록 되도록 한 발자국 뒤에서 바라보려고 노력을 했었다. ‘내가 정말 중요한 일을 하고 있는가?’ 하고.

 

그럼 Product owner는 ‘관리자’ 인건가요?

결론부터 얘기하면 ‘아니다’. Product owner나 product manager 모두 Role 자체는 관리자의 느낌을 풍기고 있지만, 엄밀히 말하면 개발자나 제품팀의 다른 실무자들을 관리하는 역할은 하지 않는다. PO는 사람을 관리(people management)하지 않고 제품을 관리(product management)한다. 제품을 관리한다는 뜻은, 위의 ‘product owner는 뭐하는 사람이에요?’에 있는 3가지 주요 역할 그대로다.

위를 다시 해석해보면 ‘관리자(boss, manager)가 아니면서 개발자들에게 영향(influence)을 끼쳐 팀을 리드하고 제품을 개발해야 한다’는 뜻이다. ‘너 이거 해’가 아니고 ‘우리 이런 상황이니, 이러이러한 이유로, 이런 걸 하자. 그러면 이러이러한 게 좋아질 것이다’와 같이 개발자들을 설득해서 움직여야 한다. 개인적으로 이 부분에서 많은 PO들이 울고 웃을 것 같다. 각 개발자들의 성향에 따라 개발팀의 분위기는 천차만별이고, 나랑 생각이 다를 확률이 굉장히 높다. 이런 개발자들을 내가 원하는 방향으로 움직이게 하려면 각 팀이 work on하고 있는 제품의 vision을 보여줘야 하고, 감이 아닌 데이터(DB의 데이터든, 리서치 결과든)로 얘기해야 하며, 팀이 개발하여 릴리즈한 기능들이 비즈니스에 어떠한 임팩트를 끼쳤는지도 주기적으로 공유하면서 동기부여도 해야 한다. ‘동기부여’는 PO의 main role은 아닐지 몰라도, 내가 맡고 있는 제품의 성공을 위해서는 개발자들도 같은 미래를 보고 같이 뛰어야 한다. 이를 위해 PO는 제품 팀의 ‘관리자’는 아니지만 그들의 마음을 얻는 것이 필수라 생각한다.

aaeaaqaaaaaaaaliaaaajdi0nzi5mtqyltawmdqtndhhzi1hyzq2lti0mwm3zmu0owezyw

위와 같은 PO는 No No.

 

그런데 Product manager는 뭐에요?

이 부분에 대해서도 할 말이 좀 있다만, 본 Posting이 너무 길어질 것 같아서 다른 글에서 다루어 볼까 한다. (이 글 참고 – Product owner? Product manager?) 내가 경험했던 위주로 Product manager가 뭔지, product owner와는 뭐가 다른지, program manager라는 건 또 뭔지 등에 대해 적어보겠다.