[주니어 PM의 협업 1편] PM, 마케터, 디자이너
feat. 여러분 안 계시면 전 아무 것도 아니에요..
01. 협업이 8할
2년 전 PM 직군으로 지원했던 첫 면접에서 "주니어 PM과 시니어 PM에게 기대되는 역할은 어떻게 다를까요?"라는 질문을 받았습니다. 잘 대답하지 못했던 질문 중 하나였습니다. 그래서 가끔 생각나는데요. 지금 다시 대답할 수 있다면- 시니어는 제품 로드맵을 수립해 '그래서 이 다음에 어디로 갈 것인가'를 제시하는 역할, 주니어는 로드맵을 밟아나갈 수 있도록 내부 추진력을 확보하는 역할 이라 생각한다고 대답하고 싶습니다.
저는 제품 로드맵 = 제품 성공 전략 이라고 생각하지는 않습니다. 차례대로 밟아나간다고 해서 성공이 보장되는 것이 아니기 때문입니다. 그래서 정성껏 오래 지나가는 것보다는, 결말이 보이는 단계까지 빠르게 달려갔다 오는 것이 낫다고 생각합니다. 주니어 PM에게 기대되는 역할을 '내부 추진력 확보'라 구체화하게 된 것도 비슷한 맥락입니다.
로드맵 내 각 단계를 유의미한 실험으로 만들기 위해 PM이 혼자서 할 수 있는 일은 거의 없습니다. 그래서 다른 직군 동료들의 역할을 이해하고, '내가 할 수 없는 일을 하는 그들을 어떻게 서포트해서 이 일을 되게 할 것인가?'를 배우는 게 중요하다고 생각합니다. 총 세 편의 글에 걸쳐 그동안 제 나름대로 습득한, 각 직군을 서포트할 때 도움이 되었던 태도를 기록해보려 합니다. 이번 편에서는 PM, (브랜드) 마케터, (프로덕트) 디자이너 와의 경험을 기록합니다.
02. PM
다른 PM들과 협업하는 주 케이스는 (1) 양 제품 간 전환이 필요할 때 (2) 휴가 등 자리를 비워 대무가 필요할 때 입니다. PM들과 일할 때는 문서 작성과 최신성 관리가 특히 더 중요하다고 생각합니다. 본인이 매니징하는 제품이 아닌 이상 담당 PM 만큼 구체적으로 맥락을 아는 것은 어렵고, 담당 PM 역시 크고 작은 모든 의사결정을 본인의 기억력에만 의존해 관리할 수는 없기 때문입니다. 그래서 구두로 논의를 완료한 건이더라도 그 날 퇴근하기 전 슬랙에 '구두 논의 완료 (결론 : A, 배경 : B)'로 기록을 남겨둡니다. 각자 자신의 제품에 대해 갖고 있는 많은 정보를 정리해두면, 서로의 제품 이해도를 좀 더 빠르게 올릴 수 있고 이것이 논의 시간을 알차게 사용하는 데에도 도움이 되었던 경험이 종종 있습니다.
구두 논의 완료건 공유저는 제가 담당하는 제품의 스쿼드에도 속해있지만 각 제품의 PM이 속한 기능 조직에도 속해있습니다. 이 조직에서는 PM 간 주요 배포 예정건을 공유하는데요. 이 때 제품이 어떻게 변했는지 before & after를 공유하는 것도 물론 중요하지만 사실 그건 문서로도 대체할 수 있다고 생각합니다. 서로 얼굴을 마주보고 이야기할 수 있는 자리에서는- 왜 이런 결정이 필요했는지 배경을 설명하고 여러 옵션 중에 이걸 택한 이유가 무엇인지를 설명하는 것이 더 필요합니다. 그걸 말하고 듣다보면 서로의 제품에서 가장 중요한 의사결정 기준을 이해하게 되고, 이런 자리를 통해 전사 제품을 공부하기도 합니다.
03. (브랜드) 마케터
브랜드 마케터는 우리 제품이 누구에게 어떤 메시지를 주고 싶은지 가장 잘 아는 직군입니다. 그리고 외부 시장이나 경쟁사 제품에 대한 인사이트를 갖고 있는 든든한 동료입니다. 그래서 제품 내 카피라이팅이나 톤앤매너에 대해 프로덕트 디자이너와 논의하다 고민이 생기면 브랜드 마케터의 피드백을 요청드리곤 합니다. 이렇게 설계한 경험이 제품에는 어떤 영향을 주는지 반대로 피드백을 드리며 브랜드 경험 - 제품 간의 얼라인을 확인할 수 있도록 합니다. 예를 들어 브랜드 캠페인 이후 실제로 유입된 고객은 어떤 특징을 갖고 있는지 통계적인 정보를 전달드리기도 하고, 상품 기대평이나 후기 등 raw text를 전달드릴 때도 있습니다.
더불어 신규 브랜드 캠페인 페이지 제작이나 이벤트 진행을 위해 마케터 - 메이커 간 협업할 때에 PM이 통역 역할을 해야 합니다. 서로 잘 하는 일이 다르기 때문에 서로 낯설게 느끼는 일도 당연히 다릅니다. 예컨대 브랜드 마케터가 이벤트 참여 신청 시점의 로그인 여부에 따른 플로우 분기를 고민하기는 어렵고, 개발자가 타겟 고객 특성에 따른 이벤트 참여 제약 조건을 먼저 제안하기는 어렵습니다. 그래서 아무리 작은 이벤트여도 브랜드 전략을 제품으로 구현하기 위한 기획 소화 과정에 PM이 함께 하는 것이 서로의 언어를 이해하는 데에 도움이 되었던 경험들이 있습니다.
04. (프로덕트) 디자이너
프로덕트 디자이너는 우리 제품 내에서의 고객 경험을 설계하고 이를 디자인으로 풀어내는 직군입니다. 저는 디자이너와 협업할 때에는 (1) 기획의도 와 (2) 이를 달성하기 위한 아이디어 를 구분해서 전달드리려고 노력했습니다. 기획의도는 PM이자 기획자인 제가 명료하게 제시하고 설명할 의무가 있습니다. 어떤 문제를 풀어야 하는지, 무엇을 개선해야 하는지 작성합니다. 이것을 해결하기 위한 아이디어, 특히 디자인 요청을 전달드릴 때는 시각 구현에 대한 아이디어도 포함하는데요. 기획의도 달성 전제 하에서 각 아이디어의 수용/반영 여부는 디자이너가 판단하실 수 있도록 코멘트를 덧붙이는 편입니다.
예를 들어 제가 와이어프레임 (가급적 무채색으로 작성하긴 함) 내에 중요 버튼을 빨간색, 초록색으로 설정해 전달드리는 것은- '버튼의 색깔이 반드시 빨간색, 초록색이어야 해서' 가 아니라 그 버튼이 화면 내에서 중요한 기능을 하기 때문에 강조되어야 하고 이를 달성하기 위한 아이디어로 보색을 제시한 것 뿐이라는 것을 소통의 전제로 깔아둡니다.
더불어 스쿼드에 제품 데이터를 공유할 때 디자이너가 어떤 것들을 궁금해하는지 파악하려고 종종 가서 여쭙기도 했습니다. 디자이너는 고객의 좋은 경험을 판단할 수 있는 지표를 궁금해할 것이고 이것을 우리가 알고 있는 것이 제품 성장에도 도움이 되기 때문입니다. 파악한 뒤에는 디자이너를 태그해 제품 데이터를 공유했고, 더 나아가 데이터 조회 접근성을 높일 수 있도록 제품 분석 툴의 사용법이나 SQL을 간단히 알려드리기도 했습니다.
데이터 공유 예시
디자이너 다혜님께 알려드린 SQL 기초 스터디다음 편에서는 프론트엔드 개발자, 백엔드 개발자와의 협업 경험을 기록할 예정입니다.
