마케터의 커뮤니케이션
개발자, 디자이너와 협업할 때 얼굴 붉히지 않고 커뮤니케이션하는 방법
마케터는 기본적으로 개발자, 디자이너, PM 등 타 부서와의 협업이 불가피한 포지션입니다. 그래서 마케터의 커뮤니케이션 스킬은 1년 차 주니어부터 10년 차 시니어까지 경력 상관없이 지속적으로 개발하고 싶은 핵심 역량인 동시에 다수의 마케팅 실무자와 대표들이 마케터를 채용할 때 가장 중요하게 보는 역량이기도 합니다. 하지만 잘하고 싶어도 학습할 방법이 마땅치 않은, 애매한 영역이죠.
GA, 앰플리튜드, SQL, 데이터 시각화 등 하드 스킬 강의는 이제 구글링만 하면 수십, 수백 개를 찾아볼 수 있어요. 반면에 '마케터가 개발자와 커뮤니케이션하는 법', '마케터가 PM과 커뮤니케이션하는 방법' 등 마케터 입장에서 커뮤니케이션 방법을 다룬 강의나 자료는 쉽게 찾아볼 수 없습니다. 결국 유의미한 데이터를 스스로 모으고 터득해야 하는 상황인 거죠. 내가 직접 시행착오를 겪으며 배우던지, 누군가가 앞서 겪은 시행착오로 차곡차곡 쌓아둔 노하우를 빌려 내 것으로 만들던지요. 그나마 주변에 도저히 배울만한 사수나 마케터가 없다면 후자는 어려우니 느리더라도 전자로 갈 수밖에 없습니다.
마케터를 위한 교육과 커리큘럼을 개발하는 포지션의 특성상 저는 다수의 마케팅 리드와 실무자들을 만나고 인터뷰하며 그들의 노하우와 인사이트를 아카이빙 합니다. 누구나 할 수 있는 관념적이고 개념적인 얘기가 아닌, 경험 기반의 찐 실무 이야기를 들려 드릴게요. 마케터가 실무 현장에서 커뮤니케이션을 잘하는 방법, 당장 실행할 수 있는 액션 아이템으로 정리해 봤습니다. 소규모 스타트업의 1인 마케터든 대기업의 마케터든 상황과 조직 형태에 상관없이 적용할 수 있는 방법들로만요. 다수의 실력자가 축적한 커뮤니케이션 노하우와 인사이트를 직접 적용해서 내 것으로 만들어 보세요.
일단 다소 측정이 모호해서 추상적으로 느껴지는 커뮤니케이션 스킬에 대한 한층 직관적인 이해를 위해 커뮤니케이션의 목적을 두 가지로 분류해보겠습니다.
첫째, 요청을 하기 위해서
둘째, 요청받은 내용을 수행하기 위해서
그럼, 요청을 할 때와 요청받은 내용을 실행할 때 각각 어떻게 해야 ‘커뮤니케이션을 잘한다'는 평가를 받을 수 있을까요?
한 마디로 정리하면 요청하는 경우엔 이 요청을 ‘왜'하는지 전달하고, 요청받는 경우에는 이 태스크가 ‘왜’ 필요한지 물어보는 것입니다.
참 쉽죠? 좀 더 구체적으로 설명드릴게요.
Why를 정확히 설명한다
예를 들어, 코드스테이츠 마케터가 개발팀에 이벤트 심는 업무를 요청한다고 가정해 볼게요. 아래 두 가지 예시 중에 어떤 커뮤니케이션이 전달받는 입장에서 효과적인 커뮤니케이션일까요?
예시 1) A 이벤트를 터뜨리고 싶어요. 근데 어떻게 해야 할지 모르겠어요. A 이벤트를 실행할 방법을 찾아주세요.
예시 2) 지원자들이 지원을 시작하는 정확하는 시점을 수집하기 위해 A 이벤트를 만들려고 하는데 어떻게 할 수 있을까요?
정답을 유추해 보셨나요? 네, 2번의 방법이 더 효과적인 커뮤니케이션이라고 할 수 있습니다. 그 이유는 뭘까요? 2번이 좋은 커뮤니케이션인 이유는 바로 Why를 설명하는 데 있습니다. 이렇게 업무를 추진하는 배경을 정확히 설명하면 개발자(디자이너) 분들이 훨씬 매끄럽게 해결책을 제안해 줍니다. 뿐만 아니라 열 마디 설명할 것이 세 마디로 단축되죠.
요청받을 때도 마찬가지예요. 요청 주는 분이 배경을 정확하게 설명해주시면 좋겠지만, 그렇지 않은 경우가 많기 때문에 이 업무가 ‘어떤 배경에서, 왜 필요한지’를 먼저 물어보면 훨씬 효과적으로 요청받은 업무를 이해하고 수행할 수 있습니다. 다음으로는 '요청을 주고받는 전달 방식과 구조'에 대해 구체적으로 얘기해 볼게요.
상대팀에게 필요한 정보를 먼저 파악하고 전달한다
업무를 요청하는 방식은 기업마다, 팀마다, 사람마다 달라지기도 합니다. 슬랙, 카톡 같은 메신저를 사용하거나 이메일로 발송하거나, 아사나 같은 프로젝트 관리 툴을 사용하는 경우도 있죠. 여기서 수단과 무관하게 커뮤니케이션에 있어 반드시 기억해야 할 본질은 상대 팀에서 필요한 정보를 파악하고 전달하는 일이에요. 그 이후에 내가 요청한 사항들을 구조적으로 문서화해서 잘 정리해줘야 합니다.
예를 들어, 코드스테이츠 마케팅 팀에는 ‘기능 개발 문서'라는 것이 있습니다. 이 문서에는 이런 항목들이 들어갑니다.
태스크의 요청 배경
기대 효과
개발했으면 하는 구체적인 내용
희망 배포일
이렇게 상대팀이 요청받은 업무를 수행할 때 필요한 (요구하는) 정보가 명확하게 정리되어 있으면 전달하는 입장에서도, 전달받는 입장에서도 한결 수월한 커뮤니케이션을 할 수 있겠죠.
이런 문서가 없으면 어떻게 하냐고요? 바로 그때 당신의 진가가 드러납니다.
시스템을 만드는 거예요.
이런 문서가 없으면 어떻게 하냐고요? 바로 그때 당신의 진가가 드러납니다. 시스템을 만드는 거예요. 이미 체계화된 시스템을 잘 이용하는 사람은 많지만, 시스템을 만들 수 있는 사람은 적습니다. 그 주인공이 되어보세요. 개발팀, 디자인팀 등 다른 팀에 협업을 요청하고 싶은데 상대팀에서 어떤 정보가 필요한지 모르겠다고요? 이때 가장 간편하고 효과적인 방법이 있습니다. 개발팀, 디자인팀에 직접 물어보세요.
“저희가 요청할 때 어떤 정보들이 정리되어 있는 게 편하세요?” “어떻게 요청받는 게 편하세요?”라고 묻고, 그대로 문서를 만들어달라고 요청하면 됩니다. 이렇게 요청하면 타 팀에서도 요청받을 때 필요한 항목을 한번 정리하는 계기를 만들 수 있어요. 이거야말로 윈윈이죠. 협업을 진행하며 작업을 하는 데 쓰는 에너지 외에 이 작업을 이해시키고 요청하기 위해 쏟는 소모적인 에너지와 피로감을 확 줄일 수 있습니다. 스무 번, 서른 번은 오갈 질문 핑퐁이 다섯 번 안에 끝나버리면 요청하는 마케터와 요청받는 개발자(디자이너)의 삶의 질이 달라질 수밖에요.
