프로덕트 매니저

제품을 만드는 팀에 무엇을 만들지 정하는 자리가 따로 없던 시절이 있었습니다. 세일즈가 고객에게 들은 요청을 개발팀에 그대로 넘기고, 급한 것은 대표가 그때그때 정했습니다. 팀이 열 명이고 요청이 주에 두세 건일 때는 이 방식으로도 돌아갑니다.

요청이 쌓이면서 같은 자리에서 대화가 멈추기 시작했습니다. 스무 건의 요청을 두고 이번 달에 셋만 만들 수 있을 때, 어느 셋인지를 정할 사람이 회의에 없었습니다. 개발팀은 판단 근거가 없어 먼저 말한 사람의 것을 만들고, 만든 뒤에 아무도 쓰지 않으면 책임이 세일즈와 개발 사이에서 흩어졌습니다. 반년 뒤 기능은 서른 개로 늘었는데 쓰이는 것은 다섯 개인 상태가 이렇게 만들어집니다.

프로덕트 매니저는 그 빈자리를 메우려고 생긴 역할입니다. 결정을 한 사람에게 모아 두고, 그 결정이 맞았는지까지 같은 사람이 설명하게 만든 것입니다. 권한을 얹어 준 자리가 아니라 책임을 얹은 자리라는 점이 이 역할의 성격을 정합니다. 팀원 평가나 인사 권한은 대개 없고, 판단의 근거를 만들어 팀을 설득하는 방식으로 움직입니다.

하루는 숫자 확인, 회의, 문서 작성 셋으로 채워집니다. 순서는 팀마다 다르지만 하는 일은 대개 아래와 같습니다.

1. 아침에 어제 숫자를 봅니다. 새로 만든 기능을 얼마나 쓰는지, 가입한 사람이 첫 가치를 느끼는 지점까지 얼마나 도달하는지를 봅니다. 어제 12퍼센트였던 값이 오늘 4퍼센트면 그날의 일정이 바뀝니다.
2. 오전에는 만들고 있는 것에 붙습니다. 디자인 시안을 보고 애매한 조건을 정해 주고, 개발자가 물은 예외 상황에 답합니다. "결제 실패하면 어떻게 보여 줄까요" 같은 질문은 하루에 여러 번 옵니다.
3. 오후에는 결정을 글로 남깁니다. 무엇을 왜 만들고 어디까지 되면 끝인지 적은 문서가 PRD이고, 그 안의 요구를 사용자 관점 한 문장으로 쪼갠 단위가 유저 스토리입니다. 만들 후보를 모아 둔 제품 백로그의 순서도 이때 손봅니다.
4. 틈틈이 사용자와 세일즈를 만납니다. 만들 값어치가 있는지 미리 확인하는 활동을 제품 디스커버리라고 부르는데, 이 대화가 그 재료입니다.
5. 주 단위로는 우선순위 결정과 제품 로드맵 갱신이 돌아옵니다. 후보가 마흔 건이고 이번 분기에 여섯 건을 만들 수 있으면, 고른 여섯 건보다 미룬 서른네 건을 설명하는 데 시간이 더 듭니다.

코드도 화면도 직접 만들지 않아 산출물이 눈에 잘 보이지 않는 역할입니다. 하루의 결과가 결정 세 개뿐인 날이 흔하고, 그 결정이 좋았는지는 몇 주 뒤 숫자로 드러납니다.

매일 붙어 있는 상대는 디자이너와 개발자입니다. 프로덕트 디자이너와는 문제를 어떻게 풀지를 같이 정하고, 개발자와는 어디까지 이번에 만들지를 조율합니다. 이 셋이 한 묶음으로 움직이는 구성을 여러 회사가 기본 단위로 씁니다.

숫자가 필요할 때는 프로덕트 애널리스트에게 갑니다. 제품 데이터를 해석해 판단 근거를 만드는 역할인데, 가설을 세우는 쪽과 검증하는 쪽을 나눠 두면 보고 싶은 결과만 보는 일이 줄어듭니다.

요청이 들어오는 경로는 세일즈와 고객 성공 쪽입니다. 계약을 놓친 이유나 고객이 떠난 이유가 여기로 먼저 들어옵니다. 만든 것을 시장의 말로 옮겨 알리는 일은 프로덕트 마케팅 매니저가 맡고, 출시 시점과 메시지를 맞추는 대화가 그 사이에서 오갑니다. 보고선은 대개 제품 조직을 총괄하는 최고 제품 책임자로 이어집니다.

이 관계 전체에 지시 권한이 없다는 점이 이 역할의 조건입니다. 디자이너도 개발자도 프로덕트 매니저의 팀원이 아니어서, 움직이는 수단은 근거와 합의뿐입니다.

"이건 PM이 정해 줘야 다음 단계가 돌아가요."

결정이 나지 않아 디자인도 개발도 멈춰 있다는 뜻입니다.

"지현 님, 이번 건은 PRD 먼저 주시면 저희가 쪼갤게요."

요구가 글로 정리돼야 개발 단위로 나눌 수 있다는 요청입니다.

"그 요청은 이번 분기 로드맵에 못 넣었어요. 이유는 적어 뒀습니다."

미룬 판단과 그 근거를 함께 내놓는 대답입니다.

페이지덱에서 문서 공유 링크에 만료 기간을 붙여 달라는 요청이 세 분기에 걸쳐 열한 번 들어온 적이 있습니다. 수아가 그 목록을 모아 왔고, 지현이 요청한 고객들의 계약 규모와 이탈 여부를 함께 붙여 우선순위 회의에 올렸습니다.

그 자리에서 정해진 것은 만든다와 만들지 않는다가 아니라 순서였습니다. 이번 분기에는 만료 기간만 넣고 접속 기록은 다음으로 미뤘습니다. 태오가 두 기능을 함께 하면 4주가 걸리고 하나만 하면 1주라고 답했기 때문입니다. 지현은 미룬 쪽의 이유를 문서에 적어 세일즈에도 공유했습니다.

미니 CEO 라는 말을 권한으로 읽는 경우가 가장 많습니다. 제품의 방향을 정하니 작은 회사의 대표처럼 보이는 것이 자연스럽습니다. 하지만 대표와 달리 사람을 뽑거나 평가하거나 지시할 권한이 없습니다. 이 차이를 모르고 결정을 통보로 전달하면 팀은 표면적으로만 따르고, 막히는 지점을 미리 말해 주지 않는 쪽으로 바뀝니다. 그러면 결정의 품질을 떨어뜨리는 것도 같은 사람입니다.

기획서를 쓰는 사람으로 좁혀 읽는 것도 흔합니다. 눈에 보이는 산출물이 문서라서 그렇게 읽힙니다. 문서는 결정을 옮기는 수단이고, 이 역할이 지는 것은 그 결정이 만든 결과입니다. 문서를 열심히 써도 쓰이지 않는 기능이 나왔다면 그 책임은 문서를 넘겨받은 쪽이 아니라 이쪽에 남습니다.