[TIL] 실무에서 PM이 겪는 문제와 커뮤니케이션

오늘 학습 키워드  
- PM의 핵심 역량(문제 정의, 비즈니스적 사고, 가설 검증 능력)  
- 제약 속 의사결정과 영향력  
- 설득력과 커뮤니케이션의 원칙  
- 요청/협업/설득/회의의 구체적 실천 방법 및 주의점

배운 점

PM이 되고 싶은 가장 큰 이유는 다양한 사람과 협업하며 의미 있는 결과를 만들어내는 과정에서 보람을 느끼기 때문이다. PM에게 필요한 역량은 단순 기획에 그치지 않고, 1) 사용자의 불편을 발견하고 진짜 문제를 정의하는 능력, 2) 해당 기능이 비즈니스에도 이익이 되는지 판단하는 비즈니스 마인드, 3) 빠르게 가설을 세우고 실행·검증하는 역량, 이 세 가지라는 점을 다시 한 번 정리했다.

PM의 역할은 화려한 아이디어맨이 아니라, 현실의 다양한 제약(일정, 리소스, 전략 등) 속에서 명확한 문제를 정의하고, 실현 가능한 안을 만들어내는 실천가임을 배웠다. 늘 “왜 이 기능·서비스가 필요한가?”를 질문하고, 실제로 해결해야 할 문제에만 집중해야 한다.

PM은 공식 리더(상사, 매니저)가 아니라 팀원 중 한 역할일 때가 많다. 명령이 아닌 설득과 조율, 커뮤니케이션을 통해 자연스럽게 영향력을 쌓아야 한다. 이를 위해선 논리적 근거(특히 데이터 기반)와 다양한 직군(개발, 디자인 등)별 맞춤 언어로 설명·설득하는 능력이 중요하다. 각 직군의 기본적 지식(디자인, 개발 등)도 갖추고, 단순히 전달이 아닌 이해·공감·납득이 되는 소통을 해야 한다.

내가 사용자가 아닌 제품을 담당할 땐(사용해 본 적이 없음), 직접 사용자가 되어 현장에서 경험하거나, 사용자와 가장 가까운 내부 동료(세일즈, 운영, CX 등)에게 적극적으로 도움을 구하는 것이 현실적 해결책임을 배웠다. 팀 내 리딩 경험을 쌓으려면 먼저 작은 일이라도 주도적으로 해보고, 절대로 “나만큼 남들도 안다”는 착각을 경계하라는 점도 새겼다.

효과적인 커뮤니케이션의 원칙으로  
1) “상대방의 니즈 파악”: 상대 입장에서, 그들이 원하는 방식과 정보로 전달, 바쁜 사람에게는 결론부터 이야기하기.
2) “빌드업”: 동의를 자연스럽게 끌어내는 구조(결정 통보 X, 미리 정보공유와 논리축적 O),  
3) “크로스체크”: 내가 의도한 바가 전달되었는지 역확인이 필요하다는 것을 정리했다.  

요청을 할 때, 단지 내 입장이 아니라 상대가 필요로 하는 정보를 미리 주고(미끼), 그냥 일만 부탁하지 말고 “왜 이게 필요하고 어떤 가치를 주는지(배경)”까지 설명해야 한다.  요청을 할때는 갑자기 요청한다기 보다, 언제쯤 요청이 들어갈 수 있다는것을 미리 공유해준다면 상대방이 업무 계획을 세울 수 있도록 여유를 주고 요청을 예고하여 혼란을 방지한다. 보고를 할때는 내가 말하고 싶은것보다 상대방이 듣고 싶은 또는 필요로 하는 정보 위주로 공유해야한다.

역으로 요청 받을 때는 표면 요청·지시의 “진짜 목적”을 파악하고, 무작정 다 받아주지 말고 우선순위를 따져 타협하거나 대안을 제안해야 한다.

설득(협상)의 핵심 역시, “상대방(개발자, 디자이너, 마케터 등)이 이것을 하면 실제로 어떤 이득이 있는지” 명확하게 제시해야 한다는 것이다. 또한 협상 과정은 급하지 않게, 단계별로 신뢰를 쌓으며 진행해야 한다는 점도 중요하다. 단순히 내 의견을 관철시키는 과정이 아니라 상대방도 이렇게 함으로써 긍정적인 영향을 미칠 수 있음을 보여주여한다!

비효율적 회의(목표/준비/진행/결론 없는 회의)의 위험성, 회의보다는 이메일/메시지 등으로 대체 가능하면 과감하게 대체하거나 회의 목적이 명확할 때만 진행해야 한다는 점도 알게 됐다.

학습하며 겪었던 궁금해서 다시 찾아본 것

PM이 설득할때 개발자, 디자이너, 마케터가 “이득”을 보는 케이스는?  
- 개발자 : 반복/귀찮고 불필요한 작업이 줄어들거나, 더 좋은 코드 품질이나 성장 기회를 얻을 때, 자신의 노력으로 실제 임팩트가 나오는 것을 볼 때
- 디자이너 : 본인의 의도가 실제 사용자 경험에 반영될 때, 결과물이 사용자나 시장에서 인정받을 때, 포트폴리오에 남길 의미 있는 사례가 될 때
- 마케터 : 새로운 시도와 캠페인으로 더 좋은 비즈니스 성과(전환·매출 등)를 내거나 브랜드 이미지를 향상시킬 때

개발자/디자이너와 과제 우선순위·일정 협상은?  
- 왜 이 과제가 지금 중요한지(비즈니스 임팩트, 고객 영향), 무얼 먼저/나중에 해야 하는지 논리적으로 설명하고, 일정에 여유나 지원이 필요한 부분이 있으면 함께 조율·지원 약속을 한다.

개발자/디자이너와 구현 방식 협상은?  
- 실현방식(난이도, 리스크, 리소스)을 객관적으로 듣고, PM이 기술/디자인적 이해를 바탕으로 현실적 제안을 하거나, 대체방안을 찾거나, 우선 MVP로 절충하는 방법이 있다.

디자이너에게 유저 피드백을 반영한 방향 제안법은?  
- 주관 아닌 데이터(실제 사용자 피드백, 사용성 테스트 결과)를 제시해서 논리적인 설득을 진행하고, 기존 디자인의 장점을 인정해주면서 “더 나은 사용자 경험”에 초점을 맞춰 대화한다.

오늘 가장 인상 깊었던 핵심은, PM에게 가장 중요한 역량은 바로 커뮤니케이션이라는 점이었다. 단순히 정보를 주고받는 수준을 넘어, 커뮤니케이션은 결국 '설득의 과정'이였다. 설득을 잘하기 위해서는 상대방이 왜 그런 결론에 도달했는지를 이해하려는 태도, 즉 역지사지의 관점이 필요하다. 상대의 입장에서 사고하고, 그 인식의 차이를 좁혀가는 과정이 진정한 커뮤니케이션이다. 

나 역시 수많은 회의를 경험해왔지만, 오늘처럼 이상적인 커뮤니케이션이 회사 생활 속에서 이루어졌다면 갈등 없이 일들이 훨씬 더 원활하게 흘러갔을 것이라는 생각이 들었다. 그동안의 나의 커뮤니케이션 방식, 그리고 리더의 소통 방식에도 분명한 문제점이 있었음을 되돌아보게 되었고, 앞으로는 같은 실수를 반복하지 말아야겠다고 다짐했다!