2년 차 프로덕트 매니저의 회고-3(完)

자투리 이야기들

쓰다 보니 글이 너무 길어져 3부작으로 나눴다.

1부에서는 '나'에 대한 이야기를 했다.

2부에서는 프로덕트 매니저로 지내며 정리한 이야기를 일부 했다.

3부에서는 남은 이야기들을 할 예정이다.

1부 보기 ☞ https://brunch.co.kr/@327roy/19 

2부 보기 ☞ https://brunch.co.kr/@327roy/20

---

줄타기는 우리의 숙명

줄타기는 프로덕트 매니저의 숙명이다. (사실 어떤 직무들, 어떤 일이든 사람은 줄타기를 잘해야 하지만)

예를 들어, 백오피스의 어떤 기능에 대해서 세일즈팀이 개선 요청을 했다고 가정하자. 하지만 기획의 우선순위가 높다고 판단된 백로그들이 많이 쌓여있는 상황이다. 당장 그 기능을 기획하고 개발하기엔 운영팀에서 요청한 것이 더 급하다고 판단된다.

세일즈팀에게 설명 후, 개선을 당장 하지 않았다. 어쩌다 팀장 회의에서 세일즈팀에게 생산성이 떨어진 이유를 묻자 프로덕트 매니저가 개선을 미뤄버린 기능 때문이라고 한다.

그 기능으로 인해 진짜 생산성이 떨어졌을 수도 있다. 개선을 마뤘을 때 드는 비용과 긴급성 측면으로 봤을 때 운영팀의 요청을 먼저 수행한 판단이 틀리지 않았다고 생각하지만, 결국 그들의 생산성 하락 원인은 프로덕트 매니저로 익식된다.

혹은 세일즈팀의 요청이 우선순위가 높다 판단되어 앞서 들어온 요청보다 먼저 개선을 진행해 배포까지 완료했다. 이 때문에 운영팀에서 요청한 기능 개선이 후순위로 밀려버렸다. 어쩌다 팀장 회의에서 운영팀에게 생산성이 떨어진 이유를 묻자 프로덕트 매니저가 후순위로 개선을 미뤄버린 기능 때문이라고 한다. (두둥)

따라서 뭘 먼저 기획할 것인가, 어느 팀의 요청을 먼저 수용할 것인가 등과 같은 의사결정을 위한 줄타기는 프로덕트 매니저의 숙명이라고 생각한다. 이로부터 오는 압박감이 분명 존재할 것이다. 적당한 압박감 업무 수행의 텐션을 높이기 때문에 원동력이 될 수 있지만, 감당하지 못할 압박감은 프로덕트 매니저를 탈진 상태로 만들고 번아웃을 부를 수 있다.

나는 이 압박감을 관리하기 위해 모든 일들의 명분을 만들고 이를 통해 당위성을 챙기려고 한다. 언제 이 요청을 들었고, 무엇을, 왜 이렇게 판단해서 어떻게 하겠다를 명확하게 정리한 후 이를 이해관계자에게 인지(혹은 납득)시킬 수 있다면, 그들의 호소가 들어왔을 때 그들의 감정케어만 잘해주면 된다.

단, 만들어진 명분을 책임 회피를 위한 변명으로 사용하지 말자.

줄타기는 언제나 어렵다.

많이 배우고 재밌었던 경험, 업무의 시스템화

21년도 8월에 입사하고 난 뒤로 좋은 사수님과 멋진 팀원들을 만나며 정말 폭발적으로 성장했다. 입사하고 1년쯤 뒤 플랫폼의 PO로 계시던 사수님이 퇴사하게 되며 플랫폼에 대한 상당 부분의 오너십이 나에게 몰리기도 했고, 이 시기에 새로운 프로덕트를 기획하여 론칭하는 풀사이클을 경험을 하기도 하고, 기존 플랫폼을 리뉴얼하는 대규모 프로젝트의 기획 책임이 되는 등 정말 다양한 경험을 할 수 있었다.

이 경험들 중 인상 깊었던 것은 당연 최근에 회고록으로 업로드하기도 했던 업무 시스템화다. 아래 업무 시스템화의 목적, 목표는 23-01-11에 실무자 리뷰 미팅에서 실무자들에게 백오피스를 왜 만드는지, 무엇을 위해서 만드는지를 설명할 따 사용한 내용을 요약한 것이다.

1. ○○ 업무 시스템화의 목적   

업무의 생산성 향상

2. ○○ 업무 시스템화의 목표   

중복되는 데이터 재사용, 상태값 관리의 자동화 등을 통한 수동 공임 제거

파편화된 업무 프로세스의 표준화

데이터 관리를 통해 누수 데이터 방지

확장성을 고려한 시스템 구축

그래서?

IT 서비스의 최종 산출물은 개발자를 거쳐서 나온다. 하지만 개선해야 하는 문제들은 세일즈팀, 운영팀 혹은 서비스 고객(소비자) 등 다양한 곳에서 쏟아진다. 결국 프로덕트 매니저는 그들이 페인포인트와 니즈, 이를 해결하기 위한 방안을 잘 정의하고 이것을 개발자가 만들어낼 수 있도록 명세서를 작성할 수 있어야 한다. 마치 요리를 위한 레시피를 만드는 것처럼 말이다.

이 외에도 프로덕트 매니저는 세일즈팀처럼 말을 잘하기도 해야 하고, 운영팀처럼 프로덕트에 대한 운영도 할 줄 알아야 한다. 개발팀만큼은 아니지만 코드의 흐름은 이해할 수 있어야 하고, 디자인팀처럼 UXUI에 대한 지식도 있어야 한다. (모든 일을 그들보다 잘해야 한다고 생각하는 것은 아니다. 잘하는 것은 잘하는 사람에게 맡기면 된다. 단 그들보다 우리가 잘해야 하는 것은 이 모든 설명을 글로 풀고 문서화할 수 있어야 한다는 것 정도.)

명확하게 프로덕트 매저의 Role이 구분된 큰 규모의 회사는 다를 수 있겠지만, 적당한 규모의 회사에서 프로덕트 매니저에게 '이것까지?' 하는 업무들이 쏠릴 수 있다. 예를 들어 "서비스 운영을 프로덕트 매니저가 하는 것이 맞을까요?" 같은 것. 내 대답은 "정답은 없습니다."다. (기획에 집중했을 때 나는 성과가 운영 담당자를 채용했을 때 드는 비용을 상회한다는 것을 정량화할 수 있다면 인사 담당자에게 운영 담당자를 채용해 달라고 말할 명분이 충분히 생길 것이다.)

'PM들의 수다'라는 직무 톡방에서 항상 많은 인사이트를 주시는 시니어 기획자 분 께서 한 말이 와닿아서 인용해 본다.

"제품을 잘 만들기 위해 기획하고 제작하는 것만 기획자나 PM의 역할이 아니라, 궁극적으로는 그 제품이 잘 알려져서 활용되고, 고객에게 가치를 주어야 하는 것이 목표라면 해야 하는 역할은 상당히 넓고 많을 수 있다."

우리는 항상 이해관계자들의 중심에 있는다. 각자가 어떤 말을 하는지 다른 관계자에게 그들의 말로 번역해 전달하는 메신저이나 프로덕트를 개선하고 관리하는 관리자다. 그래서 프로덕트 매니저는 정말 매력적인 직무다.

업무 등을 얘기하거나 논의하고 싶은 것이 있다면 편히 메일 주셨으면 좋겠다. 긴 이야기를 끝까지 읽어주신 분들께 스페셜 땡쓰!

앞으로 더 많은 고객들을 마주하고 더 좋은 경험을 선사하는 날을 기대하며 회고록을 마친다.

ⓒ 327roy