프로덕트 매니저, 1986년의 다케우치와 노나카가 팀을 럭비 스크럼에 비유하다

이 역할의 뿌리는 1931년 프록터앤갬블(P&G)의 한 메모로 거슬러 올라간다. 당시 한 젊은 임원이 하나의 제품이 성공하도록 경쟁시키기 위해 개별 '브랜드 담당자'를 배정하자고 제안한 것이다. 1980년대부터 기술 기업들이 이 직함의 한 형태를 차용했고, 2000년대와 2010년대의 애자일·린 운동이 다시 한 번 이 직무를 재편했다. 길고 상세한 명세서 대신 빠르고 반복적인 출시와 끊임없는 고객 피드백으로 방식이 바뀐 것이다. '프로덕트 매니저'라는 말은 이 직함을 쓰는 회사마다 거의 다른 의미를 갖는다. 어떤 곳에서는 전략가이고, 어떤 곳에서는 그럴듯하게 포장된 프로젝트 조율자이며, 같은 주 안에 두 가지 역할을 동시에 맡기도 한다. 전 세계 어디에도 이 직함을 관장하는 자격증이나 시험, 전문 단체는 없고, 채용공고도 저마다 다르다. 이 직업을 하나로 묶는 것은 자격증이 아니라, '무엇을 만들 가치가 있는가'에 대해 반복적으로 내려야 하는 일련의 판단들이다.

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

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