프로덕트 매니저, 1950년대의 일본에서 도요타의 치프 엔지니어 체계가 형성되다

직함에서 연상되는 것보다 '만드는' 일은 훨씬 적다. 전형적인 하루는 사용 데이터를 검토하고, 고객이나 영업팀과 무엇이 필요한지 이야기하고, 엔지니어를 위한 명세서를 작성하거나 다듬고, 다음에 무엇을 만들고 무엇을 뺄지 정하는 기획 회의에 참석하는 것으로 채워진다. 코드를 작성하거나 화면을 그리거나 직접 무언가를 출시하는 일은 하루 중 극히 일부에 불과하다. 필요하지 않지만, 소프트웨어 비중이 큰 역할에서는 도움이 된다. 많은 프로덕트 매니저가 엔지니어 출신이지만, 디자인·마케팅·컨설팅·고객 지원 출신도 상당수다. 특정 전공보다 더 중요한 것은 데이터를 읽고 명확하게 글을 쓰며, 직접 코드를 작성하지 않고도 엔지니어들과 대등하게 논의할 수 있는 능력이다.

이름은 비슷하지만 다르다. 프로젝트 매니저는 작업이 일정과 예산에 맞게 진행되는지 추적하며 팀의 일정을 조율한다. 프로덕트 매니저는 애초에 무엇을 왜 만들어야 하는지를 결정하며, 그 밑바탕이 되는 사업적·고객 관점의 논리를 책임진다. 특히 소규모 조직에서는 두 역할이 실무상 뒤섞이는 경우가 많지만, 각각이 답해야 할 핵심 질문은 서로 다르다. 국가와 회사에 따라 편차가 매우 크다. 미국의 대형 기술 기업에서는 보너스와 주식을 포함한 총 보상이 흔히 6자리 숫자를 훌쩍 넘지만, 인도나 라틴아메리카 대부분 지역에서는 같은 직무라도 그 일부에 불과하다. 주식을 제외한 기본급만 놓고 보면 같은 회사의 시니어 엔지니어 급여와 비슷한 수준인 경우가 많다.

데이터를 요약하고 명세서 초안을 작성하고 고객 피드백을 종합하는 업무는 이미 AI 도구로 더 빠르게 처리되고 있다. 자동화가 여전히 어려운 것은 애초에 어떤 아이디어를 추진할 가치가 있는지 결정하고, 의견이 엇갈리는 사람들 사이의 절충안을 협상하고, 베팅이 실패했을 때 책임을 지는 일이다. 이는 모델이 책임질 수 없는 판단 영역이다. '프로덕트 오너'는 1990년대에 등장한 스크럼 프레임워크가 정의한 구체적인 역할로, 팀의 백로그 순서를 정하는 책임을 진다. '프로덕트 매니저'는 전략, 시장 조사, 팀 간 조율을 아우르는 더 넓고 오래된 사업 직함이다. 오늘날 많은 회사가 두 용어를 혼용하지만, 둘이 공존하는 곳에서는 프로덕트 오너가 프로덕트 매니저 아래 또는 함께 일하는 경우가 많다.