brunch

브런치북 월요일이 즐거운 PM,PO,기획자 06화

라이킷 178 댓글 12

You can make anything
by writing

C.S.Lewis

계정을 잊어버리셨나요?

by 김영욱 May 13. 2020

<프로덕트 매니저>의 '생각의 틀'과 '방법의 툴'

어떻게 생각하고, 어떻게 구체화 하는가에 대한 개인적인 베스트 프랙티스

제가 주위의 개발자나 디자이너분들에게서 '프로덕트PdM/프로그램PgM 매니지먼트'에 관해 가장 많이 듣는 3가지 질문이 있습니다.

프로덕트 매니저가 되려면 어떻게 해야 하나요?

프로덕트 매니지먼트를 잘하기 위한 스킬셋은 어떤것인가요?

개발자 출신이 어떤 이유로 프로덕트PdM/프로그램 PgM 매니저를 선택하셨나요?

이런 질문에 단순히 제 개인적인 경험을 서술하기보다는 일반적인 소프트웨어/서비스기업의 엔지니어링 그룹의 프로덕트매니저 PdM 의 역할과 일하는 방법을 베이스로, 개인적 경험과 섞어서 서술 하는것이 더 현실성 있는 대답이라는 판단하에 글을 그런 방향으로 전개해 보려 합니다.

0. 글을 시작하면서

지난번에 게재했던 두개의 글을 통해서 PM이라고 통칭되는 프로덕트/프로그램/프로젝트 매니저의 각각의 차이점과 역할을 소개했고, 그 중에서 프로덕트매니저의 상위그룹인 <프로덕트 리더십>에서는 어떠한 역할을 하는지에 대해서 이야기 해 보았습니다. 오늘의 이야기는 위의 두 글의 연장선상에 있기에 아직 읽어보지 않으신 분들은 두 글을 먼저 읽은 후에 이 글을 읽으시는것이 이해에 도움이 될 듯 합니다.

이번 글은 좀더 구체적으로 IT소프트웨어/서비스 기업에서 하나의 제품/서비스를 총 책임지는 <프로덕트 매니저>는 어떻게 생각하고 그 생각을 어떻게 수행하는지에 대해서 입니다. 인터넷 혁명 초기 넷스케이프의 전설적인 프로덕트매니저였던 벤 호로비츠 Ben Horowitz가 "Good Product Manager/Bad Product Manager" 에서 했던 정의는 이렇습니다.

A good product manager is the CEO of the product

위의 표현이 프로덕트매니저에 대한 가장 정확한 표현이다 라고 하기엔 많은 이견이 있을 수 있지만, 그 본뜻은 하나의 프로덕트가 성공으로 평가되기 까지 프로덕트매니저의 책임을 강조하기 위해서입니다.

본 이야기 틀에 들어가기 전에 지난 글들을 리마인드 하고 이해를 돕기 위해, 많은 분들이 최근에 시청한 넷플릭스의 한국형 좀비 드라마 <킹덤>에 대해서 잠깐 이야기 하면서 그 역할 매칭을 하고자 합니다. 드라마나 영화에도 제작이 있고, 작가, 연출, 각색에 효과, 카메라 그리고 배우들이 있습니다. 그 중에 누가 더 중요하고 덜 중요한것을 따질 수 없는것일 텐데, 이 역할들을 엔지니어링 조직내의 역할과 매칭을 시켜보도록 하겠습니다.

제일 먼저, 킹덤이라는 영화가 어떤 영화여야 하는지를 이야기하는 비젼과 어떻게 시즌이나 에피소드를 구성해야 하는지에 대한 로드맵을 작성하는 킹덤의 제작팀이 '프로덕트 리더십'에 해당될 것입니다.

그 다음은 약간 매칭이 어려운 '시나리오 작가'의 역할인데요. 엔지니어링 그룹에선 '프로덕트 리더십'과 '프로덕트 매니저'그룹이 그 유저스토리 역할을 공유 하게 됩니다. 즉 제품/서비스의 큰 스토리라인은 리더십팀에서 오게되고 거기에 살을 붙이고, 고객의 경우를 더하고, 시장의 트렌드를 섞는 역할은 '프로덕트매니저'의 역할이 될 수 있겠습니다. 그 다음이 가장 중요한 역할인데, 실제 그 시나리오를 비주얼라이즈하는 감독연출이 바로 '프로덕트매니저'가 될듯 하구요. 그 외에 효과나 카메라는 고유기능을 담당하는 '프로그램 매니저', 배우들은 그 역할을 완성하는 충실한 '개발자','디자이너','테스터'등등이 되겠죠. 여기에 매번 진행스케쥴과 비용관리하면서 배우들 등장을 관리하는 '프로젝트 매니저'들이 있을겁니다.

Kingdom from Netflix

완전한 매칭은 아니지만, 큰 그림을 이해하는데 도움이 될까 싶어서 예를 들었지만, 제가 왜 많은 영화나 드라마중에 <킹덤>을 예로 들었냐하면, 그 연출의 디테일에 너무 많은 감동과 놀라움이 있었기 때문입니다. 배우의 연기나 화려한 효과도 더 없이 최상의 품질이었지만, 혹시라도 드라마 시청중에 자막(한국어 자막이 단연 최고입니다.)을 함께 보면서 시청하신 분이 있다면 공감하실 수 있을텐데, 거의 모든 상황을 설명하는 시나리오의 지문이 대사자막과 함께 등장합니다. "비장한 음악이 흐른다", "속절없는 새소리가 난다" 등등 평면적인 글자 (시나라오 작가의 product requirements 제품/서비스 요구사항)들을 화면과 소리와 효과로 입체감을 만들어 몰입도를 최상의 품질로 이끌고 가는 감독의 역량에 "아! 맞아, 저게 바로 진정 최고의 프로덕트매니저네" 라는 생각을 했기 때문입니다.

요즘 세상에는 내가 좋아하던 싫어하던 공기반 소프트웨어반으로 살아갑니다. 그리고 그 무대뒤에선 놀라운 능력의 개발자들이 그들의 손가락으로 키보드를 두드려 코드를 만들고 그 코드는 세상을 바꾸어가고 있습니다. 그런데 그 개발자들의 목표를 셋팅하는것은 누구의 역할일까요? 또 그 개발자들은 그들이 지금 개발하고 릴리즈하는것이 세상의 혹은 특정 고객의 어떤 문제를 어떻게 해결하는지를 어떤 방법으로 알게 되는것일까요?

이제부터 그 부분을 알려주는 '프로덕트 매니저'는 어떻게 생각을 하는지에 대한 기본 생각의 틀 3가지와 그것을 구체화하는 방법으로 사용하는 방법의 툴을 나누어 볼까 합니다.

1. 고객의 요구사항 이해 I am all ears

많은 분들이 이미 잘 아시는 영어 표현에 있는 "I am all ears"가 바로 이것입니다. "당신의 이야기를 최고로 집중해서 잘 듣겠습니다." 라는 뜻이죠. 프로덕트매니저가 가져야 할 최고의 소양은 바로 '고객의 요구사항을 명확하게 이해 understand customer requirements' 하는 것입니다. 끝없이 강조해도 모자람이 없는 최고의 덕목입니다.

프로덕트 매니지먼트는 기업 해당조직의 제품/서비스의 비전을 기초로 고객의 요구사항에 부합하는 결과물(제품/서비스)을 타켓 시장에 출하하는 책임을 갖고, 그 결과물이 시장에서 지속적 가치를 갖도록 하는 일입니다.

그리고 그런 일을 하는 사람을 프로덕트 매니저라고 하죠.

I am all ears

제가 지인을 만날때 자주 하는 이야기가 있습니다. "모든 제품/서비스의 성공의 답은 '고객'이 지금 말하고 있는데, 우리는 잘 들을 귀만 있으면 된다." 그 고객이란 좁은 의미로는 현재 사용자일 수도 있겠지만, 잠재적 사용자 일수도 도전해야할 시장일 수도 있습니다. 고객이 지금 요구하고 요청하는 부분은 우리의 제품/서비스를 품질이 확보된 완성형으로 만들어 가기 위한 가장 빠른 지름길이란 사실입니다. 여기서 중요한 점은 고객의 요청에 SI프로젝트를 실행하듯, 가감없이 예스맨으로 응하라는 뜻이 절대로 아닙니다. 그들의 요청을 겸손하게 듣되, 제품/서비스에 어떤 전략적 방법을 사용하여 어떤 모습으로, 어떤 시기에 나타나게 하는지를 판단하는 기술이 필요합니다. 고객의 필요성을 잘 해석하여, 전략적으로 제품/서비스의 기능요구사항으로 만드는 기술 입니다.

초기에 이 결과의 완성도가 높아야 그 후에 전략적 사고를 통해, 우선순위를 제대로 정할 수 있고, 릴리즈플래닝에 태워서, 고객과 시장에 울림을 만들 수 있는 제품/서비스가 됩니다.

이것을 요즘은 사용자/시장조사 User/Market Research라고 많이 부르죠. 방법도 여러가지 입니다. 직접 고객을 찾아가서 회의를 하고, 앙케이트를 할 수도 있고, 경쟁사 제품을 사용해 보기도, 애널리스트들의 리포트를 참고 하기도 합니다.

저는 이곳에서 하나하나의 유저리서치 방법을 소개를 드리지는 않습니다. 대신 모든 조사를 마친후에 그 결과를 제품/서비스화 할 수있는 가장 값진 입력치로 사용하는 '공감지도 Empathy map'에 대한 이야기를 하려고 합니다. 이 공감지도가 잘 완성이 되어야 그 다음에 나오는 두번째 PM의 소양인 '전략적 사고 Strategic Thinking'을 할 수 있기 때문입니다. 아래의 공감지도는 오리지널 공감지도를 약간 엔지니어링 업무에 맞도록 진화시킨 것입니다. 처음엔 각 고객/사용자/이용자를 대상으로 따로 만들지만, 결국 유저/마켓리서치 마지막결과물로는 한장의 감성지도 empathy map로 마무리를 합니다.

openclassrooms.com

감성지도 Empathy map

- Tasks : 사용자는 (제품을 사용하여) 무슨 일을 하려고 하는가? 어떤 질문에 답이 필요한가?

- Feelings: 사용자는 (제품을 사용하며) 과연 어떤 느낌이고, 무엇이 문제인가?

- Influences: 이 사용자의 행동으로 어떤 영향이 있는가?

- Pain points: 사용자가 (제품에서) 해결되기를 바라는 애로점은 무엇인가?

- Overall Goal: 사용자는 (이 제품을 통해서) 결과적으로 무엇을 하기를 원하는가?

제품을 완성하는데 위의 5가지 감성이 모두 중요하지만 제 개인적인 견해로는 프로덕트 매니저PM 로서 가장 중요한 감성 엔티티는 아래의 두가지 “pain points” 와 “overall goal”이라 생각합니다. 제품에 대한 큰 그림을 그릴 수 있을뿐만 아니라, 그들이 실제로 해결되면 구매로 이루어 질 수 있는 차기 제품의 우선순위를 제공하고 있기 때문입니다. 여러분들이 꼭 기억하셔야 할 사항은 PM은 고객이 구매해서 사용할 제품/서비스를 만드는것과 동시에, 여러분 기업의 영업부서가 자신감을 갖고 팔 수 있는 제품을 기획하고 제공해야 한다는 사실입니다.

"아픈 사람에겐 비타민을 파는것 보다 진통제를 파는게 훨씬 쉽다."

애로점, 매일 매일 경험하는 pain points가 해결된다는 것은 다음의 (구매, 구독) 결정을 하는데 매우 큰 동기 powerful motivator가 됩니다. PM은 Overall Goal을 이루기 위해 먼저 현재 사용자와 시장에서 어떤 Pain points가 있고, 우리가 어떤 창의적인 방법으로 그것을 해결할 수 있는지를 제시할 수 있어야 합니다. 물론 그 해결방법은 현재의 요구를 만족시키는 수준이 아닌, 고객의 Overall goal을 만족시키고, 제품의 비전에 지속적인 미래 가치를 부여하는 방향으로 진행되어야 합니다.

2. 전략적 사고 Strategic Thinking

전략적인 사고, 생각의 힘 등은 사실 굉장히 추상적인 어휘입니다. 무엇이 전략적이고, 전략적이지 않은지 역시 결과에 기초한 평가가 대부분인 세상에 살고 있는지도 모릅니다. 결과가 좋으니, 그 당시 무모하다고 생각했던 결정이 전략적이었다라고 할 수도 있고, 아무리 합리적이고 분석적인 결정이었지만, 여러 환경의 변화에 따른 예상과는 다른 결과는 전략적이지 못했다 라고 평가 되는 경우도 많을 겁니다. 하지만, PM이라는 역할을 수행하고 있는 이상 '전략적 사고 Strategic Thinking'을 이야기 하지 않을 수 없습니다.

여러분의 개발자나 디자이너라면, 이미 어느 정도의 전문적이고도 전략적인 사고를 하고 있다고 생각합니다. 새로운 모듈을 디자인 architect/design 할때, 오래된 코드를 리팩토링할때, 새로운 UX를 코드와 페어링 할때 등등 내가 어떤것들을 참조하고, 리뷰해야 하는지 이미 to-do 리스트를 갖고 계실겁니다. 그러나 PM의 역할은 그 터치포인트touch-point가 매우 넓어질 뿐만 아니라 그 세계가 매우 불확실한 부분으로 확장되기에 더욱 더 전략적 사고의 힘이 필요한 일입니다. 엔지니어링의 프로덕트 팀이 보기엔 너무나도 결함없이 잘 만들어지고 성능도 좋은 제품/서비스 라고 해서, 시장에서 성공한다는 보장은 누구도 하기 어렵습니다. 아주 소규모의 스타트업이 아닌 이상, 제품을 기획하는 단계에선, 개발팀, 디자인팀 뿐만 아니라, 세일즈팀, 마케팅팀, 고객지원팀, 파트너 회사, 그리고 가장 중요한 (현, 잠재)고객들과 360도 리뷰과정을 거쳐야 합니다. 그런 상황에서 수많은 복잡함, 헷갈림, 불확실함, 미지의 부분들이 나타납니다. 고려해야할 축이 하나씩 늘어날때 마나 새로운 문제 뿐만이 아니라 축들끼리 생기는 '이해가 상충하는' 부분들은 정말 머리 아프게 되는 부분들입니다.

그러나 이런 부분들을 미리 알고 준비할 수만 있어도, 예를 들어 이런 부분은 엔지니어링과 디자인에서 해결을 하고, 또는 어떤 부분은 고객지원팀에서 대응을 할 것인지에 대해 미리 준비하지 않으면, 고객에게는 "시장과 비즈니스를 이해하지 못한다" 라는 불만을 듣고, 회사 조직내에서는 "시장을 제대로 분석하지 않았고, 미리 소통하지 않았다" 라는 평가가 나올 수 있습니다. 결국에는 고객과 시장에서 외면되는 제품/서비스가 될 가능성이 높습니다. 스타트업 정도의 사이즈나 작은 솔루션인 경우에는 MVP (뜻과 구별에 대해서는 이 글을 참조)를 만들어 진행 해 볼수도 있으나, 기존 고객이 있거나, 플랫폼 같은 경우의 큰 솔루션인 경우엔, 이 제품/서비스의 성패가 기업의 가치를 좌지우지 할 수도 있습니다.

저의 경험엔 이런 전략적 사고를 도와주는 방법엔 아래와 같은 3가지가 있습니다.

A. 데이터 분석과 실험 Data Analysis & Experimentation

유저/마켓 리서치를 통해서 얻은 데이터들은 성능, 사용빈도, 사용과정등 현재 제품/서비스의 상태를 이야기 합니다. 좋은 프로덕트 매니저라면 이 데이터의 숨겨진 면을 파악하고, 설득력있는 스토리를 꺼내야 합니다.

여기에서는 어떤 데이터를 어떻게 분석하는것이 좋은지에 대해선 설명을 피하고자 합니다. 그 부분은 수많은 외부 요인과 타이밍, 중요도에 따라서 다르기 때문입니다. 제가 말씀드리고자 하는 부분은 그 분석을 위해서 직접 SQL을 사용하던, 임원보고용 대시보드를 사용하는것이 좋은가 보다는 이 데이터가 중요한 질문에 답할 수 있는 데이터 인지가 중요합니다. 아직 아니라는 판단이 들면, 그런 데이터를 얻기 위해 1번 스텝인 유저/마켓리서치로의 피드백을 지속적으로 제공하여 데이터의 순수 함량을 늘려갑니다. (참고 서적: Data Story by Nancy Duarte)

B. 균형성과표 BSC (Balanced Scorecard)

매우 오래전 부터 사용된 올드스쿨 클래식인 균형성과표 Balanced Scorecard입니다. 일반적으로는 사이즈가 조금 되는 제조산업에서 사용하는 성과지표이긴 하지만, 현재의 IT산업에서도 전략적 사고와 결정을 도와줄 수 있는 훌륭한 방법이라 생각합니다. 일반적으로 균형성과표를 사용하는 목적은 기업이나 조직에 퍼포먼스를 내기위한 가장 중요한 목표와 그것을 측정하는 방법을 보다 구체화 하기 위함입니다.

저의 베스트프랙티스는 이 4가지 관점을 다음과 같이 생각을 정리하는것입니다.

- Financial Perspective: 어떤 모습의 성장 (사용자수, 매출, 초당 처리 퍼포먼스, 출하후 장해신고수, 버그판정후 픽스까지 걸리는 시간등등)이 이 제품/서비스의 성공이라고 할 수 있는가?

- Internal Business Perspective: 엔지니어링내의 다른팀의 도움이나 다른 부서의 협조가 왜 그리고 얼마나 필요한것인가? (제품 출시전 마케팅, 교육부서, 파트너회사와의 협조, 기업 홈페이지에 개제 스케쥴, 컨퍼런스 참가하여 제품/서비스 프로모션, 상용라이브러리/폰트의 구매등등)

- Customer Perspective: 고객에게는 어떤 새로운 가치를 부여하는가? 그동안 집중적으로 제기 되었던 요구사항 pain points는 해결 되는가?

- Innovation and Learning Perspective: 이 프로덕트는 시장에 어떤 영향력을 미칠것이고 경쟁사와 어떤 차이점 differentiator를 제시하는가?

다시 말씀드리지만, 이러한 툴들은 여러분의 생각의 틀을 제한하는 것이 아닌, 결정에 집중할 수 있도록 할 뿐입니다. 여러번의 경험을 통해서 더욱 더 설득력 있고, 합리적인 결정을 하실 수 있게 도와드릴 뿐, 그 노력은 여러분 자신에 달려있네요. 다음 스텝으로 넘어갑니다.

3. 우선순위 정하기 Prioritization

첫번째 고객사항을 잘 이해했고, 두번째 전략적사고를 마쳤다면 이젠 제품/서비스에 무엇을 어떤 순서로 넣을것인가를 정하는 '우선순위 prioritization'을 정하는 단계입니다.

혹시나 해서 설명을 덧 붙이는데, 이렇게 PM 스스로 우선순위를 '고객의 소리와 전략적 사고'에 의해서 결정한다고 해서, 그것이 최종결정이 되지는 않습니다. 그 이후에 담당 개발, 디자인, 테스팅 담당자들과 이 우선순위에 대해서 프로젝트가 희망하는 기간내에 기대하는 품질로 실현가능하고 릴리즈 할 수 있는지에 따라서 그 우선순위 리스트는 순위변동을 하게 됩니다.

우선순위를 정하는것이 왜 중요한지는 '상생'이기 때문입니다. 제한된 시간과 비용으로 고객에게는 지속가능한 합당한 가치를 제공하고, 고객이 제공한 경제적 비용은 그 제품이 지속적인 진화를 가능하게 합니다.

그럼 과연 현실적인 질문은 어떤 방법으로 우선순위를 정하는가입니다. 사용되는 툴도 회사나 조직에 따라, 혹은 PM의 선호도에 따라서도 다를 수 있는데, 제가 사용하는 방법은 소개해 드립니다. 저는 여러가지 우선순위 점수 모델 prioritaztion scoring model을 제 나름의 철학이 들어간 effort vs. impact '우선순위 매트릭스 prioritization matrix'를 사용하는데 effort는 팀내의 자원resource 이나 비용 cost라고 봐도 되고, impact는 고객의 애로점 customer pain points나 시장에 대한 영향력 influences로 해석해도 됩니다.

effort, cost, resource vs impact, customer pain, influences

사실 이 매트릭스의 오리지널은 GE와 맥킨지가 현재 문제를 부서별로 정리하기 위해 시작했던 "GE-McKinsey Nine Box Matrix"입니다. 대신 위의 우선순위 매트릭스의 X축의 값은 왼쪽이 high, 오른쪽이 low로 설정하였습니다. 설정한 이유는 짙은 빨간색으로 된 우선순위 결과를 오른쪽 상단에 위치 시켜 쉽게 의미를 인식하도록 하는 비주얼라이제이션 효과를 주기 위함입니다. 즉 노란색 테두리의 빨간색 박스는 어떤것들 보다도 우선 순위를 가져야 하는 부분입니다.

사실 PM이 더욱 신경써야 할 부분은 Y축 보다는 X축으로 표시된 effort, resource, cost 입니다. High Effort의 경우는 시간이 오래 걸리고, 개발난이도가 어렵다는 것 이외에도, 현재 조직내의 리소스만으로는 해결이 어려운 경우도 생각해야 하기 때문입니다. 다른 그룹 (혹은 파트너, 아웃소싱)의 리소스를 빌려와야 하는경우는 훨씬 심각하게 처리되어야 합니다. 주로 이런때 저는 80:20 rule을 사용합니다. 20의 effort를 투입하여 80의 효과를 얻을 수 있는 것 부터 먼저 처리를 하고, 그 다음 순위를 정하기도 합니다. 위의 매트릭스가 제품/서비스의 기능위주로만 보일 수도 있습니다만, 꼭 그런것 만은 아닙니다. 그 다음 우선순위로 표시된 밝은 빨간색의 경우는 기존의 내 파이프라인에 있는 기술부채 리스트 technical debt list 와 비교해가면서 우선순위에 넣을지 다음 마일스톤으로 넘길지를 고민합니다. 기술 부채 technical debt가 뭐지? 하는 분들이 있을 수도 있으니 잠깐 설명을 하고 넘어가면, 어떤 기능상의 장해는 아니지만, 발전을 위해서 미흡했던 부분을 해결하는 개발 프로세스의 항목들을 이야기 합니다. 예를 들어 확장성 scalability를 개선하기 위해 백엔드 플랫폼 기술을 바꾼다던지, 코드를 리팩토링을 한다던지, 보안을 강화하고 성능을 개선해야 하는 경우도 있을 수 있구요, 모니터링 시스템과 트랜잭션 로그를 추가 한다던지, 기술사양서를 자세하게 서술한다는 등의 전반적인 품질개선 작업을 이야기 합니다. 고객이나 사용자에게는 보이지 않지만, 제품의 지속적 가치를 보유하려면 꼭 필요한 작업들입니다.

위의 작업들을 통해서 우선순위 리스트가 결정이 되면, functional managers (개발, 디자인, 테스트, DevOps)들과, 전체 공정을 책임지는 스크럼 마스터, 프로젝트 매니저들과 릴리즈 플래닝을 수립하게 됩니다.

4. 글을 마무리 하면서

저는 평범한 개발자였던 적이 있습니다. 특출나지도 않았고, 모자라지도 않은 딱 평균정도의 개발자였다고 생각합니다. 제가 PM이라는 포지션에 관심이 갖게된 배경은 '오지랖'일 수 있습니다. 제품/서비스가 나오기까지 어떻게 이야기가 시작이 되고, 어떤 프로세스로 진행되는지, 그것이 어떻게 세상에 변화를 만드는지가 매력으로 느껴졌기 때문입니다. 개발자로 지냈다면, 모르고 살아도 되었을 부분이 저에게는 꽤나 동기부여가 되었을 뿐만 아니라 성취감도 더욱 강하게 느낄 수 있었기 때문입니다.

혹시라도 프로덕트/프로그램 매니저에 관심이 있는데 지금은 무엇을 어떻게 시작해야 되는지 모르는 분들에게는 늘 "처음부터 잘하는 사람은 아무도 없다"라는 말을 드립니다. 대신 꾸준히 세상과 제품을 보는 눈을 넓여가시고, 생각의 틀안에 여러가지 팩터를 넣어 보는 연습을 하면 좋은 시작이지 않을까 싶어서 굉장히 재미없는 이야기를 길게 써내려 간듯 합니다. 그래도 관심이 있으신 분들을 위해 현재의 개발자의 위치에서, 프로젝트 매니저의 위치에서, SI엔지니어, 디자니어의 위치에서 어떻게 준비를 하면 되는지에 대한 새로운 연재를 시작하려 합니다.

오늘은 여기서 글을 마무리 합니다. 감사합니다.