프로덕트 매니지먼트 바이블(1) - 커뮤니케이션
팀의 협업을 계속 강화하다 보면 흥미로운 발견을 하게 된다. PM이 이런 조율 역할을 완벽하게 해내는 팀일수록, 결국 PM이 없어도 잘 돌아간다는 점이다. "미션팀의 효과는 PM이 없어도 이런 문제를 최소화할 수 있게 된다."
이를 이해하기 위해 두 가지 극단적인 팀 유형을 비교해보자. 이 구분은 단순한 이론이 아니라, 실제 조직에서 관찰되는 현실이다.
당신도 경험해봤을 것이다. 어떤 팀은 PM이 세세하게 지시하지 않아도 스스로 알아서 일을 찾아서 한다. 심지어 PM보다 먼저 문제를 발견하고 해결책을 제안하기도 한다.
미션팀(Mission Team)의 특징을 자세히 살펴보자:
핵심 동기: 고객 문제 해결이 목표 이들에게 일은 단순히 월급을 받기 위한 수단이 아니다. 고객의 문제를 해결했을 때 느끼는 만족감이 진짜 동기다. 그래서 새로운 기능을 개발할 때도 "이게 정말 고객에게 도움이 될까?"를 먼저 생각한다.
작업 방식: "이게 정말 필요한가?" 고민 후 개선 미션팀은 주어진 업무를 그대로 수행하지 않는다. 항상 "왜?"라는 질문을 던진다. "왜 이 기능이 필요한가? 정말 최선의 방법인가? 더 간단하고 효과적인 방법은 없을까?" 이런 습관 때문에 때로는 기획자나 PM을 힘들게 만들기도 한다. 하지만 결과적으로는 훨씬 좋은 제품이 나온다.
고객에 대한 관심: 고객 데이터를 분석하고 피드백 반영 미션팀 구성원들은 자신이 만든 기능을 고객이 어떻게 사용하는지 궁금해한다. 실제 사용 데이터를 보고, 고객 피드백을 읽고, 때로는 직접 고객과 이야기하려고 한다.
주도성: 스스로 문제를 정의하고 해결책을 찾음 가장 큰 차이점이다. 미션팀은 PM이 모든 것을 지시해주기를 기다리지 않는다. 오히려 PM에게 "이런 문제를 발견했는데, 이렇게 해결하면 어떨까요?"라고 제안한다.
팀워크: 제품의 방향성을 함께 고민 미션팀에서는 개발자도 마케팅에 관심을 갖고, 디자이너도 기술적 제약을 이해하려고 노력한다. 각자의 전문 영역을 넘어서 제품 전체를 생각한다.
PM과의 관계: PM 없이도 방향성을 고민하며 일함 PM이 휴가를 가거나 다른 일로 바쁠 때도 팀이 멈추지 않는다. 오히려 PM이 돌아왔을 때 "이런 것들을 진행했는데, 어떻게 생각하세요?"라고 보고한다.
최종 목표: 지속적인 제품 성장과 성공 단순히 프로젝트를 완료하는 것이 목표가 아니다. 제품이 시장에서 성공하고, 고객에게 가치를 제공하고, 회사가 성장하는 것이 진짜 목표다.
반대편에는 용병팀이 있다. 이들도 나름대로 열심히 일한다. 하지만 접근 방식이 근본적으로 다르다.
용병팀(Mercenary Team)의 특징:
핵심 동기: 지시받은 일 수행이 목표 이들에게 일은 월급을 받기 위한 수단이다. 주어진 업무를 정확하게 수행하는 것이 성공의 기준이다. 그 이상도, 그 이하도 아니다.
작업 방식: "시키는 대로" 구현 "기획서에 나온 대로 만들면 되는 거죠?"가 이들의 기본 태도다. 기획이 잘못되었거나 더 좋은 방법이 있어도 굳이 지적하지 않는다. "그건 내 일이 아니야"라고 생각한다.
고객에 대한 관심: 고객 반응에 관심 없음 자신이 만든 기능을 고객이 사용하는지, 만족하는지에 대해 관심이 없다. "내가 할 일은 다 했어. 고객이 안 쓰는 건 기획이나 마케팅 문제지, 내 문제가 아니야."
주도성: 주어진 요구사항만 해결 새로운 문제를 발견해도 누군가 공식적으로 요청하기 전까지는 움직이지 않는다. "그런 것까지 내가 해야 하나?"라는 생각이 기본이다.
팀워크: 기능 단위로 개인 작업 수행 자신의 담당 영역에만 집중한다. 다른 팀이 어떤 어려움을 겪고 있든, 전체 제품이 어떤 방향으로 가고 있든 관심 없다.
PM과의 관계: PM의 지시에 따라 움직임 PM이 없으면 무엇을 해야 할지 모른다. 지시가 없으면 아무것도 하지 않는다. PM에게 의존적이다.
최종 목표: 프로젝트 완료 후 종료 프로젝트가 끝나면 관계도 끝난다. 그 제품이 이후에 어떻게 되든 상관없다.
실제 상황에서 이 차이가 어떻게 나타나는지 구체적인 예시를 보자.
상황: 새로운 기능을 출시했는데 사용률이 예상보다 낮다
미션팀의 반응:
"왜 사용률이 낮을까? 우리가 놓친 부분이 있나?"
"사용자 인터뷰를 해볼까? 실제로 어떤 부분에서 어려움을 겪는지 알아보자"
"데이터를 더 자세히 분석해보면 힌트를 찾을 수 있을 것 같은데"
"다음 버전에서는 어떻게 개선할 수 있을까?"
용병팀의 반응:
"기획서대로 만들었는데? 내 잘못은 아니야"
"사용률이 낮은 건 마케팅이나 기획 문제 아닌가?"
"다음에 뭘 해야 하는지 지시해줘"
이 차이는 단순히 태도의 문제가 아니다. 근본적으로 일에 대한 관점이 다르다.
경험적으로 미션팀이 더 좋은 성과를 낸다는 것은 명확하다. 하지만 왜 그럴까? 세 가지 핵심 이유가 있다.
가장 근본적인 차이다. 같은 상황에서도 접근 방식이 완전히 다르다.
예를 들어, "고객이 제품을 사용할 때 혼란스러워한다"는 피드백이 왔다고 하자.
용병팀은 이렇게 생각한다: "UI를 더 예쁘게 만들라는 뜻인가? 아니면 도움말을 추가하라는 뜻인가? 구체적으로 뭘 하라는 건지 말해줘."
미션팀은 이렇게 접근한다: "고객이 왜 혼란스러워할까? 어떤 부분에서 막히는 걸까? 정말 UI 문제일까, 아니면 정보 구조 자체의 문제일까? 고객이 진짜 하려는 일이 뭔지부터 파악해보자."
결과적으로 용병팀은 표면적인 개선에 그치지만, 미션팀은 근본적인 해결책을 찾아낸다.
미션팀은 제품의 성공을 목표로 삼고, 문제 해결을 위해 고민하고 개선한다. 용병팀은 주어진 업무만 처리하고, 결과에는 관심이 없다.
이것이 바로 핵심이다. 진정한 미션팀은 PM에게 의존하지 않는다.
실제 사례를 보자. 한 스타트업에서 PM이 갑작스럽게 퇴사했다. 용병팀이었다면 일이 완전히 멈췄을 것이다. 하지만 그 팀은 미션팀이었다.
개발자가 먼저 나섰다: "PM이 없으니까 우리가 직접 고객 피드백을 확인해보자."
디자이너가 따라왔다: "내가 고객 인터뷰를 진행해볼게."
마케터도 합류했다: "사용 데이터를 보니까 이런 패턴이 있던데, 이걸 개선하면 어떨까?"
3개월 후 새 PM이 합류했을 때, 제품은 오히려 더 발전해 있었다. 새 PM은 "제가 할 일이 별로 없네요"라고 농담할 정도였다.
미션팀은 주도적으로 제품을 개선하는 팀이다. PM이 없어도 제품이 발전한다. 용병팀은 PM이 없으면 그냥 멈추는 팀이다. 지시가 없으면 아무것도 하지 않는다.
실패에 대한 반응이 완전히 다르다. 그리고 이 차이가 장기적으로 큰 격차를 만든다.
실제 상황: 6개월간 개발한 기능이 시장에서 실패했다.
용병팀의 반응:
"기획이 잘못됐나 보네"
"내가 할 일은 다 했는데..."
"다음엔 뭘 만들라고 할까?"
실패의 원인을 분석하려고 하지 않는다
같은 실수를 반복할 가능성이 높다
미션팀의 반응:
"왜 실패했을까? 어떤 가정이 틀렸을까?"
"고객이 우리 제품 대신 뭘 사용하고 있을까?"
"이번 실패에서 우리가 배울 수 있는 것은 뭐가 있을까?"
"다음에는 어떻게 하면 더 빨리 검증할 수 있을까?"
실패를 통해 더 많은 것을 배운다
다음 시도에서 성공 확률이 높아진다
미션팀은 실패를 통해 개선하고, 다음 기회를 만든다. 용병팀은 실패하면 "내 잘못 아니다"라고 생각하고 끝난다. 이런 차이가 누적되면서, 미션팀은 계속 성장하지만 용병팀은 제자리걸음을 하게 된다.
현실적으로 모든 기업이 미션팀을 원하는 것은 아니다. 그리고 이것이 바로 PM 역할이 회사마다 다른 이유다.
실제 채용 공고를 비교해보면 이 차이가 극명하게 드러난다.
"○○의 프로덕트 매니저는 고객 만족과 서비스 성장에 있어 핵심적인 역할을 수행합니다."
주요 업무:
제품의 핵심 문제를 정의하고, 이를 해결하기 위한 실행 방법을 수립합니다
다양한 이해관계자들과 효과적으로 소통하고 협력하여 목표에 대한 일관된 합의를 이끌어냅니다
제품 성과 지표를 관리하고, 이를 기반으로 한 의사결정을 통해 빠른 실행을 주도합니다
데이터와 사용자 피드백을 활용하여 제품을 지속적으로 개선하고, 성과를 측정합니다
주요업무:
○○○ 서비스 기획 및 운영
프로덕트팀을 리드하고 프로젝트의 우선순위 결정
개발, 디자인, 마케팅 등 협업 부서와 커뮤니케이션 주도
서비스 전반의 데이터를 바탕으로 목표, 전략 수립
사용자 데이터를 통해 서비스의 문제를 발견하고 구체적인 해결책을 제시
언뜻 비슷해 보이지만, 자세히 보면 접근 방식이 다르다.
A회사는 "문제를 정의하고", "합의를 이끌어내고", "지속적으로 개선한다"는 표현을 사용한다. 이는 미션팀 스타일의 PM을 원한다는 신호다.
B회사는 "서비스 기획", "우선순위 결정", "커뮤니케이션 주도"라는 표현을 사용한다. 이는 상대적으로 전통적인 프로젝트 관리 스타일을 원한다는 신호다.
같은 PM이라는 이름이지만 실제로는 완전히 다른 역할을 기대하고 있다.
결국 중요한 것은 기업이 어떤 팀을 원하는지 파악하는 것이다.
미션팀을 원한다면 - 소통과 협업을 중심으로 PM 역할을 설계한다. 팀원들이 스스로 문제를 정의하고 해결할 수 있도록 환경을 만들고, PM은 방향성을 제시하고 장애물을 제거하는 역할에 집중한다.
이런 회사에서 PM은:
정답을 제시하기보다는 좋은 질문을 던진다
지시하기보다는 동기를 부여한다
통제하기보다는 자율성을 제공한다
완벽한 계획보다는 빠른 학습을 추구한다
용병팀을 원한다면 - 지시와 절차를 중심으로 PM 역할을 설계한다. 명확한 업무 분장과 체계적인 프로세스를 통해 효율성을 추구하고, PM은 계획 수립과 진행 관리에 집중한다.
이런 회사에서 PM은:
상세한 기획서와 명확한 지시사항을 제공한다
일정과 품질을 엄격하게 관리한다
역할과 책임을 명확하게 구분한다
예측 가능성과 안정성을 중시한다
"이상적인 PM의 역할은 존재하지만 모든 회사가 이상적인 PM을 원하지는 않는다." 이것이 현실이다.
기업의 문화, 성장 단계, 비즈니스 특성에 따라 필요한 PM의 모습은 달라진다. 스타트업과 대기업이 원하는 PM이 다르고, 혁신이 필요한 회사와 안정성이 중요한 회사가 원하는 PM이 다르다.
하지만 여기서 중요한 질문이 생긴다. 과연 어떤 방식이 더 높은 성과를 낼 수 있을까?
역설적이게도, 최고의 프로덕트 팀은 PM이 필요 없는 팀이다. 이것은 PM이 무능해서가 아니라, 팀이 너무 잘 돌아가서 PM의 전통적인 역할이 불필요해졌다는 뜻이다.
생각해보면 당연하다. PM의 역할이 정보 조율, 우선순위 통일, 책임 분담이라면, 팀원들이 스스로 이 모든 것을 할 수 있다면 PM이 굳이 필요할까?
실제로 최고 수준의 제품팀들을 관찰해보면 흥미로운 패턴을 발견할 수 있다:
개발자가 직접 고객과 이야기한다
디자이너가 비즈니스 임팩트를 고민한다
마케터가 기술적 제약을 이해한다
모든 팀원이 제품의 전체적인 방향성을 파악하고 있다
갈등이 발생해도 스스로 해결한다
새로운 기회를 발견하면 누가 시키지 않아도 탐색한다
이런 팀에서 PM은 무엇을 할까? 전통적인 의미의 '관리'는 하지 않는다. 대신 더 전략적이고 창의적인 일에 집중할 수 있다:
장기적인 제품 비전 수립
새로운 시장 기회 탐색
조직 차원의 장애물 제거
팀이 더 높은 수준으로 성장할 수 있도록 지원
하지만 이런 팀이 하루아침에 만들어지지는 않는다. 체계적인 접근이 필요하다.
앞서 살펴본 바와 같이 미션팀이 더 나은 결과를 만든다면, 미션팀을 만들기 위해서는 어떤 조건이 필요할까? 세 가지 핵심 요소가 있다.
우리 팀이 이 제품을 왜 만들고 있는지 알고 있어야 한다. 기능을 만드는 것이 목표가 아니라, 문제를 해결하는 것이 목표라는 점을 공유해야 한다.
❌ "이 기능을 추가하자." → ✅ "이 문제를 해결하기 위해 어떤 방법이 있을까?"
이런 관점의 전환이 일어나면, 팀원들은 단순히 주어진 업무를 수행하는 것이 아니라 스스로 더 나은 해결책을 고민하게 된다. "정말 이 기능이 필요할까?" "다른 방법은 없을까?" "사용자에게 더 도움이 되는 방향은 무엇일까?" 같은 질문을 자연스럽게 던지게 된다.
미션팀은 최선의 결정을 빠르게 내리고 실행할 수 있어야 한다. PM이 이 과정에서 방향성을 조율하는 역할을 한다.
"우리는 어떤 기준을 가지고 우선순위를 정할 것인가?"
빠른 의사결정이 중요한 이유는 불확실성 때문이다. 시장 상황은 계속 변하고, 고객의 니즈도 변한다. 완벽한 정보를 기다리다가는 기회를 놓칠 수 있다. 차라리 80% 확신이 서면 결정을 내리고, 실행하면서 나머지 20%를 검증하는 것이 낫다.
미션팀은 PM이 모든 걸 지시하는 팀이 아니라, 각 팀원이 스스로 움직이는 팀이다. PM이 팀원들에게 '어떻게' 하라고 지시하는 것이 아니라, 목표를 명확하게 설정해줘야 한다.
❌ "이 기능을 이렇게 만들어 주세요." → ✅ "이 문제를 해결할 수 있는 가장 좋은 방법을 찾아주세요."
이런 접근법의 차이는 결과에서도 극명하게 드러난다. 첫 번째 방식에서는 PM이 생각한 해결책 하나만 나오지만, 두 번째 방식에서는 각 전문가가 자신의 영역에서 최선의 해결책을 제시할 수 있다. 개발자는 기술적으로 더 효율적인 방법을, 디자이너는 사용자 경험 측면에서 더 나은 방법을, 마케터는 비즈니스 측면에서 더 효과적인 방법을 제안할 수 있다.
하지만 미션팀을 만드는 것은 쉽지 않다. 세 가지 주요 장애물이 있다.
기존 계층적 구조가 강하면 미션팀이 유지될 수 없다. 위에서 승인받아야 하는 구조에서는 팀이 자율적으로 움직일 수 없다.
예를 들어, 팀에서 고객 피드백을 바탕으로 새로운 아이디어를 냈는데 "이건 위에서 결정할 문제야"라고 하면서 몇 주를 기다려야 한다면, 팀의 주도성은 점점 사라진다. 팀원들은 "어차피 위에서 결정하는데 우리가 왜 고민해야 하지?"라고 생각하게 되고, 결국 지시를 기다리는 용병팀이 된다.
개별 성과 중심의 평가 시스템은 미션팀을 방해한다. 팀 전체의 성과가 아니라, 개인 성과에 따라 보상이 결정되면 협업이 깨진다.
"내가 왜 다른 팀을 도와줘야 하지? 내 KPI에는 도움이 안 되는데..." 이런 생각이 들기 시작하면 미션팀은 불가능하다. 각자 자신의 영역에서만 성과를 내려고 하고, 전체 제품의 성공보다는 개인의 평가에 더 신경 쓰게 된다.
지나치게 느린 의사결정 프로세스는 미션팀의 강점을 무력화한다. 결정을 내리기 위해 매번 경영진 승인 절차를 거쳐야 하면, 팀의 주도성이 사라진다.
시장 상황이 빠르게 변하는데 의사결정은 느리면, 아무리 좋은 아이디어라도 기회를 놓치게 된다. 그리고 팀원들은 점점 수동적이 된다. "어차피 빨리 결정해봤자 승인 받는 데 시간 걸리는데, 굳이 서두를 필요 있나?"
결국 우리는 현실적인 한계를 인정해야 한다. 모든 상황에 맞는 완벽한 공식은 존재하지 않는다. 방식의 개선으로는 태도를 고칠 수 없다. 일하는 '방식'의 문제가 아닌 일하는 '원칙'의 문제다. 원칙에 대해 깊은 수준의 이해를 가지면 현명한 판단을 할 수 있는 '심성 모델'이 생긴다. 어떤 기법을 활용하더라도 어떨 때 적절하고 유용한지 판단할 능력이 생긴다.
"방법보다 원칙에 집중해야 한다."
방법론을 맹목적으로 따르기보다는 다음과 같은 순서로 접근해야 한다:
● 제품팀을 운영하기 위해 어떤 원칙을 세워야 하는지 고민한다
우리 팀이 추구하는 가치는 무엇인가?
어떤 방식으로 일할 때 최고의 성과를 낼 수 있는가?
팀원들이 공유해야 할 핵심 믿음은 무엇인가?
● 이 원칙하에서 어떤 문제를 해결해야 하는지 명확히 파악한다
우리 팀의 현재 상황에서 가장 큰 문제는 무엇인가?
정보 불균형인가, 우선순위 충돌인가, 책임 회피인가? 아니면 다른 문제인가?
● 적용할 수 있는 방법론들이 어떤 원칙하에 설계되었는지 이해한다
이 방법론이 해결하려는 근본적인 문제는 무엇인가?
어떤 가정을 전제로 하고 있는가?
우리 상황에 적합한가?
● 실제로 이 방법론을 적용해 보는 과정에 대해 실험하고 학습한다
작은 규모로 시작해서 효과를 검증하고, 우리 상황에 맞게 조정하며, 지속적으로 개선해나간다.
미션팀을 만드는 것도 어렵지만, 유지하는 것은 더 어렵다. 다음과 같은 조건들이 필요하다:
작은 규모의 팀: 너무 큰 팀에서는 의사소통 비용이 기하급수적으로 증가한다
명확한 권한과 책임: 누가 무엇을 결정할 수 있는지가 분명해야 한다
수평적인 보고 체계: 계층이 많을수록 정보 왜곡과 의사결정 지연이 발생한다
문제 중심 협업: 기능이나 업무가 아닌 해결해야 할 문제를 중심으로 팀이 형성되어야 한다
가능한 같은 장소에서: 물리적 거리는 심리적 거리를 만든다
지속성 유지: 프로젝트가 끝날 때마다 팀이 해체되면 시너지를 기대하기 어렵다
높은 자율성: 세부 사항까지 승인받아야 한다면 주도성이 사라진다
높은 전문성: 각자의 영역에서 최고 수준의 역량을 갖춰야 상호 존중이 가능하다
주인의식과 책임감: 남의 일이 아닌 자신의 일로 여기는 마음가짐
...
목록은 계속 늘어날 수 있다. 하지만 모든 조건을 완벽하게 갖추기를 기다린다면 영원히 시작할 수 없다.
현실적으로 PM의 역할은 단계적으로 발전한다.
1. 모든 이슈와 의사결정 안건을 CEO에게 보고한다
: PM이 단순히 CEO의 비서 역할을 하는 단계다. 모든 정보를 수집해서 위로 올리고, 위에서 내려온 결정을 아래로 전달하는 역할만 한다. 이 단계에서는 PM의 전문성이나 판단력보다는 정보 전달 능력이 중요하다.
2. 이해관계자들을 모으고 그들끼리 결정하도록 돕는다
: PM이 조정자 역할을 하는 단계다. 관련된 사람들을 한자리에 모으고, 논의할 수 있는 환경을 만들고, 결정이 내려지면 그것을 문서화하고 공유한다. 이 단계에서는 커뮤니케이션 능력과 프로세스 관리 능력이 중요하다.
3. 스스로 필요한 업무를 실행한다
: PM이 주도적으로 판단하고 실행하는 단계다. 상황을 분석하고, 대안을 검토하고, 최선의 결정을 내리고, 그것을 실행에 옮긴다. 이 단계에서는 전문성과 리더십, 그리고 책임감이 중요하다.
"어떻게 일하는 것이 더 높은 프로덕트 성과를 낼 수 있을까?"
이것이 PM이 끊임없이 고민해야 할 질문이다. 그리고 답은 상황에 따라 달라질 수 있다. 때로는 1단계의 접근이 필요할 수도 있고, 때로는 3단계의 접근이 필요할 수도 있다. 중요한 것은 현재 상황에서 무엇이 최선인지 판단할 수 있는 능력을 기르는 것이다.
"어떤 곳에서 일할지는 당신의 선택이다."
핵심을 정리하면 이렇다. 협업이 실패하는 이유는 정보 불균형, 우선순위 충돌, 책임 회피라는 세 가지 근본적인 문제 때문이다. PM의 역할은 이 문제들을 해결하는 것이다. 정보를 조율하고, 우선순위를 통일하고, 책임을 명확하게 나누는 것이다.
하지만 더 중요한 것은 PM이 없어도 잘 돌아가는 미션팀을 만드는 것이다. 미션팀은 문제를 해결하기 위해 존재하고, 스스로 학습하고 개선하며, 실패해도 포기하지 않는다. 이런 팀을 만들기 위해서는 목표를 공유하고, 빠른 의사결정을 하고, 주도성을 부여해야 한다.
완벽한 협업 시스템은 존재하지 않는다. 모든 상황에 적용되는 만능 해결책도 없다. 하지만 협업이 실패하는 이유를 이해하고, PM이 어떤 역할을 해야 하는지 알게 되면, 적어도 같은 실수를 반복하지는 않을 것이다.
그리고 방법보다는 원칙에 집중해야 한다는 점을 잊지 말자. 원칙을 이해하면 어떤 상황에서도 현명한 판단을 내릴 수 있는 심성 모델을 기를 수 있다. 그것이 바로 뛰어난 PM이 되는 길이다.
현 부지런컴퍼니 COO 겸 PM
PM 부트캠프 강사, 비즈니스 & 커리어 코치
10여년간 스타트업부터 대기업까지 다양한 환경에서 사업 경험을 쌓았으며, 현재는 PM들이 실무에서 바로 활용할 수 있는 지식과 노하우를 체계적으로 정리하고 전달하는 일에 집중하고 있습니다.
문의: fineday9@hanmail.net
더 많은 PM 인사이트: https://brunch.co.kr/magazine/pmbible
LinkedIn: https://www.linkedin.com/in/thkim9/
PM 바이블 시리즈가 도움이 되셨다면 주변에 다른 분들께도 많이 공유해주세요!