brunch

You can make anything
by writing

C.S.Lewis

by 도그냥 May 12. 2021

프로덕트 디자이너의 성장을 돕는 PO

성장할 수 있는 여지를 주고, 우린 다른 중요한 일을 하자

UI 설계에 어디까지 참여하세요?

  프로덕트팀은 한 마디로 크로스펑셔널팀이다. '기능'을 만드는 것이 목표가 아니라, '문제를 해결하는 목적'을 위한 모든 일을 하는 조직. 그래서 사실 자신의 영역을 한정 짓지 않고 일하는 것은 중요하다. 하지만 그렇다고 해서 각자의 전문성에 대해서 인정을 하지 말라는 뜻은 아니다.


 그런데 서비스 기획자 시절부터 주변의 많은 기획자들이 디자이너와 기획의 영역을 구분하지 못하는 것을 많이 봐왔다. 서비스 기획은 UX, 비즈니스, IT적 구현 사이의 균형감각을 유지해야 현실 지향적인 프로덕트를 만들어 나갈 수 있는데, 개인의 역량에 따라서 한 쪽에만 너무 집착하게 되기도 한다. 개발과 소통이 되지 않아서 우리의 프로덕트의 구조와 데이터와 정책에 대해서 잘 모른다면 이런 부분은 개발자에게 위임해버리고 싶어지고.. 비즈니스에 대해서 넓은 시각을 가지거나 회사가 프로덕트 방향성에 일관성을 줄 비전을 명확하게 제시하지 못하면 단지 지금 쳐다보는 화면의 단타성 목표에만 관심을 기울이게 되기 쉽다. 이럴 때 기획자는 자신이 할 수 있는 모든 솔루션을 UI나 UX에서만 찾게 된다.


 문제는 여기에서 프로덕트 디자이너와 업무적 영역이 충돌하기 시작한다는 점이다. PO의 주장대로만 UI를 만들어 나간다면 우리의 프로덕트 디자이너는 어디에서 성장해야할까? 요즘 디자이너는 수행자의 역할에 머물기를 희망하지 않는다. 디자이너들은 10여년 가까이 디자인에 대해서 공부하고 요즘은 UX과 인터랙션, 인지과학 등에 대해서 공부한다. 요즘은 데이터를 기반으로 한 UI 전략에 대한 공부도 많이 한다. 아무리 우리가 이 부분을 노력한다고 한들, 체득한 UI에 대한 제안 능력은 디자이너를 이길 수 없다. 아니 엄밀히 말하면 이겨 먹으려 하면 안된다.


프로덕트팀은 모두를 성장시키는 미셔너리팀이어야 한다.

 크로스펑셔널한 롤에 대한 이야기를 하는 것은 롤이 사일로를 일으킬 때다. 내가 너무 내가 한정한 역할만을 해서 더 좋은 서비스를 만드는 것에 의지가 없는 것은 문제다. 종종 그런 디자이너를 만난 적은 분명히 있었다. 그냥 내가 그린 PPT의 SB가 포토샵으로 재생산되어 돌아온 경우를 본 기억이 분명 있다. 하지만 지금의 욕심있는 디자이너들은 스스로를 더이상 '웹디자이너'라고 생각하지 않는다. 우리가 스스로를 '웹기획자'라고 더이상 부르지 않는 것과 마찬가지다. 대학시절부터 10년 넘게 디자인을 배워온 그들이 배운 디자인이 경영학과 졸업한 나보다 나은 것은 명백한 팩트다.

 

 프로덕트 오너는 프로덕트팀을 운영한다. 그리고 서비스 기획자 시절처럼 프로젝트가 아니라 프로덕트의 과거와 미래를 훨씬 넓게 보고,  전략과 비전에 대해서 연관성을 고민하고, 이에 대해서 임팩트 있는 문제 해결을 한번에 하나씩 하기 위해서 로드맵을 자르고 자른다. 이건 툴이나 기술이 아니라 '고민의 시간'이 만드는 일이다. 서비스 기획자로서 UI의 모든 케이스를 고민하며 하나하나 예외처리, 분기처리를 그림으로 그리던시간이 SB의 퀄리티를 올려줬다면, 이런 부분은 그림그리는 수고스러움은 덜어내고 어떠한 유형의 케이스들이 있다는 것만 기록한다. 케이스에 대한 UI 분기처리는 나보다 디자인 전문가인 디자이너에게 이 문제를 더 고민해서 해결할 수 있는 성장의 여지를 주려고 노력한다. 디자이너에게도 나에게도 논쟁과 챌린지의 시간이 되어야 우리는 성장한다. 디자이너는 수행자가 되려고 '프로덕트 디자이너'가 되기 위해 공부해온 것이 아니니까.


 왜 직접 UI로 된 솔루션을 제시하지 않을까?  그 부분에 대해서 고민할 시간을 다른 고민에 사용하고 프로덕트팀의 진짜 찐 디자인 전문가에게 위임해야한다는 이야기다. 크로스펑셔널 조직의 핵심은 각자의 전문성을 최대한 활용할 수 있도록 해줘야 한다는 점이다. 그리고 우리의 협업자들도 스스로 성장하는 느낌이 있어야 오래도록 함께 팀으로 일하고 싶어진다. PO가 정말 미니 CEO라면, 팀원의 성장을 돕는 것은 중요한 업무다.


 PO가 프로덕트에 대한 구현의 고민은 물론 필요하다. 자신의 UI에 대한 관심을 프로덕트 디자이너에게 덜어주고, 개발언어에 대한 관심을 개발자에게 조금 덜어주고, 대신에 만들어지는 프로덕트의 목적을 위해서 협업을 통해서 만들어지는 데이터와 로직의 설계, UI가 목적을 제대로 지향하는지를 계속 논쟁하고 검증하고 이해하고 공부해야하는 것 같다.  그래서 매트릭이란게 있는 거다. 이게 크로스펑셔널팀에서의 일하는 방법이다. 그리고 그런 협업이 모두를 성장 시켜야 한다.


종종 우리는 PO라 말하고, 폭포수방법론을 꿈꾼다.

 내가 폭포수 방법론의 서비스기획자와 프로덕트팀 형태의 프로덕트 오너를 둘 다 겪으면서 느낀 가장 큰 차이는 '고민을 언제 하고 누구와 쉐어할 것인가'다. 서비스 기획자로서의 일을 할 때는 협업자들에게 업무가 떨어지기 전에 모든 것을 판단하고 파악하고 정리해서 협업자들에게 전달하는 역할이었다. 기획자 개인의 역량이 너무나도 중요했다. 기획자가 잘하면 모든 것은 완벽했다. 반면에 기획자가 부족하면 모두 엉망진창이 되었었다.

 프로덕트팀의 핵심은 '모두를 전문가로서 인정하는 것'이다. 솔직히 아직 우리의 프로덕트 디자이너가 UX의 전문가가 아닌 것처럼 보인다면, 그 사람이 전문가로 활동할 수 있도록 우리의 고객에 대해서 자세히 알려주는 것이 PO가 해야할 역할이다. 그렇다고 손가락으로 방향만 가리키는 사람은 아니지만..

 여튼 이 알듯말듯한 업무적 분위기의 차이가 반복되면, 나는 최고의 전문가집단과 일하는 행운아가 된다. 그러니까 부디 함께 일하는 나의 디자이너가 전문가가 될 수 있도록 여지를 주자. 그럴 때 모두가 발전할 수 있게 된다.

 

 PO의 멋있는 보이는 부분만 취하려 들고, 폭포수 방법론의 기획문서가 가지는 UI설계의 권력을 탐하지 말자.

 항상 말하지만, 내 모든 글은 나에게 하는 깨달음의 말이다.


 

매거진의 이전글 디스크립션 또는 스펙 정의의 스킬
브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari