1. PM에게 직무 간 협업이 중요한 이유
PM은 공식적인 위계나 권한 없이도 다양한 직군을 연결해 제품을 완성해야 하는 역할이다. 개발자, 디자이너, 마케터, 데이터 분석가 등은 각자 다른 언어와 우선순위를 갖고 있으며, 그 차이만큼 충돌도 잦다. 협업은 단순한 커뮤니케이션 이슈가 아니라 구조와 리더십의 문제다. PM은 그 갈등을 해석하고 공동의 목표로 조율하는 조정자이며, 협업의 설계자다.
2. 직무 간 협업에서 필요한 리더십의 본질
좋은 PM은 관리자(manager)가 아니다. 각 직군이 처한 현실과 제약을 이해하고, 서로의 차이를 문제 해결의 실마리로 엮는 ‘맥락 연결자’다. PM 리더십의 본질은 갈등을 없애는 것이 아니라, 갈등의 구조를 읽고 팀이 그것을 생산적으로 통과하게 하는 데 있다.
이 과정에서 중요한 네 가지 태도가 있다.
첫째, 사람보다 상황과 구조를 먼저 보는 ‘맥락 중심 사고’를 습관처럼 가져야 한다.
둘째, 의견 충돌이 발생했을 때 이를 회피하지 않고 구조화해 문제 정의의 차이로 전환할 수 있어야 한다.
셋째, 직군마다 사용하는 언어가 다르다는 점을 이해하고, 이를 서로 번역해주는 메신저가 되어야 한다.
넷째, 팀 전체가 지금 ‘왜 이 일을 하고 있는가’를 명확히 이해하도록 공통의 목적을 끊임없이 리마인드해야 한다.
3. 협업에서 좋은 PM과 나쁜 PM은 무엇이 다른가?
갈등이 발생했을 때 나쁜 PM은 그 상황을 피하거나 애매하게 절충하려 한다. 그 결과는 누구도 만족하지 못하는 기능 혹은 흐릿한 결과물이다. 반면, 좋은 PM은 갈등을 드러내고, “UX 개선이 중요한가, 기술 리스크 관리가 중요한가”와 같은 구조적 질문을 통해 팀 간 대화를 설계한다. 이를 통해 각 직군이 서로의 우선순위를 이해하고, 진정성 있는 합의에 도달할 수 있다.
또한, 나쁜 PM은 직군을 단순한 리소스로 바라본다. 디자이너를 ‘UI 제작자’로, 개발자를 ‘요구사항 수행자’로 간주한다. 이러한 태도는 협업이 아니라 하청 관계를 만든다. 반면, 좋은 PM은 각 직군의 세계관과 전문성을 존중한다. 기획서를 설득의 수단이 아니라, 대화를 시작하는 틀로 활용한다. 동료를 기술자나 예술가로 존중할 때 진정한 협업이 시작된다.
4. PM이 직무 협업 역량을 기르기 위해 해야 할 일
첫째, 기획보다 문제 정의를 먼저 공유해야 한다. 정답을 제시하기보다는 “우리가 어떤 문제를 해결하려 하는가”를 동료들과 함께 탐색하라. 이 질문이 협업을 진정한 공동 창작으로 이끈다.
둘째, 직무 간 갈등은 회피할 리스크가 아니라, 정제할 기회다. 갈등이 없다면 누군가는 말을 아끼고 있다는 뜻일지도 모른다. 갈등을 드러내되, 감정이 아닌 구조로 해석할 수 있는 장을 설계하라.
셋째, 각 직군이 중요하게 여기는 우선순위와 리듬을 이해하라. 개발자는 안정성과 예측 가능성을, 디자이너는 흐름과 감각적 완성도를, 마케터는 타이밍과 메시지 일관성을 중요시한다. 이 차이를 이해할 수 있어야 같은 타임라인 위에서 진짜 협업이 가능해진다.
5. 직무 간 협업이 잘 안 되는 조직의 공통점
직무 간 협업이 제대로 작동하지 않는 조직에서는 공통된 문제들이 드러난다. PM이 직군의 요구를 수집만 할 뿐, 실질적인 판단과 재구성이 없다. 피드백 루프가 존재하지 않아 의견 충돌은 감정으로 누적된다. 각 직군은 자신의 관점으로만 프로젝트를 평가하고, 다른 관점은 고려되지 않는다. 이런 환경에서 PM은 단순 전달자 이상의 역할을 수행하기 어렵다.
6. 결국 PM은 협업을 설계하는 사람이다
직무 간 협업은 의사소통의 문제가 아니라, 구조 설계의 문제다. PM은 팀원 각각의 언어를 해석하고, 다름을 본질로 환원하며, 이를 하나의 방향으로 이끄는 리더다. “왜 지금 이 기능을 만들어야 하는가?”를 명확히 설명할 수 있을 때, PM은 직무 간 신뢰를 얻는다. 그리고 그 신뢰 위에서 협업은 비로소 작동한다.
7. 마지막으로, PM 자신에게 물어야 할 질문들
1. 나는 최근 프로젝트에서 직군별 우선순위를 명확히 이해하고 대화에 반영했는가?
2. 갈등이 발생했을 때 구조화하려 했는가, 피했는가?
3. 직군 간 오해를 언어의 차이로 인식하고 이를 해석하려 노력했는가?
4. 문제 정의를 함께 만들었는가, 아니면 혼자 정답을 들고 갔는가?
5. 킥오프 회의에서 ‘왜 이 일을 하는가’를 명확히 설명했는가?
이 질문에 ‘예’라고 답할 수 없다면, 지금 당신이 설계하고 있는 협업은 아직 조율이 아닌 병렬에 머물러 있을 가능성이 높다. PM은 기능을 기획하는 사람이 아니라, 협업을 설계하는 사람이다.
Dean님 글 더보러 가기 : https://brunch.co.kr/@try-harder
1. PM에게 직무 간 협업이 중요한 이유
PM은 공식적인 위계나 권한 없이도 다양한 직군을 연결해 제품을 완성해야 하는 역할이다. 개발자, 디자이너, 마케터, 데이터 분석가 등은 각자 다른 언어와 우선순위를 갖고 있으며, 그 차이만큼 충돌도 잦다. 협업은 단순한 커뮤니케이션 이슈가 아니라 구조와 리더십의 문제다. PM은 그 갈등을 해석하고 공동의 목표로 조율하는 조정자이며, 협업의 설계자다.
2. 직무 간 협업에서 필요한 리더십의 본질
좋은 PM은 관리자(manager)가 아니다. 각 직군이 처한 현실과 제약을 이해하고, 서로의 차이를 문제 해결의 실마리로 엮는 ‘맥락 연결자’다. PM 리더십의 본질은 갈등을 없애는 것이 아니라, 갈등의 구조를 읽고 팀이 그것을 생산적으로 통과하게 하는 데 있다.
이 과정에서 중요한 네 가지 태도가 있다.
첫째, 사람보다 상황과 구조를 먼저 보는 ‘맥락 중심 사고’를 습관처럼 가져야 한다.
둘째, 의견 충돌이 발생했을 때 이를 회피하지 않고 구조화해 문제 정의의 차이로 전환할 수 있어야 한다.
셋째, 직군마다 사용하는 언어가 다르다는 점을 이해하고, 이를 서로 번역해주는 메신저가 되어야 한다.
넷째, 팀 전체가 지금 ‘왜 이 일을 하고 있는가’를 명확히 이해하도록 공통의 목적을 끊임없이 리마인드해야 한다.
3. 협업에서 좋은 PM과 나쁜 PM은 무엇이 다른가?
갈등이 발생했을 때 나쁜 PM은 그 상황을 피하거나 애매하게 절충하려 한다. 그 결과는 누구도 만족하지 못하는 기능 혹은 흐릿한 결과물이다. 반면, 좋은 PM은 갈등을 드러내고, “UX 개선이 중요한가, 기술 리스크 관리가 중요한가”와 같은 구조적 질문을 통해 팀 간 대화를 설계한다. 이를 통해 각 직군이 서로의 우선순위를 이해하고, 진정성 있는 합의에 도달할 수 있다.
또한, 나쁜 PM은 직군을 단순한 리소스로 바라본다. 디자이너를 ‘UI 제작자’로, 개발자를 ‘요구사항 수행자’로 간주한다. 이러한 태도는 협업이 아니라 하청 관계를 만든다. 반면, 좋은 PM은 각 직군의 세계관과 전문성을 존중한다. 기획서를 설득의 수단이 아니라, 대화를 시작하는 틀로 활용한다. 동료를 기술자나 예술가로 존중할 때 진정한 협업이 시작된다.
4. PM이 직무 협업 역량을 기르기 위해 해야 할 일
첫째, 기획보다 문제 정의를 먼저 공유해야 한다. 정답을 제시하기보다는 “우리가 어떤 문제를 해결하려 하는가”를 동료들과 함께 탐색하라. 이 질문이 협업을 진정한 공동 창작으로 이끈다.
둘째, 직무 간 갈등은 회피할 리스크가 아니라, 정제할 기회다. 갈등이 없다면 누군가는 말을 아끼고 있다는 뜻일지도 모른다. 갈등을 드러내되, 감정이 아닌 구조로 해석할 수 있는 장을 설계하라.
셋째, 각 직군이 중요하게 여기는 우선순위와 리듬을 이해하라. 개발자는 안정성과 예측 가능성을, 디자이너는 흐름과 감각적 완성도를, 마케터는 타이밍과 메시지 일관성을 중요시한다. 이 차이를 이해할 수 있어야 같은 타임라인 위에서 진짜 협업이 가능해진다.
5. 직무 간 협업이 잘 안 되는 조직의 공통점
직무 간 협업이 제대로 작동하지 않는 조직에서는 공통된 문제들이 드러난다. PM이 직군의 요구를 수집만 할 뿐, 실질적인 판단과 재구성이 없다. 피드백 루프가 존재하지 않아 의견 충돌은 감정으로 누적된다. 각 직군은 자신의 관점으로만 프로젝트를 평가하고, 다른 관점은 고려되지 않는다. 이런 환경에서 PM은 단순 전달자 이상의 역할을 수행하기 어렵다.
6. 결국 PM은 협업을 설계하는 사람이다
직무 간 협업은 의사소통의 문제가 아니라, 구조 설계의 문제다. PM은 팀원 각각의 언어를 해석하고, 다름을 본질로 환원하며, 이를 하나의 방향으로 이끄는 리더다. “왜 지금 이 기능을 만들어야 하는가?”를 명확히 설명할 수 있을 때, PM은 직무 간 신뢰를 얻는다. 그리고 그 신뢰 위에서 협업은 비로소 작동한다.
7. 마지막으로, PM 자신에게 물어야 할 질문들
1. 나는 최근 프로젝트에서 직군별 우선순위를 명확히 이해하고 대화에 반영했는가?
2. 갈등이 발생했을 때 구조화하려 했는가, 피했는가?
3. 직군 간 오해를 언어의 차이로 인식하고 이를 해석하려 노력했는가?
4. 문제 정의를 함께 만들었는가, 아니면 혼자 정답을 들고 갔는가?
5. 킥오프 회의에서 ‘왜 이 일을 하는가’를 명확히 설명했는가?
이 질문에 ‘예’라고 답할 수 없다면, 지금 당신이 설계하고 있는 협업은 아직 조율이 아닌 병렬에 머물러 있을 가능성이 높다. PM은 기능을 기획하는 사람이 아니라, 협업을 설계하는 사람이다.
Dean님 글 더보러 가기 : https://brunch.co.kr/@try-harder
Related Posts
