Inyong Suh

토론 문화에 익숙해지기

December 29, 2017December 29, 2017Inyong Suh2 Comments

지난 2주일은 고민이 많았던 시간이었다. 네덜란드 회사로 이직 후 3개월이나 지났는데, 아직도 업무 성과/속도가 나지 않는 것 같았고, 팀 내외적으로 챌린지도 많았던 시기였기 때문이다. 자연스레 스트레스도 많았다. 그래서 지난 주말에 혼자 이런 저런 생각을 하며 내가 받는 스트레스의 원인을 분석해 보았다.

결론부터 얘기하면 내가 지금 자신감이 적은 상태였고, 그에 따라 팀원이나 다른 팀에서 챌린지하는 부분에 대해 과민반응을 하고 있는 걸로 진단했다. 내가 아직 내가 하는 일/제품에 대해 잘 모르고 있는 상태였고, 이 상태에서 다른 사람들이 나를 쿡~ 찌르면 ‘잘 모른다’는 부끄러움을 감추기 위해 조금은 감정적인 리액션이 나오는 것이었다.

이번에는 나를 스스로 진단했지만 사실 비슷한 경우를 지난 회사에서도 겪었다. 그때는 내 상사가 나에게 이런 피드백을 주었다.

싼쵸님은 다른 사람이 본인과 다른 의견으로 챌린징하거나 질문하는 경우에 좀 감정적으로 대응하는 경우가 보인다. 그냥 마음을 열고 맞는 말은 받아들이고, 아닌 경우라도 본인이 왜 그렇게 생각하는지 논리적으로 주장을 하면 된다.

당시에는 이게 내 개인적인 성향/문제라고 생각을 했으나, 이번 계기로 다시 한 번 생각을 해보게 되었고, 내 개인적인 성향 외에도 어느 정도는 ‘토론 문화에 익숙하지 않기 때문에’ 겪는 진통이라고도 생각을 했다.

정답이 없는 문제를 푸는 경우가 많다.

요새 내가 고민하는 것에 대해 예전 상사께 이메일로 조언을 구했고, 다음날 받은 장문의 피드백 중 일부를 아래와 같이 발췌해 본다(참고로, 이 분은 고등/대학교를 영어권 국가에서 나왔다.)

서양권 사람들은 예전부터 debate에 익숙하고, 토론을 통해 답을 찾아가는 과정에 익숙한 반면, 한국 사람들은 공개적인 자리(미팅)에서 내 의견에 챌린지 하는 경우 공격받는다고 생각하는 경향이 있는 것 같다.
우리가 일하면서 풀고 있는 문제들은 정답이 없는 경우가 많다. 결국 토론 시 내가 어떤 프레임워크로 고민을 했고 객관적인 증거(데이터 등)를 찾아봤는 지 등이 중요할 거다. 그게 결국 논리다.

그렇다. 생각해보면 우리는 정답이 없는 문제를 푸는 경우가 많다. 어느 경우나 장/단점이 있고, 토론과 데이터 분석을 통해 최대한 리스크가 적은 판단을 하려 한다. 논리적으로 풀어낸 생각이고, 토론에 참여한 다수가 동의한다면 그게 그 상황에서는 최선의 선택이다.

그런데 나는 유의미한 생각들을 주고 받는 생산적인 토론보다는, 내가 틀리지 않았다는 것을 증명하기 위해 최대한 ‘방어’하는 토론을 하고 있었다. 서로 생각이 다른 미팅을 하다보면 “I would like to challenge you in that ~”, “I am disappointed that you said~ I think~” 등으로 시작하는 말을 듣곤 한다. (사실 다른 나라 사람들은 disappointed 라는 표현은 잘 안 썼으나 좀 직설적인 네덜란드인이 썼다.) 한국말로 직역하자면 “도전한다(challenge)”는 것 아니겠는가! 그래서 이런 말을 들으면 속으로 “어?”라는 생각부터 들었고 이에 방어적이고 좀 부정적인 감정이 앞섰던 것 같다.

내 옛 상사가 얘기했던 것처럼 서양에서는 토론문화가 활발하고, 그런 환경에서 자라온 사람들과 토론을 하다보면 내가 논리에서 밀리는 경우가 많다. 우리 회사는 (글로벌 회사지만) 네덜란드에서 창업하고 암스테르담에 본사를 둔 회사기 때문에, 직원의 20% 정도는 네덜란드이다. 이들은 특히 영어도 잘 하고 토론도 잘 한다. (* 참고 : 국가별 영어 능력평가 1위 네덜란드, 네덜란드 토론 문화 참고) 이 사람들 사이에서 내가 팀을 대변하여 미팅을 하다보면 종종 논리에서 밀리게 되고 말을 더듬게 된다. 이 상황에서 내가 계속 ‘이기려고’ 하면 감정적으로 변하게 되는 것이다. 패배를 인정하기 싫은 것이다.

하지만 ‘정답은 없다’고 생각하면 조금은 마음이 열리는 것 같다. 논리 대 논리에서 밀렸으면 깔끔히 패배를 인정하고(“Good point!”) 하나 배웠다고 생각하면 되겠다. 논리에서는 밀렸으나 여전히 수긍이 안 가는 경우라면 “Let me think about it” 라고 하고 다른 각도에서 더 고민을 하거나 데이터를 찾아보고 다시 얘기를 할 수도 있겠다.

challenge

맨날 질 순 없잖아

열린 마음으로 토론을 하고, 상대방의 의견을 유연하게 수용한다고 해도, 맨날 토론에서 지면 안되지 않겠는가! 특히 나는 Product owner로서 나와 같이 일하는 개발팀을 대변하는 경우가 많기에, 최소한 이들에게 피해는 입히지 않아야겠다는 결심을 하게 된다. 그럼 어떻게 해야 토론을 잘 할 수 있을까? 이 부분에 대해 나는 세 가지 방법을 사용해보려 한다. (지난 영어 관련 글과 마찬가지로, 나는 내 자신을 실험의 대상으로 한다)

1. 내 고객과 내 제품에 대해 누구보다 더 잘 알아야 한다. 통계 및 주요 지표에 대한 데이터는 물론 고객 리서치 결과 등도 함께 숙지하고 있어야 한다. 자신감의 원천이다.

2. 챌린지가 예상되는 부분에 대해 내 생각과 근거를 뚜렷이 가지고 (준비하고) 있어야 한다. 지금 완벽하지 않다면 앞으로 어떤 계획을 갖고 있는지에 대해서도 생각을 해 놓는다.

3. 마지막으로 설득(persuasion) 관련 책을 읽어보고자 한다. 책 하나 읽는다고 갑자기 debate master가 되진 않겠지만 최소한 어떤 프레임으로 훈련을 해볼까 감은 잡을 수 있을 것 같다.

영어 훈련과 마찬가지로 토론에 대한 훈련도 짧은 시간 내에 효과를 확인하긴 힘들 것이다. 다만 하루하루 사람들과 커뮤니케이션하면서 도전하고 배운다면 점진적으로 실력도 늘고 자신감도 붙지 않을까 한다.

한국에서 태어나 인생의 대부분을 한국에서 보냈고 직장생활의 80% 이상을 대기업에서 경험했다. 허나 이젠 암스테르담이란 곳에서 이곳 사람들과 부대끼고 있기 때문에 변하지 않으면 survival 하기 힘들 것이라고 느낀다. 심각해지긴 싫지만 이 또한 한 단계 도약하기 위한 과정이라 생각하고 도전하고 배운다면, 어느 순간 달라진 자신을 볼 수 있지 않을까 한다.

업무용 통화와 퇴근 후 메시지

November 8, 2017Inyong Suh1 Comment

네덜란드에 있는 회사에서 세 달여간 일하면서 커뮤니케이션 방식과 시간 관련해서 한국과 다르다고 느낀 점 몇 가지가 있다. 이번에는 이 내용들을 잠시 다뤄보고자 한다.

1. 업무용으로 전화를 써 본 적이 없다.

일단 나는 IT 기업 개발(Tech)팀에서 Product owner라는 직무로 일하고 있다. 주로 개발자/디자이너/데이터 과학자들과 함께 일하며, 다른 팀과 컨택할 경우도 자주 있으나 그들도 대부분 개발조직 내부에 있다. 파트너 (호텔리어나 숙소 주인) 쪽 Product을 다루기에 그들의 요구사항을 듣기 위해 가끔 호텔리어들을 만나기는 하나, 그들과 직접/자주 컨택할 일은 많지 않다.

한국에서 일할 때도 같은 상황이긴 했다. 파트너가 아닌 실제 고객을 대하는 Product라는 점만 다를 뿐이었다. 허나 같은 상황임에도 두 회사간 1:1 커뮤니케이션 방식은 좀 달랐다. 네덜란드에서 세 달 동안 업무를 위한 전화를 받아본 적이 없다. 그리고 동료들이 누군가에게 업무상 전화를 하는 걸 본 적도 없다.

그 이유에 대해서 몇 가지 생각해봤다.

나라에 따라 문화가 다르다. 한국에선 급한 일의 경우 자주 전화를 걸어 문제를 해결했으나, 여기선 메신저(사내 메신저)로 @태그를 걸어 Notification을 보내고 기다린다. 사전 동의없이 상대방의 시간을 직접적으로 뺏는 행위를 지양하는 것 같다.
그리고 이 @태그를 보내면 답변을 곧 하리란 믿음이 있는 것 같다. 실제로 답변도 생각보다 빠르다.
영어가 공용어이나 모든 사람들이 영어로 원활히 통화하는 건 아니다. Written English가 더 효율적일 수 있다.
뭐든지 증거를 남기는 게 좋다. 전화 통화는 휘발적이다.

이게 좋은 문화인지는 사람에 따라 다를 것 같다. 개인적으로는 편한 점도 있으나 답답한 점이 더 크다. 물론, 영어가 완벽하지 않은 상황에서 전화영어가 좀 더 비효율적인 부분도 있으나, 급한 경우는 전화로 얘기하는 게 빠를 때도 많은데 말이다.

2. 업무시간 후에 메세지를 받아본 적이 거의 없다.

딱 한 명 (이 사람 역시 성격 급한 PO다) 제외하고는 저녁 7시 이후에 업무성격의 메시지를 받아본 적이 없다. 그래서 나도 그런 메시지를 보낼 수가 없었다. 어디 명문화된 Rule은 아니나 분위기가 그렇다.

이 역시 장단점이 있다. 개인적으로 애기를 재우고 밤에 종종 일하곤 하는데, 이때 팀과 공유하고 싶은 내용이 있어도 참았다가 다음 날 아침에 보내곤 한다. Work-life balance를 꿈꾸며 네덜란드에 왔는데, 이런 걸로 답답해하는 내 모습을 보며 참 모순적이라 생각하기도 했다. 나는 같이 고민하고 싶을 뿐인데 말이다. (개발자분들이 보면 싫어할 상이다)

짧게 정리하자면, 업무가 사생활을 침해할 수는 없다는 게 전체적인 분위기인 것 같다. 유사한 의미로, 휴가 사용 관련해서도 관대한 편이고, 휴가 중에는 업무 관련 커뮤니케이션은 전혀 하지 않는다.

간만에 짧은 글을 남겼다. 개인적으로 시간이 지나면서 업무에 적응해가고 있으나, 반면에 모자란 점도 많이 느끼고 있는 요즘이다. 좀 더 잘하고 싶고(비즈니스 성과), 개발팀을 잘 리드하고 싶다는 마음(리더쉽)이 큰 상황이나, 언어적인/상황적인 요인 때문에 생각만큼 잘 되진 않는다. 이에 마음이 급해지는 경향이 있는 것 같으나, 위에서 언급한 긍정적인 부분들 덕분에 너무 쪼이지 않고 밸런스를 유지하는 것 같다.

유럽에서 Product manager(owner)로 일하는데 있어서 느낀 부분이 있다면, 위에서 언급한 문화적인 부분을 최대한 존중하면서, 짧은 시간 내에 중요한 일부터 효율적으로 할 수 있는 나만의 방법을 찾아야겠다는 것이다. 빠르게 의사결정을 하되 팀원들로부터 신뢰를 얻을 수 있는 결정이어야 하기에(a.k.a 데이터+논리에 기반한 결정) 효율적인 업무는 정말 필수적이다.

사내 커뮤니케이션. 회사와 직원간의 신뢰.

October 19, 2017October 20, 2017Inyong SuhLeave a comment

지난 11여년간 3개 회사를 경험해봤고 각기 굉장히 다른 경험이었다. 오늘은 그 경험들 중 사내 커뮤니케이션에 대해 얘기해보고자 한다. 지난 경력을 잠시 요약하자면, 약 8년 간 스마트폰 사업을 하는 국내 대기업(S라고 칭하겠다)에서 일했고, 그 후 임원진 대다수가 외국인인 중견 스타트업(C)에서 2년 반 정도 일하다가, 지금은 네덜란드에 있는 글로벌 회사(B)에서 일하고 있다. B에서는 이제 겨우 두 달 일했지만 대략 분위기 및 업무 방식은 파악한 상태이다.

회사-직원 커뮤니케이션

우선 S 업체는 국내 대기업이니 말 안해도 알 수 있겠지만 굉장히 Top-down 식의 문화였다. 허나 회사에 관한 주요 소식은 미디어를 통해 더 먼저 듣게 되는 경우가 많았고 회사가 먼저 다가오는 경우는 적었던 것 같다. 사내 미디어와 블로그를 운영하기도 했는데 개인적인 느낌으로는 이런 사내 커뮤니케이션로도 ‘열려있다’는 느낌을 받긴 힘들었다. 좋은 면만 보여주고 가려운 부분/곤란한 부분은 돌아가는 것 같은 느낌이었다. 공식 사내 블로거 1기로 활동을 하면서 사내 공개 블로그에 글을 올리곤 했었는데, 한 번 ‘검열’로 인해 글 포스팅을 거절당한 이후 활동을 중지했었다. (회사의 글로벌 문화에 대해 건설적인 비판을 살짝 하던 글이었다) 그래서 더 부정적인 느낌이 강한 것 같다. 한 가지 긍정적이었던 기억은 영업/마케팅팀에서 일하던 당시 실장(사장)이었던 분이 분기에 한 번씩 회사 실적과 시장 상황 그리고 앞으로의 방향/전략에 대해 공유하던 자리였다. 덕분에 업무의 방향에 대해 조금은 뚜렷해지고 동기부여도 되곤 했으나 이 자리도 다분히 단방향의 전달이었다.

C 업체는 CEO가 굉장히 열정적이고 달변가였다. 입사 첫 날 개발팀 수백명을 모아놓고 본인이 추구하는 방향에 대해 열변을 토하던 모습을 잊을 수가 없다. 그런 덕분에 직원들의 동기부여를 잘 하곤 했었다. 허나 회사가 커지면서 대표이사 한 명의 언변보다는 소통을 위한 양방향 ‘시스템’이 있었어야 했는데, 이 부분에서 좀 부족했던 것 같다. 상황에 따라 조직이나 전략에 변화를 주는 것은 필요한 일이나, 변화를 Drive 하는 중에 경영진의 의중이 실무진에 제대로 전달이 되지 않는 부분이 많았다. 특히 조직개편, 평가나 승진 등 직원들이 민감해 하는 인사적인 부분에서 양방향 소통이 없었고 이에 신뢰감이 적어졌던 것 같다. 개인적인 생각으론, 회사가 너무 빠른 시간 내에 성장하다보니 미처 시스템이 갖춰지기도 전에 문제들이 생겼고, 경영진들도 큰 조직을 이끌기에 경험이 조금은 부족하지 않았나 싶다. 하지만 문제점에 대해 경영진이 제대로 인식한다면 충분히 바로잡을 수 있는 유연성이 있는 회사라고 생각한다.

B 업체는 주기적으로 CEO가 전 직원들 앞에서 (수백명은 오프라인으로, 나머지는 전 세계 중계로) 현재 상황 공유와 함께 앞으로 나아갈 방향을 공유한다. 이 부분은 일반적이라 말할 수 있지만 마지막 Q&A 시간이 인상적이었다. 주요 경영진이 앞에 나와 있고, 직원들이 전달한 질문들을 각 담당자들이 답변을 했다. 사전에 정리된 질문은 아니고 현장에서 바로 받은 질문들로 대답하기 굉장히 곤란한 질문들도 있었다. 개인적으로는 이런 부분을 보면서 회사에 대한 ‘신뢰’가 생겼던 것 같다. 그리고 사내 커뮤니케이션 툴을 통해 주요 경영진들이 회사의 상황을 알리고 본인의 생각을 전달하고 의견을 주고받는 것(댓글을 통해)을 볼 수 있었다.

B 업체에서 일한 지는 이제 두 달 밖에 안됐기에 어두운 부분까지는 아직 파악 못했을 수도 있다. 하지만 서로 굉장히 다른 세 개 회사에서 일하는 동안 느낀 것이 있다면, 사내 커뮤니케이션을 어떻게 하느냐에 따라 직원의 회사에 대한 ‘신뢰도’가 달라진다는 것이다. 그리고 가장 중요한 부분은 바로 Transparency(투명함)라고 생각한다. 회사가 무엇인가를 숨기고 있다고 생각하는 순간, 직원들은 다른 생각을 할 것이다.

직원 간 커뮤니케이션 툴

이번에는 정책보다는 ‘툴(Tool)’에 대해 잠시 얘기해보고자 한다. 회사-직원 관계가 아닌, 회사의 정책 하에 직원간의 커뮤니케이션에 사용되는 툴에 대한 얘기다.

S 업체에서의 주요 커뮤니케이션 툴을 들자면 이메일, 메신저, 전화 였다. 퇴사 전 몇 년간은 사내에서 개발한 채팅 앱도 사용하곤 했지만, 업무상 주로 쓰던 방식은 위 세 가지였다. 이메일은 일반적인 커뮤니케이션 툴이긴 하나, 다분히 공식적인 느낌으로, 주로 업무 전달/소통 시 사용되었고, 일반적인 직원 간 커뮤니케이션은 사내(계열사)에서 개발한 메신저로 이루어졌다. 당시에는 크게 불편한 점이 없다고 생각되었지만 퇴사 후 C 업체에서 다른 툴을 경험한 이후는, 다시 그 당시로 돌아가고 싶은 생각이 사라졌다. (한 가지 아쉬운 점은, 커뮤니케이션 툴 이름이 Single이라는 점이었다. 소통을 위한 툴인데 왜 Single이었을까)

C 업체 입사 후 초반에는 이메일 그리고 카카오톡을 주로 썼다. 이메일은 Gmail 기반이었기에 스마트폰에서 쉽게 동기화하여 사용할 수 있었고, 사내 문서도 주로 Google Doc을 사용해서 쉽게 공유하고 의견을 주고 받을 수 있었다. 다만 카카오톡을 업무에 사용하는 것은 상당히 불편했다. 간단한 대화는 무리가 없겠지만 채팅 창 여러 개를 왔다갔다 하고, 필요한 파일을 주고 받으면서 업무를 하기에는 사용성 측면에서도, 그리고 보안 측면에서도 적절치 않았다. 이에 입사 1년 후부터는 그 유명한 Slack이란 커뮤니케이션 툴을 사용하기 시작했다. 처음에는 낯설었지만 이 툴 덕분에 생산성이 굉장히 향상되었다고 생각한다. 조직별/프로젝트별로 채널을 따로 만들어놓은 후 한 App으로 모든 소통을 했고, 파일/이미지를 주고 받는 게 훨씬 편해졌고, 알림(notification)도 채널별 중요도에 따라 레벨을 설정하여 받을 수 있었다. 한 가지 아쉬웠던 점은, 주로 개발/제품팀에서 사용했기에 그 외의 Stakeholder들(CS, 마케팅, 영업조직 등)과는 결국 기존 채널을 활용할 수 밖에 없었다는 점이다.

B 업체에서는 기업용 Facebook을 사용한다. 공식 명칭은 Workplace이다. 공개를 해도 되나 고민했으나 찾아보니까 공식적으로 B 업체가 Facebook의 고객사임을 공개해놓았다. 일부 디자이너들은 Slack을 사용하고 있으나 공식적인 소통 채널은 Workplace이다. 사실 첫 느낌은 ‘대혼란’이었다. Facebook에서도 그룹이 있지만 Workplace에서도 팀별/프로젝트별/여러가지 별로 그룹이 존재하고, 입사 후 반 강제적으로 여러 개의 그룹에 가입하게 되면서 쏟아지는 알림 메시지(notification)으로 굉장히 산만한 한 주를 보냈다. 그러나 어느 순간부터는 (Slack과 같이) 그룹에 따라 Favorite 지정과 함께 알림 레벨도 설정하였고, 지금은 업무에 지장을 줄 정도로 산만하진 않다.

사실 기능상으로는 특별할 게 없다. 하지만 회사에서 공식적으로 Workplace를 소통을 위한 채널로 지정하고 집중하고 있으며, 개발팀 포함 모든 조직이 한 플랫폼에서 소통을 하다보니, 예전보다 어떤 ‘궁금증’이나 ‘문제’가 생겼을 때 해결책(혹은 해결책을 위한 실마리)을 찾는 시간이 빨라진 것 같다. 대충 어떤 팀이 있을 것이라 생각하고 전체 검색을 하면 그 문제와 관련된 팀이나 모임 그룹이 나오고, 그곳에 질문을 올리면 빠른 시간 안에 댓글이 달린다. 그리고 중요한 공지사항도 메일보다는 Workplace를 통해 관련된 사람들에게 빠르게 공유되고, 피드백도 바로바로 받을 수 있다. 모두에게 익숙한 Facebook 인터페이스에, 이메일보다 훨씬 캐쥬얼한 소통방식(like, 댓글, follow 등)으로 인해서인지, 직원들간의 소통이 굉장히 활발하다. 기존에 경험했던 채널보다 훨씬 직원들의 참여도가 높다고 느낀다.

회사에 대한 신뢰, 직원들의 참여도

사실 이 글을 쓰면서 나 자신도 생각을 정리하게 되었다. 위에서 회사-직원 간 커뮤니케이션 예를 들면서 ‘신뢰’에 대해 생각을 하게 되었고, B 업체에서의 경험을 생각하면서 ‘참여도’를 생각하게 되었다. 그리고 얼마 전에 Training 받을 시 토의 키워드가 Ownership(오너쉽), engagement(참여) 였던 기억이 난다. 여러 dot들을 연결해보자면 결국 회사가 직원들을 신뢰하면 직원이 회사를 신뢰할 것이고, 회사가 직원을 신뢰하면 직원들의 참여도도 커질 것이다 라는 점이다. 국가가 달라 문화적인 차이가 있을 수도 있지만, S / C 업체와 B 업체의 차이는 ‘회사(경영진)가 직원을 신뢰하는가?’에 있다고 본다.

개인적인 관계에 있어서도 내가 먼저 마음을 열고 다가가면 상대방도 마음을 열듯이, 회사가 직원과 소통할 때도 투명한 정보를 기반으로 다가가야 한다. 회사가 직원 앞에서 투명해 질 수 있는가는 회사가 얼마나 직원을 신뢰하는 가에 달려있다. 그리고 회사가 직원을 신뢰하면 직원들은 시키지 않아도/Micro manage하지 않아도 회사의 이익을 위한 방향으로 생각하고 움직이게 되는 것 같다. 결국 다 ‘잘 먹고 잘 살자고’ 하는 일들인데, 좀 더 긍정적인 마음으로 일하고 서로 소통하면 조금은 더 ‘잘 먹고 잘 살게’ 되지 않을까 한다.

* 위에 B 업체에 대해 좋은 점만 썼지만 이 글은 ‘소통’에 관한 부분만 다뤘지, 다른 부분들은 다루지 않았음을 참고하기 바랍니다.

Product owner? Product manager?

October 15, 2017October 15, 2017Inyong 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는 뭐하는 사람이니?

September 25, 2017October 15, 2017Inyong 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는 회사의 조직, 상황 그리고 제품의 특성에 따라 다양한 일들을 하지만, 가장 중요한 몇 가지만 꼽아 보자면 아래와 같다. (내 의견이다)

고객이 원하는 바를 파악하여 이를 제품에 반영한다.(identify customer behaviors/needs)
제품이 가야 할 방향을 설정하고(product roadmap, vision), 제품을 개발하는 팀이 가장 효과가 크고 중요한 업무부터 수행할 수 있도록 우선순위 결정을 한다(prioritization).
고객이 런칭한 기능/서비스를 우리가 원했던 대로 사용하고 있는지 분석을 하고, 분석을 통해 배운 것을 다시 제품에 반영한다. (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라는 건 또 뭔지 등에 대해 적어보겠다.