새로운 제품을 맡은 PM이 가장 먼저 해야 할 일
365 Proejct (355/365)
기사/인터넷을 보고 생각 정리하기 029: 달리기로 배운 성장의 법칙 을 읽고
기사/인터넷을 보고 생각 정리하기 030: 1년도 못 버티고 줄줄이... 를 읽고
기사/인터넷을 보고 생각 정리하기 031: 과부하에 빠진 조직을 구하기 를 읽고
이해관계자를 파악하고 대화하기
새로운 팀에 합류했거나, 기존과는 다른 새로운 제품을 맡게 된 PM은 보통 비슷한 첫날을 맞이한다. Slack 채널에 초대되고, Notion 문서 링크를 몇 개 받는다. 그리고 “일단 이것저것 보면서 파악해보세요”라는 말을 듣는다.
처음 며칠 동안은 문서를 읽고 채널을 따라가면서 전체 그림을 그리려고 노력한다. 그런데 시간이 지날수록 묘한 위화감이 생긴다. 같은 질문을 여러 사람에게 했는데 대답이 다르다. 우선순위가 분명하지 않다. 누가 최종 의사결정권자인지 애매하다. 그리고 무엇보다, 사람들이 어떤 주제에 대해서는 노골적으로 대화를 피하고 있다는 느낌이 든다.
이 지점에서 많은 PM이 하는 첫 번째 실수는 “그래도 PM이니까 빨리 결과물을 내야 한다”는 압박에 스스로를 몰아넣는 것이다. 서둘러 기획서를 쓰고, 로드맵을 만들고, 킥오프 회의를 잡는다. 뭔가 일을 벌이면 ‘일하고 있는 느낌’은 들지만, 이런 접근은 대부분 문제를 해결하기보다는 더 악화시킨다. 이미 왜곡된 이해와 엇갈린 기대 위에 또 다른 산을 쌓는 셈이기 때문이다.
새로운 제품을 맡은 PM의 첫 번째 임무는 문서를 만드는 것이 아니다.
가장 먼저 해야 할 일은 이 제품을 둘러싼 사람들을 파악하고, 그들과 제대로 대화하는 것이다.
1단계: 첫 일주일, 이해관계자 지도를 그린다
처음 1주는 “아는 척”하지 않고, 철저히 관찰자 모드로 들어가야 한다. 이 시기의 목표는 제품 기능이나 로드맵이 아니라, “이 제품을 둘러싼 사람들의 구조”를 이해하는 것이다.
가장 먼저 파악해야 할 것은 누가 의사결정을 하는 사람인지다. 직함상 리더와 실제로 “이건 안 됩니다”라고 말할 수 있는 사람은 다를 수 있다. 예산과 리소스를 쥐고 있는 사람, 우선순위를 최종적으로 조정하는 사람, 조직의 방향을 바꾸는 말을 할 수 있는 사람이 누구인지 하나씩 확인해야 한다.
다음으로, 실제로 손을 움직이는 사람들이 누구인지 살펴본다. 디자이너, 개발자, 데이터 분석가 같은 실행 주체들 중, 없으면 일이 아예 멈추는 핵심 병목 인물이 있다. 코드나 디자인만이 아니라, “의미 있는 진척”이 그 사람을 통해서만 일어나는 경우가 많다. 이 사람의 상황을 이해하지 못하면, 일정이나 계획은 금방 공허해진다.
또 하나 중요한 축은 고객과 가장 가까이 붙어 있는 사람이다. CS 팀, 세일즈 팀, 온보딩 담당자, 혹은 직접 고객 인터뷰를 담당하는 누구일 수도 있다. 이들의 말 속에 제품이 실제로 어떻게 쓰이고 있는지, 고객이 어떤 언어로 이 제품을 설명하는지, 어떤 지점에서 이탈하고 다시 돌아오는지가 숨어 있다.
조직에는 공식적인 권한과 별개로, 분위기와 정서를 좌우하는 사람도 있다. 직함은 높지 않지만 모두가 눈치를 보는 사람, 회의에서 한마디 툭 던지면 공기가 바뀌는 사람, 신입이 누구에게 먼저 고민을 털어놓는지를 보면 보이는 사람들이다. 이런 사람의 감정이 제품 추진력에 직간접적인 영향을 미친다. 이들을 무시한 채 프로세스만 손보면, 문서에서는 깔끔하지만 실제로는 잘 돌아가지 않는 구조가 된다.
마지막으로, 누구와 누구 사이에 갈등이나 회피가 존재하는지도 살펴봐야 한다. PM과 개발자 사이의 불신, 팀 간 우선순위 충돌, 과거 실패한 프로젝트의 기억이 만들어낸 조심스러운 태도 등은 공식 회의록에는 등장하지 않는다. 하지만 Slack에서 누가 누구를 잘 태그하지 않는지, 회의에서 누가 말을 아끼는지, 중요한 의사결정 직전에 어떤 채널이 조용해지는지 등을 보면 조금씩 윤곽이 드러난다.
이해관계자 지도를 그리는 방법은 거창한 게 아니다. 회의에 참석해 누가 누구의 말을 따르는지 관찰하고, Slack에서 질문이 오갈 때 흐름을 추적하고, 짧은 대화를 통해 사람들의 표정을 읽는 정도면 충분하다. 이 첫 주의 관찰이 이후 모든 결정의 바탕이 된다.
2단계: 1:1 대화로 신뢰를 쌓는다
이해관계자들의 얼굴과 이름, 역할의 윤곽이 잡히면, 이제 각 사람과 1:1 대화를 시작할 차례다. 이 대화의 목적은 정보 수집이 아니다. “이 PM과는 솔직한 이야기를 해도 된다”는 감각을 심어주는 것, 즉 신뢰 구축이다.
개발자와 디자이너에게는 주로 일의 난이도와 감정이 교차하는 지점을 묻는 것이 좋다. 지금 이 제품에서 기술적으로 가장 까다로운 부분이 무엇인지, 과거에 PM의 요구가 비현실적이라고 느낀 적이 언제였는지, 개발이나 디자인 과정에서 가장 스트레스를 받는 순간이 언제인지, 이 제품이 정말 성공하려면 무엇이 바뀌어야 한다고 생각하는지 등을 차분히 들어본다.
리더에게는 제품의 성공 정의와 우려를 묻는 것이 중요하다. 이 제품이 잘 됐다고 말하려면 어떤 상태가 되어야 하는지, 현재 가장 걱정되는 포인트가 무엇인지, 새로 온 PM으로서 가장 먼저 해결해야 할 문제를 무엇이라고 보는지, 그리고 PM이 독단적으로 결정해도 되는 범위와 반드시 상의해야 하는 영역이 어디인지 명확히 물어본다. 여기서 들은 답은 이후 의사결정의 레일 역할을 한다.
고객 접점에 있는 사람들과의 대화에서는 실제 사용 맥락에 집중해야 한다. 고객이 가장 자주 불만을 제기하는 부분이 어디인지, 반대로 가장 좋아한다고 말하는 기능은 무엇인지, 겉으로 드러난 기능 설명과는 별개로 고객이 이 제품을 쓰는 진짜 이유가 무엇이라고 느끼는지 물어본다. 이들은 수많은 실제 케이스를 접하기 때문에 “현실의 제품”을 알고 있다.
팀 내 영향력이 큰 사람에게는 조직의 공기와 숨겨진 이야기들을 묻는다. 이 팀의 분위기가 어떤지, 과거에 잘 안 풀렸던 프로젝트가 있다면 왜 그렇게 됐다고 보는지, 지금 팀 안에서 말하고 싶지만 말하지 못하는 주제가 있다면 무엇인지 등을 조심스럽게 여쭤본다.
이 모든 1:1 대화에서 중요한 원칙은 세 가지다.
첫째, 판단하지 않고 듣기만 한다. “그건 아닌 것 같은데요”라는 말은 입 밖으로 내지 않는다. 이해하지 못하겠다면 “그게 어떤 상황이었는지 조금 더 설명해주실 수 있을까요?”라고만 한다.
둘째, 즉각적인 해결책을 제시하지 않는다. “제가 당장 해결하겠습니다”라는 약속은 신뢰를 얻는 대신 기대와 부담만 키운다. “이 부분은 제가 더 파악해보고 다시 말씀드릴게요” 정도가 적절하다.
셋째, 대화를 일회성으로 끝내지 않는다. “다음 주쯤 다시 이 이야기 이어가도 될까요?”, “이 이슈는 제가 진행 상황을 따로 공유드릴게요”라고 말하며, 관계를 한 번의 인터뷰가 아니라 이어지는 대화의 시작으로 만든다.
3단계: 숨겨진 문제를 표면으로 끌어올린다
1:1 대화를 몇 주 쌓다 보면, 공식 문서나 회의에서는 드러나지 않지만 거의 모든 사람이 알고 있는 문제들이 하나씩 보이기 시작한다. 누구도 공개적으로 말하지 않을 뿐, 모두가 느끼고 있는 불편함들이다.
예를 들어, 데이터 파이프라인이 불안정해서 내부에서도 지표를 신뢰하지 못하고 있다거나, 특정 의사결정자의 결정을 기다리느라 일정이 계속 밀린다거나, 고객이 실제로는 거의 쓰지 않는 기능을 리더가 고집해서 계속 자원이 투입되고 있다거나, PM이 요구사항을 자주 바꿔서 개발자들이 지쳐 있다는 식의 이야기들이다. 이런 것들은 정식 안건으로 올리기엔 위험하고, 그렇다고 아무도 모르는 것도 아닌 애매한 영역에 놓여 있다.
PM이 1:1에서 “안전한 대화 상대”라는 인식을 얻으면, 이런 이야기들이 조금씩 밖으로 나온다. 이때 PM의 역할은 누군가를 고발하거나 책임을 묻는 것이 아니라, 이 문제들을 **“공개적으로 이야기해도 되는 주제”**로 승격시키는 것이다.
이를 위해 작은 단위의 회의를 소집할 수 있다. “지난 2주 동안 여러분과 대화하면서 공통적으로 반복되는 이슈 몇 가지를 발견했다”는 말로 시작해, 그 내용을 중립적인 언어로 정리해 공유한다. 이때 표현은 최대한 시스템 관점이어야 한다. “누가 잘못했다”가 아니라 “우리 프로세스에 이런 병목이 있다”, “이 흐름이 이렇게 설계되어 있어서 여기가 자주 막힌다”와 같은 식이다. 이렇게 프레이밍하면 방어적 반응이 줄어든다.
그리고 해결책을 혼자 제시하기보다는 “이걸 어떻게 하면 좋을까요?”라고 던진다. 사람들이 스스로 개선 아이디어를 내게 만들고, PM은 그 아이디어들이 실제 행동으로 옮겨지도록 정리하고 순서를 잡는 역할을 맡는다. 문제를 알아서 가져와서 해결해주는 사람이 아니라, 모두가 알고 있던 문제를 안전하게 테이블 위로 올리고 함께 해결하도록 판을 깔아주는 사람에 가깝다.
4단계: 작지만 분명한 승리를 만들어낸다
문제들이 표면화되고, 사람들 사이에 약간의 신뢰가 생겼다면, 이제 조직이 “어, 뭔가 달라지고 있네?”라고 느낄 수 있는 작은 변화를 만들어야 한다. 이때 필요한 것은 큰 전략 문서나 화려한 로드맵이 아니다. 바로 체감되는 변화, 작은 승리다.
예를 들어, 모두가 귀찮아하지만 관성 때문에 계속 열리고 있던 회의 하나를 정리하고, 이를 짧은 Slack 업데이트나 비동기 문서로 대체할 수 있다. 여럿이 불만을 갖고 있던 우선순위 혼선을 정리해, 이번 분기에는 이 세 가지에만 집중하고 나머지는 과감히 백로그로 미루는 결정을 내릴 수도 있다. 디자인 리뷰나 QA 같은 프로세스의 단계를 줄여, 2일 걸리던 리뷰를 1일로 줄이는 식으로 흐름을 가볍게 만들 수도 있다.
또는 CS 팀이나 세일즈 팀이 계속 이야기하던 고객 불편 포인트 중, 비교적 빠르게 고칠 수 있는 작은 항목 하나를 잡아 단기간에 개선하고, 그 결과를 당사자들과 함께 공유하는 것도 좋은 방법이다. “우리가 말한 것이 실제로 바뀌었다”는 경험은 그 어떤 프레젠테이션보다 강력하다.
이런 작은 승리들이 몇 번 쌓이면 조직은 PM을 “문서를 잘 쓰는 사람”이 아니라, “실제로 상황을 조금씩 나아지게 만드는 사람”으로 보기 시작한다. 그때부터는 더 큰 논의, 더 어려운 주제도 PM을 매개로 꺼낼 수 있게 된다.
5단계: 일하는 방식을 함께 정의한다
어느 정도 신뢰가 생기고 작은 성과들이 보이기 시작하면, 이제야 비로소 “우리가 앞으로 어떻게 일할 것인가”를 이야기할 수 있다. 이것은 멋있는 선언문을 만드는 작업이 아니라, 실제 행동을 이끌어내는 원칙을 세우는 일이다.
우선 의사결정 원칙을 명확하게 정리할 수 있다. 어떤 결정은 PM이 단독으로 해도 되는지, 어떤 결정은 팀이 함께 논의해야 하는지, 어떤 결정은 리더의 승인을 반드시 필요로 하는지 경계를 그어두면, 사소한 일마다 줄줄이 보고하고 기다리는 낭비가 줄어든다.
소통 방식에 대한 원칙도 필요하다. 정말 긴급한 이슈는 Slack DM이나 전화로, 중요하지만 시급하지 않은 일은 이슈 트래킹 도구나 문서로, 깊은 논의가 필요한 건 정해진 회의를 통해 다루는 식으로 기본 룰을 만드는 것이다. 회의에서는 가능한 한 “결정을 내리는 것”에 집중하고, 논의와 정보 수집은 사전에 문서로 공유해두는 방식이 이상적이다.
우선순위 원칙은 제품 방향을 지탱하는 뼈대가 된다. 이번 분기의 목표가 무엇인지, 이 목표와 무관한 일은 웬만하면 하지 않는다는 합의를 만든다. 외부 요청이나 “이것도 하면 좋지 않을까?” 류의 아이디어가 들어올 때 어떤 기준으로 수용·거절·보류를 판단하는지도 함께 정리해야 한다.
마지막으로 피드백 원칙을 분명히 해야 한다. 문제가 생겼을 때 최대한 빨리 말하는 것이 모두에게 이롭다는 감각, 비판은 환영하지만 가능하면 대안과 함께 이야기해달라는 기대치를 공유하는 것이다. 물론 이 모든 원칙은 PM이 먼저 지켜야 힘을 갖는다. 본인은 예외인 규칙은 아무도 진지하게 받아들이지 않는다.
PM은 기획자가 아니라 정렬자다
새로운 제품을 맡은 PM의 역할을 한 문장으로 요약하면, PM은 기획서를 생산하는 사람이 아니라 정렬자(aligner)라는 것이다.
개발자가 “내가 지금 무엇을, 왜 만드는지”를 명확히 알게 만드는 사람, 디자이너가 “이 디자인이 어떤 문제를 해결하려는 것인지”를 이해하게 만드는 사람, 리더가 “이 제품에서 무엇을 기대할 수 있는지, 무엇은 기대하면 안 되는지”를 분명히 알게 만드는 사람, 고객이 “이 제품을 통해 어떤 가치를 얻을 수 있는지”를 깨닫도록 돕는 사람이 바로 PM이다.
그리고 이 모든 정렬의 출발점은 결국 문서가 아니라 대화다.
로드맵이 아니라 신뢰에서 시작된다.
프로세스가 아니라 사람에서 출발한다.
새로운 제품을 맡게 된 PM이라면, 무엇을 만들지 고민하기 전에 먼저 “누구와 어떻게 이야기할 것인가”를 스스로에게 물어야 한다. 거기서부터 진짜 일이 시작된다.
