프로덕트 매니지먼트 바이블(1) - 커뮤니케이션
월요일 아침, 신제품 기획 회의실에는 긴장감이 흘렀다. 다음 분기 출시를 앞둔 핵심 기능을 두고 각 부서의 의견이 완전히 갈라진 상황이었다.
"이 기능이 있어야 영업이 훨씬 쉬워집니다." 영업팀장 김 과장이 목소리를 높였다. 그의 표정에는 절박함이 묻어났다. "고객들이 계속 요청하는 기능이에요. 저희가 매일 고객과 만나면서 현장 목소리를 가장 잘 알고 있잖아요."
개발팀장 박 부장은 고개를 저으며 한숨을 쉬었다. "일정상 불가능합니다. 이걸 개발하려면 최소 3개월은 더 필요해요. 기술적으로 완전히 새로운 아키텍처를 구축해야 하거든요." 그의 목소리에는 피로감이 역력했다. 또 다른 무리한 요구라는 생각이 들었다.
대표는 팔짱을 끼고 생각에 잠겼다. "우리가 처음 기획했던 방향과는 다른 것 같은데... 정말 필요한 기능인가요? 회사를 여기까지 이끌어온 제 경험으로는..." 그는 말끝을 흐렸다. 창업 초기의 방향성을 잃어가는 것 같아 불안했다.
CS팀 이 차장이 조심스럽게 입을 열었다. "고객 불만 접수가 가장 많은 건 다른 부분인데요. 매일 고객 불만을 듣고 이를 해결하는 데 최선을 다하는 저희 입장에서는 이것부터 해결해야 하지 않을까요?" 그녀의 목소리에는 현장에서 느끼는 절실함이 담겨 있었다.
마지막으로 제품팀 정 대리가 망설이며 말했다. "직접 제품을 개선시키고 결과물을 만들어내는 저희 관점에서는 사용자 경험 측면에서..." 그는 말을 다 잇지 못했다. 여러 목소리가 쏟아지는 상황에서 자신의 의견이 묻힐까 봐 걱정스러웠다.
회의실은 각자의 논리로 가득했다. 모두가 옳은 말을 하고 있었고, 각각의 전문성과 경험을 바탕으로 한 합리적인 주장이었다. 하지만 이상했다. 분명 모두 회사의 성공을 원하고 있는데, 왜 이렇게 대립하고 있는 걸까?
당신이라면 누구의 의견을 들을 것인가?
혹시 이런 생각이 들지 않았나? '회사를 설립하고 지금까지 이끌어온 대표의 비전을 따라야 하는 것 아닌가?' 아니면 '매일 고객과 만나며 현장 목소리를 잘 알고 있는 영업팀이 가장 현실적이지 않을까?' 또는 '기술적 실현 가능성을 가장 잘 아는 개발팀의 판단을 신뢰해야 하는 것 아닌가?'
이런 상황에서 많은 사람들이 범하는 치명적 착각이 있다. 정답이 존재한다고 생각하는 것이다. 마치 수학 문제처럼 누군가는 분명히 옳은 답을 가지고 있을 것이라고 믿는다.
하지만 현실은 훨씬 복잡하고 불확실하다. 각자가 가진 정보와 관점은 제한적이고, 시장은 예측 불가능하며, 고객의 니즈는 계속 변화한다. 더 중요한 것은 각자가 보는 현실 자체가 다르다는 점이다. 영업팀이 만나는 고객과 CS팀이 응대하는 고객이 다를 수 있고, 대표가 그리는 미래와 개발팀이 생각하는 기술적 가능성 사이에는 간격이 있을 수 있다.
그 누구도 무엇이 정답인지 알 수 없다. 이것이 첫 번째 불편한 진실이다.
그렇다면 진짜 문제는 무엇일까? 이 회의에서 누가 결정을 내려야 하는가? 이 모든 의견을 조율하지 않으면 어떤 일이 벌어질까? 각 부서의 의견이 다를 때, 방향을 맞추지 않으면 제품이 어떻게 될까?
조율자가 없는 조직에서 벌어지는 일들을 실제 사례로 살펴보자.
대표의 의견만 따랐던 A사는 시장과 맞지 않는 기능을 6개월간 개발한 끝에 출시 후 한 달 만에 해당 기능을 제거해야 했다. 대표는 과거의 성공 경험을 바탕으로 판단했지만, 시장 상황은 이미 바뀌어 있었다.
영업팀의 의견만 반영했던 B사는 제품이 점점 무거워져서 신규 고객들이 사용하기 어려워했다. 기존 고객들의 개별적인 요청사항들을 모두 수용하다 보니 제품의 일관성이나 사용성은 뒷전이 되었다.
개발팀이 원하는 대로만 만들었던 C사는 기술적으로는 완벽했지만 고객이 정작 원하는 기능은 없었다. 최신 기술과 완벽한 아키텍처에 집중하다 보니 사용자 관점은 놓쳤다.
CS팀의 요청을 모두 수용했던 D사는 개별 문제들은 해결했지만 전체적인 제품 전략을 잃어버렸다. 현재 발생하는 문제들을 해결하는 데만 급급하다 보니 미래 방향성을 놓쳤다.
"모든 의견을 반영한다고 해서 좋은 제품이 나오는 것이 아니다." 오히려 방향성을 잃고 일관성 없는 제품이 될 가능성이 높다. 각자 다른 목표를 추구하다 보면 결국 아무도 만족하지 못하는 제품이 나온다.
그럼에도 불구하고 많은 기업이 이런 문제를 반복하는 이유는 무엇일까? 이를 이해하기 위해 현대 IT 제품 개발이 가진 근본적 특성을 들여다보자.
상상해보자. 당신이 빵집을 운영한다면 어떨까? 밀가루와 이스트, 설탕의 비율이 정해져 있고, 오븐 온도와 굽는 시간도 경험으로 알 수 있다. 실패하더라도 몇 시간 만에 결과를 확인할 수 있고, 비용도 크지 않다.
하지만 IT 제품은 다르다. 높은 난이도 - 낮은 성공률 - 많은 리소스라는 삼중고에 시달린다. 많은 리소스를 들여 높은 난이도로 만든 제품의 성공률이 낮아진다는 역설적 상황이다.
왜 이런 일이 벌어질까? IT 제품은 단순히 기술적 복잡도의 문제가 아니다. 사용자 행동, 시장 상황, 기술 트렌드 등 수많은 변수가 복합적으로 작용하기 때문에 예측하기 어렵다. 마치 나비 효과처럼, 작은 변화 하나가 전체 결과를 뒤바꿀 수 있다.
더 심각한 것은 실패의 비용이다. 6개월 개발한 기능이 쓸모없다고 판명되면, 그 시간과 비용을 되돌릴 수 없다. 빵은 다시 구우면 되지만, 소프트웨어는 다시 개발해야 한다.
빠른 변화 - 다양한 취향 - 무한한 경쟁. 이것이 현대 시장이 PM들에게 내미는 도전장이다.
얼마나 빠를까? 6개월 전 유행했던 디자인 트렌드는 이미 낡은 것이 되어 있다. 작년에 성공했던 마케팅 전략은 올해는 통하지 않는다. 심지어 지난달에 효과적이었던 사용자 인터페이스도 이번 달에는 구식으로 느껴질 수 있다.
얼마나 다양할까? 같은 제품을 사용하는 고객이라도 사용 목적이 완전히 다르다. 20대 직장인이 원하는 기능과 50대 CEO가 원하는 기능이 다르고, 한국 사용자의 니즈와 미국 사용자의 니즈가 다르다. 심지어 같은 사람이라도 오전에 원하는 것과 오후에 원하는 것이 다를 수 있다.
얼마나 치열할까? 당신이 좋은 아이디어를 생각해냈다면, 지구 반대편의 누군가도 비슷한 아이디어를 생각해냈을 가능성이 높다. 그리고 그 누군가는 당신보다 더 많은 자본과 인력을 가지고 있을지도 모른다.
이런 환경에서 각 부서가 제각각 최선을 다한다고 해서 좋은 결과가 나올까? 영업팀이 고객 요구사항을 열심히 수집하고, 개발팀이 기술적 완성도를 높이고, 디자인팀이 아름다운 인터페이스를 만들어도, 이 모든 것이 한 방향으로 모아지지 않으면 의미가 없다.
"이 모든것을 조율해 오로지 제품의 성공에만 집중하는 전문 인력이 필요하다." 바로 여기서 PM(Product Manager)의 필요성이 대두된다.
PM의 필요성을 더 깊이 이해하기 위해 제품 개발에 관한 두 가지 불편한 진실을 마주해야 한다. 이것은 경험 많은 PM들이 수년간의 시행착오를 통해 깨달은 현실이다.
당신의 아이디어 중 최소 절반 이상은 유효하지 않을 것이다. 이것은 능력의 문제가 아니다. 아무리 경험이 많은 대표든, 고객과 가까운 영업팀이든, 기술에 정통한 개발팀이든 상관없다.
왜 이런 일이 벌어질까? 인간의 뇌는 패턴 인식에 특화되어 있다. 과거의 경험을 바탕으로 미래를 예측하려고 한다. 문제는 시장이 과거와 같지 않다는 점이다. 과거에 성공했던 방식이 지금도 통할 것이라는 보장은 없다.
더 근본적인 문제도 있다. 우리는 우리가 만들고 싶은 제품과 고객이 원하는 제품을 혼동한다. 심리학에서 말하는 '투영'이다. 내가 이 기능을 유용하다고 생각하니까, 고객들도 분명 그럴 것이라고 착각한다.
실제로 구글의 전설적인 PM이었던 마리사 메이어는 "우리가 확신하는 아이디어의 10% 정도만 성공한다"고 말한 바 있다. 구글 같은 회사에서도 이 정도라면, 일반적인 회사에서는 어떨까?
가치있는 아이디어라 하더라도 비즈니스 가치를 만들기 위해 몇번의 시도와 실패가 필요하다. 이것은 더욱 절망적인 현실이다.
좋은 아이디어를 가졌다고 해서 바로 성공하는 것이 아니다. 시장에 맞게 다듬고, 고객 피드백을 반영하고, 기술적 문제를 해결하는 과정에서 수많은 시행착오를 거쳐야 한다.
인스타그램을 생각해보자. 처음에는 '버번(Burbn)'이라는 위치 기반 체크인 앱이었다. 사진 공유는 여러 기능 중 하나일 뿐이었다. 하지만 사용자들은 사진 공유 기능만 사용했다. 창업자들이 이를 인식하고 과감히 다른 기능들을 제거한 후에야 지금의 인스타그램이 탄생했다. 트위터도 마찬가지다. 처음에는 팟캐스팅 플랫폼인 '오데오(Odeo)'의 부산물이었다. 직원들이 사내 해커톤에서 만든 프로토타입이 지금의 트위터가 되었다.
이런 사례들이 보여주는 것은 무엇인가? 좋은 제품은 계획대로 만들어지지 않는다는 것이다. 시장과의 상호작용을 통해 진화하고 발전한다.
이런 어려움을 해결하기 위해 많은 기업이 전통적인 프로젝트 관리 방식을 사용해왔다. 하지만 이 방식에는 치명적인 한계가 있다.
전통적인 프로젝트 관리자의 주요 역할은 무엇이었을까? 엔지니어를 위해 요구사항을 수집하고 문서화해주는 것이었다. 마치 건축가가 설계도를 그리면 시공업체가 그대로 짓는 것처럼 말이다.
폭포수 모델을 따라 기획 → 요구사항 정의 → 디자인 → 개발 순서로 진행했다. 각 단계가 완료되면 다음 단계로 넘어가고, 되돌아가는 것은 최대한 피했다. 변경은 비용이고, 비용은 최소화해야 한다는 논리였다.
이 방식은 분명한 장점이 있다. 계획이 명확하고, 일정 예측이 용이하며, 각자의 역할이 분명하다. 특히 물리적 제품을 만들 때는 매우 효과적이다. 자동차나 건물을 만들면서 중간에 설계를 바꾸는 것은 실제로 큰 비용이 들기 때문이다.
하지만 소프트웨어는 다르다. 코드는 유연하고, 변경은 상대적으로 쉬우며, 사용자의 피드백을 실시간으로 반영할 수 있다. 더 중요한 것은 소프트웨어의 가치는 사용자가 실제로 사용해봐야 알 수 있다는 점이다.
"프로젝트 관리의 근본적인 문제는 '고객에 대한 검증'이 너무 늦게 일어난다는 것"이다. 모든 것을 다 만들고 나서야 고객의 반응을 확인한다. 마치 요리를 다 해놓고 나서 손님의 취향을 묻는 것과 같다.
실제 사례들을 보자:
Case 1: 완벽한 기획을 했지만, 6개월 뒤 고객 니즈가 바뀜
한 스타트업이 6개월간 완벽한 기획서를 작성했다. 시장 조사도 철저히 했고, 고객 인터뷰도 수십 차례 진행했다. 하지만 개발을 시작하고 6개월이 지나자 시장 상황이 바뀐 것이다. 경쟁사가 비슷한 제품을 먼저 출시했고, 고객들의 관심사도 다른 곳으로 이동했다.
Case 2: 모든 기능을 다 만든 뒤 검증했더니, 아무도 안 씀
한 대기업의 자회사가 1년간 완벽한 제품을 개발했다. 기획에서 요구한 모든 기능이 구현되었고, 버그도 거의 없었다. 하지만 베타 테스트 결과는 참담했다. 사용자들은 핵심 기능조차 사용하지 않았다. "복잡해서 뭘 해야 할지 모르겠다"는 피드백이 대부분이었다.
Case 3: 기획을 다 하고 개발했더니, 개발팀이 처음부터 다시 만들어야 한다고 함
한 회사가 3개월간 상세한 기획을 완료했다. 하지만 개발을 시작하자 문제가 드러났다. 기존 시스템과 호환되지 않는 부분이 너무 많았다. 기획자가 원하는 사용자 경험을 구현하려면 백엔드 시스템을 전면적으로 재구축해야 했다. 결국 기획을 다시 하거나, 시스템을 새로 만들거나 둘 중 하나를 선택해야 하는 상황이 되었다.
이 모든 사례에서 공통점을 찾을 수 있다. 계획은 완벽했지만, 현실과의 괴리가 있었다는 것이다.
"결국, 우리가 배워야 하는 것은 '기획'이 아니라 '적응'이다. 제품을 만들면서 계속 조정할 수 있는 조직이 되어야 한다."
이런 문제를 해결하기 위해 등장한 것이 애자일과 린 스타트업 방법론이다. 하지만 많은 기업이 이런 방법론을 도입해도 여전히 같은 문제에 부딪힌다. 왜 그럴까?
2001년, 17명의 소프트웨어 개발자들이 미국 유타주의 스키 리조트에서 만났다. 이들은 기존의 경직된 개발 방식에 문제를 느끼고 있었다. 3일간의 논의 끝에 나온 것이 바로 애자일 소프트웨어 개발 선언이다.
핵심 원칙은 네 가지였다:
공정과 도구보다 개인과 상호작용을
포괄적인 문서보다 작동하는 소프트웨어를
계약 협상보다 고객과의 협력을
계획을 따르기보다 변화에 대응하기를
이 선언이 혁명적이었던 이유는 무엇인가? 기존의 '예측과 통제' 방식에서 '적응과 학습' 방식으로의 패러다임 전환을 제시했기 때문이다.
에릭 리스가 제시한 린 스타트업은 한 발 더 나아갔다. BUILD-MEASURE-LEARN 사이클을 통해 아이디어를 제품으로 만들고, 데이터를 측정하여 학습하는 과정을 반복한다는 접근법을 제시했다.
핵심은 '최소 기능 제품(MVP)'을 빠르게 만들어서 시장에서 검증하는 것이었다. 완벽한 제품을 오랫동안 개발하기보다는, 핵심 가설을 검증할 수 있는 최소한의 제품을 빠르게 출시하고, 고객의 반응을 보면서 개선해나가는 방식이다.
하지만 현실은 어떨까? "많은 기업들이 엄청난 시간과 비용을 들이고도 매우 허망한 성과를 거두는 현상은 그리 놀라운 일도 아니다." 애자일을 도입했다고 선언하고, 스크럼 마스터를 뽑고, 스프린트를 돌리지만 여전히 같은 문제가 반복된다.
애자일 도입 시 가장 큰 어려움을 조사한 결과를 보면 흥미로운 사실을 발견할 수 있다. 기술적인 문제나 방법론 자체의 문제가 아니라, 조직적 가치나 문화의 문제, 일반적인 저항과 변화 관리의 어려움이 상위를 차지한다.
즉, 중요한 것은 '방법'이 아니라 '태도'라는 뜻이다. 애자일 도구를 사용하고 린 스타트업 용어를 쓴다고 해서 자동으로 애자일해지는 것은 아니다. 근본적인 사고방식의 변화가 없으면 겉모습만 바뀐 채 같은 문제를 반복하게 된다.
그렇다면 올바른 접근법은 무엇일까? 표면적인 방법론을 넘어서 근본적인 원칙을 이해해야 한다.
당신이 새로운 요리를 만든다고 상상해보자. 모든 재료를 넣고 2시간 동안 끓인 후에 맛을 보는 것과, 중간중간 맛을 보면서 간을 맞춰가는 것 중 어느 쪽이 더 합리적일까?
제품 개발도 마찬가지다. 모든 것을 다 만들고 나서 시장에서 검증받는 것이 아니라, 가능한 한 빨리 핵심 가정들을 검증해야 한다.
그런데 여기서 중요한 질문이 생긴다. 도대체 무엇을 검증해야 할까? 답은 세 가지 핵심 위험에 있다:
이 제품은 가치가 있는가? 고객이 정말로 이 문제를 해결하고 싶어할까? 우리가 생각하는 문제가 실제로 고객에게는 중요하지 않을 수도 있다. 아무리 훌륭한 해결책이라도 해결할 문제가 존재하지 않으면 의미가 없다.
이 제품은 사용하기 좋은가? 가치가 있다고 해서 끝이 아니다. 고객이 실제로 사용할 수 있어야 한다. 너무 복잡하거나, 이해하기 어렵거나, 기존 습관과 너무 다르면 아무도 사용하지 않을 수 있다.
이 제품을 우리가 만들 수 있는가? 기술적으로 구현 가능할까? 우리 팀의 역량으로 감당할 수 있을까? 예산과 일정 내에서 실현 가능할까? 좋은 아이디어라도 실행할 수 없으면 그저 꿈일 뿐이다.
이 세 가지 질문에 대한 답을 조기에 찾는 것이 핵심이다. 6개월 개발하고 나서 "고객이 원하지 않네요"라고 깨닫는 것보다는, 2주 만에 "고객이 원하지 않네요"라고 깨닫는 것이 훨씬 낫다.
전통적인 방식에서는 각자의 역할이 명확했다. 기획자가 기획하고, 디자이너가 디자인하고, 개발자가 개발한다. 마치 공장의 생산라인처럼 순차적으로 진행된다. 하지만 혁신적인 제품은 이런 방식으로 나오지 않는다. 절차에 맞게 만들어지지 않는다. 대신 모든 과정에서 각 전문가들이 함께 고민하고 결정해야 한다.
예를 들어, 새로운 기능을 기획할 때를 생각해보자. 기획자가 혼자 기획서를 작성하고, 개발자에게 "이거 만들어주세요"라고 전달하는 것이 과연 최선일까?
더 좋은 방식은 이렇다: 기획자가 문제를 정의하면, 개발자와 디자이너가 함께 모여서 "이 문제를 어떻게 해결할까?"를 고민한다. 개발자는 "기술적으로 이런 방법이 더 효율적일 것 같은데요"라고 제안하고, 디자이너는 "사용자 경험 측면에서는 이렇게 하는 것이 어떨까요?"라고 의견을 낸다.
이런 과정을 거치면 처음 기획자가 생각했던 것보다 훨씬 좋은 해결책이 나올 가능성이 높다. 각자의 전문성이 시너지를 일으키기 때문이다.
가장 중요한 원칙이다. 기능을 구현하기 위해 일을 하지 않는다. 기능은 수단이고 문제 해결이 목적이라는 점을 잊지 말아야 한다.
이 차이가 얼마나 중요한지 실제 사례로 보자. 한 회사에서 "검색 기능을 개선하자"는 프로젝트를 시작했다. 기존 방식대로라면 "검색 속도를 빠르게 하고, 검색 결과의 정확도를 높이고, 검색 인터페이스를 예쁘게 만들자"가 목표가 될 것이다. 하지만 문제 해결 관점에서 접근하면 질문이 달라진다. "고객이 검색을 통해 해결하려고 하는 문제가 무엇일까?" 조사해보니 고객들은 단순히 정보를 찾는 것이 아니라, 특정 작업을 빠르게 완료하고 싶어했다. 결과적으로 팀은 검색 결과만 개선하는 것이 아니라, 자주 사용하는 작업을 바로 실행할 수 있는 '빠른 실행' 기능을 추가했다. 고객 만족도는 예상보다 훨씬 높았다. 고객의 진짜 문제를 해결했기 때문이다.
이런 관점의 전환이 일어나면, 팀원들의 사고방식도 바뀐다. "이 기능을 어떻게 구현할까?"가 아니라 "이 문제를 어떻게 해결할까?"를 고민하게 된다.
이런 접근법이 가능하려면 특별한 역할이 필요하다. 그것이 바로 PM이다. 하지만 PM의 역할을 이해하기 위해서는 먼저 현대 제품 개발의 특성을 파악해야 한다.
Product Management를 하면서 가장 많이 하는 일이 '소통'인 이유는 무엇일까? PM은 마치 유엔의 동시통역사처럼 서로 다른 언어를 쓰는 사람들 사이에서 의미를 전달하는 역할을 하기 때문이다.
생각해보자. 개발팀이 말하는 '기술적 제약'이 정확히 무엇을 의미하는지 디자인팀이 알 수 있을까? 디자인팀이 말하는 '사용자 경험'이 구체적으로 어떤 기술적 구현을 필요로 하는지 개발팀이 이해할 수 있을까?
더 복잡한 것은 각 팀이 생각하는 '좋은 제품'이 다르다는 점이다:
개발팀의 좋은 제품: "코드가 깔끔하고, 성능이 뛰어나며, 확장 가능하고 유지보수가 쉬운 제품이야. 기술적 부채가 없고, 장애 발생 가능성이 낮은 제품 말이야."
디자인팀의 좋은 제품: "사용자가 직관적으로 이해할 수 있고, 아름답고, 일관된 경험을 제공하는 제품이야. 사용자가 스트레스받지 않고 원하는 일을 쉽게 할 수 있는 제품 말이야."
마케팅팀의 좋은 제품: "차별화되고, 메시지가 명확하며, 고객에게 어필하기 쉬운 제품이야. 경쟁사와 구분되고, 우리의 브랜드 가치를 잘 표현하는 제품 말이야."
영업팀의 좋은 제품: "고객이 쉽게 이해하고, 빠르게 구매 결정을 내릴 수 있는 제품이야. 가격도 합리적이고, 고객의 ROI를 명확하게 보여줄 수 있는 제품 말이야."
경영진의 좋은 제품: "빠르게 수익을 내고, 시장 점유율을 높이며, 회사의 성장에 기여하는 제품이야. 투자 대비 수익이 명확하고, 확장 가능성이 있는 제품 말이야."
모두 틀린 말이 아니다. 하지만 이 모든 관점이 동시에 충족되기는 어렵다. 때로는 트레이드오프가 필요하고, 때로는 우선순위를 정해야 한다.
PM의 도전은 이 모든 관점을 조화시키면서도 고객에게 진정한 가치를 제공하는 제품을 만드는 것이다. 마치 오케스트라 지휘자가 각기 다른 악기의 소리를 하나의 아름다운 음악으로 만들어내는 것처럼 말이다.
"PM은 '협업'을 하기 위해 태어난 직무이다." 이 말의 진짜 의미는 무엇일까?
IT 제품을 성공시키기 위해서는 다양한 분야의 전문가가 필요하다. 그리고 전문가들은 자신의 분야에서 활약할 때 최고의 역량을 발휘한다. 개발자에게 마케팅을 맡기거나, 디자이너에게 재무 계획을 세우라고 하는 것은 비효율적이다.
하지만 각자 자신의 전문 분야에만 집중한다면? 결과적으로 나오는 제품은 파편화될 가능성이 높다. 기술적으로는 훌륭하지만 사용하기 어렵거나, 디자인은 아름답지만 구현이 불가능하거나, 마케팅 메시지는 매력적이지만 실제 제품과 다를 수 있다.
PM의 역할은 각 분야의 전문성을 가진 사람들이 오로지 '제품 성공'에 힘을 모을 수 있도록 하는 것이다. 이를 위해서는 특별한 능력이 필요하다. 각 분야를 깊이 이해할 필요는 없지만, 각 분야의 언어를 번역하고 연결할 수 있어야 한다.
예를 들어, 개발팀이 "이 기능을 구현하려면 데이터베이스 구조를 전면 수정해야 해서 3개월이 걸립니다"라고 했을 때, PM은 이것을 "사용자 경험을 개선하기 위해 기술적 투자가 필요한 상황"으로 번역해서 경영진에게 설명할 수 있어야 한다.
반대로 경영진이 "이번 분기 매출 목표를 달성하기 위해 더 많은 기능이 필요하다"고 했을 때, PM은 이것을 "고객 가치를 높이면서도 개발 리소스를 효율적으로 활용할 수 있는 방법"으로 번역해서 개발팀에게 전달할 수 있어야 한다. PM은 '협업'을 통해 '최선'의 결과물을 만들어내는 데 전문가가 되어야 한다.
그런데 협업은 말처럼 쉽지 않다. 모두가 좋은 의도를 가지고 있는데도 왜 자꾸 갈등이 생기고, 오해가 발생하고, 결과적으로 좋은 제품이 나오지 않는 걸까?
수년간 다양한 팀을 관찰하고 분석한 결과, 협업이 실패하는 핵심적인 이유는 크게 세 가지로 나눌 수 있다. 이것을 이해하면 왜 PM이 필요한지, 그리고 PM이 어떤 역할을 해야 하는지가 명확해진다.
회의실에서 같은 프로젝트에 대해 이야기하고 있는데, 마치 서로 다른 영화를 보고 있는 것 같은 경험을 해본 적이 있을 것이다. "대표, 영업, 개발팀이 전부 다른 현실을 보고 있다. 의사결정이 모든 정보를 고려하지 않은 채 이루어진다."
왜 이런 일이 벌어질까? 각자가 가진 정보의 출처와 성격이 다르기 때문이다.
영업팀은 고객과의 직접적인 만남에서 나온 정보를 가지고 있다. "고객이 이런 기능을 원한다고 직접 말했어요"라는 생생한 경험이다. 하지만 이 정보는 특정 고객이나 특정 상황에 한정될 수 있다.
개발팀은 기술적 제약과 가능성에 대한 정보를 가지고 있다. "이 방식으로 구현하면 성능 문제가 생길 것 같아요"라는 전문적 판단이다. 하지만 이 정보는 사용자 관점이나 비즈니스 영향은 고려하지 않을 수 있다.
대표는 전체적인 비즈니스 전략과 시장 상황에 대한 정보를 가지고 있다. "우리가 이 방향으로 가야 경쟁력을 확보할 수 있어요"라는 거시적 관점이다. 하지만 이 정보는 현장의 세부적인 상황은 반영하지 못할 수 있다.
CS팀은 현재 제품의 문제점과 고객 불만에 대한 정보를 가지고 있다. "이 부분 때문에 고객 문의가 가장 많이 들어와요"라는 현실적 데이터다. 하지만 이 정보는 미래 기회보다는 현재 문제에 집중될 수 있다.
문제는 이 정보들이 서로 공유되지 않는다는 점이다. 각자는 자신이 가진 정보를 바탕으로 '객관적인' 판단을 내린다고 생각하지만, 실제로는 부분적인 정보에 기반한 주관적인 판단일 수 있다.
이런 정보 불균형은 '전략적 격차'를 만들어낸다. 조직심리학자들이 발견한 세 가지 유형이 있다:
지식 격차(The Knowledge Gap): 경영진이 알고 싶어하는 것과 회사가 실제로 알고 있는 것 사이의 차이다. 실제 회의에서 이런 대화가 오간다: "이 프로젝트가 신규 고객 확보를 늘리는 데 도움이 될 것이라 생각합니다. 신규 고객 확보는 회사 차원에서 우선시되는 수익 목표입니다." "그런데 구체적으로 어떤 고객이 이 기능을 원하나요?" "음... 그건 정확히 조사해봐야 할 것 같습니다." 목표는 명확하지만 현실에 대한 이해가 부족한 상황이다. 이런 상태에서 내린 결정은 추측에 기반할 수밖에 없다.
정렬 격차(The Alignment Gap): 사람들이 실제로 하는 일과 경영진이 그들에게 기대하는 일 사이의 차이다. 한 회사에서 이런 일이 있었다: "대형 컨설팅 회사를 고용해 향후 5년간의 제품 로드맵을 설정하게 하고, 이를 팀에게 전달했습니다. 하지만 실제로 개발팀은 그 로드맵과 다른 방향으로 일하고 있었어요. 고객의 즉각적인 요구사항을 해결하는 데 시간을 쓰고 있었거든요." 회사의 평가 시스템은 로드맵 준수를 측정했지만, 현실에서는 고객 만족도가 더 중요했다. 팀원들은 딜레마에 빠졌다. 평가를 위해서는 로드맵을 따라야 하지만, 실제로는 고객 문제를 해결해야 했다.
효과 격차(The Effects Gap): 우리의 행동이 기대하는 결과와 실제로 발생하는 결과 사이의 차이다. 이런 상황을 생각해보자: "팀에게 목표와 방향을 제공하고 그들이 목표를 달성할 수 있도록 탐색할 여지를 주려고 했는데, 실제로는 더 많은 정보를 요구하고, 더 자세한 계획을 세우라고 하고 있었어요. 팀원들은 점점 수동적이 되어갔죠." 자율성을 주려는 의도였지만, 실제 행동은 통제를 강화하는 방향이었다. 의도와 행동, 그리고 결과가 모두 따로 놀고 있었던 것이다.
두 번째 문제는 더욱 복잡하다. 각 팀이 서로 다른 목표를 가지고 움직인다는 점이다.
영업팀 김 과장의 입장에서 생각해보자. 그에게는 이번 분기 매출 목표가 있다. 고객들이 요청하는 기능이 있으면 계약 성사 확률이 높아진다. 당연히 "이 기능이 있어야 영업이 쉬워요"라고 주장할 것이다. 그의 관점에서는 완전히 합리적인 요구다.
개발팀 박 부장의 입장은 어떨까? 그에게는 시스템의 안정성과 확장성이 중요하다. 급하게 기능을 추가하면 기술적 부채가 쌓이고, 나중에 더 큰 문제가 될 수 있다. "이거 개발하려면 일정이 너무 늘어납니다"라고 말하는 것도 그의 관점에서는 책임감 있는 판단이다.
CS팀 이 차장은 또 다른 우선순위를 가지고 있다. 매일 들어오는 고객 불만을 처리하면서, 현재 제품의 문제점을 누구보다 생생하게 느끼고 있다. 새로운 기능을 추가하기보다는 기존 문제를 해결하는 것이 더 시급해 보인다.
PM이 없다면? "서로 원하는 걸 주장하다가 결국 결론이 나지 않음." 혹은 목소리가 큰 사람이나 권한이 있는 사람의 의견을 따르게 되어 최선의 결정과는 거리가 멀어진다.
더 심각한 문제는 각자의 '최선'이 전체적으로는 '최악'의 결과를 만들 수 있다는 점이다. 영업팀의 요구를 모두 수용하면 제품이 복잡해지고, 개발팀의 의견만 따르면 시장 기회를 놓치고, CS팀의 문제만 해결하면 혁신이 멈출 수 있다.
각자는 선의로, 회사를 위해서 최선을 다하고 있지만, 결과적으로는 회사 전체에 해가 될 수 있다. 이것이 바로 우선순위 충돌의 함정이다.
세 번째 문제는 가장 실무적이면서도 치명적이다. 결정이 나도 아무도 실행하지 않는다는 것이다.
회의에서는 모두가 적극적으로 의견을 내고, 열정적으로 토론한다. 그리고 마침내 결론이 난다. "그럼 이렇게 진행하는 걸로 하죠." 모두가 고개를 끄덕인다. 회의는 성공적으로 끝난다. 그런데 일주일 후에 확인해보면? "회의에서 나온 결정이 결국 아무도 맡지 않아서 사라진다." 왜 이런 일이 벌어질까? 책임이 명확하지 않기 때문이다. "누군가 해야 할 일"은 "아무도 하지 않는 일"이 되기 쉽다.
더 구체적으로 보면 이런 상황들이 발생한다:
"그 일은 제가 하는 줄 알았는데, 다른 팀에서 한다고 들었어요."
"저는 A팀이 하는 걸로 알고 있었는데, A팀은 B팀이 한다고 하네요."
"중요한 일이긴 한데, 제 KPI에는 포함되어 있지 않아서..."
"그 일을 하려면 다른 팀의 협조가 필요한데, 요청하기가 애매해서..."
"PM이 없으면 누가 이 일을 실제로 진행할 것인지 명확해지지 않는다." 책임이 분산되면 아무도 책임지지 않는 상황이 발생한다. 모두가 자신의 업무라고 생각하지 않거나, 다른 사람이 할 것이라고 기대하며 미루게 된다. 이 문제는 단순히 업무 분장의 문제가 아니다. 더 근본적으로는 '주인의식'의 문제다. 프로젝트나 제품에 대해 진정으로 책임을 느끼는 사람이 없으면, 아무리 좋은 계획이라도 실행되지 않는다.
이 세 가지 문제에 대한 PM의 대응 전략은 명확하다. 하지만 단순히 문제를 해결하는 것을 넘어서, 근본적으로 다른 접근 방식이 필요하다.
PM은 팀 간 정보 비대칭을 해결해야 한다. 하지만 이것이 단순히 정보를 수집해서 전달하는 것을 의미하지는 않는다. 실제 상황을 생각해보자. 영업팀이 "고객이 이 기능을 원한다고 직접 말했어요"라고 했을 때, PM은 어떻게 반응해야 할까?
단순히 이 정보를 개발팀에게 전달하는 것만으로는 충분하지 않다. PM은 더 깊이 파고들어야 한다:
"어떤 고객이 말했나요? 그 고객의 특성은 어떤가요?"
"정확히 어떤 맥락에서 그런 요청을 했나요?"
"비슷한 요청을 한 다른 고객도 있나요?"
"그 고객이 정말 원하는 것은 그 기능일까요, 아니면 그 기능을 통해 해결하려는 다른 문제가 있을까요?"
이런 질문을 통해 정보의 맥락과 의미를 파악해야 한다. 그리고 이것을 개발팀에게 전달할 때도 단순히 "고객이 원한다"가 아니라 "이런 특성을 가진 고객이, 이런 문제를 해결하기 위해, 이런 방식의 해결책을 원하고 있다"는 식으로 구체화해야 한다.
반대로 개발팀이 "기술적으로 어렵다"고 했을 때도 마찬가지다:
"구체적으로 어떤 부분이 어려운가요?"
"어려운 이유는 기술적 한계인가요, 아니면 현재 시스템의 제약인가요?"
"다른 방법으로 비슷한 결과를 얻을 수는 없을까요?"
"만약 이 기능을 꼭 만들어야 한다면, 어떤 준비가 필요할까요?"
PM이 해야 할 일은 모든 부서가 동일한 정보를 기반으로 의사결정을 할 수 있도록 조율하고, 의사결정 과정에서 중요한 정보가 누락되지 않도록 관리하는 것이다. 하지만 여기서 중요한 것은 PM이 모든 정보를 독점하려고 해서는 안 된다는 점이다. 오히려 각 팀이 서로의 정보를 직접 공유할 수 있는 환경을 만드는 것이 더 중요하다.
PM은 각 팀이 같은 목표를 보도록 만들어야 한다. 하지만 이것이 단순히 "회사의 목표는 이거니까 다들 이걸 우선시하세요"라고 선언하는 것으로는 해결되지 않는다.
실제로는 더 섬세한 접근이 필요하다. "모든 팀이 원하는 기능이 다르다면, 결국 가장 중요한 것이 무엇인지 합의해야 한다." 하지만 이 합의는 강제로 이뤄질 수 없다. 각자가 납득할 수 있는 기준과 근거가 있어야 한다.
예를 들어, 앞서 언급한 회의 상황으로 돌아가보자. 영업팀은 "고객 요청 기능"을, 개발팀은 "기술적 안정성"을, CS팀은 "기존 문제 해결"을 우선시하고 있다.
PM이 할 수 있는 접근법은 이렇다:
1단계: 공통 목표 확인하기
"우리 모두가 원하는 것은 결국 고객 만족을 통한 비즈니스 성공이겠죠? 그렇다면 어떤 선택이 장기적으로 고객 만족도를 높일 수 있을까요?" 이 질문을 통해 각자의 관점이 어떻게 전체 목표에 기여하는지 확인할 수 있다.
2단계: 판단 기준 설정하기
"그렇다면 우리가 결정할 때 어떤 기준을 사용할까요? 고객 영향도? 구현 난이도? 비즈니스 임팩트? 이 기준들의 우선순위는 어떻게 정할까요?" 기준이 명확해지면, 각자의 주장도 이 기준에 맞춰서 평가할 수 있다.
3단계: 데이터 기반 판단하기
"영업팀에서 말씀하신 고객 요청, 구체적으로 몇 명의 고객이 요청했고, 이들의 매출 비중은 어느 정도인가요? CS팀에서 말씀하신 문제, 실제로 이 문제로 인한 고객 이탈은 얼마나 되나요?" 감정이나 추측이 아닌 데이터를 기반으로 판단할 수 있도록 돕는다.
PM이 해야 할 일:
팀 전체가 동일한 목표를 바라볼 수 있도록 공통의 기준을 세운다
"이 기능을 추가하면, 궁극적으로 제품의 목표와 일치하는가?"라는 질문을 계속 던진다
각 선택지의 장단점을 객관적으로 비교할 수 있는 프레임워크를 제공한다
중요한 것은 PM이 독단적으로 우선순위를 정하는 것이 아니라, 팀 전체가 합리적인 기준에 따라 우선순위에 합의할 수 있도록 돕는 것이다.
PM은 역할을 조정하는 사람이다. 하지만 이것도 단순히 업무를 분배하는 것 이상의 의미가 있다.
실제 상황에서 책임 회피가 발생하는 이유를 생각해보자. 대부분의 경우 악의가 있어서가 아니다. 정말로 누가 해야 할 일인지 명확하지 않거나, 다른 사람이 더 적합하다고 생각하거나, 자신이 해야 할 일이라는 것을 인식하지 못했기 때문이다.
"PM이 없으면, 결국 책임지는 사람이 없어서 일이 정체된다."
하지만 PM이 모든 일을 직접 담당할 수는 없다. 대신 각 일이 누구의 책임인지 명확하게 하고, 그 사람이 책임을 다할 수 있도록 지원하는 것이 PM의 역할이다.
효과적인 책임 분담을 위한 PM의 접근법:
1단계: 구체적인 액션 아이템 정의하기
"그럼 이렇게 진행하기로 했으니까..." (X) "김 과장님은 A고객과 B고객에게 이 기능에 대한 니즈를 구체적으로 확인해주시고, 박 부장님은 기술적 제약사항과 대안을 정리해주시고, 이 차장님은 현재 CS 이슈와의 우선순위를 검토해주세요. 모두 이번 주 금요일까지 완료하는 걸로 하겠습니다." (O)
2단계: 의존성 관리하기
"이 일을 하기 위해 다른 팀의 도움이 필요한 부분이 있나요? 있다면 제가 조율해드리겠습니다." 종종 일이 지연되는 이유는 담당자의 게으름이 아니라 다른 팀의 협조가 필요한데 요청하기 어려워서인 경우가 많다.
3단계: 진행 상황 추적하기
단순히 "어떻게 되고 있나요?"라고 묻는 것이 아니라, "어떤 부분에서 어려움을 겪고 계신가요? 제가 도울 수 있는 부분이 있을까요?"라고 접근한다.
PM이 해야 할 일:
결정된 내용이 실행될 수 있도록 각 팀이 해야 할 일을 명확하게 나누는 역할을 한다
"이 기능 개발을 누가 담당할 것인가?"
"팀별로 출시 전에 어떤 준비를 해야 하는가?"
각 담당자가 책임을 다할 수 있도록 필요한 지원을 제공한다
현 부지런컴퍼니 COO 겸 PM
PM 부트캠프 강사, 비즈니스 & 커리어 코치
10여년간 스타트업부터 대기업까지 다양한 환경에서 사업 경험을 쌓았으며, 현재는 PM들이 실무에서 바로 활용할 수 있는 지식과 노하우를 체계적으로 정리하고 전달하는 일에 집중하고 있습니다.
문의: fineday9@hanmail.net
더 많은 PM 인사이트: https://brunch.co.kr/magazine/pmbible
LinkedIn: https://www.linkedin.com/in/thkim9/
PM 바이블 시리즈가 도움이 되셨다면 주변에 다른 분들께도 많이 공유해주세요!