PM 역할과 관련한 세 가지 안티 패턴
원문: Three Common PM Role Antipatterns - Itamar Gilad
1. Product Managers reporting to a non-PM Manager
이 안티패턴엔 여러가지 변형이 있음
PM이 CTO/VP 엔지니어링에게 보고함
PM이 COO/CIO에게 보고함
PM이 마케팅/세일즈 헤드에게 보고함
PM을 긴밀하게 협업하는 사람들과 같은 조직에 배치하는 것은 매력적으로 보일 수 있지만 관련해서 문제점이 존재함
프로덕트 매니저는 특별한 종류의 직무임. 엔지니어링/비즈니스/디자인에 소속되지 않음. 프로덕트 매니저는 자신의 어려움을 이해하는 시니어 PM에게 보고하고, 코칭 받고, 업무를 진행하는데 자유를 부여받을 때 가장 성과가 나옴. non-PM에게 보고하는 것은 가능하지만 흔하지 않으며 PM의 경력 성장과 성과에 제약을 줄 수 있음
일반적인 권장 사항은 CPO에게 리포팅한는 프로덕트 조직을 구성하는 것임. CPO가 공석이라면, CEO 또는 비즈니스 유닛의 general manager에게 보고하는 head of product가 PM 조직을 맡도록 함
프로덕트 매니저가 엔지니어링 매니저, 마케팅/영업 매니저에게 보고하는 것은 좋지 않은 아이디엄. 두 경우 목표가 맞지 않음. PM은 올바른 제품을 찾는데 집중해야 하는데, 딜을 성사하거나 엔지너이의 업무 효율성을 담당하는 것은 PM에게 재미없고, 조직에게 도움이 되지도 않음
2. Splitting the PM Role
프로덕트 매니저의 역할은 다양하고 다양한 접점과 일함 - 고객, 엔지니어링, 디자인, 마케팅, 영업, 경영 지원 부서. 관련해서 몇 년동안 PM의 역할을 다양한 방식으로 분리하려는 여러 시도가 있었음:
외부 고객 담당 PM vs 내부 업무 담당하는 PM
비즈니스 PM vs 테크니컬 PM
전략을 맡는 시니어 PM vs 전술을 맡는 주니어 PM
Agile Dev의 도입과 함께 Product Managers 대 Product Owners의 등장함..
프로덕트 매니지먼트 초창기엔 프로덕트 오너가 아닌 프로덕트 매니저만 존재함. 몇년 뒤 스크럼이 도입되면서 프로덕트 오너(PO) 용어 소개됨. 스크럼 내에서 가장 중요한 역할 맡으며, 엔지니어링 팀과 가까운 위치에서 고객/사용자, 이해관계자의 요구사항을 기반으로 우선순위가 정해진 제품 백로그를 관리하는 역할
이는 PM이 하는 일의 일부분에 불과함. 오늘날 PM은 market research 기반으로 요구사항을 결정하지 않음. PM은 팀과 긴밀히 협력하여 목표 달성을 위한 제품 '발견'에 관여함(discover the product that best addresses the goals). 이는 전통적인 프로덕트 오너와 상반되는 개념임
오늘날 기업들은 주로 두가지 이유에서 프로덕트 오너를 채용함. (1) 최근 스크럼 추세는 PO에게 상세한 에픽과 유저 스토리르 작성하고, 계획 세션, 회고, 데일리 스탠드업에 참석하는 등 PO에게 상당한 부담을 주고 있음. 이것은 쉽게 전문 직무가 될 수 있음. (2) 대체로 관리자들은 업무를 나누는 개념을 좋아함. strategic, outbound-facing product work은 시니어가 다루고, 프로덕트 매니저가 직접 처리하기 어려운 전술적인 업무는 PO에게 위임됨. 이는 처음 시도된 것은 아니지만, 제대로 동작한 적이 없음
전략 및 전술적 책임에 따라 프로덕트 관리 업무를 완저히 분리하는 방법은 없음. 그리고 이렇게 일을 나누는 것이 프로덕트 오너에게 좋은 작업 경험은 아님. 이에 대한 해결은 프로덕트 오너의 전술적 업무 부담을 줄이고, 전반적으로 팀 멤버에게 위임하여 프로세스 오버헤드를 줄여서 PM의 다른 중요한 기능을 맡도록 하는 것임
3. Siloing PM, Engineering, and UX
일부 기업에선 엔지니어링 또는 UX 책임자가 에이전시 모델을 활용하여 팀의 리소스를 최적화하려 함. 고정된 fixed cross-functional team은 없고, 대신 각 분기마다 goal과 로드맵에 따라 새로운 ad-hoc 팀이 구성됨.
엔지니어, 디자이너는 필요할 때마다 영역과 프로젝트를 옮겨가며 전문가가 아닌 일반 인력처럼 다뤄짐. 어떤 엔지니어링 책임자는 이러한 방식이 엔지니어가 계속해서 새로운 것을 배우면서 더 많이 참여하게 만든다고 주장함. 어떤 UX 리더는 디자이너가 cross-functional team이 아닌 디자이너와 같은 조직에서 일해야 효과적이라고 생각해서 에이전시 모델의 조직구조 선호함.
이러한 조직구조는 아래와 같은 문제를 일으킴
Misalignment - 프로덕트 매니저, UX, 엔지니어는 자신의 전문적인 목표(예: 더 많은 기능 제공, 적절한 디자인 원칙 사용, 높은 코드 품질 유지)에 더 많이 헌신할 가능성이 있음. 타협을 찾기가 더 어려움. 제품의 성공은 프로덕트 매니저의 문제가 되며, PM은 어떤 의미에서 고객으로 인식되기도 함
Lack of area expertise - 특정 제품 영역(예: 검색 또는 결제)에서 지속적으로 작업하는 엔지니어와 디자이너는 기술, 코드베이스 및 사용자 경험에 대한 전문 지식을 쌓임. 에이전시 모델에서는 많은 지식이 분산되거나 사라져서 팀의 효율성이 크게 낮아짐
Lack of team spirit - 제품 팀은 여러 주기의 제품 개발과 론칭을 통해 합이 맞춰지는데 이에 시간이 필요합니다. 이러한 팀 스프릿은 ad-hoc 팀에서는 나타나지 않습니다.
Handoffs - 이러한 작업 방식은 PM이 요구 사항을 전달하고 디자이너가 목업을 전달하고 엔지니어가 코드를 개발하는 미니-워터폴을 장려합니다. 이로 인해 지나친 계획의 오버헤드와 민첩성 부족(planning overhead and lack of agility)과 같은 워터폴의 모든 단점이 나타납니다.
Decisions don’t stay in the team - 에이전시 모델에서 엔지니어, 특히 디자이너는 자신의 디자인 동료의 리뷰와 이를 통한 결정을 내릴 것을 장려받음. 따라서 PM은 관련 역할을 가질 수 없다고 말할 수도 있음. 왜냐하면 PM이 초대되지 않은 디자인 위원회가 잘못된 접근 방식이라고 판단했기 때문임. 이는 PM, UX 및 엔지니어가 제품을 정의하고 필요하면 리뷰로 가져가는 프로세스와 매우 다른 접근 방식임
How to fix:
명확한 정체성과 미션을 가진 cross-functional team을 만듭니다.
리더십 트리오를 만듭니다(Create leadership trios) - 팀 리더부터 PM/UX/ENG 리더가 트리오(구글에선 트라이어드 triads라고 부름)를 구성하고 긴밀하게 협력함. 직군 간의 벽을 허물고 cross-disciplinary collaboration 촉진하기 위해 노력함. 리더십 트리오는 각 cross-functional team에 권한을 위임하고 자체적으로 결정을 내릴 수 있도록 필요한 모든 컨텍스트를 제공하려고 노력해야함.
