프로덕트 매니지먼트 바이블(1) - 커뮤니케이션
김영수는 6개월 전 스타트업에 PM으로 합류했다. 이전 직장에서는 마케팅을 담당했기 때문에 개발이나 디자인 분야는 완전히 생소했다. 첫 제품 기획 회의에서 일어난 일을 그는 지금도 생생하게 기억한다.
"사용자 플로우에서 인지 부하를 줄이려면 정보 아키텍처를 단순화해야 해요." 디자이너 김민지가 말했다.
"그런데 마이크로서비스 아키텍처에서 API 게이트웨이 레이턴시 때문에 사용자 경험이 저하될 수 있어요." 개발팀장 박성호가 덧붙였다.
영수는 회의실에서 혼자 동떨어진 기분이었다. 다른 사람들은 모두 고개를 끄덕이며 열띤 토론을 이어가고 있었지만, 그는 무슨 말인지 절반도 이해할 수 없었다. '내가 PM이 되려면 이 모든 걸 다 알아야 하나?' 그날 밤 그는 개발 서적과 디자인 가이드북을 주문했다.
3개월 후, 영수는 또 다른 딜레마에 빠졌다. 개발과 디자인 기초를 나름 공부했지만, 전문가들 앞에서는 여전히 초보자였다. 그렇다고 모든 것을 전문가 수준으로 배우기에는 시간이 너무 부족했다. 회사는 기다려주지 않았고, 제품은 계속 발전해야 했다.
바로 그때 그는 한 가지 깨달음을 얻었다. PM은 모든 분야의 전문가가 될 필요가 없다는 것이었다. 하지만 그렇다고 아무것도 몰라도 되는 것은 아니었다. 그 미묘한 균형점을 찾는 것이 핵심이었다.
경영학의 아버지 피터 드러커가 남긴 명언 중 하나가 있다. "자신이 이해하지 못하는 것을 관리하려는 시도는 어리석음의 극치다." 이 말을 들은 수많은 PM들이 절망했다. '그럼 나는 개발도 배우고, 디자인도 배우고, 마케팅도 배워야 한다는 건가?'
하지만 드러커의 말을 다르게 해석해보자. 그는 '모든 것을 전문가 수준으로 알아야 한다'고 하지 않았다. '이해'라는 단어가 핵심이다. 즉, PM은 좋은 제품을 만드는데 필요한 '모든 것'을 이해할 수 있는 수준으로 알아야 한다는 뜻이다.
레이더&전파 통신 회사에서 일했던 한 PM의 실제 경험담이 있다. 그의 회사를 LED 회사가 인수했고, LED 전문가였던 연구소장이 새로 부임했다. 기존 팀원들은 "LED 전문가가 우리 분야를 어떻게 이해하겠어?"라며 반발했다.
하지만 그 연구소장은 놀라운 일을 해냈다. 그는 LED에 대해서는 전문가였지만, 레이더 기술은 문외한이었다. 대신 그는 끊임없이 질문했다. "이 기술이 고객에게 어떤 가치를 주나요?" "이 방식과 저 방식의 차이점이 뭔가요?" "고객이 가장 중요하게 생각하는 부분은 어디인가요?"
6개월 후, 그는 팀의 완전한 신뢰를 얻었다. 레이더 기술의 세부사항은 여전히 모르지만, 제품이 해결해야 할 문제와 고객이 원하는 가치는 누구보다 명확하게 파악하고 있었다. 그리고 그 이해를 바탕으로 팀원들과 효과적으로 소통할 수 있었다.
PM이 이해해야 할 '모든 것'의 범위를 파악하기 위해서는 먼저 좋은 제품의 조건을 명확히 해야 한다. 기업이 제품을 만들어 고객에게 판매하고 이익을 얻는 기본적인 비즈니스 구조를 생각해보면, 좋은 제품의 조건은 세 가지다:
고객에게 '가치 있는' 제품이어야 한다
기업에게 '이익이 남는' 제품이어야 한다
제때 '올바른 제품'을 생산할 수 있어야 한다
이 세 가지 조건을 만족시키기 위해 PM은 각각에 대한 전문성을 가져야 한다. 하지만 여기서 중요한 것은 PM이 모든 것을 깊이 알 필요는 없다는 점이다. 오히려 PM의 주요 역할은 '전문가들과 협업하는 사람'이다. 즉, PM은 '모든 것을 깊이 알 필요는 없지만, 모든 것을 연결할 수 있어야 한다.'
첫 번째로 PM이 반드시 전문성을 가져야 할 분야는 고객 가치다. 왜 고객은 제품을 구매할까? 가치가 있기 때문이다. 그런데 누가 그 가치를 결정하는가? 바로 고객이다.
많은 기업이 "우리 제품은 가치있다"고 주장하지만, 정작 고객들은 그렇게 생각하지 않는 경우가 많다. PM은 이런 간극을 메우는 역할을 해야 한다.
고객을 이해한다는 것은 다음과 같은 질문들에 답할 수 있어야 한다는 뜻이다:
고객은 무엇에 '불편함'을 느끼는가?
고객은 어떤 '욕구'가 있는가?
고객은 언제 제품을 '구매'하는가?
고객은 제품에 대해 어떤 '감정'을 느끼는가?
문제는 많은 PM들이 고객에 대해 그저 '추측'을 한다는 점이다. "고객은 이럴 것이다", "사용자들은 분명 이런 기능을 원할 것이다"와 같은 가정에 기반해 제품을 만든다. 하지만 고객 가치는 '추측'이 아닌 진짜 고객에 대한 '이해'에서 시작해야 한다.
이를 위해 PM은 정성적 분석과 정량적 분석을 모두 활용해야 한다.
정성적 분석은 고객이 특정 행동을 하는 '이유'를 이해하는 것이다. 인간은 통계로 이루어진 동물이 아니다. 고객이 왜 이런 행동을 하는지를 모르면 어떤 데이터도 해석이 불가능하다. 이를 위해서는 행동심리학, 뇌과학, 사회학, 철학 등의 지식이 도움이 된다.
정량적 분석은 고객이 실제로 '무엇'을 하는가를 파악하는 것이다. 숫자만이 더 가치있는 행동을 발견하게 한다. 다양한 분석도구들을 통해 '판단'이 가능해졌고, 데이터 분석은 PM의 핵심 의사소통 수단이 되었다. 고객 행동 데이터, 퍼널 분석, A/B 테스트 등이 여기에 포함된다.
두 번째로 PM이 오너십을 가져야 할 분야는 비즈니스다. 좋은 제품과 성공적인 제품은 다르다. 프로덕트 팀은 제품이 사업적인 성공을 거두었을 때만 가치가 있다.
여기서 주의할 점은 비즈니스 성공이 단순히 '돈을 많이 버는 것'이 아니라는 점이다. 기업이 추구하는 가치를 세상에 많이 제공하면 고객은 구매를 한다. 부동산 투자에는 프로덕트 매니저가 필요하지 않다는 말이 있다. 이는 진정한 가치 창출 없이는 지속가능한 비즈니스를 만들 수 없다는 의미다.
PM이 이해해야 할 비즈니스 영역은 광범위하다. 사업 개발, 전략 기획, 마케팅, 브랜딩, 영업, 재무, 법무 등 모든 영역을 아우른다.
특히 마케팅은 갈수록 중요해지고 있다. 제품을 구매하게 만드는 행위가 바로 마케팅이며, 제품의 개발과 마케팅은 직접적으로 연결되어 있다. 좋은 제품을 만드는 것만큼 잘 만들어진 제품을 잘 파는 것도 중요하다.
실제로 브라이언 체스키가 Airbnb에서 PM 역할을 없앤 이유 중 하나도 이것이었다. 제품의 위기에서 구한 방법과 디자이너를 향한 그의 조언을 다룬 글에서, 그는 제품과 마케팅의 경계가 모호해지는 상황에서 더 통합적인 접근이 필요하다고 설명했다.
또한 시장과 산업에 대한 이해도 필요하다. 도메인 지식의 진짜 의미는 시장과 산업의 전문성을 갖는 것이다. 많은 PM들이 도메인 분야를 가리지 않고 일할 수 있는 이유는 지식의 전문성이 아닌 시장과 산업의 전문성이 중요하기 때문이다.
경쟁사에 대한 이해
기술 트렌드의 변화
관련 산업 분석자료 조사
경쟁 환경을 이해하는 것은 특히 중요하다. 경쟁사에 비해 '압도적으로' 좋은 제품을 만들어야 성공할 수 있기 때문이다. 단순히 조금 더 나은 제품으로는 시장에서 성공하기 어렵다.
세 번째는 프로덕트 자체에 대한 이해다. PM은 제품 출시에 대한 오너십을 가져야 한다. 이를 위해서는 출시 과정에 대한 전반적인 이해가 있어야 한다:
디자인은 어떻게 진행되는가?
개발은 어떻게 진행되는가?
프로젝트는 어떻게 관리되는가?
하지만 여기서 가장 중요한 것은 기술적 지식이나 디자인 스킬이 아니다. PM에게 무엇보다 중요한 것은 더 좋은 제품을 만들기 위해 필요한 끊임없는 도전과 집착이다.
프로덕트 팀은 일반적으로 어떻게 구성될까? 회사별로 다르지만 보통 1~2인의 디자이너, 2~10인의 개발자, 그리고 PM 1인으로 구성된다. 이 팀이 제대로 작동하기 위한 핵심 철학은 '자율 + 책임'이다.
각 팀원이 자신의 전문 영역에서 자율성을 가지되, 그에 따른 책임도 져야 한다는 뜻이다. PM의 역할은 이런 자율성을 보장하면서도 팀이 같은 목표를 향해 나아갈 수 있도록 조율하는 것이다.
도널드 노먼의 『디자인과 인간 심리』에서 제시하는 좋은 디자인의 조건을 보자. 잘 디자인된 제품은:
이해 가능(의사소통)하고
쉽게 사용(상호작용)할 수 있어서
사람들의 필요를 충족시켜줄 뿐만 아니라
형태적 심미성과 즐거운 경험을 선사한다
디자인 사고(Design Thinking)는 단순한 UI/UX 설계를 넘어 문제 해결 방식을 의미한다. PM과 디자이너가 협업할 때 가장 중요한 것은 고객 문제 해결에 집중하는 것이다. 좋은 디자인은 곧 비즈니스적 가치를 창출하는 디자인이다.
아프리카의 혁신적인 물 운반 도구를 생각해보자. 기존의 물통 대신 바퀴가 달린 물통을 디자인함으로써 여성들의 물 운반 부담을 혁신적으로 줄인 사례다. 이것이 바로 디자인 사고가 세상을 변화시키는 방식이다.
디자이너는 PM의 최고의 파트너다. 디자이너는 제품의 본질을 시각화하는 역할을 하며, 단순한 '요구사항 수행자'가 아니다. 디자이너가 비즈니스 목표와 고객 경험을 기반으로 주도적으로 디자인할 수 있어야 한다.
PM은 디자이너와 끊임없이 고객 문제를 어떻게 해결할지 소통해야 한다. 함께 고민해야 할 질문들은 다음과 같다:
"이 UI 요소가 고객 경험에 어떤 영향을 줄까?"
"고객이 원하는 것은 무엇이고, 디자인적으로 어떻게 해결할 수 있을까?"
디자이너가 자율성을 발휘해야 할 영역은 크게 세 가지다:
고객 경험은 당신 생각보다 훨씬 섬세하다. UX는 단순히 예쁜 디자인이 아니라, 사용자가 어떻게 제품을 경험하는지를 설계하는 과정이다. 고객 경험의 문제를 정의하고 해결하는 데 있어서 디자이너는 독립적인 역할을 수행해야 한다. PM이 방향을 설정해주더라도, 실제 사용자 경험을 결정하는 것은 디자이너의 역할이다.
디자이너는 제품의 최종 비주얼을 담당하며, 이를 결정할 권한이 있다. PM의 역할은 디자인의 본질적인 목적을 이해하고 피드백하는 것이지, 단순한 선호를 강요하는 것이 아니다.
"이 버튼이 더 커야 할 것 같은데요?" ❌ "사용자들이 이 버튼을 쉽게 찾지 못한다고 피드백하는데 해결할 방법이 있을까요?" ✅
"예쁜 디자인"이 아니라 "이해하기 쉬운 인터페이스"를 만드는 것이 목표다. 심미성은 단순한 감각적 취향이 아니라, 사용자의 신뢰와 몰입도를 결정짓는 요소다. 감각적인 요소뿐만 아니라 브랜드 경험, 사용자 심리, 인지 부하 등을 고려해야 한다.
"이렇게 하는 게 더 예쁘지 않나요?" ❌ "이 요소가 사용자의 신뢰를 높이는 방향인가요?" ✅
디자이너는 네 가지 영역에서 오너십을 가져야 한다:
"실제 고객에게 어떤 가치가 전달되는가?"라는 질문에 대한 결과물을 만드는 사람은 디자이너다. 사용자의 니즈를 발견하고, 문제를 정의하는 과정에서 중요한 역할을 해야 한다.
디자이너의 고민이 실제 고객의 경험으로 연결된다. UX는 단순한 화면 구성이 아니라, 사용자의 행동을 유도하는 설계다. 크고 작은 차이들이 고객이 제품의 가치를 발견하고 말고를 결정한다. 디자이너는 UI 요소가 사용자 여정(Flow)과 일관되게 연결되도록 책임져야 한다.
디자이너는 실험을 통해 제품의 가능성을 테스트하는 사람이다. 개발 전에 제품의 모습을 예상할 수 있도록, 프로토타입을 만들어 리스크를 줄이는 역할을 한다. 프로토타이핑을 통해 개발자와 협업이 원활하게 진행될 수 있도록 조율해야 한다.
실제 제품이 출시되고 나서 고객이 어떻게 사용하는지에 따라 개선 방향이 결정된다. 사용자가 실제로 어떻게 반응하는지를 관찰하고, UI/UX 개선 방향을 설정하는 역할을 해야 한다. 감각적인 디자인이 아니라 데이터 기반의 피드백을 반영하여 지속적으로 개선하는 과정이 필요하다.
개발자는 PM의 든든한 해결사다. 제품팀이 상상하는 기능을 실제로 구현해 내는 역할을 하며, 전쟁으로 치면 실제 전투에 참여하는 역할이다. 개발자와 좋은 관계를 유지하는 것만큼 제품 성공에 힘이 되는 일이 없다.
특히 개선에 어려움이 있을 때 개발자에게 아이디어를 구하면 생각보다 쉽게 해결책을 찾을 수도 있다. 이는 개발자들이 시스템의 내부 구조를 가장 잘 이해하고 있기 때문이다.
현대의 소프트웨어 아키텍처는 Netflix의 시스템 설계도에서 볼 수 있듯이 매우 복잡하다. 이런 복잡한 시스템을 이해하고 최적화할 수 있는 것은 개발자뿐이다.
개발자도 디자이너와 마찬가지로 단순한 '요청 실행자'가 아니라, 제품을 현실화하는 전문가다. 세 가지 영역에서 자율성을 제공해야 한다:
일정이 촉박하거나 기술적 한계가 있을 경우, 개발자가 적절한 해결책을 찾을 수 있도록 해야 한다. 일정이 촉박해 개발이 어려운 경우 요구사항을 조정하는 것을 조율해야 한다.
"이거 구현 가능한가요?" ❌ "이번 출시 안에 이 기능을 어디까지 구현할 수 있을까요?" ✅
"어떤 기능을 개발해주세요"라고 말하면 용병팀이 되는 소통이다. 어떤 문제를 해결해야 하는지 정의하는 것은 PM의 역할이지만, 해결 방법을 찾는 것은 개발자의 역할이다. PM이 직접 해결책을 지시하기보다, 개발자들이 문제를 분석하고 최적의 방법을 제안하도록 해야 한다.
"이 기능을 추가해 주세요" ❌ "이런 경험을 설계해야 하는데 어떤 방법이 있을까요?" ✅
기능을 구현하는 순서를 정하는 것은 단순한 일정 관리가 아니다. 기술적 의사결정은 기술의 전문가가 해야 정확하다. 중요한 핵심 기능을 먼저 개발하고, 부수적인 기능을 나중에 다룰 수 있도록 조율해야 한다.
개발자는 네 가지 영역에서 오너십을 가져야 한다:
개발자가 제품 출시에 최선을 다하지 않으면 고객 가치를 만들 수 없다. 모든 개발 검토는 '구현 가능성'을 높이는 방향으로 고려되어야 한다. 단순히 "된다/안 된다"가 아니라, 최적의 방법과 현실적인 대안을 고려하는 역할을 맡아야 한다.
개발자는 단순히 주어진 기능을 구현하는 것이 아니라, 새로운 기술을 탐색하고 적용하는 역할을 수행해야 한다. 기술의 발전 속도가 빠르기 때문에, 제품이 뒤처지지 않도록 최신 기술을 연구하고 적절하게 도입하는 것이 중요하다. 단순한 기능 추가가 아니라, 장기적으로 확장 가능하고 유지 보수에 용이한 기술 스택을 고민해야 한다. 하지만 신기술을 도입한다고 해서 반드시 제품이 더 좋아지는 것은 아니다. 비즈니스 목표와 사용자의 요구를 고려한 도입이 필요하다.
소프트웨어에서 버그는 필연적이다. 하지만 버그는 종종 고객 경험에 치명적인 영향을 준다. 개발자가 자율적으로 버그를 관리하고, 장기적으로 발생할 수 있는 문제를 미리 해결할 책임이 있다. PM이 버그 해결을 강요하는 것이 아니라, 개발팀이 주도적으로 품질을 관리할 수 있도록 하는 것이 중요하다.
모든 시스템은 개발만큼 유지 보수에 많은 리소스가 필요하다. 하지만 이런 복잡한 시스템의 코드는 개발자만 접근할 수 있다. 단기적인 기능 개발만이 아니라, 장기적으로 유지보수가 가능한 코드 구조를 만드는 것이 중요하다. 개발자가 코드 품질을 책임지고 지속적으로 개선할 수 있도록 해야 한다.
그렇다면 PM이 모든 분야의 전문가가 아닐 때는 어떻게 해야 할까? PM은 "이해할 수 있을 만큼" 기술과 디자인에 대한 기초 지식을 가져야 한다. 개발자/디자이너와 신뢰 관계를 형성하는 가장 효과적인 방법은 "질문을 통한 학습"이다.
구체적인 방법은 다음과 같다:
질문을 통해 배운다: "이 개념이 고객에게 어떤 영향을 미칠까요?"
의사결정의 맥락을 공유한다: "우리가 해결하려는 문제는 이것인데, 어떤 접근이 좋을까요?"
전문성을 가진 팀원을 인정하고, 결정을 존중한다
단순히 "왜 이렇게 하나요?" 보다는 "이 방식이 고객 경험에 어떤 영향을 주나요?"라고 물어야 한다. "다른 방법도 있을까요?"라고 대안을 묻되, 해결책을 강요하지 않는다. 팀원들이 PM을 "방해 요소"가 아니라 "협업 파트너"로 인식하도록 만들어야 한다.
실제 상황에서 이런 접근법이 어떻게 작동하는지 보자. 한 PM이 개발팀과 새로운 기능에 대해 논의하고 있었다. 개발자가 "이 기능을 구현하려면 데이터베이스 구조를 전면 수정해야 해서 3개월이 걸립니다"라고 했다.
전문가가 아닌 PM이 할 수 있는 잘못된 반응:
"그럼 다른 방법으로 하면 안 되나요?" (구체적인 대안 없이 막연한 요구)
"3개월은 너무 길어요. 더 빨리 할 수 없나요?" (기술적 제약 무시)
"그냥 임시로라도 만들어주세요." (품질 희생 강요)
전문가가 아닌 PM이 할 수 있는 좋은 반응:
"데이터베이스 구조 수정이 필요한 이유를 좀 더 자세히 설명해주실 수 있을까요?"
"만약 이 기능의 핵심만 먼저 구현한다면 어느 정도 시간이 걸릴까요?"
"사용자 경험 측면에서 꼭 필요한 부분과 나중에 추가해도 되는 부분을 나눠볼 수 있을까요?"
이런 질문을 통해 PM은 기술적 세부사항을 모르더라도 전체적인 상황을 파악하고, 비즈니스 관점에서 최선의 결정을 내릴 수 있다.
한 스타트업에서 실제로 일어난 일이다. 새로운 결제 시스템을 도입하는 프로젝트였다. 초기 기획에서는 단순히 "더 빠른 결제"가 목표였다.
기존 방식 (용병팀 스타일):
PM: "결제 속도를 2초로 단축해주세요"
개발자: "기술적으로 어렵습니다. 최소 5초는 걸려요"
디자이너: "그럼 로딩 애니메이션을 예쁘게 만들어서 기다리는 시간을 덜 지루하게 하죠"
결과: 기술적으로는 구현했지만 사용자 만족도는 여전히 낮음
실제로 적용한 방식 (미션팀 스타일):
PM: "사용자들이 결제할 때 느끼는 불안감을 줄이려면 어떻게 해야 할까요?"
개발자: "결제 속도보다는 진행 상황을 실시간으로 알려주는 게 더 중요할 것 같은데요. 각 단계별로 피드백을 줄 수 있어요"
디자이너: "사용자 인터뷰를 해보니까 속도보다는 '정말 결제가 완료됐는지' 확신이 안 선다는 피드백이 많았어요. 명확한 완료 피드백이 더 중요할 것 같아요"
결과: 결제 속도는 그대로였지만 사용자 만족도가 40% 상승
이 사례에서 중요한 것은 PM이 구체적인 해결책을 제시한 것이 아니라, 해결해야 할 문제를 명확히 정의한 것이다. 그리고 각 전문가가 자신의 영역에서 최선의 방법을 찾도록 했다.
반대로 실패하는 경우도 보자. 같은 회사에서 다른 프로젝트에서 일어난 일이다.
실패 사례:
PM: "경쟁사가 AI 챗봇을 도입했으니까 우리도 만들어야 해요"
개발자: "어떤 기능을 하는 챗봇인가요?"
PM: "일단 만들어보고 나중에 정하죠. 경쟁사 것과 비슷하게"
디자이너: "사용자가 언제 챗봇을 사용하게 할 건가요?"
PM: "그것도 나중에 정하고, 일단 예쁘게 만들어주세요"
결과: 3개월 후 챗봇은 완성됐지만 아무도 사용하지 않았다. 고객이 해결하고 싶은 문제가 무엇인지, 챗봇이 그 문제를 어떻게 해결할 수 있는지에 대한 명확한 비전이 없었기 때문이다.
결국 PM의 전문성은 특정 기술이나 도구에 대한 깊은 지식이 아니라, 고객 가치, 비즈니스, 프로덕트라는 세 축을 연결하고 조율하는 능력에 있다. 이를 위해서는 각 분야의 전문가들과 효과적으로 소통할 수 있는 '이해'의 수준이 필요하다.
디자이너와 개발자가 최고의 역량을 발휘할 수 있도록 자율성을 보장하되, 그들이 같은 목표를 향해 나아갈 수 있도록 방향을 제시하는 것. 그리고 끊임없이 질문하고 학습하며, 전문가들의 의견을 존중하면서도 고객 가치라는 북극성을 잃지 않는 것. 이것이 바로 지식으로 소통하는 PM의 모습이다.
처음 회의에서 당황했던 김영수도 이제 알 것이다. PM이 모든 걸 다 알 필요는 없다는 것을. 대신 모든 것을 연결하고, 팀원들이 최고의 역량을 발휘할 수 있는 환경을 만드는 것이 진짜 PM의 역할이라는 것을.
6개월이 지난 지금, 영수는 개발 용어나 디자인 이론을 완벽하게 이해하지는 못한다. 하지만 팀원들과 효과적으로 소통하고, 함께 더 나은 제품을 만들어가고 있다. 그에게 필요했던 것은 모든 지식이 아니라, 연결하는 능력이었다.
"지식으로 소통한다"는 것은 결국 모든 것을 아는 것이 아니라, 서로 다른 전문성을 가진 사람들이 하나의 목표를 향해 나아갈 수 있도록 다리를 놓는 것이다. 그리고 그 다리 위에서 진정한 혁신이 일어난다.
현 부지런컴퍼니 COO 겸 PM
PM 부트캠프 강사, 비즈니스 & 커리어 코치
10여년간 스타트업부터 대기업까지 다양한 환경에서 사업 경험을 쌓았으며, 현재는 PM들이 실무에서 바로 활용할 수 있는 지식과 노하우를 체계적으로 정리하고 전달하는 일에 집중하고 있습니다.
문의: fineday9@hanmail.net
더 많은 PM 인사이트: https://brunch.co.kr/magazine/pmbible
LinkedIn: https://www.linkedin.com/in/thkim9/
PM 바이블 시리즈가 도움이 되셨다면 주변에 다른 분들께도 많이 공유해주세요!