프로덕트 매니저, 관계학개론
디자이너와 관계 편
미어캣 PM: "자, 어느 정도 기획은 되었고, 그럼 한번 디자이너님에게 물어보러 갈까?"
(은근히 부푼 마음을 가지고 디자이너팀으로 향한다)
미어캣 PM: "oo님, 혹시 이번 클라이언트가 위와 같은 내용으로 기획안을 요청하여 제가 기획을 했는데 혹시 디자인 관련해서 잠시 이야기 가능할까?"
( 약 1분간의 적막이 흐른 후)
디자이너: "저기 PM님 이렇게 말씀해주시면 제가 이해하기가 어려워서 디자이너가 이해하기 쉽게 문서화로 이야기가 가능할까요?"
( 속으로 '아차' 싶었지만, 당황함을 감추기 위해 웃음으로 마무리한다)
미어캣 PM: 아... 네 ㅎㅎ 그러면 제가 빠르게 수정해서 다시 요청드리겠습니다"
순간 나의 업무 방식에 자괴감이 밀려왔다...위 일화는 내가 실제 겪었던 일을 조금 각색하여 표현하였다.
실제로 PM으로서 기획을 하고 디자이너팀과 일을 하다 보면 종종 겪었던 문제였다.
어쩌면, PM이 사용하는 업무적 언어와 디자이너가 사용하는 업무적 언어 방법이 서로 다르고 PM은 이 업무적 언어를 디자이너 관점에서 쉽게 이해할 수 있도록 이끌어가야 할 역할이 있다.
큰 포부와 자신감을 가지고 디자이너팀에게 다가가는 주니어 PM분들이 이것만은 꼭 알고 디자이너와 소통하려고 하면 '센스 있는' PM으로 각인될 것이다.
때론 회의보다 정리화된 문서로 소통이 빠를 때가 있다
아무래도 나는 '회의 성애자'인 PM이었다. 무슨 문제가 봉착하거나 아니면 새로운 과업을 진행할 때마다 '회의'를 열었다. 물론, 전사 멤버들의 의견과 인사이트 수집에는 도움이 되었으나, 일의 속도면과 멤버들이 느끼는 부담감은 시간이 갈수록 클 수밖에 없었다. 사실, 회의를 진행하여 해결되는 문제들도 있었지만, 결국 PM이 방향성과 가이드라인을 내려줘야 움직이는 업무들이 더 많았다는 게 현실이었다.
그럴 때마다 나는 집단지성의 힘을 맹목적으로 맹신하여 회의를 신봉하였는지도 모른다.
하지만, 가장 중요한 것은 디자이너는 직접 클라이언트(고객사)를 만나는 접점이 없다는 것이다.
방대한 사업의 방향성과 사업의 색깔 그리고 추구해야 하는 담론적인 것을 PM이 세세하게 설명하거나 기록화하지 않으면 디자이너들은 PM의 언어와 의도를 전혀 이해하지 못한다는 것이다.
그렇다면, 디자이너에게 어떻게 문서로 소통을 하란 말인가?라고 궁금할 수 있을 것이다.
회의가 끝난 후 디자이너의 속 마음: 아니 무슨, 도대체 뭘 그려달라는 거야?사실, 나는 PPT로 전체적인 구성안과 틀을 정하고 들어갈 내용을 코멘트만 해주는 수준으로 지금 디자이너팀과 소통을 진행하고 있다. PM이 세세한 디자인까지 적용해버리게 되면 디자이너들의 사고는 좁아질 수밖에 없고 결국 PM이 AtoZ까지 디자인을 책임져야 한다.
현업에 있는 디자이너팀들도 그렇게까지 일을 하는 것을 원치 않는다.
PM이 단순히 디자이너에게 말로 전달하는 방향성과 우선 어디든 기획안으로 기록(PPT, 워드)하는 방향성은 디자이너들이 조금 더 프로덕트에 대해 고민해보고 디자인적으로 확장할 수 있는 기회를 전달할 수 있다.
디자인 레퍼런스를 정리해서 전달하되, 디자이너가 되려고 하지 마라
PM이 디자이너와 소통을 하면서 가장 많이 하게 되는 실수 중 하나가 세세하게 디자인을 해서 디자이너에게 전달하는 것이다. 물론, 이런 방식이 일의 속도면에서는 효율적이라고 할 수 있지만, 장기적으로 보았을 때는 PM에게도 디자이너에게도 전혀 도움이 되지 않는 업무의 방법이다.
회사라는 것은 다양한 이해관계자와 포지션이 얽혀서 공동의 목표를 위해 산출물을 만들어가는 곳이다.
여러분이 프리랜 서거나 1인 창업가라면 기획에서부터 디자인까지 만능에 가까워야 할 것이지만, 회사에서는 엄연하게 지켜줘야 할 포지션의 선들이 암묵적으로 자리 잡고 있다.
PM이 세세한 디자인 포맷까지 설정해버리게 되면 디자이너는 그냥 덧칠만 하는 수준이 될 것이고 본질적으로 서비스가 디자인적으로 차별성을 가질 수 있는지에 대한 적극성을 애초부터 제거해버리게 되는 것이다.
그리고 솔직히 말하면 PM이 구상하는 디자인적 아이디어와 전문적인 교육과 경험이 있는 디자이너가 만들어 내는 디자인적 아이디어와 산출물의 간극은 정말 크다는 것을 나 또한 현업에서 느끼고 있는 중이다.
PM으로서 한 가지 꼭 기억할 것은 당신이 디자이너 출신 PM이 아니라면, 당신의 디자이너나 디자이너팀을 믿고 업무를 전달하는 습관을 가지면서 피드백을 전달해야 한다는 것이다.
그렇지 않으면, 언제 가는 디자인 때문에 불필요한 야근의 연속으로 번아웃을 경험하게 될 것이다.
약은 약사에게 디자인은 디자이너에게^^
PM이 디자이너가 되려는 순간, 파국을 맞이할 수도 있습니다....디자인 업무에 대한 자세하고 정확한 테스트 설정과 데드라인 설정
주니어 PM: "디자이너님 이거 빨리 처리해야 하는 건이니깐 빠르게 좀 진행해주세요"
디자이너: "저기 죄송한데, 언제까지 어느 정도로 마무리를 해야 하는지 말씀을..."
많은 주니어 PM분들이 간혹 실수하는 부분이 업무 테스트를 너무 포괄적으로 지시하고 내려주었을 때가 많다는 것이다. 사실 나 또한 이 잘못된 습관을 최근까지 고치는데 많은 노력이 필요하였다.
PM에게는 데드라인과 테스트 진행 속도에 대한 것들이 머릿속에 있지만 디자이너들에게는 없다.
그래서 PM이 수치적으로 명확하게 전달해야 하는 부분이 꼭 필요하다
미어캣 PM: "디자이너님 앱 내의 공지 이벤트 부분의 디자인이 이번 주 금요일 오전 10시 전까지는 나와야 하는데, 가능하실까요?"
또한, 주니어 PM들이 가장 많이 실수하는 말 중 하나가 '이 기능 부분을 디자인해주세요'라고 포괄적으로 이야기하는 것이다. 물론, 결국에 최종 단계에는 완성된 디자인이 나와야 하는다는 것을 디자이너도 충분히 잘 알 고 있지만 세세한 테스크를 정하고 마감 기일을 정해주지 않는다면 일의 병목현상이 생기기 시작한다.
디자이너는 PM의 지시 업무뿐만 아니라 다양한 부서에서 요청하는 디자인 업무를 진행할 때가 많기 때문이다.
그래서 PM에게 시간관리가 중요한 만큼 디자이너들에게도 더욱 중요하다는 사실을 잊어서는 안 될 것이다.
미어캣 PM: "디자이 님 앱 내의 공지 이벤트 부분에서 팝업으로 띄울 대표 썸네일 부분만 이번 주 화요일 오후 5시 전까지 테스트 완성해주시면 감사할 것 같아요. 아무래도 이번 주 금요일이 대규모 이벤트 배포 날이니 조금 힘드시더라도 잘 부탁드립니다. 그리고 감사합니다^^
디자이너: 세부 테스크와 데드라인을 알았으니 계획을 짜 볼까?!PM, 개발과 상호관계를 생각하면서 디자이너에게 기획안을 전달하자
IT업계의 PM이라면 디자이너만 생각해서도 안된다. 결국 디자이너가 그린 그림이 개발단에서 구현되는 것인데, 여기서 많은 문제들이 봉착하게 된다. PM이 서비스에 대한 충분한 이해가 없이 기획하여 디자이너에게 업무 테스크를 내리게 되면 전혀 맞지 않는 서비스 그림이 도출될 때가 꽤 많기 때문이다.
개발자: PM이 그려주신 디자인 피그마 파일에서 봤는데, 저희 정렬은 백엔드 단에서 쿼리를 다시 짜야하고 API를 만들어야 하는 부분 알고 계신 것이죠? 당장 구현은 어려워요
미어캣 PM: 네?! 아.... 그렇군요...
PM은 눈에 힘을 빡주고 업무 테스크 구성과 지시를 해야 하는 중요한 포지션이다나 또한, 초기에 업무를 진행하면서 많이 실수했던 부분이다. 결국은 모든 일에든 유한 시간적 한계성이 있고 조직 내의 개발 한계성도 있는데, 그저 PM이 이 기능이 구현됐으면 좋겠다는 뇌피셜로 그림을 그려서는 안 된다는 것이다. 꼭 필요한 기능과 도입되어야 할 부분은 먼저 개발자와 논의한 부 디자이너에게 전달해야
디자이너가 쓸데없는 기능을 그리는 수고로움을 덜 수 있는 것이다.
그래서 나는 꼭 신규 디자인과 기능을 도입할 때에는 개발자에게 먼저 물어본다.
그리고 구현 단계의 시간이 적절하게 되면 기획을 하여 디자이너에게 업무 테스크를 넘긴다.
이렇게 되면 비효율적인 업무방식이 많이 줄게 되는 것이다.
IT업계의 PM으로서는 기획과 그림만 그리는 것이 아닌 '구현'의 메커니즘을 잊어서는 안 된다.
결국, 모든 단계는 서비스의 작동을 향하고 있기 때문이다.
그러므로, PM과 디자이너의 소통은 개발자 소통만큼 정말 중요하다고 볼 수 있다.
미어캣 PM: 디자이너님 한주 잘 보내셨나요? 그럼 업무 관련해서 이야기를 ㅎㅎㅎㅎ