프로덕트 매니저, 실제로 뭘 하는 걸까?
기획자, PO, PM 무슨일을 하는데요?
나는 첫 커리어를 퍼블리셔로 준비했었다. 기획자라는 포지션이 있는지도 몰랐었다.
'IT가 전망이 좋다니까' 라는 막연한 생각을 가지고, 또 개발은 너무 어려울 것 같고 디자이너는 너무 박봉일 것 같아, 적당히 쉽고 코드를 다루는 게 멋져보여서 퍼블리셔를 해보자! 하고 마음을 먹었던 것 같다.
그러다 퍼블리셔로 취업한 첫 회사에서 일이 없으니 PPT나 사업자료만 만들 게 시켰었는데, 지금의 기획자를 만들어준 마중물이 되었다.
기획자? 무슨일 하는데?
주변에 나를 소개할 때 '기획자'라고 하면, "그게 정확히 뭘 하는 건데?"라고 물어보면 답하기 조금 애매했다. 대충 "앱이나 웹페이지 만들기 전에 기획하는 사람인데 디자이너,개발자들이랑도 일해~!" 정도로만 이야기 했던 것 같다.
최근 여행 플랫폼에서 API 연동을 담당하는 프로덕트 매니저로 이직하게 되면서, 회사마다 같은 기획이라도 분류가 다른 걸 많이 느낀다.
심지어 같은 롤인데 Product Manager, Product Owner, Project Manager 등등 회사 안에서도 천차만별로 불려진다.
지금도 뭐라고 딱 정의하긴 어렵지만, 이 글이 끝날 때쯤엔 "아~ 이런 일 하는 구나" 알 수 있을 것이다.
끊임없이 듣고 끊임없이 해석하기
기획자에게 기록은 필수 ©unsplash내 경우엔 내부 사업부나 채널사들의 니즈를 파악하는 게 일의 큰 부분을 차지한다.
사업부에서 "이런 기능이 있어야해요", "이런 부분이 개선되어야해요" 라고 말씀을 주시면,
기존 구조를 보고 정말 구현이 가능한건지, 어떻게 구현해야하는지를 계속 고민한다.
수시로 들어오는 운영업무와 구축업무. "이 기능을 먼저 만들까, 저 기능을 먼저 만들까" 우선순위를 정하는 것도 만만치 않다. 이젠 연차도 어느정도 있어서 데이터를 보고, 내부 팀 의견을 듣고, 구현방향을 설정하고 개발자들과 커뮤니케이션 해 구현일정을 체크한다.
정말 많은 의견을 듣기 때문에, 상대방이 이렇게 말한 의도가 뭘지, 또 그래서 나의 결론은 뭔지를 정리해야한다. 나의 결론을 가지고, 팀과 사업부에 의견을 제시하고 수정하고 추진한다.
이렇게 많은 일이 들이 닥치니 시간분배도 시간분배인데, 이제는 좀 더 넓은 관점에서 "이걸 왜 해야하지?"를 계속 고민하게 된다.
왜 해야하고, 이걸 하면 우리에게 어떤 득이 있는거지? 비즈니스 임팩트는 어떻게 나타나지? 를 잠깐이라도
계속 고민하는 습관을 들이고 있다.
이걸 고민하고, 안하고의 차이는 성장의 갭차를 크게 만드는 것이라는 걸 계속 느끼고 있기 때문이다.
서로 다른 목소리를 하나로 만들기
기획자가 성장하기 위해서는 욕을 많이 먹으면 된다는 우스갯소리도 있다ㅎ ©unsplash개발팀과 사업부, 채널사가 항상 같은 방향을 보고 있는 건 아니다. 각자 중요하게 생각하는 게 다르니까.
그래서 프로덕트 매니저는 이 모든 팀이 하나의 목표를 향해 갈 수 있도록 조율해야 한다.
업무를 하다 보면 개발팀은 기술적 완성도를 중요하게 생각하고, 사업부는 빠른 출시를 원한다.
특히나 각 채널사들은 비즈니스적으로 자기들에게 유리한 방향이 되도록 기능 추가를 요청하는 경우도 있다.
이처럼 각자 추구하는 방향이 다 다르기 때문에, 우리 회사의 관점에서 내줄 수 있는 부분인지 아닌지에 대한 판단이 필요하다. 내주고 더 득볼 수 있는 거면 내주지만, 손해보는 선택이라고 하면 거절도 해야한다.
결국 모든 의견을 종합해야하지만, 스스로의 근거가 있어야한다.
최근 신규 기능을 도입해야한다는 목소리가 나왔다. 근데 기존 기능의 작동 방식이 너무 복잡해서 말로만 오가는 회의에서 서로 설명하다가 헷갈리고 회의가 너무 길어지는 문제가 있었다.
또 다음주에 같은 회의를 하면 서로 이해하고 있는 게 달라, 싱크를 맞추는 게 너무 오래걸렸다.
그래서 들은 내용 중 이해가 되지 않는 부분은 개발팀과 사업부 담당자에게 각각 미팅을 요청해 로직을 이해했고, 피그마로 도식화해서 기존 로직의 싱크를 맞췄다.
그렇게 하니 회의시간이 줄었고, 같은 생각을 공유하게 되었다.
이후로도 말로 로직 구현 방식에 대해 계속 논의되던 걸, 프로세스로 도식화해서 TO-BE는 이렇게 구현되어야한다고 설명하니 사업부도 개발쪽도 이해하기가 쉬워졌고, 다들 복잡해했던 로직을 정리해 싱크를 맞췄다.
1시간이 걸리던 회의도 30분이면 정리가 되었고, 같은 얘기를 반복하지 않고 향후 방안을 논의하게 되어 업무가 효율적으로 진행되고 있다.
소통이 얼마나 중요한지 모른다. 모든 사람이 같은 제품 비전을 이해하고 있는지, 우선순위에 대해 합의가 이루어졌는지 계속 확인해야 한다. 어떻게 보면 번거로울 수 있지만, 이게 없으면 각자 다른 방향으로 가버리기에 기획자는 우리 팀이 모두 ONE TEAM으로 ONE GOAL을 바라보고 일할 수 있도록 해야한다.
프로덕트 매니징, 힘들어도 좋은 이유
유튜브 하늬모하늬결국 이 일을 하려면 비즈니스와 제품 양쪽 모두에 대한 이해가 필요하다. 제품 개발 과정에 대한 지식, 의사소통 능력, 그리고 어느 정도의 기술적 이해도 있어야 한다. 문서 작성과 발표도 중요한 업무 중 하나다.
지금은 아니지만 이전 직장에서는 비즈니스 케이스, 시장 분석, 제품 로드맵 같은 걸 만들어도 보았고, 경쟁사 분석이나 제품 비교 자료도 필요하다면 준비해야 한다.
회사는 비용을 투자하고, 투자한 만큼의 성과를 내야하는 게 당연하다.
따라서 어떤 제품을 만들기 전, 이걸 만듦으로써의 비즈니스 임팩트는 어떻게 되고 이에 대한 확신이 섰다면
어떻게 구현하고, 어떻게 관리하겠다를 설득하기 위한 많은 지식과 준비가 필요하다.
프로덕트 매니징은 정말 만능인 사람만 할 수 있는 거 아닌가 하는 생각도 든다.
힘들지만, 이 일이 재밌고. 이뤄낸 게 많을 수록 내가 점차 꽉 찬 사람이 되어가는 그 느낌이 좋다.
그리고 모르는 게 많다고 느낄 수록 더 공부하게 되고, 더 많이 물어보고, 아직 배울 수 있는 게 이렇게나 많다는 게 행복하다.
특히 동료들이, 나와 일하는 사람들이 나와 일하고 커뮤니케이션하는 걸 즐거워하는 게 가장 좋다.
프로덕트 관리 뿐만 아니라, 이해관계 조율, 부서 간 협업, 기술적 지식, 사업적인 관점도 배우게 된다.
배우고 성장할수록 더 높은 단계로 올라갈 기회도 많아질 거라 믿는다.
