프로덕트 매니저, 1997년의 벤 호로위츠가 '좋은 프로덕트 매니저, 나쁜 프로덕트 매니저'를 쓰다

이름은 비슷하지만 다르다. 프로젝트 매니저는 작업이 일정과 예산에 맞게 진행되는지 추적하며 팀의 일정을 조율한다. 프로덕트 매니저는 애초에 무엇을 왜 만들어야 하는지를 결정하며, 그 밑바탕이 되는 사업적·고객 관점의 논리를 책임진다. 특히 소규모 조직에서는 두 역할이 실무상 뒤섞이는 경우가 많지만, 각각이 답해야 할 핵심 질문은 서로 다르다. 아니다. 프로덕트 매니저에게 엔지니어나 디자이너 등이 직접 보고하는 경우는 거의 없으며, 이 일은 권한이 아니라 영향력으로 이끄는 직무로 흔히 설명된다. 프로덕트 매니저는 우선순위와 그 근거를 정하지만, 실제로 그 일을 누가 어떻게 할지는 대개 엔지니어링 매니저나 팀 리드가 결정한다.

국가와 회사에 따라 편차가 매우 크다. 미국의 대형 기술 기업에서는 보너스와 주식을 포함한 총 보상이 흔히 6자리 숫자를 훌쩍 넘지만, 인도나 라틴아메리카 대부분 지역에서는 같은 직무라도 그 일부에 불과하다. 주식을 제외한 기본급만 놓고 보면 같은 회사의 시니어 엔지니어 급여와 비슷한 수준인 경우가 많다. 데이터를 요약하고 명세서 초안을 작성하고 고객 피드백을 종합하는 업무는 이미 AI 도구로 더 빠르게 처리되고 있다. 자동화가 여전히 어려운 것은 애초에 어떤 아이디어를 추진할 가치가 있는지 결정하고, 의견이 엇갈리는 사람들 사이의 절충안을 협상하고, 베팅이 실패했을 때 책임을 지는 일이다. 이는 모델이 책임질 수 없는 판단 영역이다.

'프로덕트 오너'는 1990년대에 등장한 스크럼 프레임워크가 정의한 구체적인 역할로, 팀의 백로그 순서를 정하는 책임을 진다. '프로덕트 매니저'는 전략, 시장 조사, 팀 간 조율을 아우르는 더 넓고 오래된 사업 직함이다. 오늘날 많은 회사가 두 용어를 혼용하지만, 둘이 공존하는 곳에서는 프로덕트 오너가 프로덕트 매니저 아래 또는 함께 일하는 경우가 많다. 가능하지만 도움 없이는 드물다. 소수의 대형 기술 기업이 학부 졸업생을 바로 채용하는 선발형 '어소시에이트 프로덕트 매니저' 프로그램을 운영하며, 2002년부터 시작된 구글의 프로그램이 가장 유명하다. 이런 프로그램 밖에서는 대부분의 프로덕트 매니저가 먼저 엔지니어링, 디자인, 영업, 분석 분야에서 몇 년을 보낸 뒤 사업이 돌아가는 방식을 이해하고 나서 프로덕트 쪽으로 옮겨간다.