PO의 커뮤니케이션, 이것만 기억하자!
업무 진행 프로세스에 따른 커뮤니케이션 대상과 방법에 대하여
이직을 위한 면접을 보면서 가장 많이 받았던 질문은 "가장 중요하게 생각하는 PO의 역량이 무엇인지, 본인의 강점이 무엇인지" 였던 것 같다. 그때마다 나는 내가 정말 중요하다고 생각한 "커뮤니케이션"에 대한 이야기를 했었는데 경험이 쌓여도 여전히 가장 갖기 어려운 스킬이라고 생각한다.
다들 알다시피 PO는 제품을 리딩 하므로, 제품에 있어서 가장 앞단에서 대내외적으로 커뮤니케이션을 가장 많이 하는 사람이다. 나는 업무를 하면서 우리 직무와 비유를 들기에 적합한 건 배를 이끄는 '선장'이라고 생각한다. 선장은 보통 배 안에서 배의 목적지와 방향을 설정한다. 선장이 어떤 목적지와 방향을 설정하느냐에 따라 이 배가 어디로, 어떻게, 언제까지 갈지가 정해지는데 이게 마치 제품을 리딩 하는 PO와 비슷해 보인다. 배 안에서의 선장의 말 한마디에 따라 배가 바다 한가운데 좌초되거나 또는 침몰될 수 있으므로 여기서의 선장의 역할이 중요하다. PO도 마찬가지로 PO의 커뮤니케이션 스킬에 따라 제품의 성패가 결정된다고 생각한다.
이제부터 PO 업무 프로세스에 따라 주로 누구와 어떤 커뮤니케이션을 하고, 이 과정에서 중요한 부분이 무엇인지에 대해 설명하고자 한다.
1-1. 로드맵 수립 - 리더와 커뮤니케이션
충분한 근거를 바탕으로 논리적으로 설명하고 설득한다.
제품을 담당하게 된 PO는 이 제품의 비전, 미션, 목표 등을 고민하고 이후 단기, 중기, 장기 로드맵을 작성한다. 이후 작성된 Draft안으로 나의 직속 상사 또는 리더에게 리뷰를 하게 된다. 개인적으로 이 과정은 제품의 방향성을 결정짓는 가장 중요한 첫 단계라고 생각하므로 여기에서 리더와의 커뮤니케이션이 중요하다. 리더와 나의 의견이 맞지 않는다면 어떤 부분이 어떻게 맞지 않는지 충분히 대화하고, 내가 생각하는 방향을 미리 준비해놓은 근거에 따라 차근차근 논리적으로 설명하고 설득한다. 여기서 나의 논리로 리더를 설득할 수 있다면 내가 짠 방향으로 진행하는 게 맞지만 리더의 논리가 내 논리보다 탄탄하거나, 더 나은 방향이라는 생각이 든다면 리더의 피드백을 반영하여 로드맵에 반영한다.
1-2 로드맵 수립 - 테크 리더와 커뮤니케이션
계획된 프로젝트를 원하는 순서대로 진행이 가능한지, 개발 검토 사항 중점으로 커뮤니케이션한다.
리더와 1차 sync가 끝난 후 이제 로드맵에 대한 실제 반영 가능 여부를 검토해야 한다. 이때는 보통 작은 회사의 경우 CTO, 조직의 규모가 조금 큰 회사의 경우 제품의 테크 리더와 같이 커뮤니케이션한다.
테크 리더와 1-1 리더와 커뮤니케이션과의 가장 큰 차이점은 방향성에 대한 논의보단 <로드맵에 반영된 과제의 수행 가능 여부>에 포커싱이 되어있다는 점이다.
제품 방향성과 비전 목표 등에 대해선 다 설명드리지만, 테크 리더와 주요하게 논의해야 하는 부분은 계획된 로드맵에 원하는 프로젝트를 진행할 수 있는지에 대한 개발 Scope을 체크하는 것이다. 내가 '원하는 기능을 포함한 프로젝트'를 '계획된 시기'에 할 수 있는지를 중점적으로 리뷰하고 이에 대한 개발 피드백을 들어 계획된 순서를 조정하거나 원하는 기능의 MVP만을 진행하는 형태로 커뮤니케이션한다. 이 과정에서 PO는 테크 리더에게 각각의 프로젝트의 사이즈, 개발 Scope, 가능 여부에 대해 묻고 답을 들을 수 있도록 한다. 만약 바로 피드백을 줄 수 없고 조금 더 고민해봐야 한다고 피드백을 받은 경우 Action Item을 작성하고 Due Date를 기재하여 정확히 언제까지 공유받을 수 있는지 확인해야 한다. 여기서 중요한 건 '각 프로젝트에 대한 배경 설명, 해야 하는 이유, 기대효과, 원하는 기능의 사이즈'를 정확하게 전달하는 것이다.
이를 이해한 테크 리더는 내가 원하는 방향에 피드백을 줄 것이다.
1-3. 로드맵 수립 - 사업부와 커뮤니케이션
사업에서 요구한 과제가 로드맵에서 빠지게 됐을땐, 그 이유에 대해 정확하게 설명한다.
리더와 커뮤니케이션 이후 제품의 방향성과 로드맵에 대한 계획이 나왔다면 이를 사업부에 리뷰하며 공유한다. 보통 로드맵에는 사업부의 요구사항이 다수 포함되어있으므로 사업부도 우리의 제품 방향성과 로드맵에 대해 매우 관심이 있는 상태이고 궁금해할 것이다. 여기에서 중요한 것은 만약 사업에서 요구한 요구사항이 우리의 방향성과 맞지 않아 로드맵에서 빠지게 됐을 때의 커뮤니케이션이다.
아래와 같은 예시를 보자.
PO : 저희 제품의 방향성과 미션 목표는 ~~ 합니다. 따라서 로드맵을 다음과 같이 수립하였습니다. 로드맵에 대한 간략한 배경과 진행 계획에 대한 설명 이어서~~
사업부: 리뷰해주신 부분 잘 들었습니다만, 저희가 요청드렸던 A, B, C 과제가 누락되어 있는 것 같은데 이 부분에 대해 설명해주실 수 있으실까요?
PO : 네, 요청 주신 과제 모두 꼼꼼하게 검토해보았으나 제가 앞서 설명드린 저희 제품의 방향성과는 맞지 않고 투입 대비 임팩트가 크지 않을 것이라는 생각이 들어 로드맵 계획에는 포함하지 못했습니다. 저희가 로드맵에 포함한 과제의 기준은 ~~ 이고, 우선순위의 기준은 ~~ 로 로드맵의 계획을 이렇게 수립하였습니다. 만약 사업부 관점에서 생각했을 때 추가로 고려해야 하는 부분이 있거나, 저희가 생각하지 못했던 요청 과제의 정량적 임팩트를 추가로 전달 주실 수 있다면 로드맵 반영 재검토를 해보도록 하겠습니다.
위의 예시를 통해 살펴보면 사업부와 커뮤니케이션에서 중요한 것은 '정확하고 사업 관점에서도 공감할만한 기준'에 대한 전달이다. 사업부에서 요구한 요구사항을 모두 검토했다는 점과 우리가 추구하는 방향성, 그리고 우리가 세운 우선순위 검토 기준에 대해 충분히 설명한 후 이러한 이유로 반영되지 못했다고 커뮤니케이션을 할 경우 내 경험상 대부분은 납득하고 알겠다고 하셨었다. 종종 이렇게 설명했음에도 불구하고 막무가내로 그래도 내가 요청한 프로젝트 무조건 해줘! 나한텐 중요해!라고 본인의 주장만을 펼치거나 무논리로 고집을 피우는 경우 '로드맵에 반영된 과제보다 우선되어야 할 이유, 이 과제가 진행되지 못할 경우 발생할 리스크, 진행된다면 얻을 수 있는 임팩트' 등을 정량적인 수치로 정리해서 달라고 요청하면 된다. 이렇게 요청하면 요청자도 본인이 요청한 요구사항이 정말 중요한지 한번 더 생각하게 된다.
여기서 중요한 것은 사업부와 '싸우는 것이 아니라, 감정을 빼고 팩트로 논의하는 자리'가 되어야 한다는 것이다. 감정적으로 나가면 서로 자존심 싸움만 하다가 결국 맞는 것도 아니라고 하고, 아닌 것도 맞다고 우기며 필요 없는 감정 소모를 할 수 있다. 감정을 뺀 채 팩트로 얘기하고 상대방의 입장에서 다시 한번 생각해보며 서로 다른 의견차를 어떻게 메울 수 있을지 고민 후 논의를 이어가는 게 좋다.
2-1. 프로젝트 리딩 - Makers
스몰토크와 친절하게 현황 파악하기
프로젝트를 진행하면 보통 제일 먼저 Makers와 프로젝트 킥오프 미팅을 진행한다. 킥오프 미팅을 진행하며 제품의 방향성, 비전, 목표를 공유하고 이에 따라 진행하게 되는 프로젝트에 대한 세부 설명을 진행한다. 이후 포함되길 원하는 기능과 라이브 타깃을 러프하게 전달하되 '콕 찍어서 이때까진 무조건 해주세요!!!'라는 어투로 말하는 것은 지양하는 게 좋다.
Makers들의 입장에서 생각해보면 '나한테는 5일이 필요한데, 왜 저 사람은 라이브 타깃은 우리 의견도 듣지 않고 저때로 콕 찍었지? 기분 나쁘네?'라고 생각할 수 있기 때문이다. 처음부터 잘못된 커뮤니케이션으로 감정이 상한채(상한지도 모른 채) 시작할 경우 프로젝트를 하는 내내 고통받는 건 프로젝트를 리딩 하는 PO일 것이다.
킥오프 미팅이 끝났으면, 이후 정기적으로 스크럼 미팅을 통해 Makers 분들과 만나게 되는데 이 과정에서 중요한 것은 '스몰 토킹으로 친밀감 주기' , '친절하게 현황 파악하기'가 있겠다. 스크럼 미팅을 진행할 땐 보통 PO가 미팅을 만들고 리딩을 하므로 미팅에 PO가 제일 먼저 들어와 있을 확률이 아주 높다. 이때 미팅 시간 전 미리 들어오시는 Makers 분들에게 이 틈을 활용해 친밀도를 높일 수 있다. 점심시간 이후 미팅이라면 '점심 식사는 하셨냐', 날씨가 좋다면 '날씨도 좋은데 나들이 안 가시냐' 등등의 스몰토크이다. 사실 이 부분은 나도 잘 못하는 부분이긴 한데 스몰 토킹을 잘하는 주변 PO들을 보니 소소한 이야기를 하며 그들과의 친밀도를 높여 분위기를 말랑말랑하게 해 둔 상태로 미팅을 진행하니 훨씬 더 부드러운 미팅이 되는 걸 새삼 느꼈다.
두 번째로는 '친절하게 현황 파악하기'이다.
스크럼 미팅을 진행하는 목적은 결국 각각의 Makers들의 진행 현황이 어떤지, 우리 프로젝트가 일정대로 잘 진행되고 있는지 체크하는 것이므로 중요한 부분이다. 미팅을 진행할 땐 미리 작성된 스크럼 노트를 띄우고 '내가 공유해야 할 내용(정책 업데이트), 문의할 내용, 우려되는 부분' 등에 대해 얘기하고 이후 각각의 현황을 체크하고 일정에 맞게 잘 진행되는지 체크한다.
이때 디자인이나 일부 개발자의 작업이 늦어지는 경우가 있는데, 이 경우 그들을 질타하기보다는 '왜 늦어지게 되었는지, 그럼 언제까지 가능한지, 전체 일정에 영향이 있는지' 등에 대해 물어보고 일정을 재논의해보는 게 좋다. 앞단에서 늦어지게 되는 경우 제일 마지막에 업무를 진행하는 프런트 개발자들의 일정에도 차질이 있으므로 전체적으로 체크하고 모두 합의된 일정으로 픽스 후 공유해줘야 한다. 이때 중요한 것은 '어디 파트에서 어떤 이슈로 늦어지게 되었고, 그래서 일정이 어떻게 변하게 되었는지'를 투명하게 Makers 모두에게 공유해주는 것이 제일!!! 중요하다. 프로젝트에서 가장 중요한 것은 각 파트의 현황 파악 및 일정관리다.
2-2. 프로젝트 리딩 - 외부 커뮤니케이션
파트너사에 대한 존중을 기반으로 커뮤니케이션 한다.
프로젝트를 하다 보면 외부 파트너사와도 같이 협업해야 하는 경우가 있다, 이 경우 보통 메일이나 슬랙으로 비동기 커뮤니케이션을 진행하게 된다. 나는 외부 기업과 프로젝트를 진행할 때 대부분 슬랙 위주로 커뮤니케이션을 했고, 필요한 경우 별도 온라인 미팅을 잡아서 정리하곤 했었다.
외부 커뮤니케이션을 진행하면서 느낀 건 우리 회사와 그 회사의 관계에 따라 커뮤니케이션을 진행할 때도 갑을 관계가 어쩔 수 없이 형성된다는 것이었다. 내가 갑인 것 같을 때도, 내가 을이 된 것 같을 때도 있었는데 프로젝트할 때 이렇게 느껴지더라도 최대한 연연하지 않고 마음속으로 '우린 파트너사다'라고 생각하며 상대방을 존중하는 커뮤니케이션을 하는 게 서로에게 가장 좋았던 것 같다. 최근 프로젝트에서 기억나는 외부 커뮤니케이션 사례가 있어서 소개한다. A 프로젝트를 진행하면서 우리 회사와 파트너사와 함께 개발하여 오픈해야 하는 게 있었는데, 서로의 개발 리소스를 조금이라도 아끼려고 했던 때였다.
우리 회사 : A 프로젝트 개발 중 1번에 대한 기능은 저희보다 파트너사에서 하는 게 ~~한 이유로 효율적인 것 같습니다. 파트너사에서 담당해주시면 감사하겠습니다.
파트너사 : 저희가 생각했을 땐 1번에 대한 기능은 그쪽에서 진행하는 게 더 효율적인 것 같습니다. ~~ 이유로 저희도 추가 개발 리소스가 들어갑니다.
우리 회사 : 아 저희도 다음 프로젝트도 있고 사용할 리소스가 한정적이라 1번에 대한 기능 모두를 개발하는 것은 어려울 것 같습니다.
파트너사 : 한정된 개발 리소스는 어느 회사나 동일한 거 아닌가요? 저희도 내부 다른 프로젝트를 진행해야 해서 이 프로젝트에 쏟을 개발 리소스는 한정되어있습니다.
1시간 미팅 내내 서로 핑퐁을 치며 네가 해라, 나는 못한다의 커뮤니케이션이 오갔다. 결국 이 미팅에서 서로 감정만 상한 채로 누가 해야 할지 한 번에 결정되지 못했다.
이후 후속 미팅을 잡았고, 그땐 서로 조금씩 양보하며 일부 개발은 우리 회사가, 일부 개발은 파트너사가 진행했고 큰 기능 개발이 있을 경우 일정을 조율하는 식으로 수월하게 커뮤니케이션을 했다. 위 프로젝트를 진행하며 느낀 점은 커뮤니케이션 방법에 따라 서로 방어적이고 적대적이게 되어 쉽게 할 수 있던 프로젝트를 오히려 어렵게 할 수 있다는 점이다. 사실 위 프로젝트를 할 때는 우리가 갑인 입장이어서 파트너사가 더 많은 기능을 가져가서 개발을 해왔으면 좋겠다는 내적 기대를 하고 미팅을 진행했었던 것 같다. 그래서 커뮤니케이션할 때 이러한 우리의 기대가 그들에겐 불편했을 수 있었을 것 같다는 생각이 들었다. 이러한 경험을 통해 외부 회사와 커뮤니케이션을 할 때는 '외부 회사의 입장에서도 생각하고, 충분히 고민한 후 업무 배분을 논의해봐야겠다'라고 생각했다.
3. 프로젝트 오픈 - 유관부서(CS, 마케팅, 사업부 등) 커뮤니케이션
여러 단계를 거쳐 드디어 프로젝트 오픈 단계에 왔다면 이제는 앞에서 했던 커뮤니케이션보다는 조금 더 수월한 단계라고 생각해도 좋다. 프로젝트 오픈을 할 때는 보통 해당 프로젝트와 연관 있는 유관부서와 주로 커뮤니케이션을 진행한다. 보통 프로젝트 오픈 후 고객 문의가 들어올 경우 제일 먼저 앞단에서 고객에게 정확하게 대응해줄 수 있는 CS 담당자와는 <프로젝트 오픈 후 응대 매뉴얼> 등에 대해 전달하고 공유한다. 이때 CS 담당자는 프로젝트에 대해 완벽하게 이해하고 숙지된 상태로 고객에 응대해야 하므로 최대한 고객 입장에서 많이 물어볼 수 있는 질문들 위주로 추려서 전달하는 것이 좋다.
이후 마케팅과 사업부에도 프로젝트 오픈에 대해 공유하고, <내부 운영 가이드> 문서를 작성하여 메일로 커뮤니케이션을 한다. 메일로 해당 내용을 공유했다면 이후 추가 문의의 경우 특정 문서 내 댓글이나 슬랙의 특정 채널 등을 같이 명시하여 메일보다 더 빠르게 커뮤니케이션할 수 있는 수단을 공유해주는 것이 좋다. 보통 문서면 문서, 슬랙 채널이면 채널 등 하나의 수단을 선정하여 공유하는 것이 질문의 히스토리 관리 차원에서 좋다.
4. 프로젝트 성과 및 회고 - Makers, 유관부서, 리더
메일&슬랙 커뮤니케이션과 더불어 화상미팅을 진행하여 성과에 대한 피드백을 받도록 한다.
프로젝트 오픈 후 한 달이 지나면 보통 성과 보고와 회고를 진행한다. 회고는 본인이 원하는 시점에 따라 프로젝트 오픈 후 즉시 또는 성과 보고와 묶어서 진행한다(정답은 없다)프로젝트에 대한 성과 분석 자료를 만들고, 별도 미팅을 만들어 유관부서 담당자, Makers, 리더 등 필요한 참석자를 모두 초대하고 리뷰한다.
이땐 작성된 성과 분석 자료를 프레젠테이션 하는 자리라고 생각하고, 프레젠테이션이 끝나면 각 실무자, 리더와 Q&A를 진행한다.
이처럼 성과분석 미팅을 진행하면 여러 가지 이점(혼자는 발견하지 못했던 인사이트, 추가 아이디어, 보완사항 등)이 있으니 성과분석은 관련 있는 실무자들과 리더를 모두 초대하여 공유하고 피드백을 받은 후 프로젝트 고도화 시 활용하는 것이 좋다.
5. 지난 로드맵 성과 보고 - 대표, 리더 커뮤니케이션, 유관부서
'프로젝트의 목표에 따른 결과'를 중점으로 말하고, 정량적 데이터 기반으로 커뮤니케이션한다.
계획했던 로드맵 내 프로젝트를 모두 완료했고, 이제 다음 분기 로드맵을 짤 때가 되면 지난 로드맵에 대한 성과를 보고한다. 먼저 지난 분기 성과의 경우 각 프로젝트의 성과분석 자료를 모아 summary를 만들고 실제 어떤 성과가 났는지 문서로 정리하여 프로젝트 연관자들을 수신으로 메일 커뮤니케이션을 진행한다. 이후 미팅이 필요할 경우 문서에 기재된 내용(계획했던 프로젝트를 모두 완수했는지, 완수했다면 성공했는지, 실패했는지, 결과가 이렇게 나온 이유가 무엇이고 어떤 점을 보완해야 더 잘할 수 있을지 등)을 포함하여 프레젠테이션 하며 공유한다.
여기서 중요한 점은 '프로젝트의 목표에 따른 결과'를 중점으로 말하고, 왜 이런 결과가 나왔는지 정량적인 데이터 기반으로 커뮤니케이션하는 것이다.
이후 Q&A를 통해 추가 논의를 하고 회의록을 작성한 후 참석자들에게 공유한다.
이러면 1년간 PO의 모든 커뮤니케이션이 끝난다.
마치며......
PO로 업무 한 기간이 길수록 커뮤니케이션 능력도 같이 우상향 할 것 같지만, 사실 커뮤니케이션은 본인이 노력한다고 해도 쉽게 향상되기 힘든 부분이라고 생각한다. 실제로 나보다 연차가 훨씬 많은 PO들 중에서도 너무 감정적인 커뮤니케이션을 해서 상사와의 관계가 틀어지거나, 프로젝트 진행 내내 힘들어하는 것을 종종 봤었다.나 또한 이 업계에서만 10년을 넘게 일을 했고, 너무나 익숙한 일임에도 불구하고 사람과 사람 간의 커뮤니케이션이 여전히 가장 어렵다고 느낀다.
그 이유는 사회에는 너무나도 다양한 사람들이 있고, 내가 10년 넘게 일을 했어도 모든 유형의 사람들을 다 만나본 것은 아니기 때문에 케이스별 대응이 힘든 거라고 느낀다. 그럼에도 불구하고 커뮤니케이션 능력 향상을 위해 노력해야 한다고 생각한 건 '내가 모든 유형의 사람에게 좋은 커뮤니케이션을 할 순 없어도, 전보다 나아질 순 있다'라고 느꼈기 때문이다. 실제로 '나의 커뮤니케이션 능력이 엄청나다!'라고 느끼진 않지만 매 프로젝트를 할 때마다 전보다 나은 커뮤니케이션을 하려고 노력하다 보니 전보다 '훨씬 커뮤니케이션 능력이 좋아졌다'라고 느끼는 순간들이 종종 있었다. 나의 커뮤니케이션의 방법에 따라 사람들이 나를 대하는 태도가 달라지고, 프로젝트의 난이도가 달라졌기 때문이다.
그래서 PO로 업무하고 계신 분들, 또는 PO가 아니더라도 커뮤니케이션이 중요한 직무를 맡고 계신 분들이 본문에 공유한 나의 경험을 토대로 어제보다 나은 커뮤니케이션을 하기를 기대한다.
그럼 다음은 PO의 주요 업무 중 하나인 <성과분석>을 하는 방법과 나만의 경험을 담은 노하우를 공유하려고 한다. 다음 편도 많관부!
