프로젝트 단계별로 본 PO의 커뮤니케이션 방법

이직을 위한 면접을 보면서 가장 많이 받았던 질문은 “가장 중요하게 생각하는 PO의 역량이 무엇인지, 본인의 강점이 무엇인지”에 대한 것이었다. 그때마다 내가 가장 중요하다고 생각한 ‘커뮤니케이션’에 대한 이야기를 했는데, 경험이 쌓여도 여전히 가장 갖기 어려운 스킬이라고 생각한다. 

PO는 제품을 리딩해야 하므로 제품의 맨 앞단에서 대내외적으로 커뮤니케이션을 가장 많이 하는 사람이다. 업무를 하며 이 직무를 비유하기에 적합한 건 배를 이끄는 선장이라고 생각했다. 선장은 보통 배 안에서 배의 목적지와 방향을 설정한다. 선장이 어떤 목적지와 방향을 설정하느냐에 따라 이 배가 어디로, 어떻게, 언제까지 갈지가 정해진다. 제품을 리딩하는 PO도 이와 비슷하다. PO의 커뮤니케이션 스킬에 따라 제품의 성패가 결정될 수 있다고 본다.

이번 글에서는 프로젝트 단계에 따라 PO는 주로 누구와 어떤 커뮤니케이션을 하는지, 이 과정에서 중요한 점은 무엇인지에 대해 알아보고자 한다.

로드맵 수립 단계에서의 커뮤니케이션

1) 리더와 커뮤니케이션하기

충분한 근거를 바탕으로 논리적으로 설명하고 설득한다.

먼저 제품을 담당하게 된 PO는 이 제품의 비전, 미션, 목표 등을 고민하고 이후 단기, 중기, 장기 로드맵을 작성한다. 이후 작성된 Draft안으로 직속 상사 또는 리더에게 리뷰를 해야 한다. 개인적으로 이 과정은 제품의 방향성을 결정짓는 가장 중요한 첫 단계라고 생각하므로, 여기에서 리더와의 커뮤니케이션이 중요하다. 

리더와 의견이 맞지 않는다면 어떤 부분이 어떻게 맞지 않는지 충분히 대화하고, 내가 생각하는 방향을 미리 준비해 놓은 근거에 따라 차근차근 논리적으로 설명하고 설득해야 한다. 여기서 나의 논리로 리더를 설득할 수 있다면 원래 방향으로 진행하는 게 맞지만, 만약 리더의 논리가 내 논리보다 탄탄하거나, 더 나은 방향이라면 리더의 피드백을 로드맵에 반영한다.

2) 테크 리더와 커뮤니케이션하기

계획된 프로젝트를 원하는 순서대로 진행이 가능한지, 개발 검토 사항 중점으로 커뮤니케이션한다.

리더와 1차 sync가 끝난 후 이제 로드맵에 대한 실제 반영 가능 여부를 검토해야 한다. 이때는 보통 작은 회사의 경우 CTO, 조직의 규모가 조금 큰 회사의 경우 제품의 테크 리더와 같이 커뮤니케이션한다. 테크 리더와의 커뮤니케이션은 방향성에 대한 논의보단 <로드맵에 반영된 과제의 수행 가능 여부>에 포커싱이 맞춰져 있다.

제품 방향성과 비전, 목표 등에 대해선 똑같이 설명하지만, 테크 리더와 주요하게 논의해야 하는 부분은 계획된 로드맵에 원하는 프로젝트를 진행할 수 있는지 개발 Scope을 체크하는 것이다. 내가 원하는 기능을 포함한 프로젝트를 계획된 시기에 할 수 있는지를 중점적으로 리뷰하고, 이에 대한 개발 피드백을 들어 계획된 순서를 조정하거나 원하는 기능의 MVP만을 진행하는 형태로 커뮤니케이션한다. 

이 과정에서 PO는 테크 리더에게 각 프로젝트의 사이즈, 개발 Scope, 가능 여부에 대해 묻고 답을 들을 수 있도록 한다. 만약 바로 피드백을 줄 수 없고 조금 더 고민해야 한다고 하는 경우, 액션 아이템과 마감 기한을 기재하여 정확히 언제까지 공유 받을 수 있는지 확인해야 한다. 여기서 중요한 건 ‘각 프로젝트에 대한 배경 설명, 해야 하는 이유, 기대효과, 원하는 기능의 사이즈’를 정확하게 전달하는 것이다. 이를 이해한 테크 리더는 내가 원하는 방향에 피드백을 줄 것이다.

3) 사업부와 커뮤니케이션하기

사업부에서 요구한 과제가 로드맵에서 빠지게 됐을 땐, 그 이유에 대해 정확하게 설명한다.

리더와 커뮤니케이션 이후 제품의 방향성과 로드맵에 대한 계획이 나왔다면 이를 사업부에 리뷰 및 공유한다. 보통 로드맵에는 사업부의 요구사항이 다수 포함되어 있으므로, 사업부도 우리의 제품 방향성과 로드맵에 대해 관심이 있고 궁금해할 것이다. 여기에서 중요한 점은 만약 사업부의 요구사항이 우리의 방향성과 맞지 않아 로드맵에서 빠지게 됐을 때의 커뮤니케이션이다.

아래 예시를 통해 살펴보자.

PO:저희 제품의 방향성과 미션 목표는 ~~합니다. 따라서 로드맵을 다음과 같이 수립했습니다. 로드맵에 대한 간략한 배경과 진행 계획에 대한 설명은 이러합니다.

사업부: 리뷰해 주신 부분 잘 들었습니다만, 저희가 요청드렸던 A, B, C 과제가 누락되어 있는 것 같은데 이 부분에 대해 설명해 주실 수 있으실까요?

PO: 네, 요청 주신 과제 모두 꼼꼼하게 검토해 보았으나 제가 앞서 설명드린 저희 제품의 방향성과는 맞지 않고, 투입 대비 임팩트가 크지 않을 것이라는 생각이 들어 로드맵 계획에는 포함하지 못했습니다. 저희가 로드맵에 포함한 과제의 기준은 ~~이고, 우선순위의 기준은 ~~으로 로드맵의 계획을 이렇게 수립했습니다. 만약 사업부 관점에서 생각했을 때 추가로 고려해야 하는 부분이 있거나, 저희가 생각하지 못했던 요청 과제의 정량적 임팩트를 추가로 전달 주신다면 로드맵 반영을 재검토해 보겠습니다.

위 예시를 보면 사업부와 커뮤니케이션에서 중요한 것은 ‘사업 관점에서도 공감할 만한 정확한 기준’에 대한 설명이다. 사업부에서 요청한 요구사항을 모두 검토했다는 점, 우리가 추구하는 방향성과 우선순위 검토 기준에 대해 충분히 설명하자. 그리고 이러한 이유로 반영하지 못했다고 커뮤니케이션하면 대부분은 납득하는 경우가 많다. 

그러나 이렇게 설명했음에도 불구하고 막무가내로 ‘요청한 프로젝트는 무조건 해줘!’라며 본인 주장만 펼치는 경우, ‘로드맵에 반영된 과제보다 우선시되어야 하는 이유, 이 과제가 진행되지 못할 경우 발생하는 리스크, 진행된다면 얻을 수 있는 임팩트’ 등을 정량적인 수치로 정리해서 달라고 요청해 보자. 이렇게 하면 요청자도 본인의 요구사항이 정말 중요한 것인지 한 번 더 생각할 수 있게 된다. 

여기서 중요한 것은 사업부와 싸우는 것이 아니라, 감정을 빼고 팩트로 논의하는 자리가 되어야 한다는 것이다. 감정적으로 나가면 서로 자존심 싸움만 하다가 결국 맞는 것도 아니라고 하고, 아닌 것도 맞다고 우기며 필요 없는 감정 소모를 하게 될 수 있다. 최대한 개인적인 감정을 빼고 팩트로 얘기하며, 상대방의 입장에서 다시 한번 생각해 보자. 잠시 쉬고 서로 다른 의견차를 어떻게 메울 수 있을지 고민한 후 논의를 이어가는 것이 좋다.

프로젝트 리딩 단계에서의 커뮤니케이션

1) 프로덕트 메이커들과의 커뮤니케이션

스몰토크와 친절하게 현황 파악하기

프로젝트를 진행하면 보통 제일 먼저 프로덕트 메이커들(주로 디자이너, 개발자)과 킥오프 미팅을 진행한다. 킥오프 미팅에서 제품의 방향성, 비전, 목표를 공유하고 이에 따라 진행하게 되는 프로젝트 세부 내용을 전달한다. 이후 포함하길 원하는 기능과 라이브 타깃을 러프하게 전달하되, ‘이때까진 무조건 해주세요!’라는 식의 요구는 지양하는 게 좋다.

실제 메이커들 입장에서는 ‘나한테는 5일이 필요한데, 왜 저 사람은 우리 의견도 듣지 않고 일정을 잡지?’라고 생각할 수 있기 때문이다. 처음부터 잘못된 커뮤니케이션으로 감정이 상한 채 시작한다면 프로젝트 내내 고통받는 건 결국 PO의 몫이니 말이다.

이렇게 킥오프 미팅이 끝난 후엔 정기적으로 스크럼 미팅을 통해 메이커들과 만나게 되는데, 이 과정에서 중요한 것은 스몰토크로 친밀감 쌓기, 친절하게 현황 파악하기가 있다. 보통은 PO가 먼저 미팅을 잡고 리딩 할 때가 많아 제일 먼저 들어와 있는 경우가 많다. 이때 미팅 시간 전 미리 들어온 팀원들과 간단한 스몰토크로 친밀감을 높여보자. 점심시간 이후 미팅이라면 점심 식사 메뉴에 대해, 가장 보편적으로는 날씨나 여행 같은 주제로 스몰토크를 시도해 볼 수 있다. 사실 스몰토크는 나도 잘 못하는 부분이긴 한데, 다른 PO들은 미팅 전 소소한 이야기를 나누며 분위기를 푼다는 얘기를 들었다. 바로 딱딱한 업무 얘기부터 진행하기보다는 때론 이런 소소한 대화도 필요하다고 느낀다.

다음으로는 ‘친절하게 현황 파악하기’다. 스크럼 미팅을 진행하는 목적은 각 메이커들의 진행 상황이 어떤지, 우리 프로젝트가 일정대로 잘 진행되고 있는지 체크하는 것이다. 미팅을 진행할 땐 미리 작성한 스크럼 노트를 띄우고 내가 공유해야 할 내용(정책 업데이트), 문의할 내용, 우려되는 부분 등에 대해 얘기하고, 이후 각각의 현황을 파악해 일정에 맞게 잘 진행되고 있는지 체크한다. 

이때 디자인이나 일부 개발자의 작업이 종종 늦어지는 경우가 있는데, 이럴 때 그들을 질타하기보다는 늦어지게 된 이유와 현재 가능한 일정, 전체 일정에 영향이 있을지 등을 물어보고 일정을 재논의하는 것이 좋다. 앞단에서 늦어지게 될 경우 제일 마지막에 업무를 진행하는 프론트엔드 개발자의 일정에도 차질이 있으므로, 전체적으로 일정을 체크하고 모두 합의된 날짜를 정해 공유해야 한다. 이때 ‘어디 파트에서 어떤 이슈로 늦어지게 되었고, 그래서 일정이 어떻게 변경되었는지’ 모두에게 투명하게 공유하는 것이 좋다. 프로젝트 진행에서 가장 신경 써야 할 부분도 바로 각 파트의 현황 파악 및 일정 관리다.

2) 외부 커뮤니케이션

파트너사에 대한 존중을 기반으로 커뮤니케이션한다. 

프로젝트를 하다 보면 외부 파트너사와 같이 협업해야 하는 경우가 있다. 이 경우 보통 메일이나 슬랙으로 비동기 커뮤니케이션을 진행하게 된다. 내 경우 외부 기업과 프로젝트를 진행할 때 대부분 슬랙 위주로 커뮤니케이션했고, 필요한 경우엔 별도 온라인 미팅을 잡아서 정리했다.

외부 커뮤니케이션을 진행하면서 느낀 점은 회사의 관계에 따라 커뮤니케이션을 진행할 때도 어쩔 수 없는 갑을 관계가 형성된다는 것이다. 그러나 이렇게 느껴지더라도 최대한 연연하지 않고 마음속으로 우린 파트너사라고 생각하며, 상대방을 존중하는 커뮤니케이션을 해야 서로에게 윈윈이다. 기억에 남는 외부 커뮤니케이션 사례가 하나 있다. 우리 회사와 파트너사가 함께 개발 후 오픈해야 하는 프로젝트를 진행했었는데, 이때 서로의 개발 리소스를 조금이라도 아끼려고 했던 것이다.

우리 회사: A 프로젝트 개발 중 1번에 대한 기능은 저희보다 파트너사에서 하는 게 ~~한 이유로 효율적인 것 같습니다. 파트너사에서 담당해 주시면 감사하겠습니다.

파트너사: 저희가 생각했을 땐 1번에 대한 기능은 그쪽에서 진행하는 게 더 효율적인 것 같습니다. ~~ 이유로 저희도 추가 개발 리소스가 들어갑니다.

우리 회사: 아 저희도 다음 프로젝트도 있고 사용할 리소스가 한정적이라, 1번에 대한 기능 모두를 개발하는 것은 어려울 것 같습니다.

파트너사: 한정된 개발 리소스는 어느 회사나 동일한 거 아닌가요? 저희도 내부 다른 프로젝트를 진행해야 해서 이 프로젝트에 쏟을 개발 리소스는 한정되어 있습니다.

1시간짜리 미팅 내내 서로 ‘네가 해라, 나는 못한다’식의 커뮤니케이션이 오고 갔다. 결국 이 미팅은 서로 감정만 상한 채로 누가 해야 할지 한 번에 결정하지 못하고 끝이 났다. 이후 후속 미팅을 잡았는데 이때는 서로 조금씩 양보해서 개발 업무를 분담했고, 큰 기능 개발이 있을 때 다시 일정을 조율하는 식으로 수월하게 커뮤니케이션했다. 

위 프로젝트를 진행하며 느낀 점은 커뮤니케이션에서 서로 방어적인 태도를 취하면 쉽게 할 수 있던 프로젝트도 오히려 어렵게 만들 수 있다는 점이다. 사실 위 프로젝트를 할 때는 우리가 갑의 입장이어서, 파트너사가 더 많은 기능을 가져가 개발하면 좋겠다는 기대를 가졌던 것 같다. 그래서 커뮤니케이션할 때 우리의 기대가 그들에겐 많이 불편했을 수 있겠다는 생각이 들었다. 이러한 경험을 통해 외부 회사와 커뮤니케이션할 때는 우리 입장도 중요하지만, 외부 회사의 입장도 충분히 고민한 후 업무를 배분해야 한다는 점을 배웠다.

프로젝트 오픈 단계: 유관 부서 커뮤니케이션

여러 단계를 거쳐 드디어 프로젝트 오픈 단계에 왔다면, 이제는 앞에서 했던 커뮤니케이션보다는 조금 더 수월한 단계라고 생각해도 좋다. 프로젝트를 오픈할 때는 보통 해당 프로젝트와 연관 있는 유관 부서와 주로 커뮤니케이션을 진행한다. 보통 프로젝트 오픈 후 고객 문의가 들어올 때, 제일 먼저 앞단에서 고객에게 정확하게 대응해 줄 수 있는 CS 담당자와는 <프로젝트 오픈 후 응대 매뉴얼>에 대해 공유한다. 이때 CS 담당자는 프로젝트에 대해 완벽하게 이해하고 숙지된 상태로 고객에 응대해야 하므로, 최대한 고객 입장에서 많이 물어볼 수 있는 질문들 위주로 추려서 전달하는 것이 좋다. 

이후 마케팅과 사업부에도 프로젝트 오픈에 대해 공유하고, <내부 운영 가이드> 문서를 작성하여 커뮤니케이션한다. 메일로 해당 내용을 공유했다면, 이후 추가 문의는 특정 문서 내 댓글이나 슬랙의 특정 채널을 같이 명시하여 메일보다 더 빠르게 커뮤니케이션할 수 있게 공유해 주는 것이 좋다. 보통 문서라면 문서, 슬랙 채널이면 채널 등 하나의 수단을 선정해 공유하는 것이 질문 히스토리 관리 차원에서 좋다.

프로젝트 성과 및 회고 단계: 메이커, 유관 부서, 리더

메일&슬랙 커뮤니케이션과 더불어 화상 미팅을 진행하여 성과에 대한 피드백을 받는다.

프로젝트 오픈 후 한 달이 지나면 보통 성과 보고와 회고를 진행한다. 회고는 본인이 원하는 시점에 따라 프로젝트 오픈 후 즉시 또는 성과 보고와 묶어서 진행한다(정답은 없다). 프로젝트에 대한 성과 분석 자료를 만들고, 별도 미팅을 잡아 유관 부서 담당자, 메이커, 리더 등 필요한 참석자를 모두 초대하고 리뷰한다.

이땐 작성한 성과 분석 자료를 프레젠테이션 하는 자리라고 생각하고, 발표가 끝나면 각 실무자, 리더와 Q&A를 진행한다. 이처럼 성과 분석 미팅을 진행하면 스스로 발견하지 못했던 인사이트, 추가 아이디어, 보완사항 등을 얻을 수 있으니, 성과 분석은 관련 있는 실무자들과 리더를 모두 초대하여 공유하고 피드백을 받은 후 프로젝트 고도화 시 활용하는 것이 좋다.

지난 로드맵 성과 보고: 대표, 리더, 유관 부서

프로젝트의 목표에 따른 결과를 중점으로 말하고, 정량적 데이터 기반으로 커뮤니케이션한다.

계획했던 로드맵 내 프로젝트를 모두 완료했고, 이제 다음 분기 로드맵을 설정할 때가 되면 지난 로드맵에 대한 성과를 보고한다. 먼저 지난 분기 성과의 경우 각 프로젝트의 성과분석 자료를 모아 요약본을 만들고, 실제 어떤 성과가 있었는지 문서로 정리하여 프로젝트 이해관계자를 대상으로 메일 커뮤니케이션을 진행한다. 이후 미팅이 필요할 경우 문서에 기재된 내용(계획했던 프로젝트를 모두 완수했는지, 완수했다면 성공했는지, 실패했는지, 결과가 이렇게 나온 이유가 무엇이고 어떤 점을 보완해야 더 잘할 수 있을지 등)을 포함하여 프레젠테이션 한다.

여기서 중요한 점은 프로젝트 목표에 따른 결과를 중점으로 말하고, 왜 이런 결과가 나왔는지 정량적인 데이터를 기반으로 커뮤니케이션하는 것이다. 이후 Q&A를 통해 추가 논의하고 회의록을 작성해 참석자들에게 공유한다. 이로써 PO의 길고 길었던 커뮤니케이션이 끝난다.

마치며

PO로 일한 기간이 길어질수록 커뮤니케이션 능력도 금세 높아질 것 같지만, 사실 커뮤니케이션은 본인이 노력한다고 해도 쉽게 얻을 수 있는 능력은 아니라고 생각한다. 실제로 나보다 연차가 훨씬 많은 PO 중에서도 감정적으로 커뮤니케이션해서 상사와의 관계가 틀어지거나, 프로젝트 진행 내내 힘들어하는 것을 종종 보았다. 나 또한 이 업계에서만 10년 넘게 일했고, 익숙한 일임에도 불구하고 사람 간의 커뮤니케이션은 여전히 어렵다고 느낀다.

그 이유는 너무 다양한 사람들이 있고, 10년 넘게 일을 했어도 모든 유형의 사람들을 다 만나본 것은 아니라 상황별 대응이 힘들 때가 있다. 그럼에도 불구하고 커뮤니케이션 능력을 키우기 위해 노력해야 하는 이유는 ‘내가 모든 유형의 사람과 좋은 커뮤니케이션을 할 순 없어도, 전보다 나아질 수는 있다’라고 느꼈기 때문이다. 

실제로 커뮤니케이션 능력이 엄청나다고 느끼진 않지만, 매 프로젝트를 할 때마다 전보다 나은 커뮤니케이션을 하려고 노력하다 보니 훨씬 좋아졌다고 느끼는 순간들이 있다. 커뮤니케이션의 방법에 따라 사람들이 나를 대하는 태도와 프로젝트의 난이도가 달라졌기 때문이다.

그래서 PO로 일하고 있거나, PO가 아니더라도 커뮤니케이션이 중요한 직무에 있다면 이런 내 경험을 토대로 용기를 얻길 바란다. 노력하다 보면 분명 어제보다 더 나은 커뮤니케이션을 할 수 있게 될 것이다. 

<원문>

PO의 커뮤니케이션, 이것만 기억하자!
 

©️요즘IT의 모든 콘텐츠는 저작권법의 보호를 받는 바, 무단 전재와 복사, 배포 등을 금합니다.