디자이너가 협업하고 싶은 PM
함께 일하는 꿀벌 PM님에게 이 주접을 바칩니다.
1년 전, 저도 PM이라는 직무에 꿈을 갖고 도전했던 적이 있었답니다. (지금은 살짝 흑역사예요)
디자인을 깊게 파고드는 것도 즐거웠지만, 서비스를 기획하는 과정도 참 재미있었거든요.
진짜 PM이 한 번 되어보려고, 회사 내 작은 PM세션을 들으면서 비즈니스 문해력과 PM이 되기 위한 기초소양도 조금 쌓아가며 기회를 노렸습니다.
이후 회사의 조직 체계가 기능 중심에서 목적 중심의 스쿼드 체제를 도입하게 되면서 자연스럽게 PM 실무를 맛볼 수 있었어요.
네. 처음 맛본 실무는 마라맛이었어요.
꿈과 환상의 나라로 그려간 서비스 아이디어는 당위가 부족한 Why, 비논리적인 What, 그리고 비현실적인 How의 벽을 만났습니다.
제 강점은 아이디어를 빠르게 쏟아내는 것인데, 기획의 세계는 명분이 있는 목적과 논리적인 가설 위에 세워진 목표가 핵심인 세계였어요.
산발적으로 떠오르는 아이디어는 목적을 달성하기 위한 Solution Brainstorming에 유용하지, 뾰족하게 하나의 목적을 세우는 단계에서는 오히려 기획서를 산만하게 만드는 방해 요소였습니다.
실무가 마라샹궈라면 나는 맵찔이었다...시간은 지나고, 기획은 제자리걸음이고... 결국 스쿼드를 불안한 일정에 빠뜨린 책임을 지게 되었습니다. PM 역할을 내려놓고 디자이너로서 할 수 있는 리서치에 집중하는 업무로 돌아갔어요. 과장 좀 보태면 이때 울어서 생긴 부기가 아직도 안 빠진 것 같아요.
이런 저를 위해 구원투수로 등장하신 분이 바로 꿀벌 PM님입니다.
'꿀벌'이란 닉네임에서 느껴지듯이 정말 꿀벌처럼 부지런하게 일하시는 분이시고, 그분의 업무 매니징 덕분에 우리 스쿼드는 불안한 일정에 빠진 팀에서 '속도감 있게, 시험적으로, 애자일 하게' 서비스를 운영하는 스타트업다운 팀이 되었습니다.
한 주 단위로 빠르게 결과물을 뽑고 데이터를 쌓으면서 다음 스프린트의 액션아이템에 대한 확신을 누적해 가는 과정에서 팀의 의욕도 쭉 차오르고, 팀원들 간의 유대도 돈독해졌어요.
꿀벌 PM님의 캐릭터에 좀 더 과몰입해볼게요. 꿀벌 PM님의 특징은 크게 두 가지예요.
1. 침을 가지고 있다
2. 꿀을 나른다
꿀벌 PM님의 침, 그것은 가능한 한 모든 것을 가시화하는 능력이라고 정리할 수 있겠습니다.
말주변 없이 고통을 호소하는 디자이너의 말을 해석하는 초능력을 발휘하고 있다디자이너의 시안에서 KPI를 달성하기 위한 디자이너의 의도를 분명하게 짚고, 이를 개발자의 코드에 반드시 반영되게 정확히 소통했어요. 사실 이 부분은 디자이너의 역할인데, 제가 정말 못하던 것이었죠. 꿀벌 PM님의 소통에서 어떻게 정보를 전달해야 하는지 이때 많이 배울 수 있었습니다.
팀의 일정이 모호해지는 순간이 오면, 꿀벌 PM님의 침이 여지없이 휘둘러졌어요.
모호한 일정의 원인을 드릴다운(Drill down)해서 무엇이 목표를 달성하는 데 방해가 되는지 찾아내기 때문에 막연히 작업 진행이 어렵다고 소통하는 것은 꿀벌 PM님 앞에서 통하지 않았어요. 작업 진행이 어려운 원인이 무엇이며 그 원인이 목표 달성과 어떤 인과관계가 있는지 파헤치고, 해결했습니다. 말 그대로 '일이 되게 하기 위해 할 수 있는 모든 것'을 하셨어요.
꿀벌 PM님의 또 다른 무기인 '꿀 나르기'도 소개하자면, 이 PM님은 팀에 긍정적인 에너지를 채우고 의욕을 끌어올리는 스킬이 어마어마하셨어요. 이 점이 꿀벌 PM님을 로봇이 아니라 꿀벌처럼 보이게 하는 포인트라고 생각해요.
칭찬에 좋아 죽고 있는 디자이너누가 언제까지, 무엇을 하는가에만 신경 써도 해야 할 일이 차고 넘칠 텐데 늘 스쿼드의 디자이너와 개발자가 일에서 동기부여를 얻을 수 있도록 정성적인 부분까지 체크하고 커버해 주셨습니다.
일이 마무리되면 항상 구체적인 이유로 감사함을 전달해 주시는 점도 좋았고요, 애자일 하게 서비스를 돌리면서 나온 데이터를 팀에 투명하게 공유하면서 좋은 지표가 나올 땐 스쿼드 전체의 공으로 돌리고 지표가 나쁠 땐, 그럼에도 우리가 얻은 인사이트를 공유하면서 넥스트 스텝을 제시해 주셨어요.
제가 잠깐 스쿼드의 PM역할을 했었을 때는 '개발팀은 중간 공유나 앞으로의 계획에 대해선 관심 없겠지?'라고 지레짐작하면서 이런 공유를 할 생각도 안 했었는데요, 오히려 개발팀은 이런 공유에 긍정적인 피드백을 돌려주셨어요.
그동안 서비스에서 소외되어 개발만 하는 사람들처럼 여겨지는 것 같았는데, 팀으로서 일하고 있는 것 같아 좋다는 피드백을 들려주셨습니다. 이 때도 제 편견이 한 번 깨지면서 꿀벌 PM님께 많이 배웠던 순간이었어요.
마지막으로, 디자이너로서 꿀벌 PM님에게 참 감사했던 부분은 디자이너의 전문성을 존중하기 위해 구체적인 솔루션 제시보다는 유저스토리를 기준으로 한 방향성 위주의 피드백에 집중하셨던 점이에요.
여러 상황을 관찰하면서 알게 된 건데, 프로덕트에 큰 애정을 가진 PM분일 수록 구체적인 솔루션을 디자이너에게 전달하는 경향이 있는 것 같아요.
만들고 있는 서비스를 매분 매초 생각하면서 이러면 어떨까, 저러면 어떨까 생각하니 자연스럽게 생각이 깊어지고 구체화될 수밖에 없는 것이겠죠.
그런데 PM이 디자이너에게 구체적인 솔루션을 제시하며 이렇게 해주세요, 저렇게 해주세요라고 하기 시작하면 PM과 PD는 결국 부딪히게 됩니다. 이런 부딪힘이 반복되면 디자이너는 결국 '프로덕트 디자이너는 PM이 하라는 대로 따르는 존재냐'라고 말하게 되고, 'PM은 프로덕트에 의견 하나 못 내냐'라고 말하게 되겠죠.
이런 갈등을 조금 풀어보려면, 프로덕트를 가장 사랑하고 또 잘 만들고 싶은 것은 결국 서로라는 것을 인정해야 합니다. 혹시 함께 일하고 있는 프로덕트 디자이너와 자꾸 갈등이 생겨 고민이 많은 PM님이 이 글을 읽고 계시다면, 디자이너로서 PM에게 기대하는 협업 방식을 살짝 알려드릴게요.
첫 번째, 기획에 자신감을 보여주시고, 이 기획을 실행시키겠다는 강한 의지를 보여주세요.
두 번째, 자신의 솔루션이 반영되었는지보다, 디자이너의 솔루션과 의도에 관심을 가져주세요.
세 번째, 디자이너의 전문성을 존중하면서 유저스토리의 목표와 방향성 기반으로 디자인 피드백을 주세요.
이 세 가지 팁을 잘 활용하셔서, 서로를 적이 아닌 아군으로 인식하고 한 발 한 발 나아가는 협업을 하실 수 있으시면 좋겠습니다. (그리고 프로덕트 디자이너분들도 함께 일하는 PM을 좀 더 믿고 마음을 열어주셨으면 좋겠습니다. PM은 아군이 되었을 때 가장 든든한 포지션입니다.)
첫 시작과는 다르게 사뭇 진지하게 마무리된 글이 되어버렸는데요. 진지한 데다가 길기까지 한 이번 글을 읽어주셔서 감사합니다!
또 만나요~~ :)
