안녕하세요, 꾸우._. 입니다. 오늘은 프로덕트 팀과 PD Life Cycle을 배우고 정리하며 하루를 보냈는데요. 그러면서 프로덕트 매니저에게 중요한 역량과 관련해 키워드에 대한 의미와 제 생각을 정리해보겠습니다.
📌 미니 CEO
앞서 말씀드렸듯 PM은 종류가 다양하고, 각 PM이 주로 하는 업무에 대한 차이점이 존재했습니다. 그 중에서도 프로덕트 매니저는 하나의 제품/서비스를 개발하고자 여러 사람들이 모여 하나로 구성된 프로덕트 팀에서 전 과정을 총괄하고, 사업 가치와 고객 가치를 창출하는 데 목표를 둔 사람이라고 했습니다. 이러한 이유 때문에 프로덕트 매니저는 한 제품의 오너라는 뜻으로 "미니 CEO" 라고 불리기도 합니다. 이런 표현은 PM (이하 프로덕트 매니저)에게 있어 결코 과장된 표현이 아니라고 생각합니다.
PM은 팀 내에서 그저 커뮤니케이션을 통해 조율하고 총괄하는 데서 그치지 않습니다.
- 때로는 사용자를 대변해 사용자의 시선으로 제품을 바라보고,
- 때로는 기획자, 설계자, 디자이너가 되어 제품에 대한 기획 및 설계를 하고,
- 때로는 사업가가 되어 제품에 대한 비즈니스 모델을 구상하고,
- 때로는 카피라이터가 되어 사용자에게 직관적이고 이해하기 쉬운 문구를 작성하고,
- 때로는 교사가 되어 자신이 기획한 제품에 대해 설명하고 이해시켜야 합니다.
이 때문에 PM은 코딩과 디자인을 제외한 모든 업무에 대해 처리할 수 있어야 하며, 그에 따른 다양한 역량이 요구되는 것입니다.
📌 "Say No!"
PM에게 커뮤니케이션 역량만큼이나 중요한 역량이 있습니다. 바로 팀원들의 의견에 대해 불가능한 것은 단호하게 "No" 라고 말할 수 있는 능력입니다. 하나의 제품을 만들 때 개발해야 할 기능이 많거나, 기간이 촉박하거나, 지금 당장 만들어야 하는 경우 모든 팀 구성원들의 요구사항을 들어주기 어렵습니다. 설사 반영한다고 해도 그로 인해 기존에 주어진 업무의 우선순위대로 일을 진행할 수 없을 뿐만 아니라 고객의 문제와 니즈를 해결하기 위한 제품이 아닌 팀원들이 원하는 제품이 돼버릴 수 있기 때문입니다.
현재 주니어 PM들의 경우 현장에 투입되면 자신보다 높은 경력의 팀 구성원들을 만날 경우, 단호하게 대처하기에는 많이 어려워 할 것이고, 그로 인해 커뮤니케이션 및 제품 개발에 있어 부정적인 효과를 야기할 수 있습니다. 그렇기 때문에 팀원들과 커뮤니케이션을 통해 의견을 조율하되, "No" 라고 밀할 때는 그 이유와 제품 개발 상황을 논리적으로 설명할 수 있어야 한다고 생각합니다.
📌 제품개발 생애 주기
PM이 프로덕트 팀을 이끌어 하나의 제품을 개발 시 거쳐가야 하는 개념적인 5단계입니다. (4. PD Life Cycle (제품개발 생애 주기)은 어떻게 흘러갈까요? 참조) 대부분의 제품들은 해당 과정을 거쳐 개발되기 때문에 PM은 해당 과정에 대해 숙지할 필요가 있다고 생각합니다.
적극적인 피드백은 언제나 환영입니다:)
참고
코드스테이츠 강의
