product management

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

Change aversion : “내가 맨날 쓰는 거 그냥 좀 놔둬!”

Inyong SuhLeave a comment

사람은 대개 변화를 두려워하죠. 익숙한 것을 좋아하고 편안해하구요. 어느날 아침 출근하니 매일 사용하던 업무용 툴의 디자인이 하루 아침에 확 바뀌어 있다고 상상해 보세요. “와 엄청 예뻐졌네. 엄청 사용하기 편해졌겠어!”라는 생각보다는 “아 이제서야 좀 익숙해졌는데 또 바뀌었어? 아 그 XX메뉴는 어딨는거야? 바빠죽겠는데 하나씩 다 눌러봐야 하나?”와 같은 반응일 거에요.

얼마 전에 저도 업무 중에 같은 경험을 했습니다. 이번엔 제가 ‘사용자’가 아닌 그 변화를 주도한 ‘제품팀’이었다는 점이 다르지만요. 모든 맥락을 설명하자면 엄청 길기에 간단히 요약하자면 : “사용자들의 불편한 점을 개선하고자 새로 디자인한 제품을 프로토타입 테스트, 알파테스트, 베타테스트를 거치며 신중하게 테스트했고 마지막에는 78%의 만족도(기준선은 65%였음)를 확인하였기에 ‘성공’을 확신했던 제품 업데이트였습니다. 하지만 큰 규모의 사용자에게 릴리즈를 하기 시작하면서 이 만족도는 급감하였습니다. 처음엔 25% 수준까지 떨어졌죠. PM으로서 실망이 컸습니다. 하지만 이 만족도를 매일 측정하다보니 조금씩 높아지는 게 보였습니다. 2주가 지난 지금은 50% 이상까지 올라왔죠. 사용자들의 피드백을 확인해보면 ‘이전께 더 좋다’, ‘왜 바꿨냐’, ‘불편하다’ 와 같은 피드백이 다수였습니다. 구체적으로 무엇이 불편하다 라는 내용보다는 그냥 불편하다, 이전 것이 더 편하다 라는 의견들이 많았죠.”

사용자들은 갑작스런 변화를 불편하게 느낍니다. 익숙한 것이 편하고 안전하다고 느끼죠. 사실 이번엔 고객 만족도가 초기에 떨어질 것이라는 것은 예상하던 일이었습니다. 이전에 어느 정도 유사한 경험을 한 적이 있었고, 첨부한 링크와 같은 자료를 읽으면서 이것이 자연스러운 일임을 미리 알고 있었기 때문입니다. 첨부된 링크에서는 이러한 현상을 ‘change aversion(변화를 싫어하는 것)’이라는 용어로 사용하고 있습니다.

작은 변화를 적용하는 A/B 테스트라면 굳이 이런 걱정은 하지 않아도 될 것입니다. 하지만 어느 정도 큰 규모의 변화를 적용하는 케이스이고, 정량적인 데이터 뿐 아니라 정성적인 데이터(사용성, 만족도 등)의 중요성도 큰 변화/실험을 계획하고 있다면 첨부한 링크를 한 번쯤 꼭 읽어보시길 바랍니다. 변화의 레벨에는 어떤 것이 있고, 어떤 경우에 큰 change aversion을 예상할 수 있고, 패턴(사용자의 반응)에 따라 어떻게 대응을 해야 할지도 알려줍니다. Change aversion을 줄이기 위한 여러가지 방법도 설명해주고 있구요.

Change aversion은 인간으로서 자연스러운 일입니다. 그렇기에 완전히 피할 순 없어도 최소화 할 수는 있습니다. 첨부된 링크 한 번 읽어보세요. 나중에 피가 되고 살이 될 내용이라 생각합니다. 저만해도 당장 ‘지금’ 경험하고 있는 것이니까요.

* 궁금해 하실까봐 첨언하자면, 베타 테스트 시 change aversion을 확인하지 못했던 이유는 사용자들이 이미변화가 올 것을 알고 있었기 때문이죠. 테스트를 자발적으로 신청한 것이니까요. 그리고 일단 새 디자인의 제품을 사용해보고 원하지 않으면 베타 테스트에서 나갈(opt-out) 수 있도록 구성을 해놓았었습니다. 지금 진행하고 있는 ‘릴리즈’는 opt-out이 불가능한 일괄 변경이기 때문에 저항이 더 큰 것이라고 보구요.

** 이 글은 Publy News에 올린 글입니다.

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

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

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

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

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

비전과 제품(Product) 리더쉽

Inyong Suh1 Comment

* 2018년 2월에 Brunch에 쓴 글입니다. 

 

우리는 업무와 일상 중에 “비전(Vision)”이란 말 참 많이 쓴다. Product management에서도 이 비전이라는 것은 참으로 중요하다. 어찌보면 ‘성과를 내는 팀(high performing team)’을 빌딩하고, 이 팀을 기반으로 고객에게 가치를 주는 제품을 만들기 위해 가장 중요한 요인인 것 같다.

벌써 네덜란드로 이주해 숙소예약업체인 B사에서 Product owner(이하 PO)로 일을 시작한 지 6개월이 되었다. 실제로 내 팀을 꾸리고 무언가 만들어나기기 시작한 것은 4분기(10~12월)부터니까 진짜 PO로 일한 것은 4개월 남짓 된 셈이다. 지난 해 말에 4분기 회고(Retrospective meeting ; 지난 시간을 되돌아보고 팀이 잘한 점, 부족한 점을 되짚어보고 앞으로 어떻게 하면 성과를 내는 팀이 될 수 있을 지 논의하는 미팅)를 했을 때 팀원들이 언급한 부분이 바로 위에서 언급한 ‘비전’이었다. 더 자세히 말하자면 비전을 명확하지 않아 중요한 의사결정을 할 때 방향이 헷갈린다는 점이었다. 팀의 PO 입장에서 부끄러웠다. 사실 회고 전에도 어느 정도는 알고 있었다. 특정 상황에서 내가 팀을 잘못 리드하여 시간을 좀 허비한 적이 있었기 때문이다.

그렇다. 오늘도 내가 못한 점, 고생한 부분으로 얘기를 시작한다. ‘해외에서 외국인들을 이끌고 멋진 서비스를 개발하는 PO’이고 싶었으나 다시 한 번 ‘좌충우돌하는 외노자 3년차 PO’ 버전으로 ‘비전’에 대해 잠깐 얘기해보고자 한다.

* 이 글에서는 편의를 위해 비전(vision), 방향, 목표(objective) 등을 섞어서 썼으나, 엄밀히 말하면 비전/미션/목표 등은 조금씩 다른 개념이고, 회사마다 정의가 다른 경우도 있다. 여기서는 굳이 정확히 나눠서 얘기하진 않겠다.

비전, 의사결정의 중요 요인

솔직히 4분기 동안 ‘비즈니스 지표’ 입장에선 못하지 않았었다. 오히려 신생팀이지만 굉장히 좋은 성적을 냈었다. 그러나 솔직히 이는 쉬운 길이 있었기 때문에 가능했었다. 우리 팀은 우리 조직(팀의 상위부서) 10개 제품팀 중 유일한 모바일 앱 개발팀이다. 우리 팀의 첫 시작이었던 4분기에는 기존에 PC Web에서 성공적이었던 기능들을 모바일 앱으로도 제공을 했었기 때문에, 어느 정도 성공이 예측가능한 기능들이었다.

그러나 우리 팀의 목표(Objective)에는 이 비즈니스 지표 외에 새로운 영역을 발굴하는 목표도 있었다. 비전의 부재는 이 두번째 목표 달성을 위한 기능을 기획, 디자인, 구현하는데 있어 큰 영향을 끼쳤다.

미지의 영역인 만큼 처음에는 사용자(우리 팀의 경우는 호텔리어나 숙소 소유주가 end user이다)가 어떤 부분에서 불편함을 느끼고, 어떤 기능들을 요구하는지를 파악하는 것부터 시작했다. 여러 목소리를 듣고 중요하다고 생각하는 순서대로 우선순위화(prioritize)하고 첫번째 기능에 대한 요구사항을 구체화하기 시작했다. 문제는 여기서부터 시작되었다. 우리 조직의 주요 목표는 우리 회사 웹사이트 상에 ‘예약 가능한 방/호텔’을 늘리는 게 목표인데, 우리 팀은 ‘방이 더 잘 팔리게(방이 booking되는 것)’ 웹 사이트를 개선하는 방향으로 고민을 했기 때문이다. 둘 다 우리 사용자의 비즈니스가 잘 되도록 돕는 것은 맞았으나, 우리 조직의 주요 목표와는 조금 다른 방향으로 기능을 디자인하기 시작했다. 이 과정에서 PO인 나는 조직의 요구사항을 대신하여 목소리를 냈고, 이 과정에서 많은 논쟁이 있었다. 목표 지표가 확정되지 않았고, 구체적인 개발 사양도 확정하지 못한 채 몇 주의 시간이 지났다. 결국 조직의 목표와는 조금 다른 방향으로 결론이 났고, 이 방향대로 구현을 완료하여 실제 사용자를 대상으로 테스트를 했으나, 원하는 결과는 얻지 못하였다.

테스트의 성공 여부를 떠나, 지난 4분기 말을 되돌아보면, 이 테스트 하나 때문에 팀이 좀 힘든 시기를 겪었다. 서두에서 얘기했지만, 회고 미팅 시 ‘비전’에 대해 얘기가 나온 것이 이 테스트 때문이었다.

그럼 왜 ‘비전’이 언급되었을까? 그건 바로 우리가 의사결정의 갈피를 잡기 힘들었던 이유가, 우리 팀이 가야할 방향에 대해 모든 팀원들의 이해가 달랐기 때문이다. 비전은 쉽게 말하면 북극성(North star)과 같이 장기적으로 봤을 때 우리가 가야 할/달성해야 할 목표점이다. 제품(Product)의 비전을 설정하고 이를 향해 팀을 리드해야 할 책임이 어느 정도 PO에게 있기 때문에, 나는 솔직히 잘못을 인정하고 미안하다고 사과했다. 팀을 잘못 리드한 것도 그렇고, 팀원들의 팀 목표에 대한 이해도가 낮았던 이유도 어찌보면 나에게 있다고 봤기 때문이다.

핑계를 대자면 많이 댈 수 있다. 해외로 이직 후 맞이한 첫 분기이기 때문에, 회사의 문화와 프로세스에 대해 이해가 얕을 수 있고, 호텔 비즈니스 자체에 대해서도 아직 완전히 따라잡진 못한 상황이기 때문이다. 하지만, 핑계를 떠나 모자람을 인정하고 다음 분기(2018년 1분기)를 도모하는 것이 더 나은 모습이라 생각했다. 그렇게 1분기가 다가왔다.

제품의 가치, 가야할 방향

벌써 18년 1분기가 반 정도 지나간 상황이다. 솔직히 아직 성과는 없었다. 비전 때문은 아니고 1월에 많은 회사 행사(회사 전체 annual event, 해커톤 등)가 있었기 때문이다.

지난 12월 말부터 모든 팀원들이 함께 팀의 비전을 설정했고, 그 이후로도 팀원들에게 가야할 방향에 대해 계속 언급을 했다. 그 덕분인지 팀원들의 팀 목표에 대한 이해도는 좀 더 높아진 것 같다. 1월 말에 팀원들에게 ‘우리 팀 목표에 대해 얼마나 이해하고 있는지’, ‘그 목표가 너를 가슴 뛰게 하는지’, ‘우리 목표가 맞는 방향이라고 생각하는지’ 3가지 질문으로 비밀 설문조사를 했다. 그 결과는 아래와 같이 생각보단 괜찮았다.

이와 별개로 1분기에 개발/런칭하고자 하는 주요 기능들에 대해 팀원들과 논의하고 구체화하는 과정에서 몇 가지 배운 점이 있다. 몇 가지를 잠시 언급해보고자 한다.

1. 모든 팀원들이 팀의 방향에 완전히 align 하기 전에는, 팀원들과 커뮤니케이션 시 ‘다른 목표’에 대해서 언급을 자제하자.

팀이 어느 정도 제 궤도에 올랐다 생각을 하고 팀의 미래(라고 해봤자 몇주/달 앞) 먹거리를 찾기 위해 잠시 조금 다른 쪽을 살펴보고 분석을 하고 있었는데, 이 과정에서 팀원들이 ‘이게 바로 다음에 Focus해야 할 것인가보다’ 라고 생각하는 것 같아 진행을 멈췄다. 자칫하면 다시 한 번 팀원들이 팀의 주요 목표/방향에 대해 헷갈려 할 것 같았기 때문이다. 팀원들이 한 방향을 바라보고 있고, 그 과정에서 ‘작은 성공’을 맛본 후에 다른 목표에 대해 언급해도 늦지 않을 것 같다. (물론 회사/팀의 상황에 따라 다르다)

2. 명문화하지만 말고 비전을 시각화(Visualize) 하는 것도 도움이 된다.

몇 줄의 문장으로 비전을 명문화 할 수도 있지만, 대충이지만 미래 제품의 모습을 스케치하여 팀과 소통하는 것도 효과적이다. 이 스케치의 방향대로 갈 지 안 갈지도 정해지진 않은 것이지만, 우리 제품의 가치를 드러내고 미래에 가야 할 방향에 대해 쉽게 이해할 수 있게 이미지화하는 것은 상호 이해에 도움이 된다.

예를 들면, “호텔리어들은 무지 바쁘다. 우리 제품은 모바일 앱 기반이기 때문에, 필요할 때마다 상황을 실시간으로/간결하게 알려주고 수행해야 할 일을 제안하자. 클릭 한 번으로 Yes/No 선택하여 본인들의 호텔을 쉽게 관리하게 하자.”라는 내용을 모바일 화면으로 스케치하여 소통해 볼 수 있을 것이다.

3. 제품의 기능 신규 기획이나 개선을 할 때, 팀원들과 근원적인 부분(Why?)에 대해 계속 질문을 하면서, 이에 대한 답이 비전과 같은 방향임을 확인하자.

좋은 아이디어가 있더라도 이걸 “왜 해야 하고”, 사용자들에게 “어떤 가치”를 주는 지 고민하지 않으면 엉뚱한 방향으로 흘러갈 수 있다. 계속 “왜” 하는지에 대해 고민을 하고 이에 대한 답이 제품의 비전과 같은 방향인지 확인을 해야 ‘팀의 성과’로 이어질 수 있다.

4. 제품 로드맵 설정 및 의사결정 시 항상 다시 ‘비전’을 되짚어보자. 이와 같은 방향이 아니라면 아무리 좋은 기능이라도 우선순위가 낮아야 한다. (위의 Why?와 어느 정도 연관된 부분)

‘비전’은 연초, 분기초에만 언급하는 게 아니다. 팀이 중요한 의사결정을 할 때 수시로 되돌아가서 짚어봐야 하는 나침반 같은 것이다. 아무리 좋은 가치를 제공하는 기능이라 할지라도 팀의 비전과 방향이 맞지 않는다면 우선순위를 낮춘 후 다음에 다시 고려하거나, 이를 더 잘 수행할 수 있는 다른 팀을 찾는 게 좋다.

비즈니스 모델이 있기 전에 비전이 있다.

한국에 있을 때부터 Publy라는 서비스를 눈여겨 봐왔다. 워낙 글 읽는 것을 좋아해서 질 좋은 컨텐츠처럼 보이는(안 읽어봤으니 평가하기 힘든 상태) Publy의 글을 읽어보려 했으나, ‘개별 구매’가 불가능했던 점 때문에 결제를 미루고 있었다. 그러던 중 Facebook에서 우연히 Publy의 이승국PO가 태그된 글을 봤고, 궁금했던 점을 직접 물어보기로 했다. 아래의 인용글은 내가 “왜 컨텐츠 개별구매는 안되고 월 subsciption 비즈니스 모델만 운영하나요? 저는 읽고 싶은 것만 돈내고 읽고 싶어요”라는 질문에 대한 이승국PO의 답변이다. (사실 이 분은 Chief Product Officer이다. 그러나 질문을 던질 당시에는 이를 모르는 상태였다)

서인용님 안녕하세요. 제 글을 재밌게 읽어주셨다니 감사합니다.

subscription만 운영하는 이유는 비전/미션과 연결된 부분도 있습니다.
개별 콘텐츠를 유료로 팔게 되면 소비가 아무래도 자신의 관심사 위주로 이루어지게 되는데요.
그러다 보면 오히려 세상이 어떻게 변하고 있는지 모르거나, 자신들이 어떤 상황에 있는지 더 큰 그림에서 볼 수 없다고 생각하고 있습니다.

subscription으로 구매를 하게되면 처음에는 관심 분야의 콘텐츠를 보는 것으로 시작하겠지만, 남은 기간 다른 콘텐츠를 보는데 있어 훨씬 자유로워지고 이런 시도에서 자신이 몰랐던 콘텐츠에서 그 가치를 발견할 수 있게 됩니다.
저희는 고객들이 이런 콘텐츠 소비 패턴을 갖추어서 좀 더 다양한 분야에 깊이를 가질 수 있기를 바라고 있습니다.

실제로 저희 서비스를 만족스럽게 쓰고 있는 고객들이 많이 하는 이야기가 PUBLY에 어떤 관심사가 있어서 그 콘텐츠를 보러 들어오는게 아니라 PUBLY가 추천해주는 콘텐츠가 무엇인지 궁금해서 들어와서 본다는 것입니다.

사실 몇몇 콘텐츠가 개별적으로 인기를 끌면서 콘텐츠 개별 구매에 대한 문의도 많이 들어오지만, 우선 멤버십을 활용해서 봐달라고 하고 있으며 이 과정을 통해서 멤버십의 가치를 느끼고 좀 더 오래 유지하는 것도 기대하고 있습니다. (사실 1달 멤버십 가격이 개별 콘텐츠 구매 가격보다 딱히 비싸지도 않습니다.)

다만 현재 초기 예약 판매가 개별 판매의 기능도 하고 있는데요. 이 부분에서 실제로 멤버십 구매와 서로 영향을 끼치고 있어서 어떻게 해결을 할지 고민중에 있습니다.
그리고 적어도 넷플릭스만큼 쉽게 해지하고 쉽게 재결재할 수 있는 방식으로 만들었습니다.

마지막으로 좋은 글의 정의를 내리긴 어렵지만, 전 개인적으로 한국에 좋은 글이 너무나 부족하다고 생각하고 있습니다.
물론 요즘 시대에 영문 콘텐츠까지 그 범위를 넓힐 수 있겠지만,
1) 언어적인 측면에서 생각보다 영문 콘텐츠를 자유롭게 소비할 수 있는 사람은 많지 않습니다. 또는 적어도 한글 콘텐츠를 훨씬 더 편하게 생각하는 경우도 많고요.
2) ‘지식’이라는 측면에서 영문이든 한글이든 콘텐츠의 universal한 부분이 있을 수 있지만, 결국 그 것이 어떻게 활용되는지는 우리 문화에서 이루어지는 바, 우리 문화의 맥락을 담은 콘텐츠가 필요합니다.
3) 지식 콘텐츠는 그 문화 안에서 소비하고, 활용하고, 논의하면서 그 경험을 지속적으로 축적시켜나가면서 발전시켜 나가야 합니다.

결론은 우리가 아예 영미권 문화로 전환하지 않는다면 우리 내부에서 좋은 콘텐츠가 계속 나오는 생태계가 필요하다는 것입니다.

‘해외카드’ 결제 지원이 안되어서 아쉽게도 유료서비스 사용을 못하고 있지만, 솔직히 위 답변을 듣고 바로 유료회원 가입을 할 작정이었다. 읽어보면 어떤 비전을 가지고 있고, 어떤 것을 이루고 싶은지, 그리고 자신들의 서비스가 고객들에게 어떤 가치를 제공해 줄 수 있을지에 대한 믿음(I believe that – !)을 확인할 수 있고, 실제 고객들의 피드백까지 언급하고 있다.

나는 단순히 ‘왜 컨텐츠 개별 구매가 안돼요?’라고 물어봤을 뿐인데, 이승국PO는 고맙게도 본인의 생각을 장문의 메시지로 답변해주었다. 물론 Publy도 여러가지 비즈니스 모델로 시뮬레이션도 하고 실제 테스트도 많이 해봤을 것이라 생각한다. 어쩌면 지금의 비즈니스 모델은 수많은 재무 시뮬레이션의 결과일지도 모른다. 하지만 위의 대화를 통해 다시 한 번 비전의 중요성을 깨달았다. 마침 이때가 2018년 1분기 시작하는 1월 초 시점이었기에 더 그 의미가 크게 다가왔던 것 같기도 하다.

* 위 대화 내용은 이승국PO님께 허락을 구하고 인용하였습니다.

제품 리더쉽(Product leadership)

한국에서 직장 생활 10.5년을 하고 네덜란드로 온 지 반년이 지났다. 한국 직장생활 중 대부분인 8년을 대기업 S사에서 보냈는데, 솔직히 ‘스마트폰을 많이 팔자’ 외에는 회사가 무엇을 이루려 했는지, 어떤 가치를 지향했는지 기억이 안 난다. 회사 다닐 당시에도 몰랐던 것 같다. 그렇다고 직장생활을 못한 것도 아니다. 지금 생각해보면 좀 이상해 보이지만, Top-down으로 주요 목표가 내려오는 한국 대기업의 특성상 굳이 알아야 할 필요도 못느꼈던 것 같다. 주로 ‘어떻게 실행할까’에 대해 고민을 많이 했었다.

지금의 회사도 규모로 보면 대기업이다. 사실 매출 규모로만 보면 애플/구글/아마존/페이스북 그리고 중국의 거인들(알리바바, 텐센트) 바로 다음에 위치한다. 그러나 팀의 목표는 팀에서 정한다. 팀의 상위 조직에도 목표가 있으나, 그 목표를 달성하기 위해 바로 아래의 팀을 쪼는 경우는 아직 못봤다. 스타트업도 아닌 대기업인데 회사 문화는 굉장히 자율적이다. 이 글 서두에서 언급한 사례와 같이 팀이 가야 할 큰 방향 자체는 정해져 있지만(예를 들어, 신규회원 유입이 목표인 마케팅 조직이 갑자기 고객 감동서비스를 하겠다는 건 좀 이상하지 않은가), 그 안에서 어떤 방식으로 일을 하던 회사는 크게 터치하지 않는다.

참 좋아보이지만 PO로서 힘든 점도 있다. 할 수 있는 일이 많은 만큼 하고 싶은 것도 많으나 모두 할 수는 없기 때문이다. 결국 개발 우선순위를 잘 정해야 하고, 그곳에 팀의 역량을 집중해야 한다. 우선순위를 정하는 방법은 여러가지가 있지만, 결국은 ‘사용자’에서 시작해야 한다고 본다. 사용자가 우리 서비스를 통해 이루려 하는 것이 뭔지, 우리 서비스가 사용자에게 어떤 가치를 주는지, 사용자들이 어떤 부분에서 불편함을 겪는지 등에 대해 고민하는 것에서 시작을 하고, 각종 리서치/데이터 분석을 기반으로 우선순위를 정해야 한다.

PO는 자신의 팀이 개발하는 제품이 가야 할 방향에 대한 확고한 믿음을 가지고 팀을 이끌어야 한다. 그렇지 않으면 제품이 사용자들에게 제공하는 가치는 무뎌지고, 팀원들은 열정적으로 일할 동기를 잃는다. 이것이 Product leadership이며 이는 비전에서 시작한다.

(솔직히 지난 몇 개월 동안 나는 이 부분을 잘 못했다. 그래서 회고를 통해 다시 한 번 다짐을 한다)