프로덕트 매니저 채용 공고를 보면 다양한 스킬을 요구한다.
기업마다 원하는 게 다르지만 비슷한 부분들이 많다.
프로덕트 매니저에게 원하는 스킬을 모아놓으면 아래와 같다.
하지만 이 모든 것을 통달하는, 협업에서 가장 중요한 것은 바로 '커뮤니케이션'이다.
한 평생 한국말로 사람들과 대화를 나눠왔는데 대화를 하는 게 대체 왜 이렇게 중요할 일인가.
프로덕트를 만드는 데는 다양한 직군, 많은 사람들이 개입을 하게 된다.
그림처럼 모든 직군이 오직 프로덕트를 위해 한 방향만 바라보지만, 그 출발점은 모두 다르다.
PO/PM: '고객의 핵심 문제를 해결할 솔루션이 필요해!'
Business: '서비스의 가치도 중요하지만 수익을 창출할 방법이 더 중요해'
Data Analyst: '이번 신기능의 이용률이 떨어지고 있는데 어떻게 하면 좋지?'
Developer: '지금 신기능을 추가하면 서비스 보안, 안정성에 부담이 갈 수 있어서 어려워..'
...
실제로 다른 직군들과 일해보면 각 직군마다 프로덕트를 바라보는 시선이 조금이 다름을 알 수 있다. 이해관계가 다른 사람들과 프로덕트를 바라보고, 프로덕트가 한 방향으로 성장하기 위해서는 많은 대화가 필요하다. 서로의 입장을 말하고, 설득하고, 설득 당하는 과정에서 우리는 서로를 더 잘 이해하고 모두가 동의하는 방향으로 일을 진행할 수 있게 된다.
특히 프로덕트 매니저의 경우 모든 직군과 한 번 이상 업무적인 대화를 주고 받게 되는 만큼 대화를 주도하는 일도 많아진다. 프로덕트를 가장 잘 아는 메이커로서 보다 적극적으로 동료들을 설득할 능력을 키워야 한다.
나 이외에 다른 누군가와 업무적 대화를 주고 받을 때 '유의미한 결과'를 도출할 수 있는 대화법에 대해 알아보자.
1. 나의 생각은 명확하게
프로덕트 매니저는 수없이 결정의 기로에 놓이게 된다.
고객의 '어떤' 문제에 집중해서 해결할지, 다음 스프린트에 프로덕트팀이 해야할 목표, CS가 발생했을 경우 어떻게 대처할 수 있는지 여러 방법을 고민하고, 디자이너나 개발자가 사소한 기능의 결정을 기획자에게 물어보는 경우 등 프로덕트의 의사결정을 도맡는다. 이럴 때 수학 문제처럼 답이 딱 정해져 있으면 문제라도 풀텐데 우리 앞에 높인 상황은 정답없이 오로지 본인과 팀을 믿고 답을 내야할 경우가 많다.
그래서 고객 리서치나 인터뷰를 진행하고, 고객 데이터를 분석하고, 우리 팀의 리소스에 실현 가능한 방법을 따져보게 된다. 이런 과정을 거쳐 PM으로서 결론을 정하고 이를 상대방에게 공유한다. 상대방에게 내 결론을 전달할 때는 이해를 돕기 위해 배경과 근거를 덧붙여서 설명할 수 있도록 한다. 특히 다른 팀과 회의할 때 나의 기획안대로 진행되기 위해서는 설득할 수 있는 나만의 명확한 주장을 준비해야한다.
2. 양방향의 대화
커뮤니케이션으로 유연하게 결론이 바뀔 수 있다.
사용자 데이터 분석 결과를 토대로 열심히 기획안을 작성해 개발팀과 미팅을 하려 한다. 내가 볼 땐 완벽한 기획안이지만, 개발팀이 봤을 땐 더 좋은 방법이 있을 수도 있다. 이를 간과하고 내 아이디어에 심취해 개발팀의 의견을 물어보는 걸 잊어선 안된다. 1년차 주니어 PM일 때 기획서를 작성해 개발팀에 공유하면 이래서 안된다 저래서 안된다길래 여러 번 기획서를 수정하고 다시 회의하고를 반복한 적이 있다. 간단한 기능이라도 사람마다 다르게 생각하기 때문에 의견을 좁히는 게 쉽지 않아 회의를 여러 번 가지는 건 좋다. 하지만 우리에겐 훨씬 복잡하고 무거운 기능들도 기다리고 있기에 간단한 기능만 붙잡고 있을 순 없다. 한 번의 회의에서 최대한 많은 결론을 내는 게 좋지 않겠는가.
그래서 나는 기획서를 작성할 때 A, B, C 다양한 버전으로 기능을 기획하고, 개발팀에게 질문을 던진다. 그럼 개발팀은 개발 난이도와 시간, 역할 등을 고려해 'B는 개발 시간이 오래 걸린다', 'A보단 C가 서비스에 안정적으로 추가할 수 있다' 등의 답을 내놓는다. 나는 개발팀의 의견을 반영해 C로 개발해달라고 결론을 짓는다. 기획안이 언제든 더 좋게 바뀔 수 있다는 가능성을 열어두고 협업관계자들의 이야기를 듣는 자세도 중요하다.
3. 신뢰관계를 먼저 쌓자
입사 2주차에 하필 기획팀장님께서 2주 해외여행을 가셔서 얼굴도 못 본 채 바로 업무에 투입된 적이 있다. 1주는 온보딩하느라 시간을 보냈고, 2주차에 영업팀에서 새로운 기능을 제안해주셨다. 당시 내가 아는 정보로는 한계가 있어서 개발팀에 확인해보고 알려주겠다고 했다. 개발팀장님께 '~ 기능도 가능한지 보고 싶다'고 하니까 돌아온 답변은 '요구사항을 문서로 정리해달라'였다. 나는 우리 기능의 동작을 보고 확장가능성에 대해 물어보고 싶었던 것인데, 개발팀장님께서는 '~ 기능을 개발해달라'로 이해하셨나보다. 그 이후로 한동안 개발팀장님과 멀어졌지만, 조금씩 가까워지면서 대화하는 데 오해같은 건 더 이상 발생하지 않았다.
그 당시에는 당황스럽지만 지금와서 생각해보면 신뢰관계 부족에서 오는 경계와 의심이었다고 생각한다. 우리 팀장님이랑은 스스럼 없이 프로덕트 개발에 대해 얘기하는 걸 자주 봤기 때문이다. 그래서 나도 개발팀장님이랑 친해지기 위해 나름의 노력을 했다. 기획팀장님은 개발팀장님 뿐만 아니라 영업팀, 인사팀, 다른 본부 사람들과도 두루두루 친하게 지내셨다. 내가 절차상의 승인을 받아야 할 때 팀장님께서 '제가 말해놓을게요'라고 하면 일사천리로 일이 해결되었다. 200명 가까이 되는 큰 조직에서 팀장님의 네트워크는 굉장히 넓었고 신뢰관계가 두터웠다. 그렇다고 사내 정치를 한다는 느낌은 전혀 없었다. 그저 팀장님은 모두에게 적당히 맞춰주면서 신뢰를 쌓고, 경험에서 우러나오는 강한 확신을 주는 사람이었다.
그동안 소규모의 조직에서만 일해와서 신뢰관계를 쌓는 일이 중요한 줄 몰랐는데, 협업에 있어서 신뢰관계는 상당히 중요함을 알게되었다. 신뢰관계가 만들어지면 이후의 커뮤니케이션은 너무나 수월해지기 때문이다. 상대방이 불쾌하지 않게 다가가는 연습도 꾸준히 하고 있다. 회사에서 만나는 사람에게 반갑게 인사하고, 도움을 요청하면 흔쾌히 도와주고, 회사 욕도 들어가주는 것들도 업무의 연장선이 맞다.
4. 배경과 맥락도 이야기 하자
배경과 맥락만 정확하게 공유하고 합의한다면, 훨씬 더 좋은 결론을 내릴 수 있다.
기획 미팅을 할 때 대표, 디자이너 그리고 개발팀 리더분만 합류해 프로덕트의 목적이나 방향성에 대해 논의했다. 기획 미팅에서 나온 결론들을 토대로 기획서를 작성해 개발팀 전체에 공유하는 자리를 가지면 '왜 이런 식으로 기획했는지' 개발자의 질문이 너무 많거나, 기획서를 온전히 이해하지 못해 질문도 못하는 개발자도 있었다. 1년차 주니어에 사수없이 기획을 해왔던 터라 결론만 공유하면 알아서 개발해줄거라 생각한 것은 나의 오만이었다. 그 뒤로 기획의 배경과 맥락을 설명하기 위해 Use Sceanario를 상세히 작성하거나 경쟁 서비스를 시연하면서 개발자들이 100% 이해할 수 있도록 다양한 시도를 했다.
회사에서 배경과 맥락을 강조하는 커뮤니케이션은 '여러분! 이건 중요한 일입니다. 그러니 잘 도와주세요!' 라는 메시지의 완곡한 표현이라고 볼 수 있다. 이해화 협조 외에도 '우리 같이 더 나은 방향성을 생각해보자'라는 의도로 배경과 맥락을 사용할 수 있다.
* 배경: "회사의 많고 많은 문제 중에 왜 이 문제에 집중하려고 하는지"
* 맥락: "그래서 지금 다양한 데이터와 상황을 분석해보니 현재는 구체적으로 이런 상태다"
이 내용은 회의를 진행할 때도 적용해볼 수 있다. 회의 참석자들에게 '이 회의가 왜 필요한지', '어떤 걸 논의해야하는지'를 이해시키고 아이디어를 끄집어내기 위해서는 회의 전에 배경과 맥락을 공유해야한다. 회의는 단순히 토론하는 시간이 아니라 더 좋은 결론을 짓기 위해 모든 이해관계자들이 시간내어 모이는 것임을 잊지 말자.
5. 소통 프로세스를 정의하자
체계적이고 합의할 수 있는 프로세스를 통해 누구와 함께 일하건 예측 가능한 방식으로 질 좋은 커뮤니케이션을 한다.
회사에는 다양한 직군이 있지만, 그 직군들이 또 다시 하나의 부서로 팀을 가진다. 규모가 큰 회사는 기획팀, 개발팀, 디자인팀 등 유사 직군끼리 부서로 나누고 본부장 - 과장 - 대리 - 사원이라는 직급을 가진다. 서열이 엄격한 회사는 우리팀 팀장님께 컨펌받은 후 다른 팀 팀장님께 공유하고, 해당 부서 팀장님이 팀원들에게 공유하면 그제서야 미팅을 진행할 수 있었다. 다이렉트로 개발자님께 미팅을 요청해 기획서를 공유드려도 되지만, 기획팀장님과 개발팀장님은 프로덕트에 돌아가는 상황을 전부 알아야 하니까 보고가 필요했다. 반면 내가 창업할 당시에는 팀 전체가 4명이 전부라서 언제 어디서든 모일 수 있어 빠르게 의사결정이 가능했다. 조직이 바뀌면 그 조직에 적절한 소통 프로세스가 필요하고 익숙해져야함을 깨달았다. 우리 기획팀은 디자인팀 마케팅팀과 데일리미팅을 진행했지만, 개발팀도 함께 했으면 프로덕트의 진행 방향에 대한 이해가 더 잘 되지 않았을까하는 아쉬움이 항상 있었다. 그래도 PO인 기획팀장님께서 진행상황을 빠르게 공유해줘 작업하는 데는 무리가 없었다.
또 아쉬웠던 점은 기획 / 개발 / 영업팀이 매주 월요일마다 팀장회의를 했지만, 기획이란 게 개발이나 영업 상황에 따라 매일 바뀌기 때문에 개발팀은 '언제까지 개발하면 되나요?', 영업팀은 '신기능 배포 언제 되나요?'라는 질문을 굉장히 많이 들었다. 안타까운 건 사원이었던 나도 의사결정이 어떻게 바뀌었는지 모를 때가 많아서 결국 팀장님께 여쭤봐야했다. 또한 본부의 모든 사람이 문서나 업무 내용을 공유하는 공간이 따로 없었다. 기획, 개발팀은 Jira와 Confluence, MS Teams를 사용했지만 디자인팀, 영업팀은 이메일이나 메신저를 사용했다. 이것도 몹시 정신없고 해야할 일을 놓쳐서 급하게 처리한 적도 있었다. 가장 기본적인 소통 프로세스가 정립되지 못하니까 내 업무의 우선순위를 결정하는 것도 어려웠다. 이렇게 큰 조직에서 일하는 게 처음이라 어떤 게 정답인지는 찾지 못했지만, 소규모 프로덕트 팀에서는 반드시 소통 프로세스를 합의하고 프로젝트를 진행하려 한다.
나는 Google Workspace를 자주 쓰는 편이다. 그 이유는 아래처럼 협업을 위한 기능이 많기 때문이다.
1. 그룹 메일을 생성해 팀원들의 개인 이메일을 등록할 수 있다.
2. Google meet으로 원격 회의가 가능하다.
3. Calender로 일정을 공유하고 일정 10분 전 알림을 보낼 수 있다.
4. Goolge Chat 그룹 및 개인 대화가 가능하다.
5. 공유 드라이브로 파일 관리가 가능하다.
6. 이메일, 채팅, 드라이브를 넘나들며 검색이 가능하다.
이 외에 Notion이나 Jira&Cofluence, Slack, Discord를 써봤는데 동시에 여러 개를 쓰는 것보다 Google Workspace + Notion, Jira&Cofluence + Slack 등 필요한 조합을 찾아서 쓰는 게 좋았다. 그리고 최근에는 Figma에 기획서 내용을 작성하거나, QA에 필요한 프로토타입을 만드는 등 새로운 프로세스도 탐색 중이다. Figma의 댓글기능으로 실시간 의사결정을 해보는 것도 좋을 것 같다.
그래도 각 문서마다 버전관리를 제대로 하고, 데일리미팅이나 주간회의를 통해 최신 버전으로 협업할 수 있도록 하는 게 중요하다.
6. 액션을 만들어내는 드라이버가 될 것
내게 주어진 업무를 주체적으로 이해하고 실행해내겠다는 주도성
커뮤니케이션의 최종 목적인 '명확한 행동'을 만들어내기 위해서는 나도 결과물을 만들어내야 한다. 프로덕트 매니저는 커뮤니케이션의 결과물로 기획서로 작성하고 공유해서 메이커들의 피드백을 받아야 한다(커뮤니케이션은 끝나지 않고 지속된다). 나는 보통 기획 공유 회의에서 다음 회의 일정을 픽스하고, 다음 회의 때까지 기획서를 보완해 사전에 공유한다. PM이 작성한 기획서는 곧 법이 된다. 이말 즉슨 디자이너는 기획서를 바탕으로 UI/UX 디자인을 하고, 개발팀도 기획서를 바탕으로 서버를 구축하고 API를 생성한다. 나중에 개발 완료된 걸 봤을 때 a라는 기능이 없어 개발팀에 물어보면 '기획서에 없었어요'라는 답변을 들을 수도 있다. 그렇기에 PM은 기획서를 신중하고 꼼꼼하게 작성하고 메이커들에게 완벽히 이해시켜야 한다. PM으로서 본인의 기획에 책임감을 갖고 주도적으로 메이커들과 협업해 프로덕트를 완성시키기 위해 커뮤니케이션은 필수불가결이다. 이 주도성이 커뮤니케이션의 핵심이라고 볼 수 있다.
커뮤니케이션은 경험에서 충분히 쌓을 수 있다고 생각한다. 부딪혀보고 깨지는 것을 두려워 말고, 일단 시작해보자. 실패라고 생각한 경험들로부터 배울 수 있는 것은 많다.
주니어 기획자들 파이팅!
참고
https://brunch.co.kr/@zseo/53
이 글을 바탕으로 프로덕트 매니저가 갖춰야할 커뮤니케이션 역량에 대해 깊이 있게 다뤄보았습니다.
'기획' 카테고리의 다른 글
| 전자의무기록(EMR: Electronic Medical Record) (0) | 2025.01.16 |
|---|---|
| CX 고객 만족도평가 구글폼으로 간편하게 (0) | 2024.11.27 |
| 기획자가 알려주는 구독하면 좋은 뉴스레터 (1) | 2021.07.08 |
| 안녕하세요. 송에디터입니다. (2) | 2021.06.27 |
댓글