brunch

매거진 서비스 기획과 UX 디자인

라이킷 35 댓글

You can make anything
by writing

C.S.Lewis

계정을 잊어버리셨나요?

by 김일간 Aug 09. 2024

좋은 프로덕트 매니저(PM)의 세 가지 조건

서비스 기획 이야기

누군가는 개발 관련 지식이 필요하다고 말한다. 누군가는 사용자 관점을 이해할 수 있어야 한다고 말한다. 누군가는 보고나 커뮤니케이션을 잘해야 한다고 말한다.

모두 맞는 말이고, 훌륭한 PM을 만드는데 도움이 되는 중요한 요소이다. 하지만 어딘가 핵심을 빗겨나간 말 같다. 가장 근본적인 목표를 생각해 보면 답은 쉽게 구해진다. 매우 간단하다.

프로덕트를 성공시키는 사람이 좋은 PM이다.

프로덕트를 성공시키기 위해 어떤 것들이 중요할까? 내가 생각하는 프로덕트의 성공을 위해 필요한 것들이자 PM의 가장 중요한 덕목들이다.

1. 프로덕트가 나아갈 방향과 현재 위치를 알고 있다.
2. 그 방향으로 사람들을 움직일 수 있다.
3. 그리고 어떻게든 그 끝에 도달하는 사람. (거기 도달하도록 무엇이든 다 하는 사람)

1. 프로덕트가 나아갈 방향과 현재 위치를 알고 있다.

프로덕트가 성공하기 위한 핵심 가치를 알고 있다.

궁극적으로 프로덕트가 나아가야 할 방향을 정할 수 있다.

프로덕트 진행 단계별로 무엇을 달성해야 하는지 알 수 있다.

모든 프로덕트가 성공할 수는 없다. 성공하지 못하는 과제가 더 많다. 하지만 성공 가능성이 낮은 프로덕트를 시도하는 것은 출발부터 틀렸다. 성공하기 위해서는 당연히 성공할만한 프로덕트로 시작해야 한다. 좋은 서비스를 만들 수 있는 핵심 가치가 무엇인지 정할 수 있어야 한다. 그리고 궁극적으로 프로덕트가 나아갈 방향은 어디인지 그리고 그 경로 중간 마일스톤들은 무엇인지 정할 수 있어야 한다. 물론 처음부터 완벽한 계획을 세울 수는 없다. 그래도 매 순간 모두를 설득할 수 있는 계획이 있어야 한다. 그래서 계속 검토하고 업데이트하며 그 생명을 계속 유지시켜야 한다.

2. 그 방향으로 사람들을 움직일 수 있다.

필요한 리소스를 알아낼 수 있다.

그 리소스를 제공할 수 있는 사람들을 설득할 수 있다.

과제가 진행되는 동안 이해관계자들의 동기를 부여할 수 있다.

혼자 프로덕트를 만들어 낼 수 없다. 사람이 더 필요하거나 투자가 필요할 것이다. 이렇게 필요한 자원들이 투입되어 원하는 방향의 프로덕트를 만들어내도록 사람들을 움직일 수 있어야 한다. 단순 커뮤니케이션 능력과는 조금 다르다. 리소스를 얻기 위한 설득은 커뮤니케이션에 가깝겠지만, 그 이후 리소스를 관리 감독하고 이해관계자들을 동기부여하기 위한 리더십까지 포함한다.

가끔 PM이 본인도 왜 해야 하는지 모르지만 상사의 지시라며 업무 협조를 구하는 경우가 있다. 이해가 안 가는 것은 아니다. 하지만 이해관계자들에게 할 말은 아니다. 내부적으로 다시 검토해 논리를 갖춰 설득하는 것이 최선일 것이다. 거기까진 어렵다면 프로덕트에 믿음을 가진 척이라도 하자. 그래야 이제부터 시간과 자원을 투자해야 하는 사람들이 속는 셈 동기부여가 될 테니 말이다.

3. 그리고 어떻게든 그 끝에 도달하는 사람. (거기 도달하도록 무엇이든 다 하는 사람)

끝에 도달하기 위해서는 필요한 것이 두 가지 있다.

1) 현재 가장 중요한 문제가 무엇인지 알아내고 해결한다.

먼저 앞으로 잘 가고 있는지 확인이 필요하다. 만약 진행이 멈춰있다면, 무엇이 발목을 잡고 있는지 알아낼 수 있어야 한다. 지속적으로 병목이 무엇인지 확인하자. ‘그런데 그 병목이 제 업무가 아니면요?’라고 물을 수도 있다. 억울함이 이해된다. PM은 원래 억울한 자리다. 어쩔 수 없다. 전화를 하든 가서 직접 만나든 이야기를 듣고 상황을 파악해서 할 수 있는 뭐든 다해 앞으로 나아가게 해야 하는 게 PM인 것이다.

과제 중 도저히 예산 안에서 서비스 로직이 불가능해 보이던 과제가 있었다. 개발팀에선 방안이 떠오르지 않는다고 했다. 당신이라면 어떻게 하겠는가? 어차피 답은 둘 중 하나다. 답을 찾아내거나, 아니면 과제를 중단하거나. 그러니 어쩌겠는가. 개발팀을 집에 못 가게 새벽까지 붙잡고 이틀간 서비스 로직을 만들어냈다. 만들어내지 못했으면 그냥 과제는 없어졌을 것이다.

2) 누가 해야 할지 모르는 일들을 처리해 준다.

개발팀, 디자인팀, 마케팅팀처럼 R&R이 정해진 업무 말고 출시를 위해 누군가는 해야 하는 일이 있어. 그건 프로덕트의 주인인 PM의 몫이야.

첫 조직장이 머릿속에 새겨준 문구다. 꼭 맞는 말은 아닐 수도 있지만, 이렇게 생각하는 게 편하다. 각자 R&R이 명확한 유관부서들은 본인 업무를 잘 마치면 끝이다. 하지만 PM의 역할은 ‘프로덕트가 성공하는 것’이다. 그러므로 프로덕트가 잘못되면 그 책임 또한 PM에게 있다. 그렇기에 잘못되지 않도록 온갖 노력을 다 해야 한다. 갈등이 있다면 찾아서 조율을 해야 하고, 어느 부서도 아닌 Gray 영역의 업무가 있다면 본인이 해치우거나 설득해서 유관부서에 요청해야 한다. 아마 대부분 직접 하게 될 것이다. ‘왜 나만 R&R이 명확하지 않아서 고생을 하는 것 같지?’라는 생각이 들 수도 있다. 이해한다. 어쩌겠는가. 집주인이니 쓰레기를 정리하는 거라 생각하면 차라리 마음이 편할 것이다.

PM업무는 힘들고 어렵고 뭐가 많다. 이름부터 얼마나 두리뭉실한가. 아무리 일해도 눈에 잘 띄지도 않는다. 눈에 보이는 디자인이나 실체화를 해주는 개발업무도 아니다. 그래서 종종 이런 생각이 들 것이다. ‘내가 뭐하는지 모르겠어.’. 나도 이런 고민으로 눈에 보이는 것을 만들고자 디자이너 업무를 시작했었다.

하지만 PM의 가치 또한 분명하다. PM은 다른 부서처럼 작업 결과물 하나하나가 성과는 아니다. 그 프로덕트 자체의 흥망성쇠가 결과물이다. 그러니 당장은 답답하고 하는 일들이 사소해 보이더라도 견뎌내 보자. 사용자들이 우리 프로덕트를 사용하는 그 순간 그 완성된 집합체 자체가 당신의 공이다. 그리고 프로덕트의 역사 또한 당신 것이다. 그러니 조급해하지 말고 멀리 보고 힘내보자.

프로덕트의 역사 또한 당신 것

퇴근 후에도 옆에서 끙끙대고 있는 와이프 및 세상의 모든 PM들을 다시 한번 응원한다.

브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari