프로덕트 매니저는 실제로 무엇을 하는가
프로덕트 매니저의 업무에 대한 가장 간결한 정의는 조쉬 엘만(Josh Elman)의 말에서 나옵니다: "팀(과 회사)이 사용자에게 올바른 제품을 출시하도록 돕는 것." 이 한 문장에는 대부분의 직무 기술서보다 더 많은 뉘앙스가 담겨 있습니다. 모든 단어가 중요하며, 이를 하나씩 분석하면 이 역할이 진정으로 요구하는 것이 드러납니다.
프로덕트 매니저 업무의 5가지 구성요소: 팀을 돕고, 회사에 기여하고, 출시하고, 올바른 제품을 만들고, 사용자를 위해 하는 것.
팀을 돕다
뛰어난 프로덕트 매니저는 팀을 전진시키는 가장 중요한 업무에 모든 관심을 쏟습니다. 이는 두 가지 핵심 기능으로 나뉩니다.
첫 번째는 조율입니다: 팀이 함께 계획하고, 명확한 목표를 가지고 결정을 내리며, 가장 중요한 것에 집중하도록 하는 것입니다. 두 번째는 커뮤니케이션입니다: 특히 계획이 변경될 때, 모두가 무엇이 일어나고 있는지, 언제 일어나는지, 왜 일어나는지를 이해하도록 하는 것입니다. 최고의 PM은 모든 팀원의 의견을 수집하고, 갈등을 초기에 표면화하며, 필요할 때 결정을 내리고, 팀 전체가 계획에 합의하도록 합의를 이끌어냅니다.
이것은 보스가 되는 것이 아닙니다. PM은 함께 일하는 사람들에 대한 직접적인 권한을 거의 갖지 않습니다. 그들의 영향력은 명확성, 신뢰, 그리고 똑똑한 사람들을 같은 방향으로 이끄는 능력에서 나옵니다.
회사에 기여하다
프로덕트 매니저는 진공 상태에서 일할 수 없습니다. 회사의 전반적인 목표와 목적을 이해하고, 팀의 작업이 전체 그림에 어떻게 맞아들어가는지를 파악해야 합니다. 최고의 PM은 자신의 팀이 독자적인 비전을 추구하기보다는 다른 팀들과 협력하여 더 큰 조직에 기여한다고 봅니다.
이는 비즈니스 모델을 이해하고, 회사 차원에서 성공이 어떻게 정의되는지를 알고, 팀이 출시하는 작업이 그러한 성과에 기여하도록 하는 것을 의미합니다. 사용자를 기쁘게 하지만 비즈니스를 약화시키는 기능은 좋은 제품 결정이 아닙니다.
출시하다
사용자의 손에 제품을 전달하는 것보다 더 중요한 것은 없습니다. 뛰어난 프로덕트 매니저는 완벽하게 만드는 것과 빨리 내보내는 것 사이의 긴장을 이해합니다. 그들은 사용자와 사용자가 달성해야 할 것에 대한 명확한 이해를 가지고 있기 때문에 올바른 트레이드오프를 내릴 수 있습니다. 출시는 단순히 속도에 관한 것이 아닙니다. 범위, 품질, 타이밍에 대해 정보에 기반한 결정을 내리는 것입니다.
올바른 제품을 만들다
빠르게 출시하는 것은 잘못된 것을 출시하면 아무 의미가 없습니다. 최고의 PM은 무엇이 맞고 틀린지에 대한 강한 직감을 가지고 있으며, 테스터와 사용자의 초기 피드백을 종합하는 효과적인 경청자입니다. 더 중요한 것은, 제품 출시 후 그것이 올바른 제품이었는지를 평가하고, 그렇지 않을 때 빠르게 방향을 수정할 수 있다는 것입니다.
여기서 프로덕트 디스커버리가 등장합니다. 마티 캐이건(Marty Cagan)이 설명한 바와 같이, 프로덕트 디스커버리는 가치 있고(사용자가 원하는), 사용하기 쉽고(사용자가 이해할 수 있는), 실현 가능하며(엔지니어링이 만들 수 있는), 비즈니스적으로 타당한(비즈니스에 도움이 되는) 솔루션을 찾는 과정입니다. 이 네 가지 테스트가 프로덕트 관리의 핵심입니다.
사용자를 위해 하다
제품을 만드는 데 있어 가장 어려운 부분은 주요 사용 사례를 명확히 하는 것입니다: 누가 이것을 사용해야 하고, 왜 사용해야 하는가. 최고의 PM은 제품에 대한 모든 대화에서 사용자의 대변인 역할을 합니다. 이를 위해서는 타겟 사용자, 그들의 문제, 불만, 그리고 제품이 어떻게 가치를 전달해야 하는지에 대한 깊은 이해가 필요합니다.
PM이 자신의 사용자가 누구이고 제품이 어떤 문제를 해결하는지 명확하게 설명할 수 없다면, 나머지 모든 것이 무너집니다. 사용자 옹호는 있으면 좋은 스킬이 아닙니다. 전체 역할이 기반하는 토대입니다.
프로덕트 관리 삼각형
PM 역할을 이해하는 데 가장 유용한 멘탈 모델 중 하나는 댄 슈미트(Dan Schmidt)가 설명한 프로덕트 관리 삼각형입니다. 핵심 통찰은 프로덕트 관리가 크로스 펑셔널 팀 사이의 "빈 공간을 채우는 것" 또는 "접착제 역할을 하는 것"이라는 것입니다. 제품을 출시할 때 다양한 사람과 기능이 관여하며, 역할 사이에 자연스럽게 공백이 생깁니다. PM의 업무는 그 공백을 찾아 메우는 것입니다.
프로덕트 관리 삼각형은 개발자, 사용자, 제품, 비즈니스 사이의 세 가지 빈 공간 영역을 보여줍니다.
이 다이어그램은 소프트웨어 제품 맥락의 기본 요소를 매핑하는 "프로덕트 네트워크"를 보여줍니다. 어떤 회사에서든 이 네트워크에 빠진 연결고리가 있으며, 그 연결고리가 채워지면 제품이 더 잘 기능하고 더 안정적으로 성공합니다.
프로덕트 매니저의 책임은 프로덕트 네트워크의 네 가지 영역을 모두 건강하게 유지하는 것입니다. 이는 어떤 빈 공간이 가장 중요한지를 인식하고, 직접 그 연결고리 역할을 하거나 채울 방법을 찾는 것을 의미합니다. 이것이 PM이 웹 분석부터 프로젝트 조율, 사용자 리서치까지 다양한 영역에서 역량을 갖춰야 하는 이유입니다.
영역 A: 개발자, 제품, 사용자 사이
사용자와 개발자는 제품을 근본적으로 다른 방식으로 봅니다. 사용자는 인터페이스를 통해 상호작용합니다. 개발자는 코드를 봅니다. 이 멘탈 모델 사이의 격차가 마찰을 만들며, 디자이너가 종종 이를 연결하는 역할을 합니다. 하지만 디자이너가 없거나, 격차가 시각적 요소가 아닌 행동에 관한 것일 때, PM이 이 두 관점 사이를 번역하는 역할을 맡습니다.
영역 B: 사용자, 제품, 비즈니스 사이
이 영역은 사용자가 제품에서 발견하는 가치가 수익으로 전환되는 곳입니다. 비즈니스 모델에 따라 이 영역은 단순할 수도 있고(직접 구독) 매우 복잡할 수도 있습니다(여러 이해관계자 유형이 있는 마켓플레이스). PM은 양쪽 모두를 이해해야 합니다: 사용자가 무엇을 가치 있게 여기는지, 그리고 비즈니스가 그 가치를 어떻게 포착하는지.
영역 C: 개발자, 제품, 비즈니스 사이
이 영역은 회사가 자원과 노력을 어떻게 배분하는지를 결정합니다. 엔지니어링 역량은 유한하며, PM은 그 역량이 어디에 투입되어야 하는지를 결정하는 데 도움을 줍니다. 이를 위해서는 무언가를 만드는 기술적 비용과 그것을 출시하는 비즈니스 가치를 모두 이해해야 합니다.
프로덕트 관리 삼각형은 PM 직무 기술서가 왜 불가능할 정도로 광범위해 보이는지를 설명합니다. 역할 자체가 본질적으로 광범위합니다. 제품을 만드는 사람, 사용하는 사람, 그리고 그것에 의존하는 비즈니스 사이에 존재하는 모든 공백을 커버하기 때문입니다.
프로덕트 관리가 아닌 것
프로덕트 관리에서 가장 큰 과제 중 하나는 많은 회사들이 이 역할이 실제로 무엇을 포함하는지 오해한다는 것입니다. 마티 캐이건(Marty Cagan)은 가장 흔한 오해에 대해 광범위하게 글을 써왔으며, 프로덕트 관리가 아닌 것을 이해하는 것은 프로덕트 관리가 무엇인지를 이해하는 것만큼이나 중요합니다.
비즈니스 케이스를 정의하는 것이 아니다
일부 PM은 비즈니스 케이스와 ROI 예측을 만드는 데 시간을 보냅니다. 이 작업에는 나름의 역할이 있지만, 제품을 만드는 데 직접적으로 기여하지는 않습니다. 비즈니스 케이스는 경영진이 투자 결정을 내릴 수 있도록 존재합니다. 이것은 커뮤니케이션 도구이지, 프로덕트 관리 활동이 아닙니다. 대부분의 시간을 비즈니스 케이스에 쓰는 PM은 프로덕트 매니저가 아닌 비즈니스 분석가로 기능하고 있는 것입니다.
시장 요구사항을 정의하는 것이 아니다
많은 조직은 PM의 업무가 시장 요구사항을 정의하고, 엔지니어링이 이를 구현하는 것이라고 믿습니다. 이러한 분리는 피드백 루프를 끊는 핸드오프를 만들기 때문에 위험합니다. 제품 정의를 담당하는 사람은 사용자와 고객에게 직접 이야기해야 합니다. 그리고 목표는 프로덕트-마켓 핏을 찾는 것이며, 이는 시장 니즈와 기술적 역량을 동시에 이해해야 합니다. 시장 요구사항과 제품 요구사항을 분리하는 것은 잘못된 구분입니다.
요구사항 수집이 아니다
진정한 프로덕트 조직은 고객이 해결해야 할 문제를 가지고 있다는 것을 이해하지만, 고객이 제품 사양을 지시할 수는 없다는 것도 이해합니다. 고객 요구사항("팀의 진행 상황을 추적할 방법이 필요합니다")은 제품 요구사항("간트 차트를 만들어라")과 다릅니다. 이 둘을 혼동하면 PM이 최선의 솔루션을 발견하는 대신 주문만 받는 기능 공장(Feature Factory)이 됩니다.
프로젝트 관리가 아니다
일부 회사에서 PM은 요구사항을 수집하고, 문서화하며, 기획부터 배포까지 작업을 조직합니다. 이것은 프로젝트 관리이며, 정당하고 중요한 분야입니다. 하지만 프로덕트 관리와 프로젝트 관리를 구분하는 것은 프로덕트 디스커버리입니다: 가치 있고, 사용하기 쉽고, 실현 가능하며, 비즈니스적으로 타당한 솔루션을 찾는 과정. 디스커버리 없이는 단순히 전달 파이프라인을 관리하는 것에 불과합니다.
프로덕트 마케팅이 아니다
가격 책정, 프로모션, 포지셔닝, 메시징, 런칭 활동은 모두 핵심 기능입니다. 하지만 이것은 프로덕트 관리가 아니라 프로덕트 마케팅의 책임입니다. PM은 작동하는 제품을 발견하는 것에 책임이 있습니다. 그 제품이 시장에서 어떻게 포지셔닝되고 판매되는지는 별도의 기능이며, PM이 마케팅 팀과 긴밀하게 협업해야 하는 부분이긴 합니다.
직급별 핵심 PM 스킬
개인 기여자(좌)와 매니저(우)의 프로덕트 매니저 커리어 경로. 각 레벨에서 스킬 요구사항이 크게 달라집니다.
XO Group 프레임워크는 브렌트 트워레츠키(Brent Tworetzky)가 상세히 설명했으며, 프로덕트 관리를 7가지 스킬 영역으로 나눕니다. 각 영역은 PM이 직급을 올라갈수록 크게 변화합니다. 이 프레임워크의 가치는 같은 스킬 영역이 어소시에이트 레벨과 디렉터 레벨에서 근본적으로 다른 것을 요구한다는 것을 명확히 보여준다는 점입니다.
스킬 1: 전략적 사고
PM 직급별 전략적 사고 요구사항.
전략적 사고는 점점 더 큰 문제와 제품 영역에 대한 답을 이끌어내는 능력이며, 그에 상응하는 전문성을 갖추는 것입니다. 여기에는 브레인스토밍, 체계적 사고, 전략 추진, 해당 분야의 전문가가 되는 것이 포함됩니다.
어소시에이트 레벨에서는 다른 사람들과 건설적으로 브레인스토밍할 수 있어야 합니다. 전략을 세울 것까지는 기대되지 않지만, 문제를 체계적으로 생각하고 사용자에게 공감할 수 있다는 것을 보여줘야 합니다. 시니어 레벨에서는 자신의 제품 영역에 대한 전략을 정의하고 다른 사람들이 사용할 수 있는 프레임워크를 구축할 것이 기대됩니다. 디렉터 레벨 이상에서는 전체 프로덕트 라인의 전략적 방향을 설정하고 회사 전체의 우선순위에 영향을 미칩니다.
"전략에 기여하는 것"에서 "전략을 정의하는 것"으로의 전환은 PM 커리어에서 가장 어려운 전환 중 하나입니다. 문제를 이해하는 것에서 문제를 프레이밍하는 것으로 넘어가야 하며, 이 둘은 매우 다른 인지적 스킬입니다.
스킬 2: 커뮤니케이션
PM 직급별 커뮤니케이션 요구사항.
커뮤니케이션은 점점 더 크고 이해관계가 높은 청중에게 명확하게 글과 말로 소통하는 것을 의미합니다. 여기에는 명확한 이메일 작성, 효과적인 대면 소통, 프레젠테이션 작성 및 발표가 포함됩니다.
커뮤니케이션은 모든 레벨에서 중요하지만, 이해관계는 크게 달라집니다. 어소시에이트 PM은 명확한 스펙을 작성하고 팀에 업데이트를 공유해야 합니다. 시니어 PM은 임원진에게 발표하고 크로스 펑셔널 이해관계자를 정렬시켜야 합니다. 디렉터는 전체 조직에 비전을 전달하고 외부에서 제품을 대표해야 합니다.
PM에게 가장 과소평가되는 커뮤니케이션 스킬은 경청입니다. 최고의 PM은 정보를 전달하는 것보다 흡수하는 데 더 많은 시간을 보냅니다. 그들은 더 좋은 질문을 하고, 다양한 출처의 의견을 종합하며, 결정이 내려지기 전에 팀의 모든 목소리가 반영되도록 합니다.
스킬 3: 협업
PM 직급별 협업 요구사항.
협업은 점점 더 많은 퍼실리테이션과 팀 내외에서 다른 사람들과 함께 일을 해내는 것입니다. 여기에는 미팅에 적극적으로 참여하기, 미팅 리딩, 팀 프로세스 운영, 다른 팀과의 문제 해결, 갈등을 적절히 예방하고 해소하는 것이 포함됩니다.
어소시에이트 레벨에서는 참여합니다. PM 레벨에서는 리드합니다. 시니어 레벨 이상에서는 팀 간, 임원진과의 협업을 퍼실리테이트합니다. 핵심적인 변화는 팀 내의 협력자에서 조직 전체의 연결자로 전환하는 것입니다.
상위 레벨의 PM은 조직 정치를 탐색하면서도 스스로 정치적이 되지 않는 기술이 필요합니다. 이것은 미묘한 균형입니다: 결정이 어떻게 내려지고 영향력이 어떻게 흐르는지를 이해하면서도, 협업을 가능하게 하는 신뢰와 투명성을 유지해야 합니다.
스킬 4: 기술
PM 직급별 기술 스킬 요구사항.
기술 스킬은 프로덕트 관리와 파트너 기능(엔지니어링, 디자인)의 도구를 사용하여 팀 전체에서 잘 협업하는 것을 의미합니다. 여기에는 유저 스토리 작성, 분석 수행, 프로토타입 구축, SEO 이해가 포함됩니다.
미드 레벨에서도 PM은 프로토타입을 성공적으로 만들 수 있어야 합니다. 이것은 프로덕션 코드를 작성하라는 것이 아니라, 디자인과 엔지니어링의 도구에 충분히 익숙하여 추상적이 아닌 구체적으로 아이디어를 전달할 수 있어야 한다는 것입니다.
기술 스킬 영역에는 데이터 리터러시도 포함됩니다. 모든 PM은 분석 도구에 익숙하고, 메트릭을 정의하고 추적하는 방법을 이해하며, 데이터에 기반한 의사결정을 내릴 수 있어야 합니다. 레벨이 올라갈수록 엔지니어링 리더와 기술적 트레이드오프에 대해 의미 있는 대화를 나눌 수 있을 정도로 시스템 아키텍처를 이해해야 합니다.
스킬 5: 디테일과 품질
PM 직급별 디테일과 품질 요구사항.
이 스킬 영역은 점점 넓어지는 범위에서 결과를 이끌어내고 실수를 잡아내는 것을 다룹니다. 여기에는 유스 케이스가 포함된 명확한 스펙 작성, 제때 적은 버그로 제품 전달, 장애물이 발생했을 때 옵션 탐색, 성과 달성이 포함됩니다.
어소시에이트 레벨에서는 범위가 작습니다. 개별 기능에 대한 스펙을 작성하고 전달합니다. 품질 기준은 단순합니다: 기능이 사양대로 작동하는가? 시니어 레벨에서는 범위가 전체 제품 영역으로 확대됩니다. 품질 기준은 "작동하는가"에서 "의도한 결과를 달성하는가"로 바뀝니다. 디렉터 레벨에서는 여러 팀과 제품 전반의 품질에 책임을 지게 되며, 이는 규모에 맞게 품질을 유지하는 시스템과 프로세스를 구축하는 것을 의미합니다.
스킬 6: 사용자 과학과 공감
PM 직급별 사용자 과학과 공감 요구사항.
사용자 과학은 사용자를 더 잘 이해하고 사용자의 니즈와 행동에 제품을 맞추기 위한 툴킷을 마스터하는 것입니다. 여기에는 설문조사, 인터뷰, 프로토타이핑, A/B 테스트, 분석 도구, 다양한 사용자 유형 이해, 리서치를 인사이트로 종합하는 것이 포함됩니다.
사용자에 대한 공감은 모든 레벨에서 기초적입니다. 레벨이 올라가도 덜 중요해지지 않는 유일한 스킬입니다. 달라지는 것은 이를 적용하는 정교함입니다. 어소시에이트 PM은 개별 사용자와 대화하고 배운 것을 보고합니다. 시니어 PM은 사용자 세그먼트 전반의 패턴을 식별하고 이를 제품 전략으로 번역합니다. 디렉터는 프로덕트 조직 전반에 사용자 중심 문화를 구축합니다.
최고의 PM은 사용자 리서치를 제품 개발 과정의 한 단계가 아닌 지속적인 실천으로 대합니다. 새로운 기능을 계획할 때뿐만 아니라 매주 사용자와 대화합니다.
스킬 7: 매니지먼트
PM 직급별 매니지먼트 요구사항.
매니지먼트는 사람과 조직을 성공적으로 성장시키는 것을 의미합니다. 여기에는 멘토링, 관리, 팀 성장, 조직 성장이 포함됩니다.
어소시에이트와 PM 레벨에서는 다른 PM을 관리하지 않기 때문에 이 스킬이 필수는 아닙니다. 디자이너, 엔지니어, 다른 팀원들은 당신에게 보고하지 않습니다. 하지만 시니어 레벨에 도달하면 주니어 PM을 멘토링하기 시작하고 소규모 팀을 이끌 수도 있습니다. 디렉터 레벨 이상에서는 매니지먼트가 주요 책임이 되며, 당신의 임팩트는 당신이 이끄는 사람들의 성장과 결과물로 측정됩니다.
개인 기여자에서 매니저로의 전환은 PM에게 특히 도전적입니다. 뛰어난 IC를 만들어준 스킬들(깊은 제품 직감, 직접적 참여, 세부사항에 대한 관심)이 다른 사람들에게 그러한 스킬을 개발시키는 것이 업무가 될 때 오히려 약점이 될 수 있기 때문입니다. 이 커리어 전환에 대한 자세한 내용은 프로덕트 매니저 커리어 경로 가이드를 참고하세요.
프로덕트 매니저에게 기술적 스킬이 필요한가
이것은 예비 PM들이 가장 자주 하는 질문 중 하나이며, 대부분의 조언보다 답이 더 미묘합니다.
프로덕트 매니저가 되기 위해 기술적 배경이 필요하지는 않습니다. 디자인, 마케팅, 컨설팅, 저널리즘 등 수많은 다른 분야에서 온 성공적인 PM들이 있습니다. 프로덕트 관리의 핵심은 사용자를 이해하고 사용자와 비즈니스 모두에 적합한 솔루션을 출시하는 것입니다. 여기에 컴퓨터 공학 학위가 필요하지는 않습니다.
하지만 여기에 뉘앙스가 있습니다: 기술적 소양은 당신을 더 나은 PM으로 만듭니다. 프로덕션 코드를 작성할 필요는 없지만, 엔지니어와 의미 있는 대화를 나눌 수 있을 정도로 소프트웨어가 어떻게 작동하는지 이해해야 합니다. 무엇이 쉽고, 무엇이 어렵고, 무엇이 불가능한지를 알아야 합니다. 엔지니어가 "6주 걸릴 것입니다"라고 말할 때 추정치를 부풀린 것인지 정말로 복잡한 문제에 직면한 것인지 판단할 수 있어야 합니다.
프로덕트 관리는 디자인, 비즈니스, 기술의 교차점에 있습니다. 이 세 가지 중 하나에 강하고 나머지 두 가지를 배울 의지가 있다면, 견고한 기반을 갖추고 있는 것입니다. PM에게 가장 도움이 되는 핵심 기술 개념은 다음과 같습니다:
- 데이터 구조와 API: 시스템을 통해 데이터가 어떻게 흐르는지 이해하면 더 나은 제품 결정을 내리고 더 명확한 요구사항을 작성할 수 있습니다.
- SQL과 분석: 분석가를 기다리지 않고 직접 데이터를 쿼리할 수 있으면 더 빠른 피드백 루프와 더 날카로운 직감을 얻을 수 있습니다.
- 기본 웹 기술: HTML, CSS, JavaScript가 어떻게 작동하는지 알면 프론트엔드가 무엇을 할 수 있고 없는지를 이해하는 데 도움이 됩니다.
- 시스템 아키텍처: 서비스, 데이터베이스, 인프라가 어떻게 연결되는지 이해하면 기술적 트레이드오프를 평가하는 데 도움이 됩니다.
일부 PM 역할, 특히 테크니컬 프로덕트 매니저 포지션은 특정 기술 스킬을 요구합니다. 하지만 대부분의 PM 역할에서는 호기심과 배우려는 의지가 기존의 기술적 자격증보다 더 중요합니다.
PM과 기술 스킬의 관계는 PM과 디자인 스킬의 관계와 유사합니다. 디자인 작업이 필요한 제품을 관리합니다. 직접 디자인을 하지는 않겠지만, 디자인 원칙에 대한 이해가 깊을수록 디자이너와 더 효과적으로 협업하고 더 높은 품질의 기여를 할 수 있습니다.
프로덕트 매니저를 위한 감성 지능
줄리아 오스틴(Julia Austin)의 프로덕트 매니저 평가 프레임워크는 세 가지 요소를 식별합니다: 핵심 역량, 감성 지능(EQ), 회사 적합성. 이 세 가지 중 감성 지능이 가장 간과되지만 아마도 가장 큰 영향을 미칩니다.
핵심 역량은 가르칠 수 있습니다. 회사 적합성은 평가할 수 있습니다. 하지만 감성 지능은 로드맵을 관리할 수 있는 PM과 팀에 영감을 주고, 조직의 복잡성을 탐색하며, 사용자에게 진정으로 공감을 얻는 제품을 만들 수 있는 PM 사이의 차이입니다.
다니엘 골먼(Daniel Goleman)은 감성 지능의 네 가지 핵심 특성을 정의했으며, 각각은 PM 역할에 직접적으로 매핑됩니다.
관계 관리
이것은 성공적인 PM의 가장 중요한 속성이라고 할 수 있습니다. 프로덕트 매니저는 전적으로 영향력을 통해 일합니다. 엔지니어, 디자이너, 데이터 사이언티스트에 대한 직접적인 권한이 없습니다. 사람들에게 동기를 부여하고 최고의 결과를 이끌어내는 능력은 내부 및 외부 이해관계자와 정직하고 신뢰할 수 있는 관계를 구축하는 것에 달려 있습니다.
최고의 PM은 관계가 필요하기 전에 관계에 투자합니다. 기술적 제약을 존중함으로써 엔지니어와 신뢰를 쌓고, 사용자 경험을 옹호함으로써 디자이너와 신뢰를 쌓고, 일관된 결과를 전달함으로써 임원진과 신뢰를 쌓습니다. 어려운 결정이 올 때, 그리고 언제나 오게 마련인데, 그러한 관계가 PM이 팀을 정렬하고 전진할 수 있게 해주는 것입니다.
자기 인식
PM은 객관성을 유지하고 개인적 선호를 고객에게 투영하는 것을 피할 만큼 자기 인식이 높아야 합니다. 이것은 간단하게 들리지만, 실제로는 유지하기 가장 어려운 규율 중 하나입니다. 모든 PM은 제품이 어떠해야 하는지에 대한 의견을 가지고 있으며, 그 의견이 쉽게 판단을 흐릴 수 있습니다.
자기 인식이 부족한 PM은 사용자가 필요로 해서가 아니라 자신이 개인적으로 원하기 때문에 기능을 밀어붙일 수 있습니다. 그 기능이 좋은 성과를 내지 못하면, 검증되지 않은 것을 만드는 데 시간을 투자한 엔지니어들에 대한 PM의 신뢰성이 손상될 수 있습니다. 자기 인식은 "내가 이것이 옳다고 생각한다"와 "증거가 이것이 옳다고 보여준다"의 차이에 대해 정직하게 만들어줍니다.
자기 관리
최고의 PM은 올바른 우선순위에 대해 긴급하게 적극적으로 추진하되 두려움이나 스트레스를 만들지 않는 방법을 알고 있습니다. 또한 언제 한 발 물러서서 재정비해야 하는지도 알고 있습니다. 프로덕트 관리에는 실패한 기능, 지연된 출시, 효과가 없는 전략 등 좌절이 가득합니다. 자기 관리는 그러한 좌절을 겪으면서도 효과적으로 일할 수 있게 해줍니다.
이것은 자신의 에너지와 집중력을 관리하는 것도 포함합니다. PM은 매일 많은 방향으로 끌려가며, 가치 낮은 업무에 가차 없이 우선순위를 매기고 거절하는 능력은 시간이 지남에 따라 복리 효과를 내는 자기 관리의 한 형태입니다.
사회적 인식
프로덕트 매니저는 모든 이해관계자 그룹의 감정과 우려를 이해해야 합니다: 제품에 불만을 가진 사용자, 그것을 팔아야 하는 영업팀, 문제를 해결해야 하는 지원팀, 그리고 그것을 만들어야 하는 엔지니어. 사회적 인식은 상황을 정확하게 파악하고, 말하지 않는 우려를 이해하며, 각 청중이 필요로 하는 것에 맞게 접근 방식을 조정하는 것을 의미합니다.
이 스킬은 프로덕트-마켓 핏과 직접적으로 연결됩니다. 사회적으로 인식이 높은 PM은 설문조사에서 사용자가 말하는 것뿐만 아니라 실제로 느끼는 것에 맞춰져 있기 때문에, 사용자의 진짜 해결해야 할 과업(Jobs to be Done)을 다루는 제품을 만듭니다. 또한 서로 다른 팀이 같은 제품 결정을 어떻게 경험하는지 이해하기 때문에 내부 역학도 더 효과적으로 탐색합니다.
회사 적합성: 환경이 PM 역할을 형성하는 방식
"프로덕트 매니저"라는 같은 직함이 다른 회사에서는 완전히 다른 의미를 가질 수 있습니다. 회사 환경이 역할을 어떻게 형성하는지 이해하는 것은 일할 곳을 선택하는 PM과 프로덕트 기능을 설계하는 조직 모두에게 중요합니다.
PM-엔지니어링 역학
프로덕트 관리와 엔지니어링 사이의 관계는 PM의 일상 업무가 어떻게 생겼는지를 결정하는 가장 큰 요인입니다. 세 가지 일반적인 모델이 있습니다.
PM이 엔지니어링을 주도하는 모델. 이 모델에서 PM은 요구사항을 수집하고, 제품 요구사항 문서를 작성하고, 엔지니어링에 구현을 넘깁니다. 이 "벽 너머로 던지기" 접근 방식은 명확한 소유권을 만들지만, 엔지니어링이 디스커버리에 참여하지 않았기 때문에 기술적으로 최적화되지 않은 솔루션을 만들어낼 때가 많습니다. 이 모델의 PM은 대부분의 시간을 요구사항과 사양서에 씁니다.
엔지니어링이 제품을 주도하는 모델. 기술 중심 회사(클라우드 인프라, 데이터 플랫폼, 네트워킹)에서는 엔지니어가 기술을 발전시키고 PM이 프론트엔드 인터페이스나 시장 진출 전략을 설계합니다. 이 모델의 PM은 강한 기술 스킬과 복잡한 기술을 사용자 친화적 가치로 번역하는 능력이 필요합니다.
PM-엔지니어링 파트너십 모델. 이것이 대부분의 현대 프로덕트 조직이 지향하는 모델입니다. PM과 엔지니어링은 공동 디스커버리, 공동 의사결정, 상호 책임을 가진 협력적 관계를 맺습니다. 엔지니어가 고객 인터뷰에 참여합니다. PM이 스프린트 미팅에 참석하여 작업 차단을 해소하고 요구사항을 명확히 합니다. 이 모델이 가장 좋은 결과를 만들지만, 양측의 강한 신뢰와 커뮤니케이션이 필요합니다.
스타트업 vs. 성숙한 회사
회사의 단계는 PM 역할을 근본적으로 바꿉니다.
스타트업에서는 PM의 범위가 방대합니다. 디스커버리, 정의, 출시 외에도 가격 책정, 마케팅, 지원, 심지어 영업까지 담당할 수 있습니다. 모호함 속에서 성장하고, 잦은 방향 전환에 편안하며, 자원이 제한적이라는 것을 받아들여야 합니다. 장점은 상당합니다: 회사 전략에 참여할 가능성이 높고, 경영진과 이사회에 접근할 수 있으며, 더 큰 임팩트의 가능성을 가진 더 큰 리스크를 감수할 수 있는 자유가 있습니다. 단점도 현실적입니다: 멘토십이 거의 없고, 롤 모델이 적으며, 확립된 모범 사례가 거의 없습니다.
성숙한 회사에서는 PM 역할이 더 정의되어 있습니다. 가격 책정, 시장 진출, 기타 기능을 담당하는 전담 인력이 있습니다. 더 많은 구조와 지원을 갖춘 큰 프로덕트 관리 팀의 일원입니다. 장점은 더 나은 멘토링, 더 명확한 프로세스, 확립된 모범 사례입니다. 단점은 회사 전략에 대한 가시성이 제한될 수 있고, 제품 방향에 대한 영향력이 적으며, 더 많은 조직 정치를 탐색해야 할 수 있다는 것입니다.
창업자 관계
초기 단계 회사에서 창업자, CEO, CTO의 제품 개발 참여도는 중요한 요인입니다. 창업자가 제품에 깊이 관여한다면, PM 역할은 지원 기능에 더 가까울 수 있습니다: 창업자의 아이디어를 구체화하고, 고객과 컨셉을 검증하고, 전략을 주도하기보다는 실행을 관리하는 것입니다.
이것은 비전을 가진 창업자와 긴밀하게 협력하는 것을 즐기는 PM에게는 보람 있을 수 있습니다. 하지만 제품 방향에 대한 더 많은 소유권을 원하는 PM에게는 좌절감을 줄 수 있습니다. 그리고 기술 지향적인 창업자가 엔지니어와 직접 일하는 것을 선호한다면, PM은 가장 중요한 결정에서 소외될 수 있습니다.
합류하기 전에 이러한 역학을 이해하는 것이 필수적입니다. 인터뷰에서 물어보세요: CEO가 일상적인 제품 결정에 얼마나 관여하는가? 로드맵에 대한 최종 결정권은 누구에게 있는가? PM이 새로운 방향을 탐색할 수 있는 자율성이 얼마나 되는가?
다음 단계
이 가이드는 프로덕트 관리를 정의하는 역할과 스킬을 다루지만, 커리어 여정 자체에는 고유한 도전과 기회가 있습니다. PM에서 시니어 PM으로의 전환, 프로덕트 리더십으로의 도약, 개인 기여자와 매니지먼트 트랙 사이의 선택 모두 각기 다른 결정과 스킬 변화를 수반합니다.
어소시에이트 프로덕트 매니저부터 최고제품책임자(CPO)까지의 전체 커리어 래더, 업계에 진입하는 방법, 승진하는 방법, 가장 어려운 전환을 탐색하는 방법에 대한 자세한 내용은 컴패니언 가이드를 읽어보세요: 프로덕트 매니저 커리어 경로: APM에서 CPO까지.
Frequently Asked Questions
프로덕트 매니저는 매일 실제로 무엇을 하나요?
프로덕트 매니저의 일상 업무는 매우 다양하지만, 일반적으로 사용자 리서치, 데이터 분석, 크로스 펑셔널 미팅, 로드맵 기획, 스펙 작성이 혼합되어 있습니다. 통합하는 주제는 의사결정입니다: PM은 사용자, 엔지니어, 디자이너, 이해관계자로부터 정보를 수집한 후 그 정보를 명확한 제품 결정으로 종합하며 하루를 보냅니다. 최고의 PM은 깊은 작업(디스커버리, 전략, 작성)을 위한 시간을 보호하면서도 팀의 차단을 해소하고 프로젝트를 추진하기에 충분히 접근 가능하도록 시간을 구조화합니다.
프로덕트 매니저와 프로젝트 매니저의 차이는 무엇인가요?
근본적인 차이는 디스커버리입니다. 프로젝트 매니저는 정해진 계획의 실행을 조율하며, 일정, 자원, 결과물을 관리하여 제때, 예산 내에 무언가를 출시합니다. 프로덕트 매니저는 사용자 리서치, 시장 분석, 반복적 디스커버리를 통해 처음에 무엇을 만들어야 하는지 알아내는 것에 책임이 있습니다. 프로덕트 매니저는 "무엇을"과 "왜"를 소유합니다. 프로젝트 매니저는 "어떻게"와 "언제"를 소유합니다. 실제로 PM은 특히 작은 회사에서 프로젝트 관리 책임을 맡는 경우가 많지만, PM 역할의 핵심은 실행 관리가 아닌 디스커버리와 의사결정입니다.
신입 프로덕트 매니저에게 가장 중요한 스킬은 무엇인가요?
프로덕트 관리에 진입하는 사람에게 가장 레버리지가 높은 스킬은 사용자 공감, 명확한 커뮤니케이션, 분석적 사고입니다. 실제 문제를 식별할 수 있을 만큼 사용자를 깊이 이해하고, 크로스 펑셔널 팀을 정렬할 수 있을 만큼 명확하게 소통하며, 결과를 측정하고 데이터에 기반한 결정을 내릴 수 있을 만큼 분석적으로 사고해야 합니다. 전략적 사고와 매니지먼트 스킬은 레벨이 올라갈수록 더 중요해지지만, 커리어 초기에는 실제 사용자 문제를 해결하는 기능을 출시하는 능력이 신뢰를 쌓고 기회를 열어줍니다.
프로덕트 매니저가 되려면 기술적 배경이 필요한가요?
아니요, 대부분의 PM 역할에 기술적 배경은 필수가 아닙니다. 성공적인 프로덕트 매니저는 디자인, 마케팅, 컨설팅, 운영 등 다양한 분야에서 옵니다. 하지만 기술적 소양, 즉 소프트웨어 시스템이 개념적 수준에서 어떻게 작동하는지 이해하는 능력은 당신을 더 효과적으로 만듭니다. 코드를 작성할 필요는 없지만, 엔지니어와 생산적인 대화를 나눌 수 있을 만큼 기술적 트레이드오프를 이해해야 합니다. 테크니컬 프로덕트 매니저와 같은 일부 전문화된 역할은 특정 기술 스킬을 요구하지만, 이것은 전체 PM 역할의 일부에 불과합니다.
프로덕트 관리와 프로덕트 마케팅은 어떻게 다른가요?
프로덕트 관리는 사용자 문제를 해결하는 제품을 발견하고, 정의하고, 출시하는 데 초점을 맞춥니다. 프로덕트 마케팅은 시장에서 제품을 포지셔닝, 메시징, 가격 책정, 런칭하는 데 초점을 맞춥니다. PM은 "무엇을 만들어야 하고 왜 만들어야 하는가"에 답하고, 프로덕트 마케팅은 "만든 것의 가치를 어떻게 전달할 것인가"에 답합니다. 실제로 두 기능은 긴밀하게 협력합니다: PM은 프로덕트 마케터에게 사용자와 제품의 가치 제안에 대한 깊은 지식을 제공하고, 프로덕트 마케터는 PM이 시장 포지셔닝, 경쟁 역학, 시장 진출 전략을 이해하도록 돕습니다.
프로덕트 매니저에게 감성 지능이 왜 중요한가요?
프로덕트 매니저는 전적으로 영향력을 통해 일합니다. 엔지니어, 디자이너, 또는 다른 팀원에 대한 직접적인 권한이 없으므로, 효과적으로 일하려면 신뢰를 쌓고, 상황을 정확하게 파악하고, 직위적 권력 없이 사람들에게 동기를 부여해야 합니다. 감성 지능은 PM이 리서치 중 사용자에게 공감하고, 원한을 만들지 않으면서 팀 내 의견 차이를 조율하고, 개인적 선호와 사용자 니즈가 충돌할 때 객관성을 유지하며, 크로스 펑셔널 협업을 가능하게 하는 장기적 관계를 구축할 수 있게 합니다. EQ가 낮은 기술적으로 뛰어난 PM은 EQ가 높은 기술적으로 평범한 PM이 겪지 않는 방식으로 어려움을 겪게 됩니다.
스타트업과 대기업에서 프로덕트 매니저 역할은 어떻게 다른가요?
스타트업에서 PM은 여러 역할을 동시에 수행합니다. 같은 주에 프로덕트 디스커버리, 가격 책정, 고객 지원, 심지어 영업까지 처리할 수 있습니다. 범위가 넓고, 자원이 제한적이며, 역할은 공식적인 직무 기술서보다 필요한 것에 의해 정의됩니다. 대기업에서 PM 역할은 더 전문화되어 있습니다. 가격 책정, 시장 진출, 분석 등을 위한 전담 팀이 있습니다. 확립된 프로세스와 커리어 래더를 갖춘 큰 프로덕트 조직 안에서 일합니다. 트레이드오프는 명확합니다: 스타트업은 구조와 멘토십을 포기하는 대가로 더 많은 자율성과 폭넓은 학습을 제공하고, 대기업은 범위와 속도를 포기하는 대가로 더 많은 지원과 전문화를 제공합니다.
프로덕트 관리 삼각형이 유용한 프레임워크인 이유는 무엇인가요?
프로덕트 관리 삼각형이 유용한 이유는 PM 역할을 책임 목록에서 구조적 기능으로 재정의하기 때문입니다. "PM이 무엇을 하는가"를 묻는 대신, "제품을 만드는 사람, 사용하는 사람, 그것에 의존하는 비즈니스 사이의 공백은 어디에 있는가"를 묻습니다. 이 프레이밍은 PM 직무 기술서가 왜 불가능할 정도로 광범위해 보이는지를 설명합니다: 역할이 조직에 존재하는 빈 공간에 의해 정의되기 때문입니다. 또한 PM 역할이 왜 회사마다 그렇게 다른지도 설명합니다. 서로 다른 조직에는 서로 다른 공백이 있기 때문입니다. 이 프레임워크는 어떤 순간에 어떤 공백을 메우는 것이 가장 중요한지를 파악하여 PM이 우선순위를 정하는 데 도움을 줍니다.