디자이너로 일하면서 좋은 PM(Product Manager)과 함께 일하는 것만큼 복된 일도 드물다. 아마 반대로 PM들도 좋은 디자이너들을 보면서 비슷한 생각을 하지 않을까 싶다. 그만큼 서로 간의 ‘쿵짝’이 잘 맞아야 프로젝트도 잘 굴러간다는 이야기. 이곳 실리콘밸리에서 일할 정도라면 개개인들의 실력은 좋을 것이고 협업 경험도 나름 풍부하고 프로젝트에 열정도 있고 성격까지 좋은 디자이너 혹은 PM들이 대부분일 것이다. 내 경험상 실제로도 그랬다.
하지만 ‘같이 커피 마실 때는 사람이 다 성격이 좋지’라는 우스갯소리처럼, 아무리 성격 좋고 실력 좋은 사람 둘이 일한들 함께 일하는 프로젝트에서의 시너지가 언제나 비례하라는 법은 없다. 이 글은 디자이너로서 좋은 PM을 가려내는 방법을 논하는 것이 아니라, 디자이너와 PM이 함께 생산성 높은 협업을 할 수 있도록 서로 간의 다른 역할과 기대치를 잘 이해할 수 있도록 내 경험에 의지해서 쓴 글이다.
역할 이해하기
일단 가장 기본적인 룰은 디자이너와 PM은 서로 다른 역할을 수행하면서 각자의 역량을 충분히 레버리지할 수 있어야 한다는 것. 실리콘밸리에서 PM이 하는 일은 흔히 한국에서 같은 의미로 일컫는 ‘상품기획자’ 정도의 역할로 한정 짓지 못한다. 그들이 가진 경험의 깊이와 지식의 폭이 한국에서 내가 경험했었던 상품기획자의 그것을 쉽게 뛰어넘기 때문이다. 마찬가지로 디자이너에게 요구되는 역할 역시 한국에서 경험했던 그것보다는 확장된 영역이다. 그렇기 때문에 디자이너는 PM의 역할을 명확히 인지해야 하며, 그 반대의 경우도 마찬가지이다.
PM의 핵심 역할
- 프로덕트 정보: 신규 출시, 혹은 개선하려는 제품의 기본적인 기능은 물론이고, 제품 히스토리와 이해관계자들의 역할도 꿰뚫었다.
- 시장 정보: 경쟁사의 동향 및 마켓에서 들려오는 여러 주요한 의견들을 취합해서, 현재 시장에서의 포지셔닝을 파악하고 제품이 다음 단계로 나아가야 할 방향을 제시한다.
- 비즈니스 성공의 명확한 목표: 신규 출시, 혹은 개선하려는 제품이 시장에서의 성공하려면 어떤 지표를 모니터링해야 하는지 명확한 성공 매트릭스를 파트너들에게 제시한다.
- 디자인과 개발 지식: 프로젝트 기획 시, 어떤 디자인과 기술이 실제로 적용될지 아직 모르는 상황임에도 어느 수준의 디자인 혹은 기술적인 노력이 최종적으로 필요할 것인지 대략적으로 그림을 그린다. 이는 프로젝트의 전체적인 범위과 타임라인, 런칭 시기를 결정하는 데 중요한 부분이다.
- 우선순위 정의 및 관리: 프로젝트를 통해서 해결하려고 하는 문제점들이나 이슈들 중에서 해당 일정 가운데 꼭 진행해야 할 부분들의 순위를 중요도, 긴급성, 파급력 등을 고려해서 정한다. 그리고 보통 하나의 큰 프로젝트를 길게 끌고 가는 것이 아니라, 2–3개월씩 해결할 수 있는 분량으로 쪼개서 프로젝트들의 우선순위를 관리하며 전체적으로 롱텀 플랜으로 계획한다.
- 일정 관리: 큰 틀에서의 일정은 보수적으로 계획하되, 세부적인 프로세스는 유연하게 관리해서 함께 일하는 디자이너와 개발자들이 전체 일정에 쫓기는 일을 방지할 수 있게 한다.
디자이너의 핵심 역할
- 디자인의 논리: 디자인이 ‘이래야 한다’고 설명할 수 있는 단단한 논리와 근거를 제시한다. 많은 경우 PM은 시장에서 얻은 정보와 본인이 가진 기존 경험으로 디자이너가 제시한 디자인에 제동을 거는 경우가 많다. 이를 염두하지 않은 채 단순히 심미적으로만 접근하면 디자이너는 PM이 원하는 디자인을 ‘그려주는’ 역할밖에 못 하게 된다.
- 사용자 정보: 사용자의 정량적 및 정성적 데이터를 충분히 리서치한다. PM은 제품과 시장의 정보가 탄탄하다. 하지만 사용자 정보는 그와 다르다. 모든 디자인의 출발과 목적지는 사용자이다. 시장에서 발견되는 문제점은 현상이고, 진짜 본질은 사용자의 제품 사용 패턴에서 발견할 수 있다. 문제의 본질을 알아야 디자인의 방향성을 구체적으로 그리기 시작할 수 있다.
- 비즈니스와 기술적인 부분의 지식: PM이 디자인에 여러 의견을 적극적으로 내는 것만큼, 디자이너도 프로젝트의 방향성에 의견을 갖는 것이 중요하다. 진행 중인 프로젝트가 기여하게 될 비즈니스 영역의 특성 및 트렌드, 최근 데이터 등은 알아야 디자인 진행하는 데 많은 도움이 된다.
- 다양한 옵션 준비: 디자인을 제안할 때는 최소한 항상 ‘최선의 것’과 ‘최고의 것’을 준비한다. ‘최선의 것’이라 함은 주어진 환경과 리소스 안에서(일정, 참여하는 개발자 수 등) 완성하고 런칭할 수 있는 최선의 디자인 제안을 말한다. 반면에 ‘최고의 것’은 주어진 환경과 리소스를 극복한다면 디자인이 어디까지 발전될 수 있는지, 지향하는 최고의 사용자 경험을 보여줄 수 있는 디자인 제안을 말한다. 따라서 ‘최고의 것’이 충분히 매력적이고 설득적으로 받아들여진다면 전체적인 프로젝트의 범위와 일정, 프로젝트와 관련된 여러 리소스 등도 변경될 수 있다.
- 일정 관리: 디자인 프로세스 내에서의 세부적인 일정 관리를 하고 협업하는 동료들과 공유한다. 이 부분을 간과하면 PM, 개발자들의 일정까지도 망칠 수 있다. 반대로 상세한 일정을 공유하면 (대부분의 경우) 디자인을 완성하는 데까지 필요한 일정을 충분히 확보할 수 있다.
요구되는 능력
PM과 디자이너가 위에서 언급한 여러 핵심 역할을 수행하기 위해서는 몇 가지 중요한 소프트 스킬(Soft skill)이 필요하다. 먼저 PM에게 요구되는 능력은 다음과 같다.
- 소통(Communication): 좋은 제품을 출시하기 위해서는 PM은 팀의 목표와 우선순위, 로드맵을 함께 일하는 파트너와 그들이 속한 조직에게 끊임없이 전달할 필요가 있다. 디자이너나 개발자는 (상대적으로) 명료하지 않은 의사전달이 있더라도 이해받는 부분이 있지만(어쨌든 이들의 업무에 필수적인 부분은 아니므로), 의사 전달이 명료하지 않은 PM은 오래가지 못할 것이다. PM은 함께 일하는 파트너들뿐 아니라 리더십, 그리고 외부 미디어에 해당 제품을 알려야 한다. 그들이 디자이너나 개발자보다 우위에 있어서가 아니라, 그들이 보통 말을 더 잘해야 하는 역할을 담당하기 때문이다. 효과적이고 설득력 있는 의사 전달 능력은 PM의 기본적인 필수 능력이다.
- 문제점 분석(Problem analysis from market): 제품이 시장에서 좀 더 좋은 퍼포먼스를 낼 수 있도록, 현재 제품이 시장에서 가진 문제점, 이슈들을 빠르게 파악하고 분석하여 더 나은 다음 버전으로 개선할 수 있도록 준비할 수 있는 능력이 중요하다. 문제점은 광범위하게 분석하기보다는 작은 단위로 쪼개어 단계별로 개선할 수 있도록 문제점 분석을 준비하는 것이 프로젝트를 수행하는 입장에서도 부담이 적고, 결과물이 가져오는 시장에서의 임팩트를 모니터링하는 입장에서도 용이하다.
- 비전(Vision): PM이 하는 역할 중의 하나는 제품의 로드맵을 통해서 미래의 비전을 보여주는 것이다. 지금 진행하는 프로젝트가 당장의 작은 변화만을 위한 것이 아니라, 전체적으로 1년, 2년 후의 큰 그림 안에서 지금의 프로젝트가 어떤 역할을 하는지 구성원들에게 설명할 수 있다면 디자이너와 개발자들도 좀 더 큰 스케일로 프로젝트를 보면서 접근할 수 있다.
- 실행(Execution): 성공적인 PM과 그렇지 못한 PM 간의 차이점은 결국은 실행 능력에 달려있다. 아무리 좋은 제품 기획이라도 실행력이 뒷받침되지 않으면 허울 좋은 기획으로 끝나버리고 만다. 제품 기획과 아이디어, 디자인, 그리고 개발의 모든 필요한 단계들이 실제 실행 플랜(execution plan) 안에서 톱니바퀴 맞물리듯이 정교하게 짜여 있지 못하면 일정이 늘어져서 원하는 타이밍에 제품을 출시할 수가 없으며, 이는 비즈니스에 크고 작은 타격을 입힐 수도 있다.
다음으로는 디자이너에게 요구되는 핵심 능력을 살펴보자. 디자이너는 기본적으로 디자인을 잘하는 것이 중요하지만, 요즘같이 협업이 중요시되는 시대에는 디자인 능력만으로는 조직 내에서 역할을 다하기에 부족하다.
- 소통(Communication): 디자이너에게도 마찬가지로 소통의 능력이 어느 때보다 중요하다. 앞서 언급한 디자인의 논리를 명확하게 전달하고 함께 일하는 이해관계자를 설득하기 위해서는 논리 자체의 근거도 명확해야 하지만, 메시지를 전달하는 방식, 태도, 사용하는 미디엄, 표현 등도 굉장히 중요하다. 다행스럽게도 디자이너에게 전체 프로젝트의 브리핑을 맡긴다거나 하는 일은 거의 드물다. 오히려 디자이너의 결과물인 디자인의 프레젠테이션마저 PM이 하게 될 경우는 이따금 있다. 때문에 들러리가 아닌 디자이너로 프로젝트에 충분히 기여하고 싶다면, 디자이너 본인의 목소리를 프로젝트 과정 중에 꾸준히 효과적으로 내야 한다.
- 문제점 정의(Problem definition from users): PM이 시장에서 제품이 어려움을 겪는 부분을 파악하고 분석하는 데 중점을 둔다면, 디자이너는 이를 바탕으로 그 문제점이 사용자의 어떤 행동 패턴에서 발생했는지, 그리고 그 행동 패턴은 왜 생겨났는지 분석을 할 수 있어야 한다. 그래야 디자인 프로젝트를 진행할 수 있는 작은 단위인 사용자 이야기를 형성할 수 있고, 디자인 진행을 손쉽게 핸들링 할 수 있게 된다. 하나의 프로젝트에 여러 문제점이 나열되는 경우가 대부분인데, 그런 경우에도 하나의 큰 문제점 안에 세부적인 문제점들로 나누어서 별도로 진행하되, 큰 그림으로 묶어서 볼 줄 아는 시각도 필요하다.
- 시각화(Visualization): 디자이너의 가장 큰 무기는 바로 아이디어를 손쉽게 시각화할 수 있다는 점이다. 프로젝트 초반에 시각화되는 아이디어의 퀄리티 및 해결 방법에 따라서 전체 프로젝트의 방향성 및 성공 여부의 큰 틀이 결정되기도 한다. 가령 프로젝트의 솔루션으로 좋은 아이디어를 제시했더라도 시각화되는 미디엄이 그저 그런 아이디어 정도에 머무른다면, 실제로 좋은 아이디어였음에도 ‘흠… 이 아이디어가 생각보다는 좋지 못한 것이었네’라는 인상을 받으며 팀 전체적으로도 그 아이디어의 진면목을 보지 못하게 될 수도 있다. 반면에 그저 그런 아이디어로 시작했더라도 시각화가 잘 된 미디엄을 보게 된다면 더 좋은 아이디어들이 그 위에 덧붙여져서 결국에는 완성도 높은 결과물로 발전해가기도 한다. PM이 비전을 보여주는 역할이라면 디자이너는 그 비전을 훌륭한 미디엄으로 시각화해서 눈에 보이게끔 해 구성원들이 그 비전에 적극적으로 동참하게 하는 것이 가장 중요한 역할이다.
- 테스트 및 제품 향상(Test & Improve): 불과 10년 전? 5년 전만 해도 내가 개발자들과 이렇게 친하게 지낼 줄 몰랐다. 예전에는 디자인을 완성하고 개발팀에 넘겨주면 제품이 완성되는 순차적인(linear) 프로세스로 일이 진행되었기 때문에 그들과 마주할 일이 많이 없었다. 하지만 요즘은 디자인과 개발이 거의 동시에(parallel) 이루어져서 제품 제작과 관련한 모든 대화를 거의 매일 하기에 좀 더 관계가 가까워진 듯하다. 그만큼 제품의 베타 테스트와 업그레이드가 지속적으로 빈번하게 일어나기에 디자이너로서도 디자인 파일만 만들어놓고 끝내는 것이 아니라, 해당 기능이 점차적으로 계속 발전하고 완성된 사용자 경험을 제공할 수 있도록 끊임없이 관심을 갖고 신경 써야 한다.
조심해야 할 실수
이렇게 PM과 디자이너 간에 다른 역할과 요구되는 능력들을 나열해보면 딱히 서로 부딪힐 것이 없어 보이는데, 실제 일하는 환경에서는 은근히 적잖게 갈등이 일어난다. 아무리 뛰어난 능력을 가진 소유자들이라 하더라도 결국 일은 사람들 간의 관계에서 이루어지기 때문에 서로 간의 이해와 배려가 필요한 지점들이 있다. 그중 대표적으로 가장 많이 범하는 실수를 역할별로 한 가지씩만 언급하고자 한다.
PM: 오지랖 금지
많은 경우 PM들이 프로젝트 시작 전에 준비하는 PRD(Product Requirement Document)를 보면, 이미 디자인 솔루션의 대략적인 설계 모습까지 포함하는 것을 볼 수 있다. 늘 그것들을 볼 때마다 나는 우스갯소리로 ‘이봐, 우리 아직 디자인 시작도 안 했는데?’라고 이야기하곤 한다.
제품과 시장의 전문가인 PM은 시장에서의 문제점들을 분석할 때 이미 머릿속에 ‘이렇게 하면 좋겠어’라는 아이디어로 가득하며, 그 아이디어를 끝내주게 실현해줄 디자이너를 본능적으로 찾게 된다. 그렇기 때문에 프로젝트 시작 후에 진행된 디자인 리뷰를 디자이너와 PM이 같이 하면, ‘어…? 이거 내가 의뢰했던 디자인이 아니잖아요.’라고 하는 PM들을 어렵지 않게 만날 수 있다.
PM은 디자이너와 일할 때 본인이 클라이언트가 아니고 함께 일하는 파트너임을 인식해야 한다. 디자이너는 PM이 기획한 프로젝트에 함께 참여해서 아웃풋을 만들어내는 사람이지, PM의 의도대로 그림을 그려주는 사람은 아니다. PRD에서 ‘예상되는 디자인 솔루션’은 이제 그만 봤으면 좋겠다.
디자이너: 공부 좀 합시다
반면에 디자이너가 PM과의 관계에서 가장 저지르기 쉬운 실수는 디자인하는 제품을 제대로 공부하지 않는 것이다. PM은 디자이너에게 쓸데없는 디자인과 관련된 오지랖을 많이 부리는 것이 문제라면, 디자이너는 그 반대로 PM에게 할 말을 안 한다. 아니, 무슨 말을 해야 할지도 모르고 그저 수동적으로 그림 그려주는 역할에 만족하는 경우가 많다. 역할론적인 관점에서 PM에 의해 길들고 진화된 디자이너의 모습일지도 모르겠다는 생각이 문득 든다.
‘그거 PM 역할 아닌가요?’라고 되물을 수도 있지만, 제대로 된 제품 디자인은 제대로 된 제품의 이해에서부터 시작된다고 하면 너무 꼰대 같은 소리일까. 제품의 기본적인 정보도 알고, 시장 데이터도 파악하고, 제품의 역사에도 관심을 갖는 것이 디자이너 스스로의 역할을 단단하게 세우는 방법이다.
PM이 디자인에 적극적으로 의견을 피력하듯이, 디자이너들도 (그만큼은 못 하겠지만) 프로젝트의 전반적인 내용, 범위, 제품의 기능 등에 의견을 갖고 함께 나누는 것이 중요하다. 입 다물고 PRD에 적혀있는 대로 아름다운 제품을 만들어낸다고 해서 좋은 디자이너가 아니다.
잘 지내봅시다
한 때 링크드인에 본인을 풀스택(full-stack) 디자이너, 풀스택 개발자, 풀스택 PM이라고 소개하는 것이 유행인 때가 있었다. 요약하자면 만능 디자이너, 만능 개발자, 만능 PM 같은 의미인데, 들여다보면 그 의미가 굉장히 협소한 느낌이 든다. 그 용어를 사용할 수 있는 나름의 자격요건이라 하면 어떤 소프트웨어들을 사용할 수 있는지, 어떤 프로그래밍 언어를 사용할 수 있는지를 나타내는 것이었다. 한국에서 말하는 ‘고 스펙’이라는 말의 영어 버전인 듯하다.
하지만 요즘은 이 용어를 예전만큼 자주 접하지 못한다. 아마도 풀스택이라고 본인을 소개한 사람들이 시간이 지나고 조직 내에서 그다지 크게 영향력을 발휘하지 못한 게 아닌가 싶기도 하고, 아니면 회사 내에서 풀스택 고용자를 뽑는 것보다 더 중요한 가치를 발견했는지도 모른다.
여하튼 협업이 점점 더 중요한 성공의 열쇠로 받아들여지면서 디자이너와 잘 협업하는 PM, PM과 잘 협업하는 디자이너들이 더욱 주목을 받기 시작했다. 앞으로도 이러한 경향은 실무에서는 당분간 지속될 것으로 보인다.
원문: seh의 브런치
