오늘은 PM의 핵심 역량 중 하나인 **이해관계자 관리(Stakeholder Management)**에 대해 이야기해볼게. PM은 비즈니스, 기술, 디자인의 교차점에 서 있는 사람이라 다양한 부서의 요구사항을 조율하는 게 일상이거든. 이 관계를 어떻게 관리하느냐에 따라 제품의 성패는 물론, 너의 업무 스트레스 지수도 완전히 달라지게 될 거야.
1. 누가 진짜 의사결정자일까? 이해관계자 매핑하기
실무에 들어가면 개발자, 디자이너뿐만 아니라 마케팅, 영업, 법무, 그리고 C-Level까지 정말 많은 사람을 만나게 돼. 이 모든 사람의 요구사항을 똑같은 가중치로 받아들이면 몸이 열 개라도 모자라거든. 그래서 필요한 게 바로 **이해관계자 매핑(Stakeholder Mapping)**이야.
- 영향력과 관심도를 기준으로 사분면을 그려봐.
- 영향력도 높고 관심도도 높은 C-Level이나 주요 파트너는 밀착 마크하며 긴밀하게 소통해야 해.
- 관심도는 낮지만 영향력이 높은 법무나 보안 팀은 이슈가 생기지 않도록 진행 상황을 주기적으로 공유하는 수준으로 관리하는 거지. 내가 10년 동안 PM으로 일하면서 느낀 건, 이 맵을 머릿속에 명확히 그리고 움직여야 커뮤니케이션 리소스를 획기적으로 줄일 수 있다는 점이야.
2. 요구사항을 그대로 전달하는 '메신저'가 되지 마라
초보 PM들이 가장 많이 하는 실수가 있어. 현업 부서에서 "이 기능 만들어주세요"라고 하면 그대로 개발팀에 토스하는 거지. 이러면 개발팀에서는 "이걸 왜 해야 하죠?"라는 반응이 나오고, 결국 양쪽에서 치이게 돼.
우리는 단순한 메신저가 아니라 **조율자(Facilitator)**가 되어야 해. 이해관계자가 요구하는 Feature 뒤에 숨겨진 '진짜 문제(Problem)'가 무엇인지 먼저 파악해봐. 그리고 제품의 KPI나 비즈니스 목표에 어떻게 기여하는지 데이터로 이야기해야 해. 소통할 때는 슬랙이나 노션 같은 공유 채널을 활용해 기대치(Expectation)를 미리 동기화해두는 것이 아주 중요해.
3. 모두를 만족시킬 순 없다, 우아하게 거절하는 기술
모든 이해관계자의 요구를 들어주다 보면 제품은 결국 정체성을 잃고 산으로 가게 되어 있어. 이때 필요한 게 바로 객관적인 우선순위(Prioritization) 기준이야.
나는 실무에서 RICE 점수 모델(Reach, Impact, Confidence, Effort)이나 MoSCoW 분석 기법을 자주 활용하거든. 객관적인 프레임워크를 바탕으로 "이번 스프린트에는 리소스 한계로 이 기능은 백로그로 이동합니다"라고 논리적으로 설명해봐. 거절할 때는 그냥 "안 돼요"가 아니라, "지금은 A에 집중하고, B는 다음 분기에 검토하겠습니다"처럼 대안과 타임라인을 함께 제시하는 것이 신뢰를 유지하는 비결이야.
💡 핵심 정리
- 이해관계자 매핑: 영향력과 관심도에 따라 소통 전략 다르게 가져가기
- 문제 정의 우선: 요구사항 뒤에 숨겨진 진짜 문제를 파악하고 조율하기
- 논리적 거절: 객관적인 우선순위 프레임워크를 활용해 대안 제시하기 처음에는 다양한 부서의 목소리를 조율하는 게 참 어렵고 무섭게 느껴질 수 있어. 하지만 이 과정을 거치면서 제품이 올바른 방향으로 나아갈 때 PM으로서 가장 큰 보람을 느끼게 될 거야. 기죽지 말고 단단하게 소통해봐, 늘 응원할게!